Date: Mon, 17 Jul 2000 10:10:21 -0500 (EST) From: "Jason T. Miller" <jasomill@shaffstall.com> To: freebsd-scsi@freebsd.org Subject: Yamaha CDR100 and FreeBSD 4.0-STABLE Message-ID: <Pine.LNX.4.10.10007170825460.5493-100000@guildenstern.shaffstall.com>
next in thread | raw e-mail | index | archive | help
I just recieved (for free), a Yamaha CDR100 4x CD burner. This is a great drive that (at work) has served me well for a couple years; it works fine with cdrecord and cdrdao. However, its cooperation with the FreeBSD SCSI CD-ROM driver is not as good. First of all, if there is no media loaded on boot, I get the messages "lost device" and "removing device entry." I haven't done much research on this particular problem yet; I'm just keeping a disc in the drive when I reboot. I have noticed, however, that the "removal" of the device entry is not complete; if I try to access /dev/cd0c, I get a kernel panic. The other problem is, initially, the drive would only mount CD-ROM mode 1 discs, and refuse both to mount CD-ROM XA mode 2 form 1 discs and to play CD-DA discs. After doing a little digging, I discovered that the CDR100 reports differing values for each disc type in response to the READ CAPACITY (0x25) command (i.e. 2048 for mode 1, 2352 for CD-DA, and 2340 for XA mode 2 form 1), and the code to open the device reads this; the disklabel code is married to the fact that the blocksize is a multiple of 512, and thus refuses permission to open the device with a console message "invalid block size nnnn." I solved the problem by hardcoding a return value of 2048 in the READ CAPACITY commands. Now everything works fine. This is an ugly, dumb hack, but not as drastic as it sounds. First of all, the SCSI-3 MMC standard (or at least the draft rev I have), the response of a CD-ROM type device to READ CAPACITY, insofar as block size is concerned, "shall be 2048;" obviously the CDR100 came about in the days of SCSI-2, who says that READ CD-ROM CAPACITY (0x25, but so named because the result is inexact, based on the TOC rather than the data). All data CD-ROM discs I've ever seen are recorded with a logical block size of 2048; there is, of course, XA mode 2 form 2, where the user data area consists of 2336 bytes, but it's not really used for data because it has no ECC. Besides, I don't think the driver would handle it anyway, set up as it is for 2048 byte blocks. So a 2048 byte block is a safe assumption, since anything else would result in an error anyway. Specific to the CDR100 (and many other drives, and MMC-3), 2340 is a valid block size, as are many other values, even though, for example, there are no CD-ROM modes or forms which provide for 2340 bytes of user data. Using MODE SELECT, one can select one of these block sizes, which then include various combinations of additional data, such as EDC, ECC, header and subheader information, sync, and padding. The default for all modes (except for mode 2 form 2, on most drives) is to return user data only. The current mode is determined, not by READ CAPACITY (which relates to the medium, not the drive's status), but by MODE SENSE. Since the drivers are already incapable of utilizing a block size which is not a multiple of 512, and all the other MODE SENSE option return such a block size, my dumb hack should not reduce functionality. It may allow a truncated mode 2 form 2 block to be transferred without error, though. The alternative would be to use MODE SENSE instead of READ CAPACITY. I don't know how that would affect other drives or functionality, however. The ideal situation, in fact, may be to do a MODE SELECT with a block size of 2048, return an error if this fails, otherwise assume the block size is 2048. This would reset the drive to send data only, and fail elegently with mode 2 form 2 discs, which, as I said above, would not work correctly anyway. Also, it should work for any drive, though I have to talk to my engineers about that. I'd like to get a working solution in the kernel, if possible, but want input before I write up the diffs. The simplest thing would be to use my "dumb hack" as a kernel DEFINE, since it shouldn't break anything that already works anyway. It could also be added as a new drive quirk. The most elegent solution, however, would be the above MODE SELECT solution, plus possibly a quirk entry if it turns out not to be compatible with all drives. Finally, I do realize that some OEM-modified CD-ROM drives allow a 512-byte block size, then do the deblocking of 2048-byte records in the drive. This was to maintain compatibility with hard drive code that was dependent on a 512-byte block size. Are these drives supported now, and is anyone using them? I don't think I have any, though I do have an old SunCD that may or may not do it; haven't checked yet. Jason T. Miller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10007170825460.5493-100000>