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!

        This causes cdrecord not wo work properly in all cases - please fix
        as soon as possible.

        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.

        Check/Repeat with the scgcheck program!


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.

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]

Reply via email to