Is CD burning supposed to work with kernel 2.6.1 using the ATAPI
interface, or are bugs still being worked out?
I have run cdrecord under kernel 2.4.2x and it worked great using the
ATAPI interface like this:
% cdrecord dev=ATAPI:bus,drive,lun
Instant disk information reads, never had to reload media, and burns
were fast and reliable. It worked fine with ide-scsi as well, but I
wanted to get away from that as it is going away. It worked with
several versions of cdrecord equally well.
I'm now running kernel 2.6.1, and using cdrecord with ATAPI is
problematic.
First problem is that cdrecord now must reload media often, runs slowly,
and burns slowly. Reading CD/RW disks burned under 2.6.x is much slower
than those burned under kernel 2.4 (same version of cdrecord in all
cases).
-scanbus works fine:
% cdrecord dev=ATAPI -scanbus
scsidev: 'ATAPI'
devname: 'ATAPI'
scsibus: -2 target: -2 lun: -2
Warning: Using ATA Packet interface.
Warning: The related libscg interface code is in pre alpha.
Warning: There may be fatal problems.
Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
Using libscg version 'schily-0.7'
scsibus0:
0,0,0 0) *
0,1,0 1) 'OPTORITE' 'CD-RW CW5205 ' '180E' Removable CD-ROM
[rest of output snipped]
However, -msinfo doesn't work at all.
With a previously recorded CD/R, I get this:
% cdrecord dev=ATAPI:0,1,0 -msinfo
cdrecord: No disk / Wrong disk!
With a previously recorded CD/RW disc, I get this:
% cdrecord dev=ATAPI:0,1,0 -msinfo
cdrecord: Drive needs to reload the media to return to proper status.
cdrecord: Input/output error. read track info: scsi sendcmd: no error
CDB: 52 01 00 00 00 FF 00 00 1C 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 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 0.000s timeout 240s
cdrecord: Cannot read first writable address
Both are successful and verified burns.
Another problem is that in later 2.4 kernels and 2.6 kernels, I often
have to reload a CD several times before the drive recognizes it. At
first I figured the kernel could not possibly cause this, but it does.
This doesn't happen when using ide-scsi.
It almost seems like cd burning worked in 2.6.0-mm2, but I no longer
have that kernel to test. I could possibly be convinced to rebuild it
if anyone wants to confirm this.
I've had better overall luck using ide-scsi, but since it is going away,
I decided to quit building it.
What should I do to continue debugging this problem?
--
UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com
Charles Shannon Hendrix <[email protected]> writes:
> Is CD burning supposed to work with kernel 2.6.1 using the ATAPI
> interface, or are bugs still being worked out?
>
> I have run cdrecord under kernel 2.4.2x and it worked great using the
> ATAPI interface like this:
>
> % cdrecord dev=ATAPI:bus,drive,lun
I use dev=/dev/hdc. It haven't seen it fail once.
--
M?ns Rullg?rd
[email protected]
On Fri, 16 Jan 2004, Charles Shannon Hendrix wrote:
> I'm now running kernel 2.6.1, and using cdrecord with ATAPI is
> problematic.
I don't find it is. It's rather cdrecord insisting on scanning buses
itself and bitching about direct device names...
> First problem is that cdrecord now must reload media often, runs slowly,
> and burns slowly. Reading CD/RW disks burned under 2.6.x is much slower
> than those burned under kernel 2.4 (same version of cdrecord in all
> cases).
Interesting. I use dev=/dev/hdc and it works fine for me (Plextor 48X),
but then again, I'm also running the latest cdrecord alpha.
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
Sat, 17 Jan 2004 @ 05:22 +0100, Matthias Andree said:
> On Fri, 16 Jan 2004, Charles Shannon Hendrix wrote:
>
> > I'm now running kernel 2.6.1, and using cdrecord with ATAPI is
> > problematic.
>
> I don't find it is.
Well, some of us are lucky that way...
> It's rather cdrecord insisting on scanning buses itself and bitching
> about direct device names...
Scanning busses doesn't appear to be the problem.
>From looking at strace, I see it scanning all devices themselves and
then trying ioctl(3,...) on them if they exist.
It isn't complaining about direct device names at all, and it finds the
right one and attempts to use it.
ioctl() fails with an EIO error a few times and cdrecord prints an error
than it can't read the drive.
> Interesting. I use dev=/dev/hdc and it works fine for me (Plextor 48X),
> but then again, I'm also running the latest cdrecord alpha.
% cdrecord -version
Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
I can try an alpha version, but from running strace on cdrecord, it
seems like Linux is the problem. Several ioctl() calls are failing just
before cdrecord prints an error message and exits.
--
UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com
Charles Shannon Hendrix <[email protected]> writes:
> Sat, 17 Jan 2004 @ 05:22 +0100, Matthias Andree said:
>
>> Interesting. I use dev=/dev/hdc and it works fine for me (Plextor 48X),
>> but then again, I'm also running the latest cdrecord alpha.
>
> % cdrecord -version
> Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
>
> I can try an alpha version, but from running strace on cdrecord, it
> seems like Linux is the problem. Several ioctl() calls are failing just
> before cdrecord prints an error message and exits.
I see similar problems on ppc, with these messages in the log:
Jan 17 16:15:43 whitebox kernel: ide0, timeout waiting for dbdma command stop
Jan 17 16:15:43 whitebox kernel: ide-cd: dma error
Jan 17 16:15:43 whitebox kernel: hdb: DMA disabled
Jan 17 16:15:43 whitebox kernel: hdb: dma error: status=0x50 { DriveReady SeekComplete }
Jan 17 16:15:43 whitebox kernel: hdb: dma error: error=0x00
Jan 17 16:15:43 whitebox kernel: cdrom_newpc_intr: 180 residual after xfer
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Sat, 17 Jan 2004 @ 18:36 +0100, Andreas Schwab said:
> > % cdrecord -version
> > Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
> >
> > I can try an alpha version, but from running strace on cdrecord, it
> > seems like Linux is the problem. Several ioctl() calls are failing just
> > before cdrecord prints an error message and exits.
>
> I see similar problems on ppc, with these messages in the log:
>
> Jan 17 16:15:43 whitebox kernel: ide0, timeout waiting for dbdma command stop
> Jan 17 16:15:43 whitebox kernel: ide-cd: dma error
> Jan 17 16:15:43 whitebox kernel: hdb: DMA disabled
> Jan 17 16:15:43 whitebox kernel: hdb: dma error: status=0x50 { DriveReady SeekComplete }
> Jan 17 16:15:43 whitebox kernel: hdb: dma error: error=0x00
> Jan 17 16:15:43 whitebox kernel: cdrom_newpc_intr: 180 residual after xfer
That's odd because it wasn't that way in 2.4 and the beta 2.6 kernels.
I did see an error trying to load sr_mod when cdrecord runs, presumably
because it is trying to scan my external SCSI burner, which is turned
off.
But "modprobe sr_mod" works fine.
In case it matters, I have a VIA 82Cxxx chipset and an Asus K7V
motherboard, one of those KT133 Pro models.
--
UNIX/Perl/C/Pizza____________________s h a n n o n@wido !SPAM maker.com
On Saturday 17 January 2004 12:36, Andreas Schwab wrote:
>Charles Shannon Hendrix <[email protected]> writes:
>> Sat, 17 Jan 2004 @ 05:22 +0100, Matthias Andree said:
>>> Interesting. I use dev=/dev/hdc and it works fine for me (Plextor
>>> 48X), but then again, I'm also running the latest cdrecord alpha.
>>
>> % cdrecord -version
>> Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg
>> Schilling
>>
>> I can try an alpha version,
Please do, a23 and a25 both work just fine ehre.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty: soap,
ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Sat, Jan 17 2004, Andreas Schwab wrote:
> Charles Shannon Hendrix <[email protected]> writes:
>
> > Sat, 17 Jan 2004 @ 05:22 +0100, Matthias Andree said:
> >
> >> Interesting. I use dev=/dev/hdc and it works fine for me (Plextor 48X),
> >> but then again, I'm also running the latest cdrecord alpha.
> >
> > % cdrecord -version
> > Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
> >
> > I can try an alpha version, but from running strace on cdrecord, it
> > seems like Linux is the problem. Several ioctl() calls are failing just
> > before cdrecord prints an error message and exits.
>
> I see similar problems on ppc, with these messages in the log:
>
> Jan 17 16:15:43 whitebox kernel: ide0, timeout waiting for dbdma command stop
> Jan 17 16:15:43 whitebox kernel: ide-cd: dma error
> Jan 17 16:15:43 whitebox kernel: hdb: DMA disabled
> Jan 17 16:15:43 whitebox kernel: hdb: dma error: status=0x50 { DriveReady SeekComplete }
> Jan 17 16:15:43 whitebox kernel: hdb: dma error: error=0x00
> Jan 17 16:15:43 whitebox kernel: cdrom_newpc_intr: 180 residual after xfer
ppc pmac ide has known problems withe residual data counts for dma
transfers. basically it's a limitation in the ide dma api.
--
Jens Axboe
Charles Shannon Hendrix wrote:
>
> Is CD burning supposed to work with kernel 2.6.1 using the ATAPI
> interface, or are bugs still being worked out?
>
> I have run cdrecord under kernel 2.4.2x and it worked great using the
> ATAPI interface like this:
>
> % cdrecord dev=ATAPI:bus,drive,lun
>
> Instant disk information reads, never had to reload media, and burns
> were fast and reliable. It worked fine with ide-scsi as well, but I
> wanted to get away from that as it is going away. It worked with
> several versions of cdrecord equally well.
>
> I'm now running kernel 2.6.1, and using cdrecord with ATAPI is
> problematic.
>
> First problem is that cdrecord now must reload media often, runs slowly,
> and burns slowly. Reading CD/RW disks burned under 2.6.x is much slower
> than those burned under kernel 2.4 (same version of cdrecord in all
> cases).
>
> -scanbus works fine:
>
> % cdrecord dev=ATAPI -scanbus
> scsidev: 'ATAPI'
> devname: 'ATAPI'
> scsibus: -2 target: -2 lun: -2
> Warning: Using ATA Packet interface.
> Warning: The related libscg interface code is in pre alpha.
> Warning: There may be fatal problems.
> Cdrecord 2.00.3 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
> Using libscg version 'schily-0.7'
> scsibus0:
> 0,0,0 0) *
> 0,1,0 1) 'OPTORITE' 'CD-RW CW5205 ' '180E' Removable CD-ROM
> [rest of output snipped]
>
> However, -msinfo doesn't work at all.
>
> With a previously recorded CD/R, I get this:
>
> % cdrecord dev=ATAPI:0,1,0 -msinfo
> cdrecord: No disk / Wrong disk!
>
> With a previously recorded CD/RW disc, I get this:
>
> % cdrecord dev=ATAPI:0,1,0 -msinfo
> cdrecord: Drive needs to reload the media to return to proper status.
> cdrecord: Input/output error. read track info: scsi sendcmd: no error
> CDB: 52 01 00 00 00 FF 00 00 1C 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 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 0.000s timeout 240s
> cdrecord: Cannot read first writable address
>
> Both are successful and verified burns.
>
> Another problem is that in later 2.4 kernels and 2.6 kernels, I often
> have to reload a CD several times before the drive recognizes it. At
> first I figured the kernel could not possibly cause this, but it does.
> This doesn't happen when using ide-scsi.
>
> It almost seems like cd burning worked in 2.6.0-mm2, but I no longer
> have that kernel to test. I could possibly be convinced to rebuild it
> if anyone wants to confirm this.
>
> I've had better overall luck using ide-scsi, but since it is going away,
> I decided to quit building it.
>
> What should I do to continue debugging this problem?
I believe that you will find that you have to compile for 2.6 on a
machine with /usr/src/linux pointing to the 2.6 kernel source. This is
being discussed elsewhere, but is what got things working for me.
Also note, this is worth doing, you can burn audio CDs using DMA if you
get a good build.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Sun, 25 Jan 2004, Bill Davidsen wrote:
> Charles Shannon Hendrix wrote:
> >
> > Is CD burning supposed to work with kernel 2.6.1 using the ATAPI
> > interface, or are bugs still being worked out?
> >
> > I have run cdrecord under kernel 2.4.2x and it worked great using the
> > ATAPI interface like this:
> >
> > % cdrecord dev=ATAPI:bus,drive,lun
> >
Did a bit of that recently with 2.4, everything was ok except that
fixation, at least for audio CDs under xcdroast, took a _very_ long
time. That box is now running 2.6.1 and using -dev=/dev/hdc : I tested
xcdroast on audio the other day - writing was ok, but it insisted on
reading from 0,0,0 and claimed there was nothing in /dev/hdc. I've just
tested writing a data cd from /dev/hdc and it works fine for me.
I got the impression that under 2.4 dev=ATAPI was not the best way to
go. For 2.6 it seems happy to use the regular device name. Burns at
16x, which is all the drive supports, reads fine on what I've tested.
Suggest you (Charles) try it as -dev=/dev/hdc (or wherever it is).
>
> I believe that you will find that you have to compile for 2.6 on a
> machine with /usr/src/linux pointing to the 2.6 kernel source. This is
> being discussed elsewhere, but is what got things working for me.
>
Surely not! The basic system on that box of mine was put together in
October 2002 (although X, the graphical stuff, and cdrecord were only
compiled two or three months back - 2.6.1 is my first try with 2.6 on
it). I'm a good boy, I don't have /usr/src/linux:
GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.3 20010315 (release).
Compiled on a Linux 2.4.19 system on 2002-10-10.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.9 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <[email protected]>.
ls: /usr/src/linux: No such file or directory
Ken
--
This is a job for Riviera Kid!
Sun, 25 Jan 2004 @ 21:17 -0500, Bill Davidsen said:
> I believe that you will find that you have to compile for 2.6 on a
> machine with /usr/src/linux pointing to the 2.6 kernel source. This is
> being discussed elsewhere, but is what got things working for me.
That should not matter any more.
For what it is worth, the problem appears to be fixed, and in the
wierdest way.
I booted kernel 2.4 without ide-scsi, and it failed to work. Then I
booted 2.4 with ide-scsi, and things were working again.
The burner could not read the last three CDs I burned, one CD/RW, and
the other CD/R's on kernel 2.6.1 and the other on a Windows machine.
Just for the hell of it, I blanked and burned the CD/RW.
Instantly, I could read all of the "problem" CDs.
I booted 2.4 without ide-scsi, and it worked.
I booted 2.6.1 without ide-scsi, and it worked.
It's as if doing that blank and burn operation "fixed" something about
the drive.
I'm hoping to try a few reboots to make sure this drive is working
before fully deciding things are OK, but it certainly looks that way.
--
shannon "AT" widomaker.com -- ["If you tell the truth, you don't have to
remember anything" -- Mark Twain]