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