Date: Fri, 14 Feb 2003 23:20:02 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: scsi@FreeBSD.org, current@FreeBSD.org Cc: joe@FreeBSD.org, thomas@FreeBSD.org Subject: call for testers: cd(4) changes Message-ID: <20030214232001.A71462@panzer.kdm.org>
next in thread | raw e-mail | index | archive | help
Here are patches against -current to add automatic detection of CDROM drives that can't handle 6 byte mode sense and mode select: http://people.FreeBSD.org/~ken/scsi_cd.cmdsize.20030214 These patches will be checked in in a few days if I don't get any negative feedback. Things fixed/changed in this patchset: - Automatically detect CDROM drives that can't handle 6 byte mode sense and mode select, and adjust our command size accordingly. More information on that below. - MODE_SENSE and MODE_SELECT translation removed in ATAPICAM and in the umass(4) driver, since there's no way for that to work properly (see below). - Change the way the da(4) handles the no_6_byte sysctl. There is now a per-drive sysctl to set the minimum command size for that particular disk. (Since you could have multiple disks with multiple requirements in one system.) - Loader tunable support for all the sysctls in the da(4) and cd(4) drivers. - Add a CDIOCCLOSE ioctl (bde pointed this out a long time ago). - Add a media validation routine (cdcheckmedia()) to the cd(4) driver, to fix some problems bde pointed out a long time ago. We now allow open() to succeed no matter what, but if we don't detect valid media, the user can only issue CDIOCCLOSE or CDIOCEJECT ioctls. - The media validation routine also reads the table of contents off the drive. We use the table of contents to implement the CDIOCPLAYTRACKS ioctl using the PLAY AUDIO MSF command. The PLAY AUDIO TRACK INDEX command that we previously used was deprecated after SCSI-2. It works in every SCSI CDROM I've tried, but doesn't seem to work on ATAPI CDROM drives. We still use the play audio track index command if we don't have a valid TOC, but I suppose it'll fail anyway in that case. That's the last issue I know of with using ATAPI/firewire/USB drives with the ioctl interface. (firewire and USB drives are generally ATAPI drives underneath anyway) - Add _len() versions of scsi_mode_sense() and scsi_mode_select(). - Fix a couple of formatting problems in the sense printing code. I'd appreciate it if folks could test this, especially people with CDROM drives running via usb, firewire, or ATAPICAM, but also people with older SCSI CDROM drives. To test this, apply the patch and do the following: cdcontrol status cdcontrol info cdcontrol play (make sure audio comes out) cdcontrol next (make sure it skips to the next track here) If you get an error in response to 'cdcontrol next', definitely let me know what kind of drive you have (dmesg is fine) and how it is hooked up (SCSI, firewire, ATAPICAM, usb, etc.). Reports of success or failure are welcome. ======= Now for more details.... When we get an illegal request in response to a 6 byte mode sense or mode select, we reformat the command to be a 10-byte mode sense or mode select and reissue it. These patches also work with drives that do not return block descriptors (even when dbd is 0 in the mode sense command), and drives that return multiple block descriptors. (They work better with the former than the latter; with the latter, they mostly just bail out.) While commands like READ(6) and WRITE(6) can be translated down in the SIM driver, like the ATAPICAM and usb code do, MODE_SENSE(6) and MODE_SELECT(6) cannot be translated, because the 10-byte version of the parameter list is longer. This means that when, e.g., a MODE_SENSE(6) command is translated to a MODE_SENSE(10) command, the page will likely be truncated (unless more space is allocated than needed), and since the peripheral driver code isn't expecting the returned data to be in MODE_SENSE(10) format, it'll be looking in the wrong place for the mode page. The SIM drivers have no way of knowing how long the buffer is that they've been given for a mode sense or mode select, so they can't just up the dxfer_len, change the CDB and call it good. The only way to do translation effectively for these two commands is where the buffer was originally allocated -- in the peripheral driver. So I have implemented translation and 10-byte mode sense and mode select for the cd(4) driver. Why do translation? Why not just default to 10-byte commands? Because some SCSI CDROM drives, maybe quite a few, don't support 10 byte mode sense and mode select. (The 8x Plextor in my test box doesn't, for example.) The right way to do this, eventually, is with the CAM_NEW_TRAN_CODE. 6byte/10byte can be a function of the protocol, and we can hopefully select the right size command up front. It will take a lot of infrastructure work to make it happen, but that functionality will hopefully solve several problems. Since translation won't work at the SIM level, I have disabled MODE_SENSE(6) and MODE_SELECT translation in ATAPICAM and umass(4). Comments are welcome on the patches; they're more complicated than I would like, but unfortunately that complication seems necessary to get the desired functionality. Many thanks to David Kleiner <kleiner@panix.com> for testing multiple iterations of these patches, he has been a big help. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030214232001.A71462>