From owner-freebsd-current  Wed Sep 13 21:00:34 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA16291
          for current-outgoing; Wed, 13 Sep 1995 21:00:34 -0700
Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA16282
          for <current@freebsd.org>; Wed, 13 Sep 1995 21:00:32 -0700
Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id WAA02589; Wed, 13 Sep 1995 22:59:27 -0500
Message-Id: <199509140359.WAA02589@chrome.onramp.net>
X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol
To: Josh Littlefield <josh@American.COM>
cc: current@freebsd.org
Subject: Re: more ATAPI CD issues 
In-reply-to: Your message of "Tue, 12 Sep 1995 20:03:04 EDT."
             <199509130003.UAA11780@mozart.american.com> 
Reply-To: jdl@chromatic.com
Clarity-Index: null
Threat-Level: none
Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code.
Net-thought: If you meet the Buddha on the net, put him in your Kill file.
Date: Wed, 13 Sep 1995 22:59:26 -0500
From: Jon Loeliger <jdl@chrome.onramp.net>
Sender: current-owner@freebsd.org
Precedence: bulk

Apparently, Josh Littlefield scribbled:
> 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.

Serge, has your "latest" patch to me been incorporated into a 1.4 release
and plunked into the tree yet?


> 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.

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...


>  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.

Agreed.  I even read the ATAPI driver from the L camp, and it clearly
black-holes the overruns and white-holes the needed extras.

> 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.

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.

jdl