Messages in this thread | | | Date | Mon, 27 Apr 1998 18:50:58 -0500 | From | Doug Ledford <> | Subject | Re: 2.0.34p11b SCSI (Adaptec) probs? |
| |
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
| |