I'm running 2.6.30-rc2-00446-ga939b96 on a Dell E4300 with a
upgraded-to-Jaunty-mostly Ubuntu install. Using 2.6.28 and 2.6.29.1,
I've successfully burned a dozen CDRs, but since updating to .30-rc1
I've noticed intermittent failures to burn CDRs using wodim at the Gnome
desktop. (Switching back to .29.1 makes wodim reliable again.) There
have been a few different failure modes, but all of them seem to be
associated with these messages in dmesg, which I haven't seen before:
[ 360.740810] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 360.740816] sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current]
[ 360.740820] sr 1:0:0:0: [sr0] Add. Sense: Logical block address out of range
[ 360.740826] end_request: I/O error, dev sr0, sector 0
[ 360.740830] Buffer I/O error on device sr0, logical block 0
(repeated a few dozen times).
I haven't been able to reproduce these messages running wodim at the
console (after "/etc/init.d/gdm stop") so I suspect there's some
interference between wodim and Gnome's desktop device detection.
I've seen the following behavior running wodim under gnome:
1. wodim blocked in D state for >10 minutes, system showing interactive
lagginess. Unfortunately I've not been able to reproduce this to get
wchan info, but I *think* it was showing blk_execute_rq.
2. running wodim triggers DID_OK messages, but wodim seems to be able to
complete writing the ISO and the resulting CDR reads OK.
3. running wodim triggers DID_OK messages, and wodim fails: (but I
think this is just due to the media having been partially written by a
previous iteration of wodim.)
% wodim ubuntu-9.04-rc-desktop-amd64.iso
wodim: No write mode specified.
wodim: Asuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.Device was not specified. Trying to find an appropriate drive...
Looking for a CD-R drive to store 698.17 MiB...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'TSSTcorp'
Identification : 'DVD+-RW TS-U633A'
Revision : 'D200'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Speed set to 4234 KB/s
Starting to write CD/DVD at speed 24.0 in real TAO mode for single session.
Last chance to quit, starting real write in 0 seconds. Operation starts.
Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error
CDB: 2A 00 FF FF FF FF 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x00 (logical block address out of range) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.003s timeout 40s
write track data: error after 0 bytes
wodim: The current problem looks like a buffer underrun.
wodim: It looks like 'driveropts=burnfree' does not work for this drive.
wodim: Please report.
wodim: Make sure that you are root, enable DMA and check your HW/OS set up.
Errno: 5 (Input/output error), close track/session scsi sendcmd: no error
CDB: 5B 00 02 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 72 03 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x72 Qual 0x03 (session fixation error - incomplete track in session) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.340s timeout 480s
cmd finished after 0.340s timeout 480s
wodim: Cannot fixate disk.
I'm running "wodim ubuntu-9.04-rc-desktop-amd64.iso" as a regular user
with group write permissions to /dev/sr0.
I've seen /lib/udev/vol_id running *after* wodim has opened the device,
so I wonder if there's some race condition there.
This is with udev 140-2 and wodim 9:1.1.9-1ubuntu1. .config and
additional information available at:
http://web.hexapodia.org/~adi/sysinfo/1240274989_cvpe4300_2.6.30-rc2-00446-ga939b96/
-andy
On Mon, 20 Apr 2009 18:52:34 -0700
Andy Isaacson <[email protected]> wrote:
> I'm running 2.6.30-rc2-00446-ga939b96 on a Dell E4300 with a
> upgraded-to-Jaunty-mostly Ubuntu install. Using 2.6.28 and 2.6.29.1,
> I've successfully burned a dozen CDRs, but since updating to .30-rc1
> I've noticed intermittent failures to burn CDRs using wodim at the Gnome
> desktop. (Switching back to .29.1 makes wodim reliable again.) There
> have been a few different failure modes, but all of them seem to be
> associated with these messages in dmesg, which I haven't seen before:
>
> [ 360.740810] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [ 360.740816] sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current]
> [ 360.740820] sr 1:0:0:0: [sr0] Add. Sense: Logical block address out of range
> [ 360.740826] end_request: I/O error, dev sr0, sector 0
> [ 360.740830] Buffer I/O error on device sr0, logical block 0
>
> (repeated a few dozen times).
>
> I haven't been able to reproduce these messages running wodim at the
> console (after "/etc/init.d/gdm stop") so I suspect there's some
> interference between wodim and Gnome's desktop device detection.
>
> I've seen the following behavior running wodim under gnome:
>
> 1. wodim blocked in D state for >10 minutes, system showing interactive
> lagginess. Unfortunately I've not been able to reproduce this to get
> wchan info, but I *think* it was showing blk_execute_rq.
>
> 2. running wodim triggers DID_OK messages, but wodim seems to be able to
> complete writing the ISO and the resulting CDR reads OK.
>
> 3. running wodim triggers DID_OK messages, and wodim fails: (but I
> think this is just due to the media having been partially written by a
> previous iteration of wodim.)
>
> % wodim ubuntu-9.04-rc-desktop-amd64.iso
> wodim: No write mode specified.
> wodim: Asuming -tao mode.
> wodim: Future versions of wodim may have different drive dependent defaults.
> wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.Device was not specified. Trying to find an appropriate drive...
> Looking for a CD-R drive to store 698.17 MiB...
> Detected CD-R drive: /dev/cdrw
> Using /dev/cdrom of unknown capabilities
> Device type : Removable CD-ROM
> Version : 5
> Response Format: 2
> Capabilities :
> Vendor_info : 'TSSTcorp'
> Identification : 'DVD+-RW TS-U633A'
> Revision : 'D200'
> Device seems to be: Generic mmc2 DVD-R/DVD-RW.
> Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
> Driver flags : MMC-3 SWABAUDIO BURNFREE
> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
> Speed set to 4234 KB/s
> Starting to write CD/DVD at speed 24.0 in real TAO mode for single session.
> Last chance to quit, starting real write in 0 seconds. Operation starts.
> Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error
> CDB: 2A 00 FF FF FF FF 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 00 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x21 Qual 0x00 (logical block address out of range) Fru 0x0
> Sense flags: Blk 0 (not valid)
> cmd finished after 0.003s timeout 40s
> write track data: error after 0 bytes
> wodim: The current problem looks like a buffer underrun.
> wodim: It looks like 'driveropts=burnfree' does not work for this drive.
> wodim: Please report.
> wodim: Make sure that you are root, enable DMA and check your HW/OS set up.
> Errno: 5 (Input/output error), close track/session scsi sendcmd: no error
> CDB: 5B 00 02 00 00 00 00 00 00 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 72 03 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x72 Qual 0x03 (session fixation error - incomplete track in session) Fru 0x0
> Sense flags: Blk 0 (not valid)
> cmd finished after 0.340s timeout 480s
> cmd finished after 0.340s timeout 480s
> wodim: Cannot fixate disk.
>
> I'm running "wodim ubuntu-9.04-rc-desktop-amd64.iso" as a regular user
> with group write permissions to /dev/sr0.
>
> I've seen /lib/udev/vol_id running *after* wodim has opened the device,
> so I wonder if there's some race condition there.
>
> This is with udev 140-2 and wodim 9:1.1.9-1ubuntu1. .config and
> additional information available at:
>
> http://web.hexapodia.org/~adi/sysinfo/1240274989_cvpe4300_2.6.30-rc2-00446-ga939b96/
>
Is seems unreasonably hard (to me) to work out what low-level driver is
in use when we see bug reports like this.
Trolling your dmesg
(http://web.hexapodia.org/~adi/sysinfo/1240274989_cvpe4300_2.6.30-rc2-00446-ga939b96/dmesg.out)
I see
[ 2.184016] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2.198709] ata2.00: ATAPI: TSSTcorp DVD+/-RW TS-U633A, D200, max UDMA/100, ATAPI AN
[ 2.198774] ata2.00: applying bridge limits
[ 2.214107] ata2.00: configured for UDMA/100
[ 2.230305] scsi 1:0:0:0: CD-ROM TSSTcorp DVD+-RW TS-U633A D200 PQ: 0 ANSI: 5
[ 2.548015] ata5: SATA link down (SStatus 0 SControl 300)
[ 2.884014] ata6: SATA link down (SStatus 0 SControl 300)
so I guess that it's serial ATA, at least.
But which lower-level ata driver is being used under that?
[ 0.717960] ahci 0000:00:1f.2: version 3.0
[ 0.717968] ahci 0000:00:1f.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[ 0.718057] ahci 0000:00:1f.2: irq 27 for MSI/MSI-X
[ 0.718097] ahci: SSS flag set, parallel bus scan disabled
[ 0.718176] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 4 ports 3 Gbps 0x33 impl RAID mode
[ 0.718236] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ems
[ 0.718298] ahci 0000:00:1f.2: setting latency timer to 64
ahci, I guess.
Probably this is all perfectly obvious to the initiated, but for those
whose life revolves around telling the initiated about their bugs, this
is all unreasonably hard :(
Oh well, let's tentatively assume that we have a post-2.6.29 regression
in the libata ahci driver.
Andrew Morton wrote:
> On Mon, 20 Apr 2009 18:52:34 -0700
> Andy Isaacson <[email protected]> wrote:
>
>> I'm running 2.6.30-rc2-00446-ga939b96 on a Dell E4300 with a
>> upgraded-to-Jaunty-mostly Ubuntu install. Using 2.6.28 and 2.6.29.1,
>> I've successfully burned a dozen CDRs, but since updating to .30-rc1
>> I've noticed intermittent failures to burn CDRs using wodim at the Gnome
>> desktop. (Switching back to .29.1 makes wodim reliable again.) There
>> have been a few different failure modes, but all of them seem to be
>> associated with these messages in dmesg, which I haven't seen before:
>>
>> [ 360.740810] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
>> [ 360.740816] sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current]
>> [ 360.740820] sr 1:0:0:0: [sr0] Add. Sense: Logical block address out of range
>> [ 360.740826] end_request: I/O error, dev sr0, sector 0
>> [ 360.740830] Buffer I/O error on device sr0, logical block 0
...
> Oh well, let's tentatively assume that we have a post-2.6.29 regression
> in the libata ahci driver.
I tend to doubt it's a problem in ahci itself, I would guess it's higher
up the stack. Or could be that it's not a kernel bug, just some change
in timing that triggers the problem.
What's supposed to stop udev/hal from poking at the drive while wodim is
writing to the disc, anyway?
On Thu, Apr 23, 2009 at 12:46:19AM -0600, Robert Hancock wrote:
> >Oh well, let's tentatively assume that we have a post-2.6.29 regression
> >in the libata ahci driver.
>
> I tend to doubt it's a problem in ahci itself, I would guess it's higher
> up the stack. Or could be that it's not a kernel bug, just some change
> in timing that triggers the problem.
>
> What's supposed to stop udev/hal from poking at the drive while wodim is
> writing to the disc, anyway?
wodim opens O_EXCL, and it does occasionally complain about not being
able to open, then sleeping and retrying.
-andy
I see two possible problems that should be first resolved.
1) You are using "wodim" instead of cdrecord.
"wodim" is a very old version (4+ years) of cdrecord with
additional bugs. Due to Copyright & GPL violations, it cannot
even be legally distributed.
2) You may be using the linux hald version
I recommend to first get a recent original cdrtools package from
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and to try with this after running "make install" as root.
As Linux requires root privileges for many SCSI commands, you need to
install cdreord suid root which is automatically done via "make install"
as root.
If your problem persists, try to kill hald. Hald on Linux has many problems:
- It looks for the wrong state transitions on the CD drive
and thus distrurbes CD/DVD/BD writing. It may e.g. try to mount a CD
that has not yet been fully written.
- The O_EXCL metod it believes on just cannot ever work correctly:
- You would not be able to read out written media CD-DA or CD-ROM
- You would not be able to deal with multi-session media
- As Linux offers to access CD/DVD/BD-drives vie more than one
device driver and as these device drivers don't know each other
O_EXCL cannot work anyway.
If your problem still persists, you may have a Linux kernel problem.
BTW: please keep me on CC:
J?rg
--
EMail:[email protected] (home) J?rg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling wrote:
> I see two possible problems that should be first resolved.
>
> 1) You are using "wodim" instead of cdrecord.
> "wodim" is a very old version (4+ years) of cdrecord with
> additional bugs. Due to Copyright & GPL violations, it cannot
> even be legally distributed.
>
> 2) You may be using the linux hald version
>
> I recommend to first get a recent original cdrtools package from
>
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> and to try with this after running "make install" as root.
> As Linux requires root privileges for many SCSI commands, you need to
> install cdreord suid root which is automatically done via "make install"
> as root.
>
> If your problem persists, try to kill hald. Hald on Linux has many problems:
>
> - It looks for the wrong state transitions on the CD drive
> and thus distrurbes CD/DVD/BD writing. It may e.g. try to mount a CD
> that has not yet been fully written.
>
Appears to be true, but that's not a kernel problem, it's a hald problem, the
fix belongs there.
> - The O_EXCL metod it believes on just cannot ever work correctly:
>
> - You would not be able to read out written media CD-DA or CD-ROM
>
> - You would not be able to deal with multi-session media
>
I don't quite see how these two follow from using O-EXCL, assuming the device is
released after writing, but see next:
> - As Linux offers to access CD/DVD/BD-drives vie more than one
> device driver and as these device drivers don't know each other
> O_EXCL cannot work anyway.
>
And that is a kernel problem, allowing multiple access paths which don't share
exclusion is a dubious design decision. O_EXCL really should work.
> If your problem still persists, you may have a Linux kernel problem.
>
The usual solution is to tell hald and your window manager of choice not to
mount things automatically, or at least not while they are opened. But that's a
fudge, not a fix, O_EXCL should positively prevent this problem.
> BTW: please keep me on CC:
>
> J?rg
>
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot