Bug 28868 - (SCSI AIC7XXX)[aic7xxx] strange SCSI errors when mounting SCSI CD
Summary: (SCSI AIC7XXX)[aic7xxx] strange SCSI errors when mounting SCSI CD
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-22 15:21 UTC by Chris Runge
Modified: 2008-08-01 16:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-30 15:38:55 UTC

Attachments (Terms of Use)

Description Chris Runge 2001-02-22 15:21:31 UTC
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

Comment 1 Michael K. Johnson 2001-02-22 15:56:20 UTC
Doug, is this the configuration bug that you fixed last night?

Comment 2 Doug Ledford 2001-02-22 19:49:54 UTC
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 :-(

Comment 3 Chris Runge 2001-02-24 14:17:29 UTC

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.

Comment 4 Bugzilla owner 2004-09-30 15:38:55 UTC
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

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/

Note You need to log in before you can comment on or make changes to this bug.