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 [email protected] 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:[email protected] (home) Jörg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
