[PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Shawn Starr]

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                                                                                      
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE                                                           
sr 6:0:0:0: [sr0] Sense Key : Medium Error [current]                                                                        
Info fld=0x0                                                                                                                
sr 6:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error                                                                      
end_request: I/O error, dev sr0, sector 0                                                                                   
Buffer I/O error on device sr0, logical block 0                                                                             

wodim (cdrecord):

Errno: 5 (Input/output error), reserve track scsi sendcmd: no error
CDB:  53 00 00 00 00 00 1D 60 3C 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 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.006s timeout 40s
wodim: Cannot open new session.

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

Anyone also able to confirm something broke or if I'm enabling something in 
.config I shouldn't be?

Thanks, 
Shawn.

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Jeff Garzik]

On 10/01/2009 10:15 PM, Shawn Starr wrote:
>
> 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
> sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sr 6:0:0:0: [sr0] Sense Key : Medium Error [current]
> Info fld=0x0
> sr 6:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
> end_request: I/O error, dev sr0, sector 0
> Buffer I/O error on device sr0, logical block 0
>
> wodim (cdrecord):
>
> Errno: 5 (Input/output error), reserve track scsi sendcmd: no error
> CDB:  53 00 00 00 00 00 1D 60 3C 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 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.006s timeout 40s
> wodim: Cannot open new session.
>
> I thought maybe this was due to something with kernel config but I'm not sure
> now. This used to work fine.
>
> Anyone also able to confirm something broke or if I'm enabling something in
> .config I shouldn't be?

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

	Jeff

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Joerg Schilling]

>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                                                                                      
>sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK 
>driverbyte=DRIVER_SENSE                                                           
>sr 6:0:0:0: [sr0] Sense Key : Medium Error 
>[current]                                                                        
>Info fld=0x0  
>sr 6:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
>end_request: I/O error, dev sr0, sector 0
>Buffer I/O error on device sr0, logical block 0

>wodim (cdrecord):

>Errno: 5 (Input/output error), reserve track scsi sendcmd: no error
>CDB:  53 00 00 00 00 00 1D 60 3C 00
>status: 0x2 (CHECK CONDITION)
>Sense Bytes: 70 00 05 00 00 00 00 0E 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.006s timeout 40s
>wodim: Cannot open new session.

Please note that this is not cdrecord but a defective fork where someone
did rip off the working DVD support from the cdrecord original source and 
replaced it with something half baken. Wodim (this is what you used)
does not retrieve information about the medium and this is why it is
very probable that wodim fails when trying to send a SCSi command that is
related to the actual free size on the medium.

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

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

I've seen similar reports before in the net and reports from users that
reported success after upgrading to the original software.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

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?


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Joerg Schilling]

Valdis.Kletnieks@vt.edu wrote:

> > 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:

Just in case you don't know:

It is the fork that cannot be distributed legally because the fork has been 
made to be in conflict with the copyright law. And it is the fork that is still
full of bugs that never have been in the original software. The fork did see 
some speudo activity in the time between september 2006 and May 6th 2007 but it
is dead since then. 

You can help: Ask your Linux distributor why he distributes an illegal and 
buggy fork instead of the legal original software!

The fork is a problem caused by a hostile packetizer, see:

http://cdrecord.berlios.de/private/linux-dist.html

We, the OSS creators need to find a way to deal with hostile downstreams. Don't
look away when free software is atackedby hostile downstreams....

Back to the original topic: I cannot help you if you don't understand that
I was of course answering to the problem of the OP and the only kernel problem
I can see in the OP is that the kernel should of course not print such "error"
messages at all as errors from SCSI pass through commands are not handled by 
the kernel but by the application program that is the only instance that knows 
whether a specific SCSI error should be exposed to the user.

As I mentioned before, the OP reported a problem that I've seen before elsewhere 
and that problem was reported to disappear after upgrading to cdrecord.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

On Tue, 06 Oct 2009 00:15:48 +0200, Joerg Schilling said:
>                                                        The fork did see 
> some speudo activity in the time between september 2006 and May 6th 2007 but it
> is dead since then.

http://cdrkit.org/releases/ says differently:

[ ]	cdrkit-1.1.3.tar.gz	26-Mar-2007 20:38 	1.4M
[ ]	cdrkit-1.1.4.tgz	01-Apr-2007 20:12 	1.4M
[ ]	cdrkit-1.1.5.1.tar.gz	21-Apr-2007 09:54 	1.3M
[ ]	cdrkit-1.1.5.tar.gz	21-Apr-2007 09:24 	1.3M
[ ]	cdrkit-1.1.6.tar.gz	06-May-2007 15:44 	1.3M
[ ]	cdrkit-1.1.7.1.tar.gz	17-Mar-2008 21:47 	1.4M
[ ]	cdrkit-1.1.8.tar.gz	25-May-2008 23:02 	1.4M
[ ]	cdrkit-1.1.9.tar.gz	26-Oct-2008 23:17 	1.4M

Slow-moving maybe, but hardly "dead". 

> The fork is a problem caused by a hostile packetizer, see:

> http://cdrecord.berlios.de/private/linux-dist.html

Which says:

"Although there is no "project" activity on the "fork" anymore since more than
28 months (which is more than three times of the speudo activity period), there
are still people who spread incorrect claims on both the original project and
the fork. Please help the free original project by correcting these incorrect
claims."

Unfortunately, "there are still people who spread incorrect claims" seems to
include one Joerg Schilling. Please fix your incorrect "28 months" claim, and
all similar issues.  It will help your original project's credibility.

It also says:

"In all programs of the fork that send SCSI commands, you may be unable to
access any of the CD/DVD/Blu-Ray drives at all if you are on Linux-2.6.8.1 or
later. This is due to a missing workaround for the Linux kernel interface
change that happened with Linux-2.6.8.1."

If this is the SCSI command filtering that was cleared up in 2.6.12, you
probably owe it to users to point out that little detail.  2.6.12 is over 4
years ago.  Given that when the fork happened, 2.6.17 was already current, I
could see why they didn't forward-port the fix for an issue that was only a
problem then if your kernel was already more than 2 years old, and instead just
put in doc/plattforms/README.linux:

 - Linux kernel versions between 2.6.8 and 2.6.11 are known to have invasive
   SCSI command filtering which makes the use of wodim almost inpossible or
   complicated for non-root users. Avoid those kernel versions, unless they
   have been patched to disable that filtering.

So this claim, although possibly technically correct, is vastly misleading,
especially 4 years later.

> You can help: Ask your Linux distributor why he distributes an illegal and 
> buggy fork instead of the legal original software!

Apparently it's distributed because their legal team doesn't think it's an
illegal fork, and it's still buggy because after you relicensed to CDDL, they
felt they couldn't backport your fixes to the original GPL code.

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Shawn Starr]

On October 2, 2009 10:46:49 am Jeff Garzik wrote:
>Can you post full dmesg output?  And you have verified that vanilla 
>2.6.30 kernel works OK?
>
>        Jeff

I have not tried stock .30 kernel, I did try .32-rc2 vanilla and still no go. 
I can test .30 however this week. 

On October 5, 2009 11:43:55 pm Valdis.Kletnieks@vt.edu wrote:
> On Tue, 06 Oct 2009 00:15:48 +0200, Joerg Schilling said:
...
> 
> > You can help: Ask your Linux distributor why he distributes an illegal
> > and buggy fork instead of the legal original software!
> 
> Apparently it's distributed because their legal team doesn't think it's an
> illegal fork, and it's still buggy because after you relicensed to CDDL,
>  they felt they couldn't backport your fixes to the original GPL code.
> 

Listen, I don't care about that who forked what. if wodim or cdrecord is 
broken in design, then it's time for a cdrecord-ng and start over please.  I 
don't want to see this bickering anymore.

We're just damaging users. We really should not be rehashing CD/DVD burning 
issues over again when there's much, much more pressing issues that need to be 
fixed.

Joerg, For one thing, I want to be able to access the burner devices with 
their proper /dev name. Just like any other sane unix tool like, even dd. (you 
used to resist this idea if I remember correctly on MLs) not the SCSI bus IDs, 
honestly, what are you trying to achieve here?? make it EASY for users, not 
harder.

Also, maybe if you cooperated a little better we can clean up this stinking 
pile of mess. 

Sincerely,  
Shawn.

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Joerg Schilling]

Shawn Starr <shawn.starr@rogers.com> wrote:

> On October 2, 2009 10:46:49 am Jeff Garzik wrote:
> On October 5, 2009 11:43:55 pm Valdis.Kletnieks@vt.edu wrote:
> > On Tue, 06 Oct 2009 00:15:48 +0200, Joerg Schilling said:
> ...
> > 
> > > You can help: Ask your Linux distributor why he distributes an illegal
> > > and buggy fork instead of the legal original software!
> > 
> > Apparently it's distributed because their legal team doesn't think it's an
> > illegal fork, and it's still buggy because after you relicensed to CDDL,
> >  they felt they couldn't backport your fixes to the original GPL code.
> > 
>
> Listen, I don't care about that who forked what. if wodim or cdrecord is 
> broken in design, then it's time for a cdrecord-ng and start over please.  I 
> don't want to see this bickering anymore.

As mentioned already, wodim is based on a 4+ year old cdrecord source with 
wodim specific bugs added but with not a single additional feature or bug fix 
related to the original software.

I cannot understand why some Linux distibutors still believe that their users 
accept to be forced to use broken forked software while working original 
software with even many new features is available for free.


> We're just damaging users. We really should not be rehashing CD/DVD burning 
> issues over again when there's much, much more pressing issues that need to be 
> fixed.

You could try to help convincing the Linux distributors. The problem with the
hostile downstream started more than 5 years ago, it is sad to see that there is
no mechanism in the OSS world to reliably recover from problems that have been 
caused by hostile downstreams.

> Joerg, For one thing, I want to be able to access the burner devices with 
> their proper /dev name. Just like any other sane unix tool like, even dd. (you 
> used to resist this idea if I remember correctly on MLs) not the SCSI bus IDs, 
> honestly, what are you trying to achieve here?? make it EASY for users, not 
> harder.

You ask me to do something that is not granted to work and that is not compliant
with the ANSI-X10t3 standard. You ask me this although there is absolutely no 
need for a change as the current implementation of cdrecord works nicely on 30
platforms.

------------important-------------->
As cdrecord implements the "auto-target" feature since August 2006 (since 
November 2006 even for Linux), 99% of the users do not need to care about the 
dev= option anymore at all. These users have one single drive that is detected 
automatically by cdrecord and libscg in case you simply omit dev=.
<------------important--------------

Note that cdrecord depends on libscg which is the oldest and most portable 
generic SCSI pass though implementation I am aware of (I wrote the first 
version for SunOS in August 1986). Today (if you count all Microsoft operating 
systems as one only), libscg supports 30 different operating systems. 

Only 9 (counting NetBSD/OpenBSD/DragonFly separately) of the 30 supported 
operating systems allow to specify /dev/something at all for sending SCSI 
commands.

4 of the latter (including FreeBSD) implement the ANSI X10t3 CAM standard that
defines the same addressing scheme as libscg uses.

Even though people believe that Mac OS X is a "UNIX variant", it does not 
implement /dev/* interfaces but something relly strange (see "DeviceKIT"). 

As you see, using /dev/* is only possible on a minority of the supported 
plaforms, so depending on /dev/* is definitely a mistake. As we all know that 
even on Linux, the name of the related /dev/* entries to access the drives 
changed many times in the past, cdrecord is bringing you stability on top of a 
changing platform. Even if dev=/dev/* _may_ work for some of the supported 
devices on Linux, I cannot grant you that it will work in the future.

> Also, maybe if you cooperated a little better we can clean up this stinking 
> pile of mess. 

If you like to address the speudo problems that are mentioned by some Linux 
users, this is obviouyls mainly a missunderstanding of the general constraints
in the background by some people who do know nothing but Linux.

If we look at GNOME, it is unfortunately also a problem of a GUI that likes to 
be portable but that does not look at other possible target platforms while
defining to use Linux only interfaces for important tasks (thus causing 
portability problems). I hope that this is a problem that can be solved by 
talking with each others....

If we look at hald (the Linux variant), this is an application that mainly 
implements an incorrect strategy in order to detect media changes and as a 
result of this incorrect strategy, it interrupts the burning process. These 
problems also could have been avoided if the authors of the Linux hald did ask
me _before_ implementing. It still could be fixed now.

I am cooperating with all people who also like to cooperate and I e.g. annunce 
interface changes for cdrtools to my known "users" (i.e. authors of GUIs and 
other front ends for the cdrtools) at least 3-5 years before I implement them.
I hope that for the future we can again have a good cooperation with the Linux 
kernel development (as we had before ~ 2001).

BTW: As we are on the topic, I would like e.g. to see Linux supporting hard 
links on ISO-9660+Rockridge. Any interest in implementing it? I did make the
implementation for Solaris in 2006, so it would be easy to implement it for 
Linux by just looking at my Solaris "hsfs" implementation.

PP.S. I would also like to see Linux to support the sparse file interface I 
defined together with Sun in 2004. This interface is based on lseek whence
values SEEK_HOLE and SEEK_DATA and on *pathconf(*, _PC_MIN_HOLE_SIZE);
This allows star to create 100% correct copies of sparse files.

In case you don't know: while GNU tar does not implement a single Linux specific
feature, star does implement many Linux specific features.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Re: [PROBLEM][2.6.31.1] - Cannot burn DVDs - PIONEER DVD-RW DVR-111D

[Joerg Schilling]

Valdis.Kletnieks@vt.edu wrote:

> On Tue, 06 Oct 2009 00:15:48 +0200, Joerg Schilling said:
> >                                                        The fork did see 
> > some speudo activity in the time between september 2006 and May 6th 2007 but it
> > is dead since then.
>
> http://cdrkit.org/releases/ says differently:
>
> [ ]	cdrkit-1.1.3.tar.gz	26-Mar-2007 20:38 	1.4M
> [ ]	cdrkit-1.1.4.tgz	01-Apr-2007 20:12 	1.4M
> [ ]	cdrkit-1.1.5.1.tar.gz	21-Apr-2007 09:54 	1.3M
> [ ]	cdrkit-1.1.5.tar.gz	21-Apr-2007 09:24 	1.3M
> [ ]	cdrkit-1.1.6.tar.gz	06-May-2007 15:44 	1.3M
> [ ]	cdrkit-1.1.7.1.tar.gz	17-Mar-2008 21:47 	1.4M
> [ ]	cdrkit-1.1.8.tar.gz	25-May-2008 23:02 	1.4M
> [ ]	cdrkit-1.1.9.tar.gz	26-Oct-2008 23:17 	1.4M
>
> Slow-moving maybe, but hardly "dead". 

Even a corpse may slowly move, at the least when maggots are inside ;-)


The fact that you see "new versions" does not prove _project_ _activities_.
Do you like to call single char changes in man pages "project activity"?
In a lazy week, cdrtools change more than cdrkit changed since May 6th 2007.

Since the version that the fork was based on, more than 30% new code and 
features have been added to cdrtools and more than 50% of all code was replaced 
or rewritten in the original project. People who continue to use the fork
contiunue to use software from 2005 with even bugs added. Do you like to
continue to use a Linux kernel from 2005?

Do you like to use software (like cdrkit) where the maintainers just ignore bug 
reports? If you sum up all related bugs from all Linux distributors, you will 
find more than 100 distinct bugs in the fork. None of these bugs (even very 
easy to fix ones) has been fixed since May 6th 2007. This is why I call the fork
"unmaintained". Does this help you to understand my message?


> > The fork is a problem caused by a hostile packetizer, see:
>
> > http://cdrecord.berlios.de/private/linux-dist.html

> Unfortunately, "there are still people who spread incorrect claims" seems to
> include one Joerg Schilling. Please fix your incorrect "28 months" claim, and
> all similar issues.  It will help your original project's credibility.

OK, I fixed this and changed 28 to 30 and reworded a bit...
What other problems do you see?


> It also says:
>
> "In all programs of the fork that send SCSI commands, you may be unable to
> access any of the CD/DVD/Blu-Ray drives at all if you are on Linux-2.6.8.1 or
> later. This is due to a missing workaround for the Linux kernel interface
> change that happened with Linux-2.6.8.1."

This is correct!

There are two problems that have been introduced at the time when Linux-2.6.8.1
did came out.

One was: The SCSI over ATA transport was ripped out off the SCSI subsystem.

The other: The Linux kernel interface did get an incompatible change that 
caused applications (like cdrcord), that conform to the official interface 
descriptions to fail, while it did help applications that did depend on a 
recently introduced Linux kernel security bug. This is a sad fact as the 
applications that depend on the security bug are developed on Linux but as
a result are non-portable to other platforms. 

Note that these programs are mostly GUIs and due to the complexity of GUI 
system libraries, you cannot do complete security audits on GUI programs and
as a result, sysadmins do not like GUIs to be installed suid root. Porting the
related applications to other platforms would force them to be installed suid 
root in order to be able to work :-(

> If this is the SCSI command filtering that was cleared up in 2.6.12, you
> probably owe it to users to point out that little detail.  2.6.12 is over 4
> years ago.  Given that when the fork happened, 2.6.17 was already current, I
> could see why they didn't forward-port the fix for an issue that was only a
> problem then if your kernel was already more than 2 years old, and instead just
> put in doc/plattforms/README.linux:

You may not know that the incompatible interface change in the Linux kernel
has been introduced less than a seek before cdrtools-2.01-final was released.
For this reason, we have been in a code-freeze phase and all I could do at that 
time was to add a message that told the users to downgrade to a Linux kernel
from a time before the incompatible change was introduced.

Sidenote begin ----->
I hope that in future, interface changes in the Linux kernel are avoided. If 
they are needed, they should be announced to the related "consumers" of the
interfaces early anough in order to allow to write a workaround. Note that
many applications and GUIs depend on cdrtools and I tend to announce 
incompatible interface changes 5 years before I implement them.
<----- Sidenote end

Because of a high workload with OpenSolaris activities, I did not find the time
to introduce a _complete_ workaround for the incompatible interface change in 
the Linux kernel before November 12th 2006. I introduced a partial workaround 
in May 2005 (this may have made it into the fork), but the workarounds introduced
on November 12th 2006 finally allowed cdrecord to work again smoothly on recent 
Linux kernels. Note that the latter changes are definitely not inside the fork.

At the same time, I added a new feature into cdrecord/libscg that I call 
"auto-target" mode that allows cdrecord and other SCSI programs that depend on 
libscg to work without dev= parameter for 99% of all users.

>  - Linux kernel versions between 2.6.8 and 2.6.11 are known to have invasive
>    SCSI command filtering which makes the use of wodim almost inpossible or
>    complicated for non-root users. Avoid those kernel versions, unless they
>    have been patched to disable that filtering.

Do you like to tell me that the SCSI filtering does no longer apply to recent 
Linux kernels? From my information, the SCSI filtering is still present and 
requires cdrecord to have root privileges as it was needed for every SCSI 
command during the whole life of Linux before Linux-2.6.8.1 (if you forget 
about the security bug introduced a short time before 2.6.8.1).

> So this claim, although possibly technically correct, is vastly misleading,
> especially 4 years later.

I am not shure, but you may not be informed correctly....

> > You can help: Ask your Linux distributor why he distributes an illegal and 
> > buggy fork instead of the legal original software!
>
> Apparently it's distributed because their legal team doesn't think it's an
> illegal fork, and it's still buggy because after you relicensed to CDDL, they
> felt they couldn't backport your fixes to the original GPL code.

The Linux distributors that distribute the fork need to be repared to be sued
because they distribute software that is in conflict with the Copyright law.
Note that the Copyright law is a higher legal estate than a contract (like the 
GPL) that does not even mention the specific changes that make the fork
unredistributable. As a result, the GPL does not allow you to do changes on 
software in case these changes are in conflict with the Copyright law.

The CDDL is definitely an approved OpenSource License, so the distributors only 
need to upgrade cdrtools to a recent CDDL based version.

BTW: If taken seriously, the incorrect claims made about cdrtools by the hostile 
downstream (that introduced the conflict), would turn the GPL into a definitely 
non-free license as his GPL interpretations are in conflict with the 
OpenSource definition section 9. See the special comment in 
http://www.opensource.org/docs/definition.php for section 9.

If the Linux distributors pay own lawyers, they should know this. The whole 
problem did cause a massive harm to the OpenSource movement in special as it is 
obviously not a legal problem but a social problem.

Hostile downstreams are a real risk for OSS and we the OSS authors need to find a 
way to deal with this problem.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily