On Sep 28, 2007, at 03:06, matthew green wrote:
> actually, i think that the right bus_dmamem_map() is in
> sparc64/dev/iommu.c:iommu_dvmamap_load().

   Interesting.  In looking at iommu_dvmamap_load(), I see that one  
place (the only place?) it returns -1 is on line 531, inside of a  
conditional on a pmap_extract() call failing.  In this case, with  
DIAGNOSTIC, it will print a message explaining this as the failure.   
So, I built a diagnostic kernel to see if I got that message.

   Now, when I "reboot 0x104", I get a new crash, a panic() from  
callout_stop() in kern/kern_timeout.c:

dumping to dev 7,1 offset 4310231
dump panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC"  
failed: file "/data/NetBSD/src/sys/kern/kern_timeout.c", line 427
cpu0: kdb breakpoint at 1419e80
Stopped in pid 0.2 (system) at  netbsd:cpu_Debugger+0x4:        nop
db> bt
__kernassert(15e6510, 16206c8, 1ab, 16206f8, 8, 8) at  
netbsd:__kernassert+0x2c
callout_stop(187ea98, 2000, 7463700, 200, 8, a) at netbsd:callout_stop 
+0x198
esiop_scsicmd_end(187ea78, 7318400, 580, b0, 0, 5) at  
netbsd:esiop_scsicmd_end+0xb0
esiop_checkdone(7318400, 7312000, 580, b0, 5, 5) at  
netbsd:esiop_checkdone+0x2a4
esiop_intr(7318400, 46a14aefb, 46a14af01, 6, fffffffffffffffe,  
746d000) at netbsd:esiop_intr+0x68
esiop_scsipi_request(7318400, 7460300, 187ea78, 1, 187ea78, 1000000)  
at netbsd:e
siop_scsipi_request+0x6b0
sddump(1, 41c4d7, e0016c40, 187e800, ff800000, ff000000) at  
netbsd:sddump+0x1b0
pmap_dumpmmu(13f9b20, 41c4d7, 1, 41c4d7, fffffffffffffffc, 18a4800)  
at netbsd:pmap_dumpmmu+0x154
dumpsys(165a000, d, 0, e00171e0, 1857800, 13f9b20) at netbsd:dumpsys 
+0xe0
cpu_reboot(104, 0, e00170a8, 1860800, 1860bc8, 188c7e8) at  
netbsd:cpu_reboot+0xd0
db_reboot_cmd(1, 0, 4, e0017170, e0017298, 188c7e8) at  
netbsd:db_reboot_cmd+0x40
db_command(180f318, 4, 0, 0, e0017388, 0) at netbsd:db_command+0x98
db_command_loop(1419e88, 0, 2, 1898859, 0, 0) at  
netbsd:db_command_loop+0x108
db_trap(0, 0, 0, 0, 4, 1000000) at netbsd:db_trap+0x11c

   Perhaps this is eluding to the underlying problem?  Anyone have  
any idea why callout_stop might be called on something that  
apparently isn't a callout?

                                - Chris