Date: Tue, 12 Sep 1995 20:03:04 -0400 From: Josh Littlefield <josh@American.COM> To: current@freebsd.org Subject: more ATAPI CD issues Message-ID: <199509130003.UAA11780@mozart.american.com>
next in thread | raw e-mail | index | archive | help
I've stuck the -current atapi support into a stock 2.0.5 kernel, and believe I've done it correctly. I've discovered some problems with the atapi code I'd like let people know about. First, I'm running ONLY a CD ATAPI device, no hard disk. I know others have had their own issues with this, but mine seem to be different. My CD is a Sony CDU-55E. First, the current layering of wd.c is obviously not well suited to this configuration. Your ATAPI controller has to react a certain way to particular ATA commands to get to the point of being probed at all as an ATAPI CD. The 3 trials of ATA you must pass are 1) writable byte count / cyl. address registers, 2) successful wdreset(), and 3) successful WDCC_DIAGNOSE behavior. The first test is reasonable, for what its worth. My ATAPI CD fails the current implementation of wdreset(), although the ATAPI spec is pretty specific about how this should be handled and the code looks potentially correct. I need to trace this down more. I get through the WDCC_DIAGNOSE test OK. So, by ignoring wdreset() failure in the wdc probe, I can get my device recognized. At that point the atapi_probe/atapi_attach work just fine and identify the device. The next issue is with the MODE_SENSE issued by the wcd code. It asks for the CDROM Capabilites page (0x2A). It expects this in a 24 byte struct and asks for 24 bytes. However, my ATAPI spec indicates that this page is 28 bytes long, and that's also what my device tries to send. The atapi.c code considers this an overrun (although the device indicates no errors) and leaves the data on the table. By defining the last 4 bytes in the capabilities struct, giving me a 28 byte struct, I succeed with the MODE_SENSE and get valid information. I have a couple of issues/questions with this. First, wcd.c seems to be using too small a struct for this MODE_SENSE command. Perhaps this is version skew on the ATAPI spec? Second, the spec indicates that since a host doesn't know how much data will be returned with a MODE_SENSE, it should rely on the byte count registers from the device. This is probably referring to a request for ALL pages, which returns an unpredictable amount of data. However the spec says that, in general, the host should divert to the bit bucket any excess data offered by the device (and send pad bytes when the device asks for more than is required). Seems like atapi_io() should be less sensitive to overrun/underrun. Finally, even if we consider the byte count in error, it does no good to leave the data there. It would think it better to transfer the data to the bit bucket to finish the command, returning an error. My current (final?) problem is that the TEST_UNIT_READY command issued during wcd driver open never seems to generate an interrupt. I haven't solved this one yet, but it may be related to the state of the IEN bit in wd_ctrl at the end of wdreset(), since this is the first opportunity for the device to interrupt. Which reminds me that the infinite sleeps in atapi.c are less than ideal. BTW, the spec I refer to is the ATAPI for CD-ROMs spec, rev. 2.5 8/10/95. It's marked as "Status: Review Copy" so I guess some parts are in flux. But I figured its accurate for basic information. I believe there was an earlier version as well where I got this, but it was 8MB and this one was 3MB. I found it through the magic of the Internet at ftp://fission.dt.wdc.com/pub/stan dards/atapi/. -josh ======================================================================== Josh Littlefield American Internet Corporation josh@american.com 4 Preston Court tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509130003.UAA11780>