Subject: Re: scsi sub-system
To: Marshall Midden <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 12/18/1996 11:31:29
On Wed, 18 Dec 1996 13:22:47 -0600
"Marshall Midden" <firstname.lastname@example.org> 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 email@example.com
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