From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 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): kdemultimedia-3.1.3-3.1 How reproducible: Always Steps to Reproduce: 1.remove all CDs from CD-ROMs 2.start KsCD 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. Additional info: 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 time around. 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, ascq=0x02) Jun 9 22:08:01 makah kernel: The failed "Read Subchannel" packet command was: 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 every second. 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 suspect.
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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 kdemultimedia-3.5.9-1.fc8
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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 linux-scsi.org or the upstream kscd folks to solve the problem once and for all.