I changed QLOGICFC_REQ_QUEUE_LEN from 127 to 255, andthe lockup hasn't happened again yet, in circumstancesthat fairly reliably reproduced it before. (Couldjust mean I have to hit it harder.)

BUT: I am still getting those "no handle slots, thisshould not happen" messages. (Especially when I playwith nicing my dd down to -20, although that may becheating...) These seem to match with noticeablestalls in the drive array light blinkiness, whereabout every 2 seconds there's a visible pause in thewhole array. If I do a read that's short enough toNOT cause one of these stalls, I get 178megabytes/second throughput (which is about up towardsthe theoretical limit of the two qlogic fiber channelcards and the ten drives per card).

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

According to top, at least one CPU is pegged duringall this, by the way. dd uses 99.9% of available cputime, with bdflush taking another 32% or so (on theother cpu, one assumes. :) Guess: lots of copying ofthe zero page to fill up dd's buffers? I'm trying todo an i/o bound test, may have to write my own itseems. Oh well, no biggie... (The real applicatinofor 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 shouldprobably 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" inthe body of a message to majordomo@vger.kernel.orgPlease read the FAQ at http://www.tux.org/lkml/