From Bugzilla Helper:
User-Agent: Mozilla/5.7 [en] (Win98; U)
Description of problem:
My new laptop has a CD on /dev/hdb. It is a 1.6GHz but performed much
slower than the old 0.5GHz laptop. After some testing i became
convinced that the settings in cd-capplet to check data or audio
CDs interferes rather badly with linux if the controller is shared
with a disk that contains the system. The task at fault is called
magicdev.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1.check data or audio CD action
2.hdparm -t /dev/hda a few times
3.uncheck it
4. hdparam -t /dev/hda a few times
Actual Results: 2-> very fluctuating , from 8 to 18 MB/sec
4-> consistent 21 MB/sec
Expected Results: the checking should perhaps be done less often, or perhaps
could check if the CD is on IDE and shared with / or so....
in that case perhaps lower the frequency.
Or perhaps add an interfce to cd-capplet to allow the user
to select a frequency of checking (how is this done, just
polling??? there was nothing obvious to magicdev)
Additional info:
The fact that i didnt notice this on the old laptop is probably
because they don't share the IDE controller (old one used /dev/hdc).
I tried measuring it on my desktop, but the CD is SCSI and found
it (not too surprisingly) not to matter too much.
It's a serious error though, the buttons below don't let me
choose an appropriate option it seems since there isn't
loss of data or memory, just unacceptably slow :-)

I just checked a new fresh installation of rh73 on the same model laptop
(a Dell 8200) and by default the settings of cd-capplet are such that
the IO problem will be present.
On the good side of things, KDE seems to suffer from the same problem.
A casual check of the sourcecode of magicdev appears to show devices are
checked only every 1000 ms, or 1s. So, it's still a mystery to me how it
can interfere with traffic on /dev/hda so badly.
I have another machine where I believe i also have a CD shared with /, this
would be another testcase. It could also be that the hardware on this laptop
is peculiar as to aggrevate this 'problem'.
Btw, most of the Dell8k series laptops should have this problem, since they most
have a CD or DVD on /dev/hdb. Some have a a DVD in hdb, and the CD in hdc, if
two multimedia are used. I decided to get the combo version instead.

In general, I very much that sharing a bus should be sufficient
to trigger this problem; more likely its a bug in your CD-ROM
drive.
I don't see any possible interval that would be both non-intrusive
and useful; it sounds like all that's really possible for you
is to turn off the automount feature.
Can you provide the model information from /proc/ide/hd*/model ?
A blacklist in magicdev is possible.

more /proc/ide/hd?/model
::::::::::::::
/proc/ide/hda/model
::::::::::::::
IC25T060ATCS05-0
::::::::::::::
/proc/ide/hdb/model
::::::::::::::
HL-DT-STCD-RW/DVD-ROM GCC-4240N
and there are not suspicious - or any for that matter - messages in
/var/log/messages.
Btw, note again that KDE seems to suffer from same. We also tracked down a
solution, i.e. Programs -> Settings -> Peripherals -> CD Properties.
It also brings up a window very similar to cd_capplet, and if turned off
the IO is acceptable again, and hdparm will show a normal throughput on
an idle system (which has been our testcase to test good vs. bad).

I have a Dell C840 with the exact same harddrive and CD model combo. I was
observing very slow startup times and reported it in bug 73661, but only
determined the problem was with 'magicdev' recently.
How do I disable magicdev in gnome? Currently I just kill the process.
Also, I installed RH 8.1 beta (Phobe) and in that release magicdev doesn't seem
to exhibit the same problem.

I'd like to add that I have a Dell Inspiron 8200 with a DVD/CDRW drive and
magicdev was causing excruciatingly slow performance, which I only discovered
after a lot of searching on the web. The only solution I've discovered is rpm -
e magicdev.
I've read other people having this problem (a reviewer noted that his Open
Office launch times were 90+ seconds --- I was getting 100 seconds on my 2 GHz
Dell), so it might not be restricted to Inspirons.

One thing that would be interesting to know is whether the commands
that magicdev is sending to the drive are taking a long time to
complete. You should be able to determine this by, when logged
into GNOME.
A) Make sure that magicdev is enabled in the 'gnome-cd-properties'
dialog.
B) Run:
$ killall magicdev
$ strace -T -o /tmp/log -e open,close,ioctl magicdev
Wait for about a minute then kill it.
C) Attach the resulting log file to this bug report

The above strace output that I just attached was just while running magicdev on
an Inspiron 8200 with no other activity. I can also try running an strace while
trying to do something else (launch OpenOffice)... as noted above, while running
magicdev on an I8200, launching OpenOffice takes 100+ seconds, as opposed to 15
seconds, normally.