I have to report the same behaviour here at my computer, after upgrading to
2.0.36, something with my configuration is badly broken and recording with
absolutely no additional activity went away two times yesterday.
In my case 2.0.36-pre13 was perfect and didn't show any such behaviour...
I have the scsi-idle-patch installed and had scsi-idle running yesterday and
now I wonder if this may be the cause? The recording reported something
about bus-reset, sorry that I didn't write the whole msg down, but if
anybody is interested I can try to reproduce the problem and record it...
additional installed kernel-patches are ncr53c810a-0.1a, sg_patch_2_0,
awe-driver, ...
Dschau.. Dominik
> -----Ursprüngliche Nachricht-----
> Von: Mike A. Harris [SMTP:mharris@ican.net]
> Gesendet am: Dienstag, 19. Januar 1999 01:15
> An: Heinz Mauelshagen
> Cc: Linux Kernel mailing list; mge@u9ete.ez-darmstadt.telekom.de; Alan
> Cox
> Betreff: Re: cdrecord trouble with recent kernels
>
> On Tue, 5 Jan 1999, Heinz Mauelshagen wrote:
>
> >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/
-
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/