Re: 2.0.34p11b SCSI (Adaptec) probs?

Doug Ledford (dledford@dialnet.net)
Mon, 27 Apr 1998 18:50:58 -0500


Matthew Kirkwood wrote:
> 2 x Adaptec 2940U's, one with 2x2Gb disks, one with a Yamaha
> CD-rewriter.

> I forget the precise error, but can ruin another CD if requested :-)

I'll probably need this to debug the problem, but before you do ruin another
CD, check out what I have to say further on.

> The error comes from cdrecord, not the kernel, and claims to be retryable,
> but it bombs out shortly after.
>
> The same setup was just fine on 2.0.33, even while the machine was under
> quite heavy load.
>
> Is it likely that the Adaptec changes have caused this to happen,

Yes, it is almost certain the Adaptec changes have an impact on this
problem.

> or the
> hardware on the way out?
>
> More details upon request.

OK....before you go ruining a CD, let me explain what one of the most
important changes in the aic7xxx driver was. Namely, the aic7xxx driver now
properly passes back the sense data from a drive to the upper levels of the
kernel and to the user land software (if using the scsi_generic or
scsi_ioctl interface). The driver in 2.0.33 used to send this data to
never-never land, scribbling on memory and never returning the true state of
the drive to the application program in the process. Fixing this bug alone
is enough to bring up all sorts of problems in software trying to parse the
sense data from a device. Where as the sense data used to be all 0 bytes,
it now has valid sense data and if the software doesn't properly handle this
sense data, then it can puke.

Now, along with proper sense data returns, this seems to have possibly
uncovered a bug in the more generic SCSI layer processing in regards to
specific commands common to CD writers. Namely, the timeout value for some
commands is too short. I haven't looked into the mid level code because I
haven't had the time, but at least one other person is able to cause bus
resets without even doing a real write to his cd recorder. The condition
appears to be something along the lines of the software saying "OK, prepare
for a write", at which point the CD-R starts to check out the CD and make
sure it can write, and in the process, the command times out. I'm not sure
if this is a mid level code thing or the user land software is setting its
own timeout too short, I haven't even looked into how it's done that much.
So, as soon as I can get my hands on a CD-R device and start testing, I'll
get it figured out and fixed.

-- 

Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu