Well hosts that don't use the new EH code don't handle QUEUE_FULL. Not
quite sure what would happen with it, actually.
If everything goes according to plan, when the device returns
QUEUE_FULL, the io should get stuck back in the queue to be handled later.
In addition a flag should be set to prevent further I/O from being sent to
that device - that flag should be cleared when one of the existing I/O
requests actually completes.
I am not completely sure how best to debug this. I guess the first
thing to do is to see if in fact the QUEUE_FULL is being handled as I
described and the flag is getting set. Then the next thing to look for is
to see what happens when some other I/O finishes.
-Eric
----- Original Message -----
From: "Steve Ralston" <[EMAIL PROTECTED]>
To: "linux-scsi" <[EMAIL PROTECTED]>
Sent: Sunday, April 01, 2001 10:08 PM
Subject: QUEUE_FULL + use_new_eh_code = bad_karma?
> It seems that for a SCSI driver which sets use_new_eh_code
> (in Scsi_Host_Template), the scsi host will hang very shortly
> after a device happens to return QUEUE_FULL for an io.
>
> Same driver which does NOT set use_new_eh_code continues to
> work merrily along despite any number of QUEUE_FULL's.
>
> Can anyone explain any possibilities why this might happen?
>
> Happens for me on linux-2.4.3 and linux-2.4.2-ac28.
> Working on Fusion MPT FC+SCSI+LAN driver development,
> SCSI initiator testing, cmd-line was:
> time dd if=/dev/sda1 of=/dev/sdd1 bs=256k
> can_queue and cmd_per_lun are set to 64, devices under test are:
> scsi0,0:0:0 /dev/sda1 SEAGATE ST39102FC-0007
> scsi1,0:1:0 /dev/sdd1 SEAGATE ST19171FC-0017
> the latter being one that returns QUEUE_FULL at qdepth of 32.
> (it's my QUEUE_FULL regression testing disk:)
>
> Thanks,
> -SteveR
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
