Actually CHIP_MEM_SYS_START(v) seems a physical address per *_mem_map()
function, but I don't think mmap() function should return K0SEG address
(it should return PA cookie IIUC) so I guess there is something wrong
in Titan's bus space functions. I'll investigate them later.
I haven't studied the code, but I'm concerned that not initializing
sf->sf_edi could potentially leak a few bytes of information to a new
userspace process.
Stop unwinding frames when db_stack_trace_print() encouters
Xsoftintr(). This avoids a recursive panic() due to an invalid
pointer dereference when a software interrupt panic()s.
Here's what happens without this change:
When db_stack_trace_print() runs during a panic() and db_nextframe()
encounters the Xsoftintr() frame, db_nextframe() does the following at
db_machdep.c:292:
1. checks to see if there's a Xsoftintr() symbol (there is)
2. checks to see if the frame corresponds to an interrupt (the
symbol name begins with "Xsoft" so it does)
If both of the above are true (they are), db_nextframe() at
db_machdep.c:303 tries to get a pointer to a struct intrframe.
According to the comment at line 300, the second argument passed to
Xsoftintr() is a pointer to a struct intrframe. However, the comment
and the corresponding code are not correct -- Xsoftintr() doesn't take
any arguments[1]. Attempting to fetch the second argument only yields
stack garbage, not a struct intrframe. This causes db_machdep.c:307
to dereference a bad pointer, triggering the recursive panic().
[1] Xsoftintr() is called by Xspllower() which is called by splx()
a.k.a. spllower(). Neither Xspllower() nor Xsoftintr() set up a
standard frame when called (they don't do 'pushl %ebp; movl %esp,
%ebp'), so Xsoftintr()'s %ebp is the same as splx()'s %ebp. This
makes splx()'s arguments look like Xsoftintr()'s arguments, and
splx() does not take any arguments.
You can reproduce the recursive panic by reverting this change and
adding a call to panic() inside ipintr(). The backtrace will look
like the following (the line numbers you see might differ from these
line numbers -- this backtrace was generated from a slightly modified
version of the NetBSD 6.1 kernel):
#0 vpanic (fmt=0xc0ba995b "trap", ap=0xdaa51730) at /usr/src/sys/kern/subr_prf.c:211
#1 0xc0790529 in panic (fmt=0xc0ba995b "trap") at /usr/src/sys/kern/subr_prf.c:205
#2 0xc07decbc in trap (frame=0xdaa517c0) at /usr/src/sys/arch/i386/i386/trap.c:396
#3 0xc010cf48 in ?? () at /usr/src/sys/arch/i386/i386/vector.S:983
#4 0xc02857f0 in db_get_value (addr=56, size=4, is_signed=false) at /usr/src/sys/ddb/db_access.c:72
#5 0xc028a09a in db_nextframe (nextframe=0xdaa51b40, retaddr=0xdaa51b3c, arg0=0xdaa51b38, ip=0xdaa51b34, argp=0xdaa51d88, is_trap=0, pr=0xc07901b5 <printf>) at /usr/src/sys/arch/i386/i386/db_machdep.c:308
#6 0xc028be2b in db_stack_trace_print (addr=<optimized out>, have_addr=true, count=65533, modif=0xc0bb44bf "", pr=0xc07901b5 <printf>) at /usr/src/sys/arch/x86/x86/db_trace.c:275
#7 0xc07903cb in vpanic (fmt=0xc0b6ba76 "testing", ap=0xdaa51d4c) at /usr/src/sys/kern/subr_prf.c:296
#8 0xc0790529 in panic (fmt=0xc0b6ba76 "testing") at /usr/src/sys/kern/subr_prf.c:205
#9 0xc04e3d4f in ipintr () at /usr/src/sys/netinet/ip_input.c:369
#10 0xc054ac0d in softint_execute (s=<optimized out>, si=<optimized out>, l=<optimized out>) at /usr/src/sys/kern/kern_softint.c:543
#11 softint_dispatch (pinned=0xc4085560, s=4) at /usr/src/sys/kern/kern_softint.c:825
#12 0xc0100fdb in ?? () at /usr/src/sys/arch/i386/i386/spl.S:390
#13 0xc07d2e11 in tcp_usrreq (so=0xc40b0534, req=4, m=0x0, nam=0xc317ba00, control=0x0, l=0xc4085560) at /usr/src/sys/netinet/tcp_usrreq.c:615
#14 0xc04bb300 in tcp_usrreq_wrapper (a=0xc40b0534, b=4, c=0x0, d=0xc317ba00, e=0x0, f=0xc4085560) at /usr/src/sys/netinet/in_proto.c:164
#15 0xc0839006 in soconnect (so=0xc40b0534, nam=0xc317ba00, l=0xc4085560) at /usr/src/sys/kern/uipc_socket.c:821
#16 0xc083c4ce in do_sys_connect (l=0xc4085560, fd=4, nam=0xc317ba00) at /usr/src/sys/kern/uipc_syscalls.c:371
#17 0xc083dbeb in sys_connect (l=0xc4085560, uap=0xdbc27d00, retval=0xdbc27d28) at /usr/src/sys/kern/uipc_syscalls.c:350
#18 0xc07b1b4a in sy_call (rval=0xdbc27d28, uap=0xdbc27d00, l=0xc4085560, sy=0xc0c2f018) at /usr/src/sys/sys/syscallvar.h:61
#19 syscall (frame=0xdbc27d48) at /usr/src/sys/arch/x86/x86/syscall.c:179
#20 0xc010056d in ?? () at /usr/src/sys/arch/i386/i386/locore.S:1160
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
This line was introduced with a call to printk() in CVS revision
1.22.4.3 and should have been removed when the call to printk() was
removed in CVS revision 1.22.4.6. (Richard Hansen)
Bootloader side changes:
- make boot command parse boothowto flags (-ads etc.)
- pass boothowto and bootdev info to the kernel via %d7 and %d6
as the old 4.4BSD/luna68k kernel expected
- remove unused and now unnecessary "howto" (how_to_boot) command
- export and tweak make_device() in devopen.c to prepare bootdev info
- remove unused and commented out get_boot_device()
Kernel side changes:
- use %d7 (boothowto) and %d6 (bootdev) to pass info and also use
old macro in <sys/reboot.h> as ancient 4.4BSD did for simplicity
- add <machine/bootinfo.h> to define values as API to pass these info
- save boothowto and bootdev in registers right after zero'ing bss
- add MD device_register(9) to check booted_device per passed bootdev info
- merge old bootarg checks in rootconf() and luna68k_init() with
tweaks for backward compatibility
(direct boot a.out kernel from ROM monitor without bootloader still works)
It looks the device is mapped at both regions.
4.4BSD/luna68k probes it at 0xf1000000, but UniOS-Mach for LUNA-II
attaches the lance at 0xf0000000. It is probably because
the UniOS needs to map DS1220 NVRAM (mapped at 0xf1000004 and
used to store the MAC address) to the different kernel page,
but there is no reason for us to use different addresses.
(Note our bootloader already use the same address for both machines.)
This change will make (forthcoming) booted device check easier.
- remove kernel-like autoconfiguration to probe bootable devices
- initialize SCSI and Ethernet controllers statically instead
- reorganize device softc structures per autoconf removal
- probe and print all SCSI disks (but don't assign unit numbers)
- make sdopen() to recheck the device and allocate softc dynamically
- use controller number and SCSI target ID (ctlr * 10 + id) to specify
the boot disk on the "boot" command arg
- bump version to denote changes
Now bootloader works as the following:
---
>> NetBSD/luna68k boot, Revision 1.8 (Wed Jan 8 22:13:12 JST 2014)
>> (based on Stinger ver 0.0 [Phase-31])
Machine model = LUNA-II
Physical Memory = 0x4000000 (64 MB)
sc0 at 0xe1000000: async, parity, ID 7
ID 3: TEAC FC-1 HGF 10 rev , 512 bytes/sect x 2879 sectors
ID 6: IBM DPES-31080 rev S31Q, 512 bytes/sect x 2118143 sectors
sc1 at 0xe1000040: async, parity, ID 7
ID 6: MELCO DSC-G rev 1.00, 512 bytes/sect x 62533295 sectors
le0: Am7990 LANCE Ethernet, mem at 0x71010000
le0: Ethernet address = 00:00:0a:03:42:77
Press return to boot now, any other key for boot menu
booting sd(16,0)netbsd - starting in 0 seconds.
auto-boot sd(16,0)netbsd
1911696+96040 [280480+159179]=0x255a30
:
into both a message for the case where cngetc() doesn't work. If
there's no console attached, this won't accomplish anything; but if
there's a screen but no keyboard, or the keyboard's wedged, or
whatever, it might provide useful information.
Suggested back in 2009 by some stuff in PR 37924 and has been hanging
about in one of my trees ever since.
