Hi, what in the OpenBSD kernel might mangle scsireq_t.sense before it is made available to a caller of ioctl(SCIOCCOMMAND) that acts on an AHCI connected CD drive ?
SASANO Takayoshi as user of OpenBSD and me as upstream of libburn are testing libburn operation of optical drives via that ioctl. The largest part of the adapter code is already in use with NetBSD. http://libburnia-project.org/browser/libburn/trunk/libburn/sg-netbsd.c Only small adaptions were necessary to make it run #ifdef __OpenBSD__. Nevertheless, there is a problem with SATA attached drives if AHCI is used. It not only appears with libburn but also with program cdrecord if the necessary conditions are met. The problem does not appear if PCI-IDE is used. It nearly (*) always appears when provoked on AHCI. The problem is that scsireq_t.sense does not contain plausible ASC, ASCQ values when KEY 2 "NOT READY" is indicated by the drive. E.g. when one of the tested drives (iHAS524) indicates that its write buffer currently does not accept more data, libburn's log tells that it sends (for CD SAO beginning at LBA -150): WRITE(10) 2a 00 ff ff ff ea 00 00 10 00 and gets indicated by (scsireq_t.retsts == SCCMD_SENSE) that scsireq_t.sense is valid with this content: sense data = 70 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key=2 asc=00h ascq=00h For a burn program this means: Drive is not ready and no info is available why. The program may then either end or wait for the condition to go away. But if the program is willing to wait until TEST UNIT READY indicates readiness, then it gets to see always the same sense data 2,0,0 until the user runs out of patience and kills it from outside. With PCI-IDE (and on another operating system with AHCI) the reply is sense data = 70 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 00 00 00 key=2 asc=04h ascq=08h which according to MMC-5 means: Not ready, Long write in progress. A burn program knows that it shall wait and then resend the same WRITE command with the same LBA. After some re-tries, writing goes on on PCI-IDE until successful end. Another drive (BH14NS48) does not reply sense data during normal burning or blanking runs, unless the Immed bit is used with commands like START/STOP UNIT, SYNCHRONIZE CACHE, or BLANK. cdrecord does not use this bit by default. So with AHCI on OpenBSD it does burn and blank properly, unless unexpected things like media error happen. With cdrecord option -immed it is possible to cause the same failures as happen with libburn when it uses the Immed bit. Freshly released libburn 1.4.6 by default does not to use the Immed bit when it runs on OpenBSD. So it is supposed to work as good or bad as does cdrecord. But in in general the Immed bit is beneficial because it lets commands end swiftly and thus cannot clog a bus or driver as much as a command that runs dozens of seconds or even minutes. In the context of this problem report it can serve as a way to reproduce the problem with drives like the BH14NS48 which elsewise work well in many cases. E.g. with a CD-RW which contains some data: cdrecord -immed dev=/dev/rcd0c:2,0,0 blank=fast --- (*) I have to write "nearly always when provoked" because the cdrecord -immed blanking run succeeded on iHAS524, when SASANO Takayoshi tried to provoke it after BH14NS48 nicely got stuck with the same cdrecord options. It is a riddle to me why iHAS524 worked on that occasion. I could not get cdrecord to showing the sense data of TEST UNIT READY. But after some due time such a command reported no sense data and cdrecord went on. With BH14NS48 the TEST UNIT READY commands yielded sense data until finally cdrecord was killed from outside. Have a nice day :) Thomas
