Bug 62277 - cdrecord locks computer when blanking a cd-rw disk
Summary: cdrecord locks computer when blanking a cd-rw disk
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 61901 67218 79579 CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2002-03-29 00:22 UTC by Jim Hayward
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:39:28 UTC
Embargoed:


Attachments (Terms of Use)

Description Jim Hayward 2002-03-29 00:22:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314

Description of problem:
Every time I try to blank a cd-rw disk the computer locks completely. It does
this using blank=all or blank=fast. It seems to lock the computer as soon as it
finishes blanking the disc. It displays the amount of time it took to blank the
disc then it locks. When it locks both the caps lock and the scroll lock LED's
are flashing.

I killed this before it started.

# cdrecord -v speed=10 dev=4,0 blank=all
Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jvrg Schilling
TOC Type: 1 = CD-ROM
scsidev: '4,0'
scsibus: 0 target: 4 lun: 0
Linux sg driver version: 3.1.22
Using libscg version 'schily-0.5'
atapi: 0
Device type    : Removable CD-ROM
Version        : 2
Response Format: 2
Capabilities   : SYNC LINKED 
Vendor_info    : 'PLEXTOR '
Identifikation : 'CD-R   PX-W1210S'
Revision       : '1.04'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
Drive buf size : 2394336 = 2338 KB
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 2
  Reference speed: 0
  Is not unrestricted
  Is erasable
  Disk sub type: High speed Rewritable (CAV) media (1)
  ATIP start of lead in:  -11077 (97:34/23)
  ATIP start of lead out: 336075 (74:43/00)
  speed low: 4 speed high: 8
  power mult factor: 2 6
  recommended erase/write power: 5
  A2 values: 14 A4 4A
Disk type:    Phase change
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Blocks total: 336075 Blocks current: 336075 Blocks remaining: 336225
Starting to write CD/DVD at speed 10 in write mode for single session.
Last chance to quit, starting real write in 6 seconds.

Is there anything else I can do to help you try and figure out what the problem is?

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

How reproducible:
Always

Steps to Reproduce:
1. cdrecord -v speed=10 dev=4,0 blank=all
2.
3.
	

Actual Results:  Computer locks when blanking a cd-rw disk

Expected Results:  Blanking a disc to work

Additional info:

Comment 1 Jim Hayward 2002-03-29 01:14:21 UTC
From a tip on the Skipjack mailing I disabled automounting in Gnome and tried
blanking a disc again. With automounting off the computer does not lock up. I
also noticed that the cd does not eject when it is finished blanking the disc
like it did with 7.2. I did not have any problems blanking a disc in 7.2 even
with automounting enabled.

Comment 2 Mike A. Harris 2002-03-29 11:05:02 UTC
Nothing has changed in the package since 7.2, just a rebuild basically.
I've burned 3 CD's in the last few days, and 2 CDRW's - blanking first.
It has worked ok for me so far.

Keep in mind also CDRW drives should be on their own unshared cable,
because when a disk is blanking, the cable is locked and no other disk can
communicate on the cable.  If your hard disk is on that cable, then your
system will hang.  One could cast the blame on the ATA standards, or on the
CDRW drive manufacturer.. either way, it still hangs.

Also, as you discovered the GNOME auto foo stuff hoses cd burning as well.
This isn't a bug per se as much as it is a lack of a feature.  We are
discussing how to solve issues like this in a friendly manner without
hangs, etc.



Comment 3 Jim Hayward 2002-03-29 13:55:48 UTC
After finding that turning off the Gnome automounting works around this problem
I do not believe this to be an issue with cdrecord. I just have no idea what
might be the problem. This problem definitely does not exist for me with 7.2.
Note my comment about about the flashing caps lock and scroll lock leds when the
computer locks. I get the impression that something is causing the kernel to
oops. I also cannot reproduce this problem while not in X. Also note these are
not IDE cdrom drives.

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
<Adaptec 2930CU SCSI adapter>
kernel:         aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
kernel: 
kernel:   Vendor: TEAC      Model: CD-ROM CD-532S    Rev: 1.0A
kernel:   Type:   CD-ROM                             ANSI SCSI revision: 02
kernel:   Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.04
kernel:   Type:   CD-ROM

Any ideas about how I might be able to diagnosis this further?

Comment 4 Alan Cox 2002-04-01 23:56:29 UTC
Can you repeat the problem while in console mode - the flashing keys indicate a
kernel panic occurred and the actual message is rather important.

Comment 5 Jim Hayward 2002-04-02 02:30:23 UTC
Well I after trying it numerous ways I finally managed to get the kernel to
panic at the console. The only way I could get it to panic at the console was to
first startx, then CTRL-ALT-F2, then login again,  then cdrecord -v speed=10
dev=4,0 blank=fast.

I know I have to run the output through ksymoops for it to do you any good, but
it doesn't seem to produce an Oops file. Is there a way force it to produce one?
Or do I just have to carefully copy the output by hand from screen?

It looks like this is going to have something to do with the aic7xxx module. I
see a couple references to it in the output to the console. Thanks.

Comment 6 Bugzilla owner 2004-09-30 15:39:28 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
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.