Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Sep 1995 18:37:04 -0400
From:      Josh Littlefield <josh@American.COM>
To:        jdl@chromatic.com
Cc:        current@freebsd.org
Subject:   Re: more ATAPI CD issues 
Message-ID:  <199509152237.SAA19750@mozart.american.com>
In-Reply-To: Your message of "Wed, 13 Sep 1995 22:59:26 CDT." <199509140359.WAA02589@chrome.onramp.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509152237.SAA19750>