Sophia Li wrote, > Juergen Keil wrote: > > [ Hmm, it seems that the www.opensolaris.org forum > > "Communities ? device drivers ? usb driver" still doesn't forward > > my messages to the USB discussion mailing list, although I'm subscribed > > to the mailing list now. Resending via mail ... ] > > > > > > Bug 6576064 > > Synopsis: Lacie Biggest F800 USB drive does not support zero byte write(10) > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6576064 > > > > mentions that a lacie usb mass storage device hangs because of zero byte > > write(10). > > > > Note that CD recording in DAO mode actually needs zero byte writes, > > so I hope any fixes for 6576064 won't break CD recording in DAO mode > > for USB CD/DVD recorder devices. > > Thanks for pointing this out. How can I verify zero byte write work for > CD/DVD recorder devices? Can you show me the command to trigger zero > byte write?
Support for zero byte writes was added with the fix for 5107848, Synopsis: "scsa2usb: panic for WRITE command without data buffer" http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5107848 The relevant SCSI command is (see MMC-6 standard, http://www.t10.org/ftp/t10/drafts/mmc6/mmc6r00.pdf ): "6.32 SEND CUE SHEET" with a "Data Form of Main Data" (6.32.3.8 - 6.32.3.14, pages 550-552): 01h (CD-DA) 14h (CD-ROM mode1) 24h (CD-ROM XA) 34h (CD-ROM mode2) For all of these "Data Form of Main Data", footnote 2 (page 552) applies, which is: ? For all forms: [...] 2. Generate Data: The Drive generates the data in this area. The Host should not send the data for this area. All sectors in the program area shall have an associated write, even if all data for the sector is to be generated by the Drive. Zero bytes shall be transferred for such sectors. [...] ? For an LG "HL-DT-ST DVDRAM GMA-4020B" CD/DVD recorder device connected as USB2.0 mass storage device (running on a system bfu'ed to use last week's opensolaris sources; ~snv_69), a SCSI command trace looks like this: 0 24529 scsi_transport:entry sd7 DATA=00020 CDB: 5d 00 00 00 00 00 00 00 20 00 / SEND_CUE_SHEET 0 55959 sdintr:entry state 1f, reason 0, t/ms 2, to/s 5, no arq sk/asc/ascq 0 0 0 [ This sends 0x20 == 32 byte cue sheet data to the drive, telling it the layout of the CD. In the cue sheet data (not visible here) I've used data mode 0x14 (CD-ROM mode1, drive generates the data) ] 0 24529 scsi_transport:entry sd7 DATA=00000 CDB: 2a 00 ff ff ff 6a 00 00 96 00 / WRITE(10) 0 55959 sdintr:entry state 37, reason 0, t/ms 2205, to/s 240, arq sk/asc/ascq 2 4 8 [ This is a 0x96 == 150 sector write starting at LBA 0xffffff6a == -150, with a zero sized data buffer. It tells the drive to generate and write the data for the TOC area of the CD. The drive is still busy writing the lead-in of the CD, so the command is not yet accepted - it fails with asc/ascq 0x4/0x8 == "LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS" ] 0 24529 scsi_transport:entry sd7 DATA=00000 CDB: 2a 00 ff ff ff 6a 00 00 96 00 / WRITE(10) 0 55959 sdintr:entry state 37, reason 0, t/ms 4, to/s 240, arq sk/asc/ascq 2 4 8 [ ... zero byte WRITE(10) still not accepted ... ... I've deleted several failed WRITE(10) attempts here while the drive is busy for several seconds ... ] 0 24529 scsi_transport:entry sd7 DATA=00000 CDB: 2a 00 ff ff ff 6a 00 00 96 00 / WRITE(10) 0 55959 sdintr:entry state 37, reason 0, t/ms 3, to/s 240, arq sk/asc/ascq 2 4 8 [ ... zero byte WRITE(10) still not accepted ... ] 0 24529 scsi_transport:entry sd7 DATA=00000 CDB: 2a 00 ff ff ff 6a 00 00 96 00 / WRITE(10) 0 55959 sdintr:entry state 17, reason 0, t/ms 2, to/s 240, no arq sk/asc/ascq 0 0 0 [ now the drive has accepted the zero byte WRITE(10) for the TOC area (Sectors: -150 .. -1) ] 0 24529 scsi_transport:entry sd7 DATA=0f000 CDB: 2a 00 00 00 00 00 00 00 1e 00 / WRITE(10) 0 55959 sdintr:entry state 1f, reason 0, t/ms 6, to/s 240, no arq sk/asc/ascq 0 0 0 [ This is a regular write, 0x001e data sectors * 2048 bytes starting at LBA 0x00000000; this write does transfer 0xf000 == 61440 bytes of data ] 0 24529 scsi_transport:entry sd7 DATA=0f000 CDB: 2a 00 00 00 00 1e 00 00 1e 00 / WRITE(10) 0 55959 sdintr:entry state 1f, reason 0, t/ms 6, to/s 240, no arq sk/asc/ascq 0 0 0 [ Next write, starting at LBA 0x0000001e, 0x001e sectors ] I'm not yet sure if J. Schilling's cdrecord is able to record a CD using CUE SHEETS, using one of these cue sheet data modes 0x01, 0x14, 0x24 or 0x34. > > Btw. reading the text for 6576064 seems to indicate that hal is trying > > to send zero byte write(10) requests. Any idea why and where this is > > happening? > > It is not directly sent by HAL. It is sent scsi_watch_thread(). When HAL > is enabled, the disk device would be open and scsi_watch_thread() would > be started. > > sd sends this command to detect reservation changes as the result of > bugfix 5041567. Originally sd sent test unit ready command for > reservation changes, but due to the difference in SPC-2 and SPC-3 > regarding reservation, some devices never return reservation conflict > for TUR command when reservation is lost. So zero byte write is sent > instead later. The code is as below: > > if (((dtype == 0) || (dtype == 0xE)) && > (devp->sd_inq->inq_ansi > 2)) { > pkt = scsi_init_pkt(ROUTE, (struct scsi_pkt *)NULL, NULL, > CDB_GROUP1, sizeof (struct scsi_arq_status), > 0, 0, SLEEP_FUNC, NULL); > > (void) scsi_setup_cdb((union scsi_cdb *)pkt->pkt_cdbp, > SCMD_WRITE_G1, 0, 0, 0); > } else { > pkt = scsi_init_pkt(ROUTE, (struct scsi_pkt *)NULL, NULL, > CDB_GROUP0, sizeof (struct scsi_arq_status), > 0, 0, SLEEP_FUNC, NULL); > > (void) scsi_setup_cdb((union scsi_cdb *)pkt->pkt_cdbp, > SCMD_TEST_UNIT_READY, 0, 0, 0); > FILL_SCSI1_LUN(devp, pkt); > } > > We need some changes in scsa2usb driver to handle the situation that > some USB disk devices might not support zero byte write. Have you any > suggestion that we can solve the issue without breaking CD/DVD support? OK, so sd(7d) seems to be sending a WRITE(10) with a sector count of 0 and no data buffer; while the CD recording case is sending a WRITE with a sector count > 0 and no data buffer. So I think, if scsa2usb is changed to silently accept a WRITE with a sector count == 0, it wouldn't break CD recording using CUE SHEETS and the above data modes 0x01, 0x14, 0x24, 0x34 (where we have WRITE commands with sector count > 0).
