Message-Id: <20090422144904.407df635.akpm@linux-foundation.org>
Date:	Wed, 22 Apr 2009 14:49:04 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andy Isaacson <adi@...apodia.org>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [2.6.30-rc2] CD-R: wodim intermittent failures: [sr0] Add.
 Sense: Logical block address out of range, sector 0

On Mon, 20 Apr 2009 18:52:34 -0700
Andy Isaacson <adi@...apodia.org> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists