qlogicfc.c hard lockups in 2.4.0

qlogicfc.c hard lockups in 2.4.0

[Rob Landley]

I've got a 20 drive raid0 set up off of two asus fiber
channel controllers using the qlogicfc.c driver.  (I
think it's a variant of ISP2200.)  Dual pentium 866
SMP machine, apparently stable under NT.  Half a gig
of ram, booting off of a different drive (hanging off
of an LSI1010 scsi controller not involved in the
raid, doubt that's involved).

The problem is that when I go:

time dd if=/dev/zero of=/root/raid/zerofile bs=1000000
count=8000

The sucker not only has visible bus stalls (the array
has lots of lights on the front), but sometimes the
whole machine locks hard (I.E. num-lock no longer
affecting the keyboard LEDs).

Before it goes bye-bye (and it doesn't always. 
Sometimes it finishes with lower throughput than it
should have...)  I get rather a lot of the following
in /var/log/messages:

Jan 16 03:40:55 dalek kernel: qlogicfc0 : no handle
slots, this should not happen.
Jan 16 03:40:55 dalek kernel: hostdata->queued is 4f,
in_ptr: 49
Jan 16 03:40:55 dalek kernel: qlogicfc0 : no handle
slots, this should not happen.
Jan 16 03:40:55 dalek kernel: hostdata->queued is 4f,
in_ptr 53

Repeat the above with in_ptr being 58, 5d, 6c, 76, 7b,
5, f, 19, 20, 2a, 2f, and 39.  At that point, the
machine achieved lockup and the next thing in the log
is syslog restarting from the (hard power off) reboot.

Help!  Should I enable any of the debugging macros in
qlogicfc.c?  I've reproduced this lockup three times
so far this morning.  It's rather annoying, but making
it happen again doesn't seem to be a problem...

Rob

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: qlogicfc.c hard lockups in 2.4.0

[Rob Landley]

More data:

I changed QLOGICFC_REQ_QUEUE_LEN from 127 to 255, and
the lockup hasn't happened again yet, in circumstances
that fairly reliably reproduced it before.  (Could
just mean I have to hit it harder.)

BUT: I am still getting those "no handle slots, this
should not happen" messages.  (Especially when I play
with nicing my dd down to -20, although that may be
cheating...)  These seem to match with noticeable
stalls in the drive array light blinkiness, where
about every 2 seconds there's a visible pause in the
whole array.  If I do a read that's short enough to
NOT cause one of these stalls, I get 178
megabytes/second throughput (which is about up towards
the theoretical limit of the two qlogic fiber channel
cards and the ten drives per card).

With the stalls, it gets dragged down into the 150
megabyte per second range.  That's right on the border
of causing dropped capturing from the hdtv card, and
stalls playing to it.  (I forget exactly what I need,
something like 157 megabytes/second...  Bigger is
better, of course...)

According to top, at least one CPU is pegged during
all this, by the way.  dd uses 99.9% of available cpu
time, with bdflush taking another 32% or so (on the
other cpu, one assumes. :)  Guess: lots of copying of
the zero page to fill up dd's buffers?  I'm trying to
do an i/o bound test, may have to write my own it
seems.  Oh well, no biggie...  (The real applicatino
for this is dma into and out of a mondo ring buffer,
not particularly cpu intensive at all, you'd think...)

Fun fun fun...  Sun's coming up in an hour, I should
probably get some sleep.

Rob

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/