Red Hat Bugzilla – Bug 59541
Writing CDs fails on HP CD-Writer+ 8290
Last modified: 2005-10-31 17:00:50 EST
First of all: I'm burning CDs since more than two years under Linux, Redhat 6.2,
Redhat 7.2 and different SuSE distributions worked absolutely proper on that.
Since I've moved to RedHat 7.2 i have terrible problems creating CDs. I have
tried with kernel 2.4.7 and 2.4.9, id didn't work. I've downloaded kernel 2.4.17
and built the kernel by myself. First this worked (I've burned at least 2 CDs),
but after some more kernel configuration the same problem occurs now, and I
don't know how to get rid of it. I have tried the newest cdrecord version (the
author recommended that), but it didn't change the situation. I think it has
something to do with the SCSI system, expecially the ide-scsi module. Here's the
typical output I receive from cdrecord:
scsibus: 1 target: 1 lun: 0
Linux sg driver version: 3.1.22
Cdrecord 1.11a13 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jvrg Schilling
TOC Type: 0 = CD-DA
Using libscg version 'schily-0.5'
Device type : Removable CD-ROM
Version : 0
Response Format: 1
Vendor_info : 'HP '
Identifikation : 'CD-Writer+ 8290 '
Revision : '1.3C'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags : SWABAUDIO
Supported modes: TAO PACKET RAW/R16 RAW/R96R
FIFO size : 4194304 = 4096 KB
Track 01: audio 50 MB (04:58.10) no preemp pad
Track 02: audio 36 MB (03:36.03) no preemp pad
Track 03: audio 40 MB (03:58.65) no preemp pad
Track 04: audio 35 MB (03:28.37) no preemp pad
Track 05: audio 38 MB (03:47.10) no preemp pad
Track 06: audio 41 MB (04:06.15) no preemp pad
Track 07: audio 35 MB (03:33.73) no preemp pad
Track 08: audio 54 MB (05:22.82) no preemp pad
Track 09: audio 38 MB (03:47.84) no preemp
Track 10: audio 37 MB (03:43.05) no preemp pad
Track 11: audio 34 MB (03:22.39) no preemp pad
Track 12: audio 42 MB (04:11.35) no preemp pad
Track 13: audio 104 MB (10:20.74) no preemp pad
Track 14: audio 35 MB (03:29.73) no preemp pad
Track 15: audio 36 MB (03:34.02) no preemp pad
Track 16: audio 36 MB (03:34.83) no preemp pad
Track 17: audio 42 MB (04:13.30) no preemp pad
Track 18: audio 42 MB (04:11.74) no preemp pad
Total size: 786 MB (77:54.17) = 350563 sectors
Lout start: 786 MB (77:56/13) = 350563 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, high Beta category (A+) (3)
ATIP start of lead in: -12513 (97:15/12)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Long strategy type (Cyanine, AZO or similar)
Manuf. index: 22
Manufacturer: Ritek Co.
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 9286
Starting to write CD/DVD at speed 2 in dummy mode for single session.
Waiting for reader process to fill input buffer ... input buffer ready.
Starting new track at sector: 0
Track 01: 1 of 50 MB written (fifo 100%).cdrecord: Input/output error.
write_g1: scsi sendcmd: no error
CDB: 2A 00 00 00 02 52 00 00 1B 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 4.590s timeout 40s
Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
write track data: error after 1397088 bytes
Writing time: 12.441s
WARNING: Some drives don't like fixation in dummy mode.
Fixating time: 0.004s
The problem occurs, no matter if a audio or data CD is burned.
I hope someone can help me to get rid of this problem!
I've solved the problem! Nothing is wrong with the kernel or cdrecord (in this
special case). The problem is, that the automounter tried to mount the CD while
cdrecord was burning it. Now that I switched of auto mounting, everything work
THat autorun stuff is evil. Pure evil. Dunno what will be the
longterm solution for that problem, but I hope it gets solved
sometime before long either in autorun, the kernel, cdrecord or
some combination of the 3. ;o) More of a lack of a feature than
a bug though. I'm going to close it since you got it working with
the workaround. I'll poke the cdrecord author and kernel folk about