Wolverine (RC1) Mounting a CD-ROM on a SCSI CD-ROM drive connected to an on-board AIC7899 controller spews this information: # mount /dev/cdrom Attached scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0 scsi1 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 1 channel 0. scsi: aborting command due to timeout : pid 0, scsi1, channel 0, id 3, lun 0 Mode Sense 00 2a 00 80 00 sr0: scsi-1 drive No issues with previous betas of RHL7.1 or with RHL7
Doug, is this the configuration bug that you fixed last night?
No, this is totally different. It may not even be an aic7xxx bug. This is an old SCSI-1 CD-ROM drive. It is failing to perform a mode sense command that the sr.c driver is sending out in an attempt to identify certain characteristics of the drive. The return value from the command is unknown here, but from the looks of it, it isn't returning a CHECK_CONDITION, instead it is likely returning some other error. So, the mid layer SCSI code is retrying the command multiple time, and half way through the retries it resets the bus just in case that might help. When the command finally fails, the sr.c driver says "Oh, this must be a SCSI-1 drive then" and prints out a message to that effect. So, conclusions. One, this is a low priority bug. It will happen once at sr.c init time on a small subsection of devices and then not reappear and it is non-fatal (although if you unload the sr driver and then reload it, it must reinit itself and you will see this again then). Two, in order to know why the mid layer code is using the MAY_REDO retry path (which is the one that does a bus reset half way through the allowed number of retries) instead of simply failing the command I would have to know the exact return value of the command in question, and the best and easiest way to get that requires a new kernel with modest changes to scsi_obsolete.c (modify the mid layer to print out the offending return value whenever it issues a synchronous reset). So, if the reporter feels like compiling a kernel module, or testing a kernel module I send him, then we might be able to get somewhere. Otherwise, this is a low-prio bug until I have some device with which I can reproduce the problem (and even my old 4 speed Plextor CD-ROM isn't doing this to me :-(
hmmm.... The drive isn't an old SCSI-1 drive--it is a Plextor UltraPlex WIDE (40x). I didn't see the problems with older releases, hence my conclusion that this was an issue with the driver shipped with Wolverine. Given the other bug I've seen with the driver (28845) that is now fixed I'm wondering if this bug will go away with the fix as well. If I get some time I'll pull down the latest kernel RPMS and try.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/