isp(4) - kernel panic on initialization of driver

[Alexander Sack]

On Fri, Aug 29, 2008 at 10:36 AM, Ross <westr at 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