Bug 63281 - CD-R(W) access conflicts hang kernel
CD-R(W) access conflicts hang kernel
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-11 19:25 EDT by Craig Lawson
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:29 EDT
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 Craig Lawson 2002-04-11 19:25:14 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.
Comment 1 Havoc Pennington 2002-04-12 09:25:32 EDT
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.
Comment 2 Havoc Pennington 2002-04-12 12:29:12 EDT
BTW, to me mandatory locking has a lot of appeal here vs. advisory, since the
consequences of concurrent access are pretty dire.
Comment 3 Bugzilla owner 2004-09-30 11:39:29 EDT
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/

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