Date: Fri, 29 Aug 2008 11:22:25 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: Ross <westr@connection.ca> Cc: freebsd-scsi@freebsd.org Subject: Re: Re[4]: isp(4) - kernel panic on initialization of driver Message-ID: <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> In-Reply-To: <34442830.20080829103621@connection.ca> References: <13710393234.20080826164158@connection.ca> <48B46EE1.8060408@samsco.org> <3c0b01820808270743n5fd40995u6e9506b772f2b03c@mail.gmail.com> <86689256.20080827112751@connection.ca> <3c0b01820808271333l34ead8ele99daab695baf667@mail.gmail.com> <34442830.20080829103621@connection.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 29, 2008 at 10:36 AM, Ross <westr@connection.ca> wrote: > > AS> which will enable the debugger. Then boot with a "-v" and when you > AS> get into a panic you should fall into the kernel debugger. At the > AS> prompt do a "t" and copy the output (you don't have to copy the > AS> addresses just the stack trace). I think I can imagine what it looks > AS> like but it would be better if you provided it. > > Here you go - a rather large pain in the butt, since HP's ilom doesn't > allow for cut'n'paste from the virtual console (even in serial mode). > Ugh. Hope that it helps some more. > > This kernel has been built using the 1 line patch you gave me > (removing the ISP_ENABLE_INTS call). Thanks Ross. Unfortunately, seems like your problem is even before we get to isp_attach()! > -= > ...[clipped]... > stack pointer = 0x20:0xc0af63cc > frame pointer = 0x20:0xc0af63cc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at xpt_freeze_simq+0x6: movl 0x58(%ecx),%eax > db> t > Tracing pid 0 tid 0 td 0xc079fd30 > xpt_freeze_simq(0,1,c06f7a16,c06f800f,c06f800f,...) at xpt_freeze_simq+0x6 > isp_freeze_loopdown(c81d0e00,2,c06f800f,0,c0cf1f6c,...) at isp_freeze_loopdown+0x42 > isp_async(c81d0e00,6,0,14e1,2001d5c3,...) at isp_async+0xa72 > isp_intr(c81d0e00,8012,1,8014,c0af6718,...) at isp_intr+0xbc7 > isp_mbox_wait_complete(c81d0e00,c0af67e8,50000000,0,8,...) at isp_mbox_wait_complete+0x120 > isp_mboxcmd(c0af67e8,24,40000000,c827c380,c0af67cc,...) at isp_mboxcmd+0x1ef > isp_reset(c81d0e00,c827c380,e,c0af6880,c02d6ce0,...) at isp_reset+0xe9 > isp_pci_attach(c827c380,c827c380,ffffffff,c0708a0a,80000000,...) at isp_pci_attach+0x1899 > device_attach(c827c380,c827c380,1,c827c380,c8263980,...) at device_attach+0x36f > device_probe_and_attach(c827c380,c8266800,c0af6944,c08b13a1,c8263980,...) at device_probe_and_attach+0xdd > bus_generic_attach(c8263980,c816c600,1,c08b0e80,c8263980,...) at bus_generic_attach+0x19 > ...[much more clipped]... > -= > > If any number seems 'off', let me know, as it could be my typing > skills. Don't worry about that Ross. Just the stack trace of functions is very enlightening! Looks like you got to isp_reset() before things screwed up. The issue is the CAM stuff is not initialized until isp_attach() I believe so that's why things are screwy (I don't think there is a simq allocated let alone freeze at this point). Give me a sec to look a this some more....bottom line is isp should not be servicing async interrupts until its absolutely ready! -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820808290822tce5619bie11b8e97fe9a9062>