Bug 91684 - (IDE)Kernel 2.4.20-13 panic after CD burn
Summary: (IDE)Kernel 2.4.20-13 panic after CD burn
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-27 07:23 UTC by Rodi Evers
Modified: 2007-04-18 16:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:41:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Rodi Evers 2003-05-27 07:23:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Description of problem:
I've installed the kernel-2.4.20-13 by downloading the update and installing it
by running "rpm -Uvh kernel-2.4.20-13.8.i686.rpm". Since then, *after* burning a
CD (with cdrecord), the kernel panics with blinking leds (Caps Lock & Scroll
Lock) and the system hangs. No information is found in the system logs regarding
this problem. I'm using a PlexWriter 24/10/40A. I can reproduce the problem
using the command "/usr/bin/cdrecord  eject speed=10 dev=0,0,0
driveropts=burnproof blank=all". The disc is blanked, then the leds start
blinking, and system hangs. Since I ran the update with the -Uvh options, I can
no longer choose an older kernel from grub (stupid?!).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run "/usr/bin/cdrecord  eject speed=10 dev=0,0,0 driveropts=burnproof
blank=all", but probably every burn results in crash (though the cd *is* burned).
2. leds blink
3. system hangs

Actual Results:  total crash

Expected Results:  return to prompt

Additional info:

Comment 1 Craig Lawson 2003-06-04 16:49:46 UTC
I see the same thing with RH 9, kernel 2.4.20-13.9.
It seems OK with RH 9, kernel 2.4.20-9.

I am using similar hardware with cdrecord's "blank=fast" option.

Some details: I am using CD-RW media, 4x write speed. When using bad media, the 
SCSI layer complains but the system doesn't crash. With good media, 
reproducability is less than 100%. I am using the "cdbk" backup app (available 
from SourceForge) which first blanks and then writes a file system to the CD. I 
have been unable to complete a single back-up because the system crashes either 
during the blanking or during the file system write. So although reproducability 
is < 100%, it's high enough that the CD is essentially unusable.

Comment 2 Craig Lawson 2003-06-13 23:58:57 UTC
2.4.20-18.9 has the same problem.

Comment 3 shahada abubakar 2003-06-15 06:08:27 UTC
I have a similar problem with my RH8.0 (up2dated) when attempting cdrecord on my
2.4.20-18.8 kernel. If I run cdrecord from the console prompt (rather than X) I
see a SCSI timeout followed  by a kernel panic. In my case it happens 100% of
the time, a few seconds after the drive starts writing. Am using a LITE-ON
Model: LTR-40125S Rev: ZS0N. Problem is the same whether I have DMA on or off.

It was working with an older kernel on RedHat 8.0, and the cdwriter works fine
from W2K.

Comment 4 Matt McClure 2003-07-15 04:51:49 UTC
I get a complete hang using gtoaster to burn a data CD with cdrecord.

[mlm@carter mlm]$ uname -r
[mlm@carter mlm]$ rpm -q cdrecord gtoaster
[mlm@carter mlm]$

Comment 5 Craig Lawson 2003-08-09 22:34:52 UTC
It seems OK with RH 9, kernel 2.4.20-19.9.

Comment 6 Bugzilla owner 2004-09-30 15:41:00 UTC
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

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.