From owner-freebsd-current Thu Sep 21 13:23:25 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA27388 for current-outgoing; Thu, 21 Sep 1995 13:23:25 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA27368 for ; Thu, 21 Sep 1995 13:23:17 -0700 Received: by crox.net.kiae.su id AAA00190; (8.6.9/vak/1.8a) Fri, 22 Sep 1995 00:19:12 +0400 To: current@freebsd.org, josh@American.COM References: Message-ID: Organization: Cronyx Ltd. Date: Fri, 22 Sep 95 00:19:12 +0400 X-Mailer: BML [UNIX Beauty Mail v.1.39] From: vak@cronyx.ru Subject: Re: more ATAPI CD issues Sender: owner-current@freebsd.org Precedence: bulk > 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. This test could fail for single-drive configurations. The driver does not set the drive unit number to 0 before testing the cylinder register. If the BIOS leaves it set to 1, then the test will fail... > 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. The current version of wdreset() is incorrect with respect to ATA specs. I made another version, which works correctly for IDE disks, and uses an ATAPI signature to identify an ATAPI drive. I posted it to freebsd-current list. > 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. Really, it's a problem. Not a bug though, just an incompatibility. A lot of drives, such as Toshiba XM5302, Mitsumi FX400, NEC 260, Dolphin 8001, etc. have 16-byte Capabilities page length, not 20 bytes as it should be according to ATAPI specs. > 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. I tried to fix this in version 1.5 of the driver. I'll send the patches to freebsd-current today. Serge --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development