isp panic after printing the uptime

[Marius Strobl]

On Mon, Feb 23, 2009 at 03:36:20PM +0100, Florian Smeets wrote:
> Hi,
> 
> i have a 100% reproducible panic on sparc64 with an isp controller.
> Every time i reboot/shutdown the machine it panics after printing
> "Uptime: XXXX". I'm not sure if this is more scsi or sparc64 related but
> as the trace includes isp_* functions i went for scsi at .
> 
> The controller used is:
> 
> isp0: <Qlogic ISP 2200 PCI FC-AL Adapter> port 0x300-0x3ff mem
> 0x100000-0x100fff at device 4.0 on pci2
> isp0: [ITHREAD]
> isp0: Board Type 2200, Chip Revision 0x5, loaded F/W Revision 2.2.6
> isp0: invalid NVRAM header
> isp0: invalid NVRAM header
> 
> The messages prior to the panic and the panic look like this:
> 
> Sayncing diisks, vnotdes remaiining...n2 g (max 60 seconds) for system
> process `syncer' to stop...2 1 0 1 0 0 done
> All buffers synced.
> zfs_umount:969[0]: Force unmount is not supported, removing FORCE flag.
> zfs_umount:969[0]: Force unmount is not supported, removing FORCE flag.
> zfs_umount:969[0]: Force unmount is not supported, removing FORCE flag.
> lock order reversal:
>  1st 0xfffff800038394e0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1202
>  2nd 0xfffff80003839c40 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2092
> KDB: stack backtrace:
> _witness_debugger() at _witness_debugger+0x38
> witness_checkorder() at witness_checkorder+0xcf8
> __lockmgr_args() at __lockmgr_args+0x874
> vop_stdlock() at vop_stdlock+0x38
> VOP_LOCK1_APV() at VOP_LOCK1_APV+0x110
> _vn_lock() at _vn_lock+0x80
> vget() at vget+0x120
> devfs_allocv() at devfs_allocv+0x114
> devfs_root() at devfs_root+0x3c
> dounmount() at dounmount+0x490
> vfs_unmountall() at vfs_unmountall+0x3c
> boot() at boot+0x674
> reboot() at reboot+0x58
> syscall() at syscall+0x2bc
> -- syscall (55, FreeBSD ELF64, reboot) %o7=0x102a88 --
> userland() at 0x12b348
> user trace: trap %o7=0x102a88
> pc 0x12b348, sp 0x7fdffffdd91
> pc 0x101778, sp 0x7fdffffdf01
> pc 0x1001d0, sp 0x7fdffffe531
> pc 0, sp 0x7fdffffe5f1
> done
> Uptime: 6m9s
> panic: trap: fast data access mmu miss
> cpuid = 0
> KDB: enter: panic
> [thread pid 1 tid 100001 ]
> Stopped at      kdb_enter+0x80: ta              %xcc, 1
> db> where
> Tracing pid 1 tid 100001 td 0xfffff80002082000
> panic() at panic+0x20c
> trap() at trap+0x570
> -- 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
> 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+0xf0
> dashutdown() at dashutdown+0x130
> boot() at boot+0x8ac
> reboot() at reboot+0x58
> syscall() at syscall+0x2bc
> -- syscall (55, FreeBSD ELF64, reboot) %o7=0x102a88 --
> userland() at 0x12b348
> user trace: trap %o7=0x102a88
> pc 0x12b348, sp 0x7fdffffdd91
> pc 0x101778, sp 0x7fdffffdf01
> pc 0x1001d0, sp 0x7fdffffe531
> pc 0, sp 0x7fdffffe5f1
> done
> db>
> 
> Anything i can do, aside from not rebooting the machine :-) ?
> 

For the records, this was fixed with r191979.

Marius