>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:[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
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?
[email protected] 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:[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
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.
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 [email protected] 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.
[email protected] 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:[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
Shawn Starr <[email protected]> wrote:
> On October 2, 2009 10:46:49 am Jeff Garzik wrote:
> On October 5, 2009 11:43:55 pm [email protected] 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:[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