>From [EMAIL PROTECTED] Sun Apr 1 07:37:17 2001
>Last time we worked on this, the way to detect it was to notice that the
>unit had reset itself after you got the 2 bytes but before you got the rest
>of the data -- that is, the ASC/ASCQ of the failed full-length mode sense
>command would indicated that the unit had just been reset and was becoming
>ready.
It did work but it may not be reliable...
The correct way would be to signal the DMA overrun itself.
If the drive signalles back that there has been a reset, then the reset must
have been during the execution time of the command. This may not always be
the case...
If the hostadapter status for the command is set to something != OK, then
libscg may signal this to the libscg user with sp->error = SCG_RETRYABLE
This seems to work for me for my VAIO and with 2.4.
NOTE that this will only work correctly with cdrecord-1.10a17 or later as
the use of the new scgcheck command helped me tofix the Linux low level
SCSI implementation. Now all remaining libscg noncompliancies on Linux are
a result of missing features inside the Linux kernel. Some caused by the
sg driver others by the code below.
>Note that this behavior hasn't changed from 1.10a4 which worked until now.
>cdrecord used to print a warning along the lines of "controler generates
>hard failure when retrieveing capabilities page" or somesuch -- I'm still
>unpacking, so I can't do a setup and test with teh version of cdrecord that
>I have been using.
>Did you change this behavior for a reason? I remember pointing out to you
>that this is actually the firmware in the OEM Phillips drive (which you
>pointed out had been failing elsewhere but didn't know why) doing bad
>things.
Cdrecord introduced the code on Sept 5 and fixed it on Sept 19.
Nothing changed up to now. The next release will introduce some minor changes
but this will not really change the behaviour.
On my VAIO, I do _not_ get the reset signalled via the sense bytes but the
SCSI transport status is set to SCG_RETRYABLE.
If there is a different bahaviour that does not allow me to detect the
DMA problem by some facts, then it is caused by a different behaviour
of the combination HW kernel.
Note that I got into contact with Philips developers because of this
and it turns out that Philips drives do not have the problem.
It may be that IOMEGA uses a Philips clone with modified firmware.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
