isp(4) - kernel panic on initialization of driver

Alexander Sack pisymbol at gmail.com
Thu Aug 28 21:59:55 UTC 2008


On Wed, Aug 27, 2008 at 4:33 PM, Alexander Sack <pisymbol at gmail.com> wrote:
> On Wed, Aug 27, 2008 at 11:27 AM, Ross <westr at connection.ca> wrote:
>> 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.

Ross, can you please try this patch?  I don't have access to the
external SAN right now so if this blows up, I'm apologize in advance.
I'm not 100% sure about what is exactly going on without my hardware
in front of me.  However, it would seem that the LIP events that are
enabled in isp_init() are coming in before the isp_ldt (loop down
timer) and other things are initialized.  I believe interrupts should
be disabled until the intrhook gets called before root is mounted.
That's what I *think* the author intended.

Can you try the following small patch:

--- isp_freebsd.c.0	2008-08-28 13:54:27.000000000 -0400
+++ isp_freebsd.c	2008-08-28 13:48:45.000000000 -0400
@@ -231,7 +231,6 @@

 	if (isp->isp_role != ISP_ROLE_NONE) {
 		isp->isp_state = ISP_RUNSTATE;
-		ISP_ENABLE_INTS(isp);
 	}
 	if (isplist == NULL) {
 		isplist = isp;


I just don't see why ISP_ENABLE_INTS should be called since
isp_intr_enable() has been established as the config_intrhook to be
called before root mounts.

One of the things I noticed is that the isp driver actually handles
LIP events as they come in INSTEAD of first doing all the loop/fabric
enumeration up front (during attach time which is what other OSes I
believe do).  This means when the card finally does come up and we are
ready to go, it gets very noisy very fast until the fabric settles
down. Hence all those portdb change messages during normal bootup!

Give this a shot and let me know (either patch or edit the file, its
one line, rebuild, reboot etc.).  I tried it on my card with no
devices attached so I know it works on my system!  j/k

Again, I'm stabbing in the dark a little but I'm curious if this
prevents the panic.

-aps


More information about the freebsd-scsi mailing list