isp(4) - kernel panic on initialization of driver

Alexander Sack pisymbol at gmail.com
Tue Sep 2 18:42:14 UTC 2008


On Tue, Sep 2, 2008 at 12:52 PM, Ross <westr at connection.ca> wrote:
>
> AS> I think your doing some great work but I don't think this is the
> AS> *right* direction to take.  The bottom line is the ISP should have
> AS> interrupts disabled until it completes a full reset and loads the
> AS> firmware, period.  You shouldn't have to ignore ASYNC events during a
> AS> reset - that doesn't make sense to me....yet....!
>
> I've created a small patch that so far seems to be working (survived
> ~10+ reboots). From what I can tell, using the ISP_ENABLE_INTS &
> ISP_DISABLE_INTS functions won't do anything to stop the problem.

Yes Ross, I just discovered this myself that AYNC events are let
through to the host regardless of ISP_ENABLE_INTS.

> Basically my hypotheses is that the ASYNC command is already sitting
> around in the mailbox of the card waiting to be read, so no interrupt
> is actually being generated during the time the driver is starting up
> - so you can't disable it.

That's right but the ISP should be reset.  YWe actually issue mailbox
commands BEFORE we do the RISC reset.  I think that maybe ultimately
the bug.

> (The card is active with a valid running rom before freebsd gets it's
> paws on it, so it's probably already cleanly read it, but hasn't acted
> upon it)

Yes I believe your right.

> The crash is located with the very first mailbox read, where if it
> doesn't recognize the mailbox response, it parses it anyways
> (in case it's something that needs to be done), and exit out if
> there's an error.
>
> But the isp_parse_async() function makes the assumption that isp_state
> == ISP_RUNSTATE, so it's safe to do anything. Where in fact is
> actually gets called when not in ISP_RUNSTATE (with the assumption
> that no problematic async command could be generated at this point).
>
> I'm guessing the true fix would be upon startup to somehow make sure
> the mailbox queue is emptied before attempting to query the card
> (for the firmware version).  But how to do that is beyond me.

Are you ok with trying another patch to maybe do exactly that?  Let me
take a look at your patch as well.

Thanks!

-aps


More information about the freebsd-scsi mailing list