isp(4) - kernel panic on initialization of driver

[Alexander Sack]

On Wed, Aug 27, 2008 at 11:27 AM, Ross <westr at connection.ca> wrote:
>
> AS> So one question I have is why doesn't the isp driver load the
> AS> firmware in ispfw? [...clip...] By any chance do you have
> AS> "hint.isp.0.fwload_disable" set? I'm not saying that will fix your
> AS> problem but I just noticed this.

Ok, I just wanted to make sure I wasn't going crazy!  I've just
patched the 6.x driver to load firmware again (without the use of the
generic firmware driver which I believe came later).  I still have to
thoroughly test it.

> The card came with 4.00.90 which is newer than the firmware included in
> ispfw (4.00.20) - but to answer your question, yes, fwload_disable is
> set for the cards.  I believe that got set since there was some kind
> of problem that we ran into at one point.  I'll do some testing on
> that.

Please do but I think what you did is very reasonable.

> AS> WARNING: this is pure speculation on my part from quickly looking at
> AS> it.  I'm just wondering if this is a bug in isp allowing the ASYNC
> AS> events occuring before a complete attach has been performed.
>
> Apologies if it didn't come across in my previous message, that's
> basically what I'm saying too.  I have about a 50/50 chance of the
> card booting successfully, and when it does, the output from the debug
> lines is different, and it looks like the ASYNC event is executing
> before it's time.  (See the end of this message for the full output
> from isp[01]: for a clean boot, since it's a long output.)

Yea it looks like the loop down timer kthread gets started further
down isp_attach() which I believe maybe the issue.  I got to look at
it some more.

> AS> I'm assuming all you are doing is booting 7.0-RELEASE off the SAN?
>
> That is correct. We're just using the i386 image at the current time
> (eventually going to amd64, but not now). It's been trimmed of the
> fat, but nothing special/custom added in.

Sure, thanks.

> AS> As Scott asked, can you get a dump or a trace of the crash?
>
> See my other message to freebsd-scsi/Scott for that.

Ummm, can you get more than what you posted?  i.e. can you rebuild the
kernel with

options KDB
options DDB

which will enable the debugger.  Then boot with a "-v" and when you
get into a panic you should fall into the kernel debugger.  At the
prompt do a "t" and copy the output (you don't have to copy the
addresses just the stack trace).  I think I can imagine what it looks
like but it would be better if you provided it.

Another possibility is to obtain a dump:

http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN

and post it.

Thanks!

-aps