US-III crashes on current

[Marius Strobl]

On Tue, Apr 21, 2009 at 01:45:27AM +0200, Florian Smeets wrote:
> On 20.04.09 20:36, Marius Strobl wrote:
> >On Wed, Mar 25, 2009 at 12:56:33PM +0100, Florian Smeets wrote:
> >>On 25.03.2009 12:44 Uhr, Marius Strobl wrote:
> >>>On Sun, Mar 22, 2009 at 07:30:28PM -0500, zenxyzzy wrote:
> >>>
> >>>>2) halt consistently panic's the machine. quite benign, if you think
> >>>>about it:
> >>>>
> >>>>panic: trap: fast data access mmu miss
> >>>>cpuid = 0
> >>>>KDB: enter: panic
> >>>>[thread pid 1402 tid 100148 ]
> >>>>Stopped at      kdb_enter+0x80: ta              %xcc, 1
> >>>>db>   where
> >>>>Tracing pid 1402 tid 100148 td 0xfffff8000448a700
> >>>>panic() at panic+0x20c
> >>>>trap() at trap+0x4d0
> >>>>-- fast data access mmu miss tar=0x14543da000 %o7=0xc034c96c --
> >>>>callout_lock() at callout_lock+0x40
> >>>>untimeout() at untimeout+0xc
> >>>>isp_done() at isp_done+0x140
> >>>>isp_intr() at isp_intr+0x3eb8
> >>>>isp_poll() at isp_poll+0x38
> >>>>xpt_polled_action() at xpt_polled_action+0xc8
> >>>>dashutdown() at dashutdown+0x16c
> >>>>boot() at boot+0x858
> >>>>reboot() at reboot+0x64
> >>>>syscall() at syscall+0x2e8
> >>>>-- syscall (55, FreeBSD ELF64, reboot) %o7=0x1013e4 --
> >>>>userland() at 0x4056af08
> >>>>user trace: trap %o7=0x1013e4
> >>>>pc 0x4056af08, sp 0x7fdffffe261
> >>>>pc 0x100df0, sp 0x7fdffffe321
> >>>>pc 0x402066f4, sp 0x7fdffffe3e1
> >>>
> >>>IIRC, this was recently already (correctly) reported to scsi at .
> >>>At least I for one didn't have time to investigate this so far
> >>>though.
> >>>
> >>
> >>I can offer console access to a machine which has this problem to any
> >>developer interested.
> >>
> >
> >Are you still seeing this on current CURRENT? Unfortunately
> >I'm not able to reproduce it here. Recently there was some
> >rototilling in sub-system startup and I think also shutdown
> >which caused some fallout but which might have been fixed
> >again.
> >
> 
> Yes, i can still reproduce this on every shutdown. Tried with r191337. 
> Trace is still the same.
> 

Could you please run gdb(1) on the corresponding kernel.debug
and report the output of the following commands?
l *(0xc034c96c)
l *(callout_lock+0x40)
Change as needed if the addresses differ from the above
backtrace. Hrm, the one you reported to scsi@ actually
is a bit different:
> -- fast data access mmu miss tar=0x1454156000 %o7=0xc040e7a4 --
> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x5c
> callout_lock() at callout_lock+0x50

In that case please additionally get the output of
l *(_mtx_lock_spin_flags+0x5c)

Marius