At 16:50 Uhr +1100 7.1.2003, matthew green wrote:
>   -- Is there any way to find out where exactly in
>   [ ... ]
>   the watchdog interrupt hit?
>
>if you use "disassemble <address>", you can normally find it by
>matching up the actual address given and the assembler code...
>if you don't know sparc asm, send me the output from the disassemble
>command and we'll figure it out...

"Unfortunately", with the locore.s patch to enable the second cpu the focus
has changed... A kernel configured with the floppy driver gets over the fdc
probe but consistently hangs while probing the second scsi bus (a sunswift
wide scsi/fast ethernet card). Breaking into the debugger only gives me


NetBSD 1.6L (PIZZA) #15: Tue Jan  7 20:48:32 CET 2003
    hauke@pizza.causeuse.org:/usr/src/sys/arch/sparc/compile/PIZZA

[...]
ms0 at zs1 channel 1: baud rate 1200
fdc0 at obio0 slot 0 offset 0x700000 level 11 softpri 4: chip 82077
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
[...]
SUNW,DBRIe at sbus0 slot 15 offset 0x8010000 level 9 not configured
hme0 at sbus0 slot 2 offset 0x8c00000 level 4 (ipl 7): Sun Happy Meal
Ethernet (SUNW,hme)
hme0: Ethernet address 08:00:20:18:76:7e
nsphy0 at hme0 phy 1: DP83840 10/100 media interface, rev. 0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
esp1 at sbus0 slot 2 offset 0x8800000 level 3 (ipl 5): FAS366/HME, 40MHz,
SCSI ID 7
scsibus1 at esp1: 16 targets, 8 luns per target
eccmemctl0 at mainbus0 ioaddr 0x0: version 0x0/0x1
IPsec: Initialized Security Association Processing.
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <QUANTUM, QM34500TD-S, N1B0> disk fixed
sd0: 4341 MB, 8057 cyl, 5 head, 220 sec, 512 bytes/sect x 8891624 sectors
sd0: sync (100.0ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 1 lun 0: <QUANTUM, QM34500TD-S, N1B0> disk fixed
sd1: 4341 MB, 8057 cyl, 5 head, 220 sec, 512 bytes/sect x 8891624 sectors
sd1: sync (100.0ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
scsibus1: waiting 2 seconds for devices to settle...
Stopped at      cpu_Debugger+0x8:       call            esigcode
db{0}> t
cpu_Debugger(0x0, 0x100, 0xf024d7a0, 0xf0002000, 0xf023ec00, 0xf0203c00) at
zs_abort+0x24
zs_abort(0xf089f670, 0x0, 0xf01af8a4, 0xf0242280, 0xf028dd50, 0xf2288000)
at zstty_stint+0x88
zstty_stint(0x8, 0xf08a0ea0, 0xfe024000, 0xf0002000, 0xffff, 0x0) at
zsc_intr_hard+0x68
zsc_intr_hard(0x0, 0xf01ad2d0, 0xd00, 0x408000e7, 0x0, 0xfffffffe) at
zshard+0x40
zshard(0x0, 0x0, 0xf01e49b8, 0x0, 0xffffffff, 0xf02871e0) at
sparc_interrupt44c+0x150
sparc_interrupt44c(0x400000e1, 0x23, 0x23, 0xf683af30, 0xf683af38,
0xf683af29) at idle
db{0}> reboot
syncing disks... Stopped in pid 0 (swapper) at   cpu_Debugger+0x8:       call
         esigcode

db{0}> reboot
rebooting

Resetting ...


-- the kernel appears to sit in an idle loop, probably waiting for an
interrupt that never comes. pk's update doesn't change this.

Funny enough, when I configure the kernel without floppy driver, it gets
through the scsi probes allright and boots multi-user.

	hauke

--
/~\  The ASCII Ribbon Campaign
\ /    No HTML/RTF in email
 X     No Word docs in email
/ \  Respect for open standards