linux-kernel - Re: [2.6.30-rc2] CD-R: wodim intermittent failures: [sr0] Add. Sense: Logical block address out of range, sector 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2009 00:46:19 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Andy Isaacson <adi@...apodia.org>, 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

Andrew Morton wrote:
> 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

...

> 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?
--
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/