Red Hat Bugzilla – Bug 63281
CD-R(W) access conflicts hang kernel
Last modified: 2008-08-01 12:22:52 EDT
Description of Problem: Attempting to write to a CD-R(W) while playing audio tracks hangs the kernel. Yes, I know this sounds like a silly thing to do; read on... Version-Release number of selected component (if applicable): Kernel: 2.4.9-31 i686 cdrecord: 1.10-4 gtcd: 1.2.3 CPU: Pentium 3 933Mz RAM: 256 Mb Plextor CD-RW PX-W1610A Rev: 1.03 ATAPI How Reproducible: 100% Steps to Reproduce: 1. Prepare to create a multi-session CD. The first session will contain audio tracks. Choose material at least several minutes long. 2. Use cdrecord to write the first session to the CD-R. 3. Use cdrecord to write the second session to the CD-R. In my case, my second session was an ISO data image. 4. While cdrecord is preparing to write the second session, start a CD player, such as gtcd, and play the audio tracks. Actual Results: cdrecord will attempt writing, but will be unable to, as the laser is positioned elsewhere for reading. The CD player will continue playing, but the track will occasionally be reset to the beginning, presumably because cdrecord has moved the head. System load will increase. The CD player will not respond to clicks on the "stop" button, and cdrecord does not respond to ctrl-C. After 15-30 seconds of this, the cursor disappears, and the CD player display no longer updates, and X does not respond to ctrl-alt-backspace (or C-A-delete), and the screen is frozen. Except for the audio still playing through the sound card, the system is hung. Two resets were required to reboot the system from this state! Yow! I found a bunch of these in my system log: Apr 11 01:34:10 localhost kernel: ISOFS: unable to read i-node block Apr 11 01:34:10 localhost kernel: hdd: command error: status=0x51 { DriveReady SeekComplete Error } Oh, yeah, so why did I start playing the audio while attempting to write? I didn't, really. After the first session was complete, Gnome recognized an audio CD in the drive and automatically opened the CD player. This happened while cdrecord was doing its count down for the second session. Before I knew what was happening (see the time from the log, above), it was doomed. I prevented this from happening again by disabling the auto-play preference. Expected Results: Several alternatives would be acceptable. (a) cdrecord could time out if it is unable to write data. It would probably ruin a CD-R, but a hard reset has that same potential; (b) Refuse to allow CD players to play audio tracks while cdrecord has the device open for writing, or vice versa; (c) Allow both cdrecord and CD players to be interruptable when something funny is going on.
This has nothing to do with Nautilus, Nautilus isn't even involved in what happens (magicdev happens to access the CD device; but it could as easily be anything else). a) as per another bug in here somewhere, there must be a way to lock the CD device. This can be a userspace convention, it can be F_SETLK, or it can be a new system call; but the docs or feature must be in the kernel or other system-level package. If I put such docs or feature in the GNOME packages, then cdrecord etc. will NOT use it. The kernel (and some small set of other things) form our hardware abstraction layer. At that level the concurrent access problem must be solved. If I don't have a way to lock the CD device, I can't fix this bug. b) I don't think the kernel should export system calls to userspace that let you lock the kernel, anyhow (isn't this a security issue?), but I don't know enough about the issue to say that definitively. Anyway, I do not want to see this bug on any GNOME package until I have a way to lock the CD device that I can ask cdrecord to use. Feel free to pass the buck to "distribution" or something instead of kernel. ;-) But I need the locking problem solved below the desktop layer before I can do anything about it. cc'ing Bill since maybe he owns just-above-the-kernel packages that could address the locking issue.
BTW, to me mandatory locking has a lot of appeal here vs. advisory, since the consequences of concurrent access are pretty dire.
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 persists. 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/