Date: Sun, 10 May 2009 22:49:59 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-scsi@freebsd.org Subject: Re: isp panic after printing the uptime Message-ID: <20090510204959.GA27204@alchemy.franken.de> In-Reply-To: <49A2B464.4020409@kasimir.com> References: <49A2B464.4020409@kasimir.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090510204959.GA27204>