linux-kernel - Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs

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:	Mon, 05 Oct 2009 17:55:00 -0400
From:	Valdis.Kletnieks@...edu
To:	Joerg.Schilling@...us.fraunhofer.de (Joerg Schilling)
Cc:	linux-kernel@...r.kernel.org, shawn.starr@...ers.com
Subject: Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

On Mon, 05 Oct 2009 13:11:51 +0200, Joerg Schilling said:
> >Model is: 
> >Unable to burn DVDs with 2.6.31.x
> 
> >ata7.00: ATAPI: PIONEER DVD-RW  DVR-111D, 1.29, max UDMA/66
> >scsi 6:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-111D 1.29 PQ: 0 ANSI: 5
> 
> >sr 6:0:0:0: [sr0] Unhandled sense code                                                                        

> Please note that this is not cdrecord but a defective fork where someone

Please note that it doesn't matter if it's Joerg's Officially Blessed Cdrecord
or not - the question is if userspace should be able to cause that error
to happen  *at all*.

Also, it's quite possible that we're looking at a *kernel* regression, that
the userspace software managed to actually *work* with previous kernels, even
if it wasn't blessed by you:

>> I thought maybe this was due to something with kernel config but I'm not sure
>> now. This used to work fine.

If it breaks when somebody upgrades their kernel, it's probably the kernel's
fault, not the user's fault for using a distro that ships The Other Fork.

> It is very likely that this problem does not occur with the original
> cdrecord from:

> ftp://ftp.berlios.de/pub/cdrecord/alpha/

Yes, but his distro probably feels it can't ship the original cdrecord
so it ships wodim instead.  And if it's indeed a kernel bug, replacing
a forked userspace program to work around a kernel bug is The Wrong Answer.

It forked 3 whole years ago, Joerg.  Let it go already. And if you can't
let it go, at least ask the user *helpful* questions, like Jeff Garzik did:

> Can you post full dmesg output?  And you have verified that vanilla 
> 2.6.30 kernel works OK?

Content of type "application/pgp-signature" skipped