Hi, 

I thought that Sun is running automated tests on a regular base 
in order to foster code quality.

As we had frequent problems with the SCSI code in the past, I would asume that
every available test program is used to verify that a code change does not
introduce new bugs.

We currently _again_ (I believe this is the 4th time during the past 8 years)
have problems with the residual cound with PATAPI drives. The DMA residual count
is currently _always_ 0 even iff there was an incomplete transfer.

SCSI over USB is currently close to unusable for both cdrecord and cdda2wav.


-       Timeouts are not honored. This may be a result if running retries in 
        "sd" even though a USCSI command was issued with 

        USCSI_SILENT | USCSI_DIAGNOSE | USCSI_RQENABLE

        and thus no retry at driver level is allowed

-       All SCSI commands with odd DMA count seem to fail with strange and
        undocumented error conditions.

        -       With a USB <-> PATA/SATA adaptor:

                JMicron USB to ATA/ATAPI Bridge 2222917915E1

                This causes sometimes unrecorerable hangs in the driver. 
                Note that Linux has no problem with the same hardware.

        -       With a USB <-> PATA/SATA adaptor:

                Cypress Semiconductor USB2.0 Storage Device DEF107F5D1BB

                the SCSI stack does not hang but still even the next SCSI 
                command fails with strange and undocumented error conditions.

Note that some of the SCSI commands issued by cdrtools have a timeout of 
approx. one hour. If there is a hang _and_ illegal retries at driver level, 
this results in the device becoming unusable for three hours.

Note that many SCSI commands used by cdrtools _need_ to be able to deal with
odd DMA counts. 

Also note that cdrtools include a command named "scgcheck" that verifies correct
behavior of the SCSI stack under all important error conditions and that SCSI 
is a protocol that lives from correctly reported error conditions. Why is 
"scgcheck" not run on a regular base in the Sun Solaris test strategy?

BTW: I am currently in contact with guoqing....@sun.com but it seems that this
is a general problem (in special as Sun introduced similar bugs on a regular 
base in the past) that should be fixed in a more general way in order to prevent
the same bug (or similar bugs) to reappear frequently.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       j...@cs.tu-berlin.de                (uni)  
       joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to