Red Hat Bugzilla – Bug 122417
KsCD produces excessive errors when CD not loaded
Last modified: 2008-06-25 15:36:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
When KsCD is launched and a CD is not loaded, KsCD will send to syslog:
CDROM not ready. Make sure there is a disc in the drive.
once every second!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.remove all CDs from CD-ROMs
3.tail -f /var/log/messages
Actual Results: From syslog:
May 2 10:01:45 host kernel: sr0: CDROM not ready. Make sure there is
a disc in the drive.
May 2 10:02:16 host last message repeated 31 times
May 2 10:03:17 host last message repeated 61 times
May 2 10:04:18 host last message repeated 61 times
May 2 10:05:19 host last message repeated 61 times
May 2 10:06:20 host last message repeated 61 times
May 2 10:07:21 host last message repeated 61 times
May 2 10:08:22 host last message repeated 61 times
May 2 10:09:23 host last message repeated 61 times
May 2 10:10:24 host last message repeated 61 times
May 2 10:11:25 host last message repeated 61 times
May 2 10:12:26 host last message repeated 61 times
May 2 10:13:27 host last message repeated 61 times
May 2 10:14:28 host last message repeated 61 times
May 2 10:15:29 host last message repeated 61 times
May 2 10:16:30 host last message repeated 61 times
May 2 10:17:31 host last message repeated 61 times
Expected Results: KsCD will issue the "CDROM not ready" once if there
is no CD ready.
It is quite normal to not have an Audio CD for KsCD to play
right away. One might launch KsCD at login and maybe insert
a CD to play a few hours later. In the mean time, syslog
has been sent a few hundred "CDROM not ready" messages.
Not only does it waste syslog bandwidth, it tends to allow
sysadmins who monitor syslogs for problems.
is the autorun running on your machine (ps -xa) ? does this problem
exist, if you kill it from process list?
There is no autorun process on our machines. In our environment,
we do need nor want to use autorun.
No need for autorun. (Always the first thing I uninstall.) Session
management is enough to restart KsCD if you were running it the last
With Fedora Core 2 the KsCD-triggered messages are not the same as
RHEL. They're even more verbose and annoying. Example:
Jun 9 22:08:01 makah kernel: ATAPI device hda:
Jun 9 22:08:01 makah kernel: Error: Not ready -- (Sense key=0x02)
Jun 9 22:08:01 makah kernel: (reserved error code) -- (asc=0x30,
Jun 9 22:08:01 makah kernel: The failed "Read Subchannel" packet
Jun 9 22:08:01 makah kernel: "42 02 40 01 00 00 00 00 10 00 00 00
00 00 00 00 "
Being a five-line message there's no "last message repeated ..."
compression. You get the full five-line message in /var/log/messages
And as if that's not enough, if you're logged in to the console
these message come there as well, every second.
The kernel is actually the one generating the messages, not KsCD.
OK fine. Somewhere between KsCD and the kernel there ought to be a
way for KsCD to politely poll the CD-ROM drive without cluttering
the logs and the console.
(And yes my CD drive is on /dev/hda. It's just the way things came
out with an SATA hard drive in the mix.)
I guess it could be that KsCD checks for the type of medium in the
drive, without checking first if there is a medium in the drive.
it's not reproduceable in RHEL4 Beta1. it's fixed in next RHEL4 release
sorry, it still happens if booting kernel with hdx=ide-scsi.
it's not a bug in kscd but in sr_mod module (kernel). Only this module
generates this message kernel. reassign to kernel component.
This is a very old bug with little to no chance of being fixed. Closing as WONTFIX.
This is back in current Fedora devel because of the recent changes to libata I
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Apr 3 09:43:04 cynosure kernel: sr0: CDROM not ready. Make sure there is a
disc in the drive.
Apr 3 09:44:05 cynosure kernel:last message repeated 60 times
Based on he above report, I would say that this bug is still an issue.
Also in latest rawhide.
Comment #13 shows the bug is an fc8. Comment #15 shows that it is also in
rawhide. Should the version change to 8 or should it remain as rawhide?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
The fix being requested here isn't really an appropriate fix to carry in the
Fedora space. This needs to be done upstream, either in the kernel or in kscd.
The problem is that kernel people think that kscd should check if there is a
disc present before trying to issue an audio specific read command to the drive,
and the kscd authors think that because ide-cd allows this and scsi cd doesn't,
that's it's obviously a kernel issue (some kernel people might argue the bug is
in ide-cd, not sr, and *both* should generate these errors). So, until one side
or the other does something to settle this, the issue lingers. And until they
settle this, whatever we might do in Fedora would have to be carried as a custom
patch forever. Since I don't want to sign maintainers in Fedora up for a
permanent carry forward patch, I'm closing this and suggesting that people
approach either firstname.lastname@example.org or the upstream kscd folks to solve
the problem once and for all.