[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> I just found an ugly bug and a fatal bug in Linux 2.4.2-4GB:
>
> - The ugly bug is that the sg driver in ioctl() mode
> does not set the SCSI status byte correctly (at least
> when the drive is ATAPI).
>
> Note that ATAPI has no SCSI status byte but there is
> a IDE status bit that is used to signal the driver to
> fetch sense data. This bit is equivalent to CHECK_CONDITION
> in the SCSI status byte. So a conforming SCSI driver needs
> to emulate the CHECK_CONDITION bit (0x02) in the SCSI
> status byte in this case.
>
> Observed behaviour (with cdrecord -d):
>
> ioctl ret: 0
> host_status: 00 driver_status: 28
> cdrecord: Input/output error. read toc: scsi sendcmd: no error
> CDB: 43 00 00 00 00 00 00 00 04 00
> status: 0x0 (GOOD STATUS)
> cmd finished after 0.000s timeout 40s
>
> The driver status includes DID_SENSE but the SCSI status is 0!
It has been like this for a long time, probably as long as
there has been a ide-scsi driver in Linux. I have asked the
maintainer to "fix" it but he said that it is difficult.
This has been documented in sg for several years. Here
is a snippet from sg.h :
unsigned char sense_buffer[SG_MAX_SENSE]; /* [o] Output in 3 cases:
when target_status is CHECK_CONDITION or
when target_status is COMMAND_TERMINATED or
when (driver_status & DRIVER_SENSE) is true. */
Note the last line of the comment.
Unfortunately nothing has changed in this respect in lk 2.4 .
> This causes cdrecord not wo work properly in all cases - please fix
> as soon as possible.
Cdrecord handled this in the past. It is less than ideal
but cdrecord can use the same logic to handle this
situation in the future.
> Check/Repeat with the scgcheck program!
??
> - The fatal bug is that Linux 2.4.2-4GB dies on a
> DMA overrun situation.
>
> My observed behaviour was that the machine freezes and
> a ping from another machine is not answered anymore.
Again this doesn't sound like a sg problem. More likely
it is a HBA driver problem. I expect the data overrun
case (as distinct from the more common data underrun case)
is not well tested on all adapter drivers. Which adapter
driver were you using? If it was the aic7xxx, it may be
worth trying the new one introduced in lk 2.4.3 .
> BTW: scgcheck is now out for one month. It seems to be a good idea
> to for correct check kernel behaviour in error situations
> from time to time.
>
> Note that incorrect behaviour for error situatiuons in the
> Linux sg driver was the most frequent problem in the past.
True.
Doug Gilbert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
