Bug 34433 - Magicdev breaks cdrecord
Magicdev breaks cdrecord
Product: Red Hat Linux
Classification: Retired
Component: magicdev (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
David Lawrence
: 76218 83826 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-04-03 02:57 EDT by Edward Kuns
Modified: 2013-03-13 00:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-25 13:13:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Edward Kuns 2001-04-03 02:57:06 EDT
cdrecord absolutely fails to successfully record anything on a CD-R if
magicdev is running.  I don't know what the cause is, but this is 100%
reproducable here.  If I kill magicdev, all works.

I use this via xcdrecord ... if magicdev is running, the last message I
see in the xcdrecord status window is:

    Starting new track at sector: 0

and there it hangs.  Indefinitely.  If I eject and reinsert the CD-R,
cdrecord wakes up and errors out, but I have coastered the CD-R.

And again, if I kill magicdev, I don't have a single problem.

I've most recently reproduced this with QA0328 ... but I have also seen
this with earlier releases as well.  I haven't tried this with 7.0,
so I don't know if this is a new problem or not.  (And I don't run
magicdev on kilroy, my always-live, non-beta machine.)
Comment 1 Owen Taylor 2001-08-01 15:08:32 EDT
Basically, this is just a problem with lousy hardware that
breaks if a test-unit-ready command is sent while recording
is in process. Douglas Gilbert (the ide-scsi maintainer) has 
some ideas about how to work around this problem.at the
scsi layer.

Comment 2 Owen Taylor 2002-10-31 17:40:54 EST
*** Bug 76218 has been marked as a duplicate of this bug. ***
Comment 3 Tom Trebisky 2003-02-06 18:28:13 EST
Under RH 8.0 it is absolutely clear that having magicdev active
breaks cdrecord.  I didn't have a clue what was wrong (and why my
burner had mysteriously failed), but someone told me to go to 
preferences>cd-properties and disable "mount on insertion".
I remember having to shoot magicdev in the head back in RH6 or 7
days for some other reason.  More trouble than it is worth in
my opinion.  This could be fixed by a change in policy (like
shipping with magicdev disabled and warning about this ugly
behaviour if it is), or by adding some kind of locking so that
magicdev backs off which a CD is being burned.  I would have been
pretty upset if I went out and bought a new burner and found out
that magicdev was to blame.

  On a scsi Yamaha burner CRW2100S after burning
the disk and in the midst of "Fixating" I get:

Track 01: 383 of 383 MB written (fifo 100%).
Track 01: Total bytes read/written: 402030592/402030592 (196304 sectors).
Writing  time:  775.378s
cdrecord: Input/output error. close track/session: scsi sendcmd: no error
CDB:  5B 00 02 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 06 00 00 00 00 0A 00 00 00 00 29 00 00 00
Sense Key: 0x6 Unit Attention, Segment 0
Sense Code: 0x29 Qual 0x00 (power on, reset, or bus device reset occurred) Fru
0Sense flags: Blk 0 (not valid)
cmd finished after 32.053s timeout 480s
cmd finished after 32.053s timeout 480s
Fixating time:   45.080s
cdrecord: fifo had 6333 puts and 6333 gets.
cdrecord: fifo was 0 times empty and 6192 times full, min fill was 90%.
make: *** [burn] Error 254
Comment 4 Owen Taylor 2003-02-11 14:20:08 EST
*** Bug 83826 has been marked as a duplicate of this bug. ***
Comment 5 John (J5) Palmieri 2004-08-25 13:13:08 EDT
Closing bug.  Magicdev has been removed in favor of
gnome-volume-manager in the development branch.

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