Hi all,
and here is something for the SCSI Gods out there:
my IOMEGA Zip drive is going into error handling upon access.
Surprisingly enough, the device recovered so it's not really critical.
However, I wonder whether the error recovery is really a hardware error
on the driver itself or whether it's again this blasted aic79xx driver.
What happens is the following:
sd 4:0:6:0: send 0xffff810076858dc0 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 00 00 00 08 00
-> Read some bytes, ok.
sd 4:0:6:0: send 0xffff810076858488 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 08 00 00 38 00
-> send request to read some more bytes, ok. Note that the previous
request has not returned (yet).
sd 4:0:6:0: done 0xffff810076858488 RETRY 8000002 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 08 00 00 38 00
sdb: Current: sense key: Aborted Command
Additional sense: Overlapped commands attempted
-> this _looks_ like an error on the drive as the commands do not really
overlap. It looks more as if the device can't handle more than one
command at a time. Do we have a blacklist flag for such things?
sd 4:0:6:0: send 0xffff810076858488 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 08 00 00 38 00
-> Command requeued, okay.
sd 4:0:6:0: done 0xffff810076858488 SUCCESS 0 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 08 00 00 38 00
-> command finished, okay.
sd 4:0:6:0: done 0xffff810076858dc0 TIMEOUT 0 sd 4:0:6:0:
command: Read (10): 28 00 00 00 00 00 00 00 08 00
-> First command was still out there, but appearently never returned.
So of course error recovery started for this command.
It looks to me as if the device has aborted _both_ commands when
returning the 'overlapped commands attempted' sense.
Is that conformant behaviour?
SCSI-2 states in section 7.5.2:
A target that detects an incorrect initiator connection shall abort all
I/O processes for the initiator on the logical unit or target routine
and shall return CHECK CONDITION status. The sense key shall be set to
ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED
COMMANDS ATTEMPTED.
So the behaviour of the drive seems to be okay; however, the scsi stack
doesn't abort all commands (yet).
Might that be an error in the scsi stack?
Curious,
Hannes
--
Dr. Hannes Reinecke hare@xxxxxxx
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
