This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 11144 - GNOME causes slow SCSI CD-ROM reads
GNOME causes slow SCSI CD-ROM reads
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-01 10:12 EDT by jhubbs
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-19 12:45:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jhubbs 2000-05-01 10:12:52 EDT
This system is based on a 700-MHz Athlon, K7V motherboard.  There is an
SIIG AP-10 SCSI controller on which I have connected a Ricoh CD-RW drive.

The OS version is RH 6.2.

When in GNOME, if I insert a CD and type a command like this from a shell:

cp -av /mnt/cdrom /home/test

The first dozen-odd files shoot over and the remainder just sort of "leaks"
over - maybe a file every 1-2 seconds, even if the files are only 20-50K.
I strongly suspected a CD-RW or SCSI controller problem until I noticed
that outside of X, the problem went away.  I started KDE and the problem
was gone.  It seems to only occur when in GNOME.  I suspect it may have
something to do with the automount feature, which doesn't seem to be
enabled or present in your 6.2 distribution's KDE setup.
Comment 1 Preston Brown 2000-05-08 10:52:59 EDT
make sure you have magicdev turned off in the control panel.
Comment 2 jhubbs 2000-05-24 15:54:59 EDT
<snip>
------- Additional Comments From pbrown@redhat.com  05/08/00 10:52 -------
 make sure you have magicdev turned off in the control panel.
<snip>

I'm sorry, but I don't find your response very helpful.  Are you saying that
magicdev is SUPPOSED to screw up CD-ROM reads??  If so, why is it even in your
distribution??  Is there another way, in KDE or GNOME, to obtain automounting of
CDs and floppies?

- Jeff

- Jeff
Comment 3 Elliot Lee 2000-07-17 18:16:55 EDT
> Are you saying that
> magicdev is SUPPOSED to screw up CD-ROM reads??  If so, why is it even in your
> distribution??  Is there another way, in KDE or GNOME, to obtain
> automounting of CDs and floppies?

It is not "supposed to" - it is inevitable. To check for the presence or
abscence of a disk requires reading from the drive, which will interfere with
other pending operations.

I agree that it is not desirable for this to happen, but there is no other way
to do it.
Comment 4 jhubbs 2000-07-18 09:37:37 EDT
In that case, I question the logic on which the whole scheme is based.  I would think that the act of reading from a CD is evidence enough that a CD is in 
fact in the drive; why is it necessary or "inevitable" to have to interrupt that process to the extent that the CD-ROM drive runs at a tiny fraction of its rated 
speed to test a fact that the OS already knows?  This is more than simply "undesirable;" it's downright shoddy and does not illustrate Red Hat's to be a 
"quality" distribution.

Comment 5 Martijn 2000-09-20 11:28:32 EDT
Have you read the docs? /usr/src/linux/Documentation/cdrom/cdrom-standard.tex
explains why this isn't inevitable at all.
Comment 6 Elliot Lee 2000-09-20 17:59:12 EDT
I'm always willing to accept patches that show my stupidity up. Until then, I
remain unconvinced - for example, just reading from a CD is not going to work
with audio CD's.
Comment 7 Owen Taylor 2001-02-07 19:09:09 EST
Magicdev does not read from the device - it opens it in
non-reading mode (O_NONBLOCK) and does some ioctls.

This is a kernel bug.
Comment 8 Elliot Lee 2001-02-19 12:45:24 EST
Perhaps assigning this to a kernel person would be in order, then...
Comment 9 Michael K. Johnson 2001-02-21 11:42:08 EST
Different CDROM device deal differently with being queried.  For this
hardware, the workaround is to simply disable magicdev.  For other
hardware, this bug doesn't happen.  But I do believe it to be related
to the particular CDROM device you have.

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