[CLUE-Tech] Nasty CD burner behavior

[Matt Gushee]

Hi, All--

Well, I got a new (used) CD burner yesterday. It's a TEAC CD-W516EC, an
internal ATAPI model rated for 16X writing. The machine I installed it
on had a dead CD-ROM, so I just stuck the new device in its place. So
it's the only device on the second IDE cable, jumpered as master, and
started out with a Linux device name of /dev/hdc -- of course, I need
SCSI emulation to burn CDs on it, so I set up SCSI emulation, and it's
now known to the system as /dev/scd0.

Here's some system information:

  Debian GNU/Linux 3.0 (Woody)
  Custom-compiled 2.4.18 kernel with the following as modules:
    SCSI generic support
    SCSI cd-rom support
    SCSI emulation
    (is that a bad idea? is it safer to have them compiled in to
      the kernel?)
  File systems: / is ext2, all other Linux partitions are ReiserFS
  cdrecord v. 1.10
  

Then I went to burn my first CD. Now, the machine with the burner
doesn't normally have its own keyboard and monitor; I run it remotely
through SSH. So I opened up an SSH session in an Rxvt, and ran cdrecord
at 16X.  The startup sequence seemed to go normally, and it began
writing. As far as I can recall, the cdrecord progress message was
indicating normal progress as long as it was visible. The write was up
to 41 of 647 blocks, and I decided I didn't need to keep watching, so I
minimized the Rxvt.

A few moments later, I noticed that the CD burner didn't seem to be
making any sound, and its LED was dark. That was a little odd, but I
waited a few more minutes. Then I brought up the Rxvt and, lo and
behold, the progress message still said "41 of 647 tracks". And the
Rxvt session was dead: no response to keystrokes. So then I tried to ssh
into the box from another window, but no go: it was off the network.

So it *appears* that my minimizing the Rxvt caused cdrecord to fail, and
the cdrecord failure either took down networking, or caused a kernel
panic, or ... I don't know what. I checked the logs after bringing the
machine back up, but I couldn't find any record of unusual incidents at
that time.

I tried again later, and got a good CD. I did two things differently the
second time: I dropped the speed to 8X, and left the Rxvt alone during
the write. But I have a couple questions about this:

  Does it make sense that minimizing a terminal window would cause
  cdrecord to fail? (why should a window event on one machine have any
  effect at all on a remote process running in that window?) If so, how
  can I avoid that in the future? Would running cdrecord in the
  background prevent this kind of thing?

  Obviously, I'm not particularly keen on reproducing the failure, but
  I'd like to be prepared to capture some useful information in case it
  ever does happen again. Any idea how I can do that? Is there an option
  to syslog that would take care of this?
  
-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee at havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)