On Wed, 18 Dec 1996 13:22:47 -0600 
 "Marshall Midden" <m4@nts.umn.edu> wrote:

 >       /netbsd: sd9(esp1:1:0): not ready, data = ...  (if you accessed via df/dd)

Ok... So, the ccd access didn't generate these errors, either?  The ccd
is layered... when the ccd fires off a request to the underlying component,
the component errors should be reported by their drivers, as well...

In any case, it might be worth exploring the possibility of:

	- issuing START to the device
	- requeuing buffer

when a NOT READY condition is encountered during a data transfer to/from
a disk device.  (This should be safe, since the disk was `ready' when
it was opened the first time...)

If you'd like to investigate adding that code, I'd appreciate it... I don't
really have time to do so, myself.  If you need pointers on where to start,
I can help you with that.

 > Else, since it was in the middle of a ccd:
 >       /netbsd: ccd0: error 5 on component 4
 > 
 > And when I powered the last component (sd10) I got:
 >       /netbsd: ccd0: error 5 on component 8
 > 
 >   ccd0 0 0 /dev/sd1g /dev/sd2g /dev/sd3g /dev/sd4g /dev/sd5g \
 > 	   /dev/sd8g /dev/sd8h /dev/sd9g /dev/sd10g
 > 
 > So, if 4 is the 2nd to the last one, and the 8 is the last one -- what
 > are the
 > other seven numbered?

Right, so this was a bug in the computation of the component number.
Thankfully, the component number, as was bogusly computed, was used
_only_ for error reporting :-)  I've committed the patch I sent you
(CC port-sparc) previously which should fix the problem.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939