>Is there any known problem with cdrecord complaining about the
>writer process with recent kernels?
>I'm not quite sure when it started, but it's there in > 2.1.131
>up to 2.2.0-pre4-ac1.
>It was fine with the same SCSI HW configuration in 2.0.36 also.
I've had trouble in 2.0.36. I've got a K6-200, 64Mb. If I burn
using kernel <= 2.0.35 I can have a free for all process running
extravaganza, 30 netscape windows, pine, fetchmail, kernel
compile, whatever.. and I get a good burn from xcdroast. If I
use 2.0.36 however, I get a frisbee on an idle system if I start
up *ONE* thing that accesses the hard disk, such as a new
invocation of pine, or an invocation of fetchmail (which calls
sendmail/procmail).
I posted about this problem previously to the cdwrite mailing
list, and was told it is likely a media problem. It is not a
media problem however. I took a CDRW and tested 2.0.35/2.0.36
and it is replicable. The burn succeeds in .35, and fails in
.36. Burns succeed in .36 if the system is idle. I even reniced
xcdroast, cdrecord, etc to -20 (which shouldn't make any
difference anyways) and it did affect the length of time that it
took to cause frisbeeness, but it did still produce a bad burn.
My CDRW is *NOT* bad. I have burned several things on that disc
since (in 2.0.35) and in windows, and the disk images are
flawless.
IMHO 2.0.36 is somehow broken when it comes to burning CD's. It
seems like the RT scheduling isn't happening, but I have no idea
how to debug the true problem or where to begin, so my comment is
just mere speculation. Since I do have a CDRW, I am certainly
willing to try and locate the problem, all I need are _detailed_
instructions of what to do to track the problem down. Right now,
I'm falling back to 2.0.35 to get any burns done and still be
able to abuse my computer.
Here is the output of cdrecord from a burn I did a while ago:
Cdrecord release 1.6.1 Copyright (C) 1995-1998 Jrg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,00,00'
scsibus: 0 target: 0 lun: 0
atapi: -1
Device type : Removable CD-ROM
Version : 2
Response Format: 1
Vendor_info : 'HP '
Identifikation : 'CD-Writer+ 7200 '
Revision : '3.01'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags : SWABAUDIO
Track 01: data 621 MB
Total size: 713 MB (70:40.32) = 318024 sectors
Lout start: 713 MB (70:42/24) = 318024 sectors
Current Secsize: -1
ATIP start of lead in: -11640 (97:26/60)
ATIP start of lead out: 337350 (75:00/00)
Disk type: Cyanine, AZO or similar
Manufacturer: CMC Magnetics Corporation
Blocks total: 337350 Blocks current: 337350 Blocks remaining:
19326
RBlocks total: 349030 RBlocks current: 349030 RBlocks remaining:
31006
Starting to write CD/DVD at speed 2 in write mode for single
session.
Waiting for reader process to fill input-buffer ... input-buffer
ready.
Starting new track at sector: 0
/usr/lib/xcdroast-0.96e/bin/cdrecord-1.6.1: Input/output error.
write_g1: scsi sendcmd: retryable error
status: 0x2 (CHECK CONDITION)
CDB: 2A 00 00 00 29 20 00 00 10 00
Sense Bytes: F0 00 03 00 00 00 00 19 00 00 2C B0 0C 09 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x0C Qual 0x09 (write error - loss of streaming) Fru
0x0
Sense flags: Blk 0 (valid)
cmd finished after 3.024s timeout 40s
write track data: error after 21561344 bytes
Sense Bytes: F0 00 00 00 00 00 00 19 00 00 2C B0 00 00 00 00 00
00
Writing time: 82.795s
/usr/lib/xcdroast-0.96e/bin/cdrecord-1.6.1: fifo had 786 puts and
659 gets.
/usr/lib/xcdroast-0.96e/bin/cdrecord-1.6.1: fifo was 0 times
empty and 641 times full, min fill was 97%.
Fixating time: 133.975s
Now, I don't understand all of the above, but when I look at it,
it seems to indicate bad media "Medium Error". Thats fine and
dandy, except it does the same with my CDRW disk and it *ONLY*
does it in 2.0.36, and only when I try and run any apps while
burning. If I then reboot into 2.0.35, and do the exact same
burn, it succeeds and the disk verifies perfectly.
This is VERY strange indeed... Let me know what I can do to try
and put together an adequate bug report that may lead to a
solution.
-- Mike A. Harris - Computer Consultant - Linux advocate
Linux software galore: http://freshmeat.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/