----- Original Message -----
From: Kai Harrekilde-Petersen <[EMAIL PROTECTED]>
To: 'Linux-scsi' <[EMAIL PROTECTED]>
Sent: Wednesday, May 17, 2000 7:57 AM
Subject: Re: aha1542 vs. DAT vs. kernel 2.0.x
> Eric wrote:
>
> >>>> Steven:
>
> > > I think perhaps there are at least two bugs here--the one that caused
> > > the (unnecessary?) reset, and the one that didn't properly clean up
> > > the device after the reset.
>
> > The first one I think I already got. The second one I don't know
about.
> > That is why I was thinking I should try adding a disk to the bus with
the
> > screwy cdrom, and see whether the disk is usable after the cdrom is
taken
> > offline.
>
> Taking the entire CDROM drive offline, due to a bad/scratched CD appears
> rather harsh to me (at least for units with removable media. For
> non-removable media units, it is quite reasonable).
I absolutely agree here. The bug that I encountered in 2.3 was that we
would attempt bus resets even though commands were completing with I/O
errors, and ultimately this resulted in the device being taken offline.
Once I fixed it, the I/O errors would be reported up the chain, and you
would get a simple I/O error with no other side effects.
Sometimes the thing would get into a particularly bad section of the
cdrom and the command would time out. It was probably having a hard time
seeking to find a particular sector. It was in these cases that the error
recovery code would attempt abort/reset, etc, and take the thing offline.
A "soft" offline would be reasonable. Actually it is on my list of
things to do to figure out a reasonable way of clearing the offline
condition for exactly cases such as this. The tricky thing is that for the
device to be put in the offline category, the device is (or should be)
unresponsive, and thus probing the thing even for a media change might be a
bit dangerous.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
