Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Sep 2008 12:52:07 -0400
From:      Ross <westr@connection.ca>
To:        freebsd-scsi@freebsd.org
Subject:   Re[8]: isp(4) - kernel panic on initialization of driver
Message-ID:  <479922773.20080902125207@connection.ca>
In-Reply-To: <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com>
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> <3c0b01820808290822tce5619bie11b8e97fe9a9062@mail.gmail.com> <08661720.20080829151750@connection.ca> <3c0b01820808291515j759236e6h262c533846587d57@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

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.

(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)

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.

Let me know what you think.

Ross.

-= start
[~/isp]$ diff -u isp.c.orig isp.c
--- isp.c.orig  2008-08-22 16:32:57.000000000 -0400
+++ isp.c       2008-09-02 11:48:18.000000000 -0400
@@ -4557,8 +4557,10 @@
                                isp_prt(isp, ISP_LOGWARN,
                                    "mailbox cmd (0x%x) with no waiters", mbox);
                        }
-               } else if (isp_parse_async(isp, mbox) < 0) {
-                       return;
+               } else if (isp->isp_state == ISP_RUNSTATE) {
+                       if (isp_parse_async(isp, mbox) < 0) {
+                               return;
+                       }
                }
                if ((IS_FC(isp) && mbox != ASYNC_RIO_RESP) ||
                    isp->isp_state != ISP_RUNSTATE) {
-=


-- 
  Ross West                          Tel:   +1 416 967 6767
  Network Manager                    Fax:   +1 416 967 7777
  Network Connection                 Email: westr@connection.ca




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479922773.20080902125207>