From owner-freebsd-current Fri Sep 15 15:37:49 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA12478 for current-outgoing; Fri, 15 Sep 1995 15:37:49 -0700 Received: from mozart.american.com (mozart.american.com [204.253.96.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA12473 for ; Fri, 15 Sep 1995 15:37:45 -0700 Received: from localhost (localhost [127.0.0.1]) by mozart.american.com (8.6.12/8.6.9) with SMTP id SAA19750; Fri, 15 Sep 1995 18:37:05 -0400 Message-Id: <199509152237.SAA19750@mozart.american.com> X-Authentication-Warning: mozart.american.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.3 12/28/94 To: jdl@chromatic.com cc: current@freebsd.org Subject: Re: more ATAPI CD issues In-reply-to: Your message of "Wed, 13 Sep 1995 22:59:26 CDT." <199509140359.WAA02589@chrome.onramp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Sep 1995 18:37:04 -0400 From: Josh Littlefield Sender: owner-current@freebsd.org Precedence: bulk >> The 3 trials of ATA you must pass are 1) writable byte count / cyl. address >> registers, >> >> The first test is reasonable, for what its worth. > > Hmm. Not sure I agree here. My POS NEC 260 fails this test badly. > Not sure why. I (w)hacked it out to get even vague functionality... Wow. Writable byte count registers are pretty much mandatory for atapi to work at all, since they are the way of communicating ATAPI packet sizes and data lengths. The best explanation I can think of is that this is not really a good test. I'm not sure there is really any guarantee that this register will read the same as its written. For ATAPI, one writes it to indicate the size of data desired to be read or written. One reads it AFTER SENDING A PACKET COMMAND, and when BSY is gone to find out about the subsequent device needs for data transfer. Even the length of time the register is supposed to contain info the device has generated is only until the first data register access. Other parts of the spec indicate that the device should place its "signature" (0xEB14) in the cnt_hi/lo registers and maintain it until the first ATAPI command is recieved, which might explain the need to generalize this test to checking for != 0xFF after the write. All in all, sounds like a bogus "test". > Hmm.. You may need Serge's latest and greates patch that I alude to above. > With minor work, I could dredge this up for you if you don't have it. I don't have this, and it doesn't appear that -current does either. Could you send it? >From some behavior I've noticed where the drive gets stuck in an aborted command state (and stays there across a reboot), I'm wondering why there appears to be no code which ever issues an ATAPI SRST command. Seems like that might be a good thing to do, both initially during probe or attach, and maybe also during ioctl reset. -josh ======================================================================== Josh Littlefield American Internet Corporation josh@american.com 4 Preston Court tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334