From owner-freebsd-hackers  Mon Sep 18 01:35:03 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA07999
          for hackers-outgoing; Mon, 18 Sep 1995 01:35:03 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA07991
          ; Mon, 18 Sep 1995 01:34:53 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA14431; Mon, 18 Sep 1995 18:30:56 +1000
Date: Mon, 18 Sep 1995 18:30:56 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199509180830.SAA14431@godzilla.zeta.org.au>
To: jehamby@lightside.com, sos@freebsd.org
Subject: Re: atapi.c and wcd.c missing....
Cc: davidg@root.com, hackers@freebsd.org, vak@cronyx.ru
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> Has anyone reported bugs with the ATAPI support failing for IDE disks?  
>> If so, which version are you using?  If these problems have been 
>> resolved, I would like to see IDE CD-ROMs supported in the GENERIC 2.1.0 
>> kernel (you'll sell more Walnut Creek CD-ROMs for sure :-)

Yes.  All versions.  Not resolved yet.

>The 1.3 version is in -current (I committed the patches last week)
>And yes  it still has problems with some old IDE disks that gets
>confused by the ATAPI probestuff. I'm not sure taht this is solvable
>at this point...

The probe begins with wdreset() which is already weakened (broken) to
pass both IDE drives and IDE cdroms.  The following bugs in wdreset()
are known:

1) it doesn't do a drive select, so it may be reading the status register
   for a random drive.
2) it only looks at the status register for one drive.
3) if all drives and cdroms followed the specs, then it should be testing
   for (dk_status == 0x50) (which implies that a drive is attached) ||
   (dk_status == 0x00) (which implies that a cdrom is attached).  It
   actually tests for ((dk_status & 0x50) == 0x00) which passes drives,
   cdroms, and anything that sets the 0x50 bits to 0x10 or 0x40 and the
   other bits to 0x00.
4) some drives set the 0x02 bit in dk_status.

There may be a problem when wdreset() is called from wdunwedge().
wdunwedge() knows to reset some internal state for drives.  It doesn't
know anything about cdroms.

Bruce