Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
following error from wodim:
Errno: 0 (Success), write_g1 scsi sendcmd: no error
CDB: 2A 00 00 00 00 00 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 63488
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> following error from wodim:
>
> Errno: 0 (Success), write_g1 scsi sendcmd: no error
> CDB: 2A 00 00 00 00 00 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> Sense flags: Blk 0 (not valid)
> resid: 63488
Does libata on the same hardware work?
Jeff
Jeff Garzik <[email protected]> writes:
> Andreas Schwab wrote:
>> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>> following error from wodim:
>>
>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>> CDB: 2A 00 00 00 00 00 00 00 1F 00
>> status: 0x2 (CHECK CONDITION)
>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>> Sense Key: 0x5 Illegal Request, Segment 0
>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>> Sense flags: Blk 0 (not valid) resid: 63488
>
> Does libata on the same hardware work?
There is no libata driver for ide-pmac.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
> Jeff Garzik <[email protected]> writes:
>
>> Andreas Schwab wrote:
>>> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
>>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>>> following error from wodim:
>>>
>>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>>> CDB: 2A 00 00 00 00 00 00 00 1F 00
>>> status: 0x2 (CHECK CONDITION)
>>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>>> Sense Key: 0x5 Illegal Request, Segment 0
>>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>>> Sense flags: Blk 0 (not valid) resid: 63488
>> Does libata on the same hardware work?
>
> There is no libata driver for ide-pmac.
..
What chipset is that.. CMD646 ?
Mark Lord <[email protected]> writes:
> Andreas Schwab wrote:
>> Jeff Garzik <[email protected]> writes:
>>
>>> Andreas Schwab wrote:
>>>> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
>>>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>>>> following error from wodim:
>>>>
>>>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>>>> CDB: 2A 00 00 00 00 00 00 00 1F 00
>>>> status: 0x2 (CHECK CONDITION)
>>>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>>>> Sense Key: 0x5 Illegal Request, Segment 0
>>>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>>>> Sense flags: Blk 0 (not valid) resid: 63488
>>> Does libata on the same hardware work?
>>
>> There is no libata driver for ide-pmac.
> ..
>
> What chipset is that.. CMD646 ?
Apple KeyLargo ATA-3 and Apple K2 ATA-6.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> following error from wodim:
> Errno: 0 (Success), write_g1 scsi sendcmd: no error
> CDB: 2A 00 00 00 00 00 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> Sense flags: Blk 0 (not valid)
> resid: 63488
This fragment is much too short to allow to judge on possible reasons.
There is a high probability that your problem is caused by the cdrecord
fork called "wodim".
Please always include the following information in your bug-report:
- The version number of cdrecord that caused the bug.
- The command line that was used for the failing command.
- The complete output (including error messages) from 'cdrecord -v ...'
- Probably the important part of the 'cdrecord -V' output if we agreed on it
- The OS name, release and hardware (processor)
- Special conditions of your environment (libc vers. SCSI transport ...)
- Sufficient information on the media used. This is at least the ATIP data, a
note to CD-R/CD-RW and information on the state and the case history of this
media.
As a general advise: if you have problems, always first try recent original
software from
ftp://ftp.berlios.de/pub/cdrecord/alpha/
None of the 30+ bugs reported against wodim in various Linux distributions is
known to be present with recent 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/old/private/ ftp://ftp.berlios.de/pub/schily
On Feb 18 2008 00:21, Joerg Schilling wrote:
>
>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>> following error from wodim:
>
>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>> CDB: 2A 00 00 00 00 00 00 00 1F 00
>> status: 0x2 (CHECK CONDITION)
>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>> Sense Key: 0x5 Illegal Request, Segment 0
>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>> Sense flags: Blk 0 (not valid)
>> resid: 63488
>
>This fragment is much too short to allow to judge on possible reasons.
>There is a high probability that your problem is caused by the cdrecord
>fork called "wodim".
>
[...]
>
>As a general advise: if you have problems, always first try recent original
>software from
SUSE 10.3 users (and the OP seems to be one..) may use the 'cdrtools'
RPM which I have in my repository (I don't like wodim either, but that's
not the point here). Just !webpin for cdrtools.
(oh and please use reply-to-all/dont-strip-Ccs, thanks :)
Joerg Schilling wrote:
> This fragment is much too short to allow to judge on possible reasons.
> There is a high probability that your problem is caused by the cdrecord
> fork called "wodim".
There is also the 100% certainty that this reply was from a known troll and
should just be ignored.
On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote:
> Joerg Schilling wrote:
> > This fragment is much too short to allow to judge on possible reasons.
> > There is a high probability that your problem is caused by the cdrecord
> > fork called "wodim".
>
> There is also the 100% certainty that this reply was from a known troll and
> should just be ignored.
That was rude, crude and uncalled for.
-Mike
On Monday 18 February 2008, Mike Galbraith wrote:
> On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote:
> > Joerg Schilling wrote:
> > > This fragment is much too short to allow to judge on possible
> > > reasons. There is a high probability that your problem is caused by
> > > the cdrecord fork called "wodim".
> >
> > There is also the 100% certainty that this reply was from a known troll
> > and should just be ignored.
>
> That was rude, crude and uncalled for.
I have no problems with my reply being called "rude" or "crude". After all,
I wasn't even remotely trying to be nice or considerate.
However, I do think it was called for as mr. Schilling's reply was nothing
other than the next mail in his endlessly running FUD campain against
Wodim. If you're not aware of that campain, please try for example the
following link:
http://www.google.com/search?q=schilling+wodim&ie=UTF-8&oe=UTF-8
Cheers,
FJP
Jan Engelhardt <[email protected]> wrote:
> >This fragment is much too short to allow to judge on possible reasons.
> >There is a high probability that your problem is caused by the cdrecord
> >fork called "wodim".
> >
> [...]
> >
> >As a general advise: if you have problems, always first try recent original
> >software from
>
> SUSE 10.3 users (and the OP seems to be one..) may use the 'cdrtools'
> RPM which I have in my repository (I don't like wodim either, but that's
> not the point here). Just !webpin for cdrtools.
Thank you for this hint!
Maybe, you should mention a URL to your repository....
> (oh and please use reply-to-all/dont-strip-Ccs, thanks :)
For me too please
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/old/private/ ftp://ftp.berlios.de/pub/schily
On Feb 18 2008 12:28, Joerg Schilling wrote:
>
>> >This fragment is much too short to allow to judge on possible reasons.
>> >There is a high probability that your problem is caused by the cdrecord
>> >fork called "wodim".
>> >
>> [...]
>> >
>> >As a general advise: if you have problems, always first try recent original
>> >software from
>>
>> SUSE 10.3 users (and the OP seems to be one..) may use the 'cdrtools'
>> RPM which I have in my repository (I don't like wodim either, but that's
>> not the point here). Just !webpin for cdrtools.
>
>Thank you for this hint!
>
>Maybe, you should mention a URL to your repository....
Indeed,
{http,ftp,rsync}://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/SUSE-10.3
There is more than just cdrtools, so people please be aware before
blindly hitting "Global System Upgrade" :)
On Mon, 2008-02-18 at 11:31 +0100, Frans Pop wrote:
> On Monday 18 February 2008, Mike Galbraith wrote:
> > On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote:
> > > Joerg Schilling wrote:
> > > > This fragment is much too short to allow to judge on possible
> > > > reasons. There is a high probability that your problem is caused by
> > > > the cdrecord fork called "wodim".
> > >
> > > There is also the 100% certainty that this reply was from a known troll
> > > and should just be ignored.
> >
> > That was rude, crude and uncalled for.
>
> I have no problems with my reply being called "rude" or "crude". After all,
> I wasn't even remotely trying to be nice or considerate.
Your bad.
Lame excuse for poor behavior elided.
-Mike
Hi,
On Feb 16, 2008 9:52 PM, Andreas Schwab <[email protected]> wrote:
> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> following error from wodim:
>
> Errno: 0 (Success), write_g1 scsi sendcmd: no error
> CDB: 2A 00 00 00 00 00 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> Sense flags: Blk 0 (not valid)
> resid: 63488
blk_end_request: changing ide-cd (take 4)
This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request
interfaces. Related 'uptodate' arguments are converted to 'error'.
In PIO mode, ide-cd (cdrom_newpc_intr()) needs to defer
end_that_request_last() until the device clears DRQ_STAT and raises
an interrupt after end_that_request_first().
So blk_end_request() has to return without completing request
even if no leftover in the request.
ide-cd uses blk_end_request_callback() and a dummy callback function,
which just returns value '1', to tell blk_end_request_callback()
about that.
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Kiyoshi Ueda <[email protected]>
Signed-off-by: Jun'ichi Nomura <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
[...]
I looked at the commit again but nothing seems obviously wrong (probably there
was a silent change in the behavior of block layer API that upsets ide-cd)...
Kiyoshi/Jens: please follow up on this bug.
Thanks,
Bart
Hi Andreas,
On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> following error from wodim:
>
> Errno: 0 (Success), write_g1 scsi sendcmd: no error
> CDB: 2A 00 00 00 00 00 00 00 1F 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> Sense Key: 0x5 Illegal Request, Segment 0
> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> Sense flags: Blk 0 (not valid)
> resid: 63488
Could you try this patch?
I've only done a compile test, so this patch may not work.
During the conversion to blk_end_request, the code was changed
*not* to set rq->data_len = 0.
I removed that part because I thought it was just a trigger to
call post_transform_command(). However, since data_len can be
used as a residual length of the transfer, it might have to remain
there.
Actually, wodim seems checking the residual count how far it wrote
(e.g. wodim/wodim.c:write_track_data()).
This patch brings back the rq->data_len = 0.
--- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
+++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
@@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
end_request:
if (blk_pc_request(rq)) {
unsigned long flags;
+ unsigned int dlen = rq->data_len;
+
+ if (dma)
+ rq->data_len = 0;
spin_lock_irqsave(&ide_lock, flags);
- if (__blk_end_request(rq, 0, rq->data_len))
+ if (__blk_end_request(rq, 0, dlen))
BUG();
HWGROUP(drive)->rq = NULL;
spin_unlock_irqrestore(&ide_lock, flags);
Thanks,
Kiyoshi Ueda
It works great for me.
Thanks,
Laura.
Kiyoshi Ueda wrote:
> Hi Andreas,
>
> On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
>> Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
>> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
>> following error from wodim:
>>
>> Errno: 0 (Success), write_g1 scsi sendcmd: no error
>> CDB: 2A 00 00 00 00 00 00 00 1F 00
>> status: 0x2 (CHECK CONDITION)
>> Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
>> Sense Key: 0x5 Illegal Request, Segment 0
>> Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
>> Sense flags: Blk 0 (not valid)
>> resid: 63488
>
> Could you try this patch?
> I've only done a compile test, so this patch may not work.
>
> During the conversion to blk_end_request, the code was changed
> *not* to set rq->data_len = 0.
> I removed that part because I thought it was just a trigger to
> call post_transform_command(). However, since data_len can be
> used as a residual length of the transfer, it might have to remain
> there.
> Actually, wodim seems checking the residual count how far it wrote
> (e.g. wodim/wodim.c:write_track_data()).
>
> This patch brings back the rq->data_len = 0.
>
> --- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
> +++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
> @@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
> end_request:
> if (blk_pc_request(rq)) {
> unsigned long flags;
> + unsigned int dlen = rq->data_len;
> +
> + if (dma)
> + rq->data_len = 0;
>
> spin_lock_irqsave(&ide_lock, flags);
> - if (__blk_end_request(rq, 0, rq->data_len))
> + if (__blk_end_request(rq, 0, dlen))
> BUG();
> HWGROUP(drive)->rq = NULL;
> spin_unlock_irqrestore(&ide_lock, flags);
>
> Thanks,
> Kiyoshi Ueda
Kiyoshi Ueda <[email protected]> writes:
> Could you try this patch?
> I've only done a compile test, so this patch may not work.
>
> During the conversion to blk_end_request, the code was changed
> *not* to set rq->data_len = 0.
> I removed that part because I thought it was just a trigger to
> call post_transform_command(). However, since data_len can be
> used as a residual length of the transfer, it might have to remain
> there.
> Actually, wodim seems checking the residual count how far it wrote
> (e.g. wodim/wodim.c:write_track_data()).
>
> This patch brings back the rq->data_len = 0.
Looks good, I was successfully able to burn a CD-RW.
Thanks, Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, Feb 18, 2008 at 01:58:27PM -0500, Kiyoshi Ueda wrote:
> Hi Andreas,
>
> On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
> > Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> > changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> > following error from wodim:
> >
> > Errno: 0 (Success), write_g1 scsi sendcmd: no error
> > CDB: 2A 00 00 00 00 00 00 00 1F 00
> > status: 0x2 (CHECK CONDITION)
> > Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> > Sense Key: 0x5 Illegal Request, Segment 0
> > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> > Sense flags: Blk 0 (not valid)
> > resid: 63488
>
> Could you try this patch?
> I've only done a compile test, so this patch may not work.
>
> During the conversion to blk_end_request, the code was changed
> *not* to set rq->data_len = 0.
> I removed that part because I thought it was just a trigger to
> call post_transform_command(). However, since data_len can be
> used as a residual length of the transfer, it might have to remain
> there.
> Actually, wodim seems checking the residual count how far it wrote
> (e.g. wodim/wodim.c:write_track_data()).
and there seems to be some discrepancy between the different burning tools for i
just did test burning a cdimage with cdrdao unter 2.6.25-rc2 and it _works_
flawlessly:
# cdrdao write --device /dev/hdc test.toc
Cdrdao version 1.2.2 - (C) Andreas Mueller <[email protected]>
SCSI interface library - (C) Joerg Schilling
Paranoia DAE library - (C) Monty
Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.
Using libscg version 'ubuntu-0.8ubuntu1'
/dev/hdc: TOSHIBA ODD-DVD SD-R6372 Rev: 1730
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)
Starting write at speed 4...
Pausing 10 seconds - hit CTRL-C to abort.
Process can be aborted with QUIT signal (usually CTRL-\).
Turning BURN-Proof on
Executing power calibration...
Power calibration successful.
Writing track 01 (mode MODE1_RAW/MODE1_RAW )...
Wrote 1 of 18 MB (Buffers 100% 94%).
Wrote 2 of 18 MB (Buffers 100% 94%).
Wrote 3 of 18 MB (Buffers 100% 94%).
Wrote 4 of 18 MB (Buffers 100% 94%).
Wrote 5 of 18 MB (Buffers 100% 94%).
Wrote 6 of 18 MB (Buffers 100% 94%).
Wrote 7 of 18 MB (Buffers 100% 94%).
Wrote 8 of 18 MB (Buffers 100% 94%).
Wrote 9 of 18 MB (Buffers 100% 94%).
Wrote 10 of 18 MB (Buffers 100% 94%).
Wrote 11 of 18 MB (Buffers 100% 94%).
Wrote 12 of 18 MB (Buffers 100% 94%).
Wrote 13 of 18 MB (Buffers 100% 94%).
Wrote 14 of 18 MB (Buffers 100% 94%).
Wrote 15 of 18 MB (Buffers 100% 94%).
Wrote 16 of 18 MB (Buffers 100% 94%).
Wrote 17 of 18 MB (Buffers 100% 94%).
Wrote 18 of 18 MB (Buffers 100% 94%).
Wrote 8056 blocks. Buffer fill min 100%/max 100%.
Flushing cache...
Writing finished successfully.
> This patch brings back the rq->data_len = 0.
>
> --- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
> +++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
> @@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
> end_request:
> if (blk_pc_request(rq)) {
> unsigned long flags;
> + unsigned int dlen = rq->data_len;
> +
> + if (dma)
> + rq->data_len = 0;
>
> spin_lock_irqsave(&ide_lock, flags);
> - if (__blk_end_request(rq, 0, rq->data_len))
> + if (__blk_end_request(rq, 0, dlen))
> BUG();
> HWGROUP(drive)->rq = NULL;
> spin_unlock_irqrestore(&ide_lock, flags);
>
> Thanks,
> Kiyoshi Ueda
next will test the one above...
--
Regards/Gru?,
Boris.
On Mon, Feb 18, 2008 at 09:20:41PM +0100, Borislav Petkov wrote:
> On Mon, Feb 18, 2008 at 01:58:27PM -0500, Kiyoshi Ueda wrote:
> > Hi Andreas,
> >
> > On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
> > > Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> > > changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> > > following error from wodim:
> > >
> > > Errno: 0 (Success), write_g1 scsi sendcmd: no error
> > > CDB: 2A 00 00 00 00 00 00 00 1F 00
> > > status: 0x2 (CHECK CONDITION)
> > > Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> > > Sense Key: 0x5 Illegal Request, Segment 0
> > > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> > > Sense flags: Blk 0 (not valid)
> > > resid: 63488
> >
> > Could you try this patch?
> > I've only done a compile test, so this patch may not work.
> >
> > During the conversion to blk_end_request, the code was changed
> > *not* to set rq->data_len = 0.
> > I removed that part because I thought it was just a trigger to
> > call post_transform_command(). However, since data_len can be
> > used as a residual length of the transfer, it might have to remain
> > there.
> > Actually, wodim seems checking the residual count how far it wrote
> > (e.g. wodim/wodim.c:write_track_data()).
>
> and there seems to be some discrepancy between the different burning tools for i
> just did test burning a cdimage with cdrdao unter 2.6.25-rc2 and it _works_
> flawlessly:
>
> # cdrdao write --device /dev/hdc test.toc
>
> Cdrdao version 1.2.2 - (C) Andreas Mueller <[email protected]>
> SCSI interface library - (C) Joerg Schilling
> Paranoia DAE library - (C) Monty
>
> Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.
>
> Using libscg version 'ubuntu-0.8ubuntu1'
>
> /dev/hdc: TOSHIBA ODD-DVD SD-R6372 Rev: 1730
> Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)
>
> Starting write at speed 4...
> Pausing 10 seconds - hit CTRL-C to abort.
> Process can be aborted with QUIT signal (usually CTRL-\).
> Turning BURN-Proof on
> Executing power calibration...
> Power calibration successful.
> Writing track 01 (mode MODE1_RAW/MODE1_RAW )...
> Wrote 1 of 18 MB (Buffers 100% 94%).
> Wrote 2 of 18 MB (Buffers 100% 94%).
> Wrote 3 of 18 MB (Buffers 100% 94%).
> Wrote 4 of 18 MB (Buffers 100% 94%).
> Wrote 5 of 18 MB (Buffers 100% 94%).
> Wrote 6 of 18 MB (Buffers 100% 94%).
> Wrote 7 of 18 MB (Buffers 100% 94%).
> Wrote 8 of 18 MB (Buffers 100% 94%).
> Wrote 9 of 18 MB (Buffers 100% 94%).
> Wrote 10 of 18 MB (Buffers 100% 94%).
> Wrote 11 of 18 MB (Buffers 100% 94%).
> Wrote 12 of 18 MB (Buffers 100% 94%).
> Wrote 13 of 18 MB (Buffers 100% 94%).
> Wrote 14 of 18 MB (Buffers 100% 94%).
> Wrote 15 of 18 MB (Buffers 100% 94%).
> Wrote 16 of 18 MB (Buffers 100% 94%).
> Wrote 17 of 18 MB (Buffers 100% 94%).
> Wrote 18 of 18 MB (Buffers 100% 94%).
>
> Wrote 8056 blocks. Buffer fill min 100%/max 100%.
> Flushing cache...
> Writing finished successfully.
>
> > This patch brings back the rq->data_len = 0.
> >
> > --- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
> > +++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
> > @@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
> > end_request:
> > if (blk_pc_request(rq)) {
> > unsigned long flags;
> > + unsigned int dlen = rq->data_len;
> > +
> > + if (dma)
> > + rq->data_len = 0;
> >
> > spin_lock_irqsave(&ide_lock, flags);
> > - if (__blk_end_request(rq, 0, rq->data_len))
> > + if (__blk_end_request(rq, 0, dlen))
> > BUG();
> > HWGROUP(drive)->rq = NULL;
> > spin_unlock_irqrestore(&ide_lock, flags);
> >
> > Thanks,
> > Kiyoshi Ueda
>
> next will test the one above...
confirmed here too - burning succeeds both with wodim and cdrdao.
>
> --
> Regards/Gru?,
> Boris.
--
Regards/Gru?,
Boris.
Hi,
On Mon, 18 Feb 2008 23:37:48 +0100, Borislav Petkov wrote:
> On Mon, Feb 18, 2008 at 09:20:41PM +0100, Borislav Petkov wrote:
> > On Mon, Feb 18, 2008 at 01:58:27PM -0500, Kiyoshi Ueda wrote:
> > > Hi Andreas,
> > >
> > > On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
> > > > Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> > > > changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> > > > following error from wodim:
> > > >
> > > > Errno: 0 (Success), write_g1 scsi sendcmd: no error
> > > > CDB: 2A 00 00 00 00 00 00 00 1F 00
> > > > status: 0x2 (CHECK CONDITION)
> > > > Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> > > > Sense Key: 0x5 Illegal Request, Segment 0
> > > > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> > > > Sense flags: Blk 0 (not valid)
> > > > resid: 63488
> > >
> > > Could you try this patch?
> > > I've only done a compile test, so this patch may not work.
> > >
> > > During the conversion to blk_end_request, the code was changed
> > > *not* to set rq->data_len = 0.
> > > I removed that part because I thought it was just a trigger to
> > > call post_transform_command(). However, since data_len can be
> > > used as a residual length of the transfer, it might have to remain
> > > there.
> > > Actually, wodim seems checking the residual count how far it wrote
> > > (e.g. wodim/wodim.c:write_track_data()).
> >
> > and there seems to be some discrepancy between the different burning tools for i
> > just did test burning a cdimage with cdrdao unter 2.6.25-rc2 and it _works_
> > flawlessly:
> >
> > # cdrdao write --device /dev/hdc test.toc
> >
> > Cdrdao version 1.2.2 - (C) Andreas Mueller <[email protected]>
> > SCSI interface library - (C) Joerg Schilling
> > Paranoia DAE library - (C) Monty
> >
> > Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.
> >
> > Using libscg version 'ubuntu-0.8ubuntu1'
> >
> > /dev/hdc: TOSHIBA ODD-DVD SD-R6372 Rev: 1730
> > Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)
> >
> > Starting write at speed 4...
> > Pausing 10 seconds - hit CTRL-C to abort.
> > Process can be aborted with QUIT signal (usually CTRL-\).
> > Turning BURN-Proof on
> > Executing power calibration...
> > Power calibration successful.
> > Writing track 01 (mode MODE1_RAW/MODE1_RAW )...
> > Wrote 1 of 18 MB (Buffers 100% 94%).
> > Wrote 2 of 18 MB (Buffers 100% 94%).
> > Wrote 3 of 18 MB (Buffers 100% 94%).
> > Wrote 4 of 18 MB (Buffers 100% 94%).
> > Wrote 5 of 18 MB (Buffers 100% 94%).
> > Wrote 6 of 18 MB (Buffers 100% 94%).
> > Wrote 7 of 18 MB (Buffers 100% 94%).
> > Wrote 8 of 18 MB (Buffers 100% 94%).
> > Wrote 9 of 18 MB (Buffers 100% 94%).
> > Wrote 10 of 18 MB (Buffers 100% 94%).
> > Wrote 11 of 18 MB (Buffers 100% 94%).
> > Wrote 12 of 18 MB (Buffers 100% 94%).
> > Wrote 13 of 18 MB (Buffers 100% 94%).
> > Wrote 14 of 18 MB (Buffers 100% 94%).
> > Wrote 15 of 18 MB (Buffers 100% 94%).
> > Wrote 16 of 18 MB (Buffers 100% 94%).
> > Wrote 17 of 18 MB (Buffers 100% 94%).
> > Wrote 18 of 18 MB (Buffers 100% 94%).
> >
> > Wrote 8056 blocks. Buffer fill min 100%/max 100%.
> > Flushing cache...
> > Writing finished successfully.
> >
> > > This patch brings back the rq->data_len = 0.
> > >
> > > --- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
> > > +++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
> > > @@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
> > > end_request:
> > > if (blk_pc_request(rq)) {
> > > unsigned long flags;
> > > + unsigned int dlen = rq->data_len;
> > > +
> > > + if (dma)
> > > + rq->data_len = 0;
> > >
> > > spin_lock_irqsave(&ide_lock, flags);
> > > - if (__blk_end_request(rq, 0, rq->data_len))
> > > + if (__blk_end_request(rq, 0, dlen))
> > > BUG();
> > > HWGROUP(drive)->rq = NULL;
> > > spin_unlock_irqrestore(&ide_lock, flags);
> > >
> > > Thanks,
> > > Kiyoshi Ueda
> >
> > next will test the one above...
>
>
> confirmed here too - burning succeeds both with wodim and cdrdao.
Thank you for testing, Laura, Andreas, Boris.
And I'm really sorry about the bug, all.
Bart,
Please review and apply the patch below to fix the bug.
[PATCH] ide-cd: fix missing residual count setting in DMA mode
This patch fixes the missing residual count setting in DMA mode,
which was introduced during the conversion to blk-end-request.
The residual count could be used by the request submitter.
So if it isn't set correctly, some upper layers does not work.
(e.g. wodim for CD burning.)
The bug is in only DMA mode.
In PIO mode, we are setting the residual count correctly,
so no need to fix.
Signed-off-by: Kiyoshi Ueda <[email protected]>
Signed-off-by: Jun'ichi Nomura <[email protected]>
---
drivers/ide/ide-cd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
+++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
@@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
end_request:
if (blk_pc_request(rq)) {
unsigned long flags;
+ unsigned int dlen = rq->data_len;
+
+ if (dma)
+ rq->data_len = 0;
spin_lock_irqsave(&ide_lock, flags);
- if (__blk_end_request(rq, 0, rq->data_len))
+ if (__blk_end_request(rq, 0, dlen))
BUG();
HWGROUP(drive)->rq = NULL;
spin_unlock_irqrestore(&ide_lock, flags);
Thanks,
Kiyoshi Ueda
On Feb 18 2008 11:31, Frans Pop wrote:
>> >
>> > There is also the 100% certainty that this reply was from a known troll
>> > and should just be ignored.
>>
>> That was rude, crude and uncalled for.
>
>I have no problems with my reply being called "rude" or "crude". After all,
>I wasn't even remotely trying to be nice or considerate.
>
>However, I do think it was called for as mr. Schilling's reply was nothing
>other than the next mail in his endlessly running FUD campain against
>Wodim. If you're not aware of that campain, please try for example the
>following link:
They both compaign against each other, but whatever they do
I choose cdrtools because it has the little extra:
http://pastebin.ca/909154 - cdrecord output of two commands
http://pastebin.ca/909160 - wodim output of two commands
Or in short, readable form:
Reading ATIP from a DVD:
--- wodim 2008-02-19 00:10:32.492871654 +0100
+++ cdrtools 2008-02-19 00:05:36.322901247 +0100
@@ 0,0 0,0 @@
-Supported modes: PACKET SAO
- ATIP start of lead in: -150 (00:00/00)
-Disk type: unknown dye (reserved id code)
-Manuf. index: -1
-Manufacturer: unknown (not in table)
+Supported modes: PACKET SAO LAYER_JUMP
+book type: DVD-ROM, Version (0.1)
+disc size: 120mm (0)
+maximum rate: 10.08 MB/s (2)
+number of layers:2
+track path: Opposite Track Path (1)
[...]
Drive capabilities:
-Device seems to be: Generic mmc2 DVD-R/DVD-RW.
-Current: 0x0010
-Profile: 0x0012
-Profile: 0x0010 (current)
[...]
+Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
+Current: DVD-ROM
+Profile: DVD-RAM
+Profile: DVD-ROM (current)
[...]
On Tuesday 19 February 2008, Kiyoshi Ueda wrote:
> Hi,
>
> On Mon, 18 Feb 2008 23:37:48 +0100, Borislav Petkov wrote:
> > On Mon, Feb 18, 2008 at 09:20:41PM +0100, Borislav Petkov wrote:
> > > On Mon, Feb 18, 2008 at 01:58:27PM -0500, Kiyoshi Ueda wrote:
> > > > Hi Andreas,
> > > >
> > > > On Sat, 16 Feb 2008 21:52:21 +0100, Andreas Schwab wrote:
> > > > > Since commit aaa04c28cb9a1efd42541fdb7ab648231c2a2263 [blk_end_request:
> > > > > changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the
> > > > > following error from wodim:
> > > > >
> > > > > Errno: 0 (Success), write_g1 scsi sendcmd: no error
> > > > > CDB: 2A 00 00 00 00 00 00 00 1F 00
> > > > > status: 0x2 (CHECK CONDITION)
> > > > > Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00
> > > > > Sense Key: 0x5 Illegal Request, Segment 0
> > > > > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
> > > > > Sense flags: Blk 0 (not valid)
> > > > > resid: 63488
> > > >
> > > > Could you try this patch?
> > > > I've only done a compile test, so this patch may not work.
> > > >
> > > > During the conversion to blk_end_request, the code was changed
> > > > *not* to set rq->data_len = 0.
> > > > I removed that part because I thought it was just a trigger to
> > > > call post_transform_command(). However, since data_len can be
> > > > used as a residual length of the transfer, it might have to remain
> > > > there.
> > > > Actually, wodim seems checking the residual count how far it wrote
> > > > (e.g. wodim/wodim.c:write_track_data()).
> > >
> > > and there seems to be some discrepancy between the different burning tools for i
> > > just did test burning a cdimage with cdrdao unter 2.6.25-rc2 and it _works_
> > > flawlessly:
> > >
> > > # cdrdao write --device /dev/hdc test.toc
> > >
> > > Cdrdao version 1.2.2 - (C) Andreas Mueller <[email protected]>
> > > SCSI interface library - (C) Joerg Schilling
> > > Paranoia DAE library - (C) Monty
> > >
> > > Check http://cdrdao.sourceforge.net/drives.html#dt for current driver tables.
> > >
> > > Using libscg version 'ubuntu-0.8ubuntu1'
> > >
> > > /dev/hdc: TOSHIBA ODD-DVD SD-R6372 Rev: 1730
> > > Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)
> > >
> > > Starting write at speed 4...
> > > Pausing 10 seconds - hit CTRL-C to abort.
> > > Process can be aborted with QUIT signal (usually CTRL-\).
> > > Turning BURN-Proof on
> > > Executing power calibration...
> > > Power calibration successful.
> > > Writing track 01 (mode MODE1_RAW/MODE1_RAW )...
> > > Wrote 1 of 18 MB (Buffers 100% 94%).
> > > Wrote 2 of 18 MB (Buffers 100% 94%).
> > > Wrote 3 of 18 MB (Buffers 100% 94%).
> > > Wrote 4 of 18 MB (Buffers 100% 94%).
> > > Wrote 5 of 18 MB (Buffers 100% 94%).
> > > Wrote 6 of 18 MB (Buffers 100% 94%).
> > > Wrote 7 of 18 MB (Buffers 100% 94%).
> > > Wrote 8 of 18 MB (Buffers 100% 94%).
> > > Wrote 9 of 18 MB (Buffers 100% 94%).
> > > Wrote 10 of 18 MB (Buffers 100% 94%).
> > > Wrote 11 of 18 MB (Buffers 100% 94%).
> > > Wrote 12 of 18 MB (Buffers 100% 94%).
> > > Wrote 13 of 18 MB (Buffers 100% 94%).
> > > Wrote 14 of 18 MB (Buffers 100% 94%).
> > > Wrote 15 of 18 MB (Buffers 100% 94%).
> > > Wrote 16 of 18 MB (Buffers 100% 94%).
> > > Wrote 17 of 18 MB (Buffers 100% 94%).
> > > Wrote 18 of 18 MB (Buffers 100% 94%).
> > >
> > > Wrote 8056 blocks. Buffer fill min 100%/max 100%.
> > > Flushing cache...
> > > Writing finished successfully.
> > >
> > > > This patch brings back the rq->data_len = 0.
> > > >
> > > > --- 2.6.25-rc2/drivers/ide/ide-cd.c 2008-02-15 15:57:20.000000000 -0500
> > > > +++ ide-fix/drivers/ide/ide-cd.c 2008-02-18 01:23:40.000000000 -0500
> > > > @@ -1207,9 +1207,13 @@ static ide_startstop_t cdrom_newpc_intr(
> > > > end_request:
> > > > if (blk_pc_request(rq)) {
> > > > unsigned long flags;
> > > > + unsigned int dlen = rq->data_len;
> > > > +
> > > > + if (dma)
> > > > + rq->data_len = 0;
> > > >
> > > > spin_lock_irqsave(&ide_lock, flags);
> > > > - if (__blk_end_request(rq, 0, rq->data_len))
> > > > + if (__blk_end_request(rq, 0, dlen))
> > > > BUG();
> > > > HWGROUP(drive)->rq = NULL;
> > > > spin_unlock_irqrestore(&ide_lock, flags);
> > > >
> > > > Thanks,
> > > > Kiyoshi Ueda
> > >
> > > next will test the one above...
> >
> >
> > confirmed here too - burning succeeds both with wodim and cdrdao.
>
> Thank you for testing, Laura, Andreas, Boris.
> And I'm really sorry about the bug, all.
>
>
> Bart,
> Please review and apply the patch below to fix the bug.
>
>
> [PATCH] ide-cd: fix missing residual count setting in DMA mode
>
> This patch fixes the missing residual count setting in DMA mode,
> which was introduced during the conversion to blk-end-request.
> The residual count could be used by the request submitter.
> So if it isn't set correctly, some upper layers does not work.
> (e.g. wodim for CD burning.)
>
> The bug is in only DMA mode.
> In PIO mode, we are setting the residual count correctly,
> so no need to fix.
>
> Signed-off-by: Kiyoshi Ueda <[email protected]>
> Signed-off-by: Jun'ichi Nomura <[email protected]>
Looks fine, thanks for fixing it so quickly.
Applied.
Kiyoshi Ueda <[email protected]> writes:
> Could you try this patch?
> I've only done a compile test, so this patch may not work.
Unfortunately, that is not enough to get DVD burning working again.
This is the error that growisofs is getting:
ioctl(6, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 00, 03, 10, 00, 00, 10, 00], mx_sb_len=64, iovec_count=0, dxfer_len=32768, timeout=60000, flags=0x3, data[32768]=["\360R\360\314Wt\277\241\36.\347\356L$\201]\210\372_~]I\213\366\253SV\2\372\356\312\257"...], status=02, masked_status=01, sb[0]=[], host_status=0, driver_status=0, resid=32768, duration=0, info=0x1}) = 0
write(2, ":-( unable to WRITE@LBA=310h: ", 30) = 30
It looks like the sense buffer is not filled in. In a successfully run
of growisfs under 2.6.24.2 the sense code is "LONG WRITE IN PROGRESS".
I also see that resid always equals dxfer_len even when the transfer was
successful, although growisofs does not seem to care. With 2.6.24.2
resid is only non-zero when a sense error occurred.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sat, Feb 23, 2008 at 04:47:50PM +0100, Andreas Schwab wrote:
> Kiyoshi Ueda <[email protected]> writes:
>
> > Could you try this patch?
> > I've only done a compile test, so this patch may not work.
>
> Unfortunately, that is not enough to get DVD burning working again.
> This is the error that growisofs is getting:
>
> ioctl(6, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 00, 03, 10, 00, 00, 10, 00], mx_sb_len=64, iovec_count=0, dxfer_len=32768, timeout=60000, flags=0x3, data[32768]=["\360R\360\314Wt\277\241\36.\347\356L$\201]\210\372_~]I\213\366\253SV\2\372\356\312\257"...], status=02, masked_status=01, sb[0]=[], host_status=0, driver_status=0, resid=32768, duration=0, info=0x1}) = 0
> write(2, ":-( unable to WRITE@LBA=310h: ", 30) = 30
>
> It looks like the sense buffer is not filled in. In a successfully run
> of growisfs under 2.6.24.2 the sense code is "LONG WRITE IN PROGRESS".
>
> I also see that resid always equals dxfer_len even when the transfer was
> successful, although growisofs does not seem to care. With 2.6.24.2
> resid is only non-zero when a sense error occurred.
Hm, strange,
burning a dvd here with growisofs works just fine. However, my
strace -v won't dereference the struct pointer passed to the ioctl:
...
open("/dev/dvd", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 5
...
ioctl(5, SG_IO, 0xbf804d14) = 0
...
--
Regards/Gru?,
Boris.
Borislav Petkov <[email protected]> writes:
> burning a dvd here with growisofs works just fine.
You probably don't have a Pioneer.
> However, my strace -v won't dereference the struct pointer passed to
> the ioctl:
I use strace 4.5.16.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hi Andreas,
On Sat, 23 Feb 2008 16:47:50 +0100, Andreas Schwab wrote:
> Kiyoshi Ueda <[email protected]> writes:
>
> > Could you try this patch?
> > I've only done a compile test, so this patch may not work.
>
> Unfortunately, that is not enough to get DVD burning working again.
> This is the error that growisofs is getting:
>
> ioctl(6, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[10]=[2a, 00, 00, 00, 03, 10,
> 00, 00, 10, 00], mx_sb_len=64, iovec_count=0, dxfer_len=32768,
> timeout=60000, flags=0x3,
> data[32768]=["\360R\360\314Wt\277\241\36.\347\356L$\201]\210\372_~]I\213\366\253SV\2\372\356\312\257"...],
> status=02, masked_status=01, sb[0]=[], host_status=0, driver_status=0,
> resid=32768, duration=0, info=0x1}) = 0
> write(2, ":-( unable to WRITE@LBA=310h: ", 30) = 30
>
> It looks like the sense buffer is not filled in. In a successfully run
> of growisfs under 2.6.24.2 the sense code is "LONG WRITE IN PROGRESS".
>
> I also see that resid always equals dxfer_len even when the transfer was
> successful, although growisofs does not seem to care. With 2.6.24.2
> resid is only non-zero when a sense error occurred.
I'm looking at this problem, but currently no idea why the conversion
to blk_end_request causes it.
growisofs (in dvd+rw-tools-7.0) seems to care only the sense buffer
of the sg_io_hdr, as you said.
(growisofs_mmc.cpp:poor_mans_pwrite64() and transport.hxx:transport())
So if the driver sets the sense code correctly, growisofs should work
correctly I think.
However, I can't find why the blk_end_request patch affects the sense
code setting.
Could you give me some more information below to help investigation?
o Have you tried bisecting the kernel changes to find suspicious
commit? If so, that information will be much appreciated.
o Is this problem 100% reproducible on your Pioneer drive?
o What is your dvd+rw-tools version?
o Do you get some messages from kernel like "DMA error" when
the problem happens?
And I'm sorry but I can't make enough time for this problem
until late this week.
Thanks,
Kiyoshi Ueda
"Kiyoshi Ueda" <[email protected]> writes:
> o Have you tried bisecting the kernel changes to find suspicious
> commit? If so, that information will be much appreciated.
That is close to impossible. Intervening kernels either don't boot or
crash while burning. Especially the one with the bad commit crashes in
cdrom_newpc_intr almost immediately when burning starts.
> o Is this problem 100% reproducible on your Pioneer drive?
Yes. See the comment in the growisofs sources, this sense code is
Pioneer specific.
> o Do you get some messages from kernel like "DMA error" when
> the problem happens?
Never.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
"Kiyoshi Ueda" <[email protected]> writes:
> I'm looking at this problem, but currently no idea why the conversion
> to blk_end_request causes it.
cdrom_newpc_intr apparently never sets rq->sense_len.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
> "Kiyoshi Ueda" <[email protected]> writes:
>
> > I'm looking at this problem, but currently no idea why the conversion
> > to blk_end_request causes it.
>
> cdrom_newpc_intr apparently never sets rq->sense_len.
>
actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
example.
--
Regards/Gru?,
Boris.
Borislav Petkov <[email protected]> writes:
> On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
>> "Kiyoshi Ueda" <[email protected]> writes:
>>
>> > I'm looking at this problem, but currently no idea why the conversion
>> > to blk_end_request causes it.
>>
>> cdrom_newpc_intr apparently never sets rq->sense_len.
>>
>
> actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
> example.
Yes, it does, but it always adds zero.
Move counting of sense bytes into the transfer loop.
Signed-off-by: Andreas Schwab <[email protected]>
---
drivers/ide/ide-cd.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.25-rc3.orig/drivers/ide/ide-cd.c 2008-02-25 01:03:31.000000000 +0100
+++ linux-2.6.25-rc3/drivers/ide/ide-cd.c 2008-02-25 22:54:42.000000000 +0100
@@ -1182,11 +1182,10 @@ static ide_startstop_t cdrom_newpc_intr(
else
rq->data += blen;
}
+ if (!write && blk_sense_request(rq))
+ rq->sense_len += blen;
}
- if (write && blk_sense_request(rq))
- rq->sense_len += thislen;
-
/*
* pad, if necessary
*/
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote:
> Borislav Petkov <[email protected]> writes:
>
> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
> >> "Kiyoshi Ueda" <[email protected]> writes:
> >>
> >> > I'm looking at this problem, but currently no idea why the conversion
> >> > to blk_end_request causes it.
> >>
> >> cdrom_newpc_intr apparently never sets rq->sense_len.
> >>
> >
> > actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
> > example.
>
> Yes, it does, but it always adds zero.
yep, true. Does that fix your dvd burning problem?
> Move counting of sense bytes into the transfer loop.
>
> Signed-off-by: Andreas Schwab <[email protected]>
>
> ---
> drivers/ide/ide-cd.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> --- linux-2.6.25-rc3.orig/drivers/ide/ide-cd.c 2008-02-25 01:03:31.000000000 +0100
> +++ linux-2.6.25-rc3/drivers/ide/ide-cd.c 2008-02-25 22:54:42.000000000 +0100
> @@ -1182,11 +1182,10 @@ static ide_startstop_t cdrom_newpc_intr(
> else
> rq->data += blen;
> }
> + if (!write && blk_sense_request(rq))
> + rq->sense_len += blen;
> }
>
> - if (write && blk_sense_request(rq))
> - rq->sense_len += thislen;
> -
> /*
> * pad, if necessary
> */
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, [email protected]
> SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
--
Regards/Gru?,
Boris.
Borislav Petkov <[email protected]> writes:
> On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote:
>> Borislav Petkov <[email protected]> writes:
>>
>> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
>> >> "Kiyoshi Ueda" <[email protected]> writes:
>> >>
>> >> > I'm looking at this problem, but currently no idea why the conversion
>> >> > to blk_end_request causes it.
>> >>
>> >> cdrom_newpc_intr apparently never sets rq->sense_len.
>> >>
>> >
>> > actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
>> > example.
>>
>> Yes, it does, but it always adds zero.
>
> yep, true. Does that fix your dvd burning problem?
Yes, sure.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Tue, Feb 26, 2008 at 03:52:13PM +0100, Andreas Schwab wrote:
> Borislav Petkov <[email protected]> writes:
>
> > On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote:
> >> Borislav Petkov <[email protected]> writes:
> >>
> >> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
> >> >> "Kiyoshi Ueda" <[email protected]> writes:
> >> >>
> >> >> > I'm looking at this problem, but currently no idea why the conversion
> >> >> > to blk_end_request causes it.
> >> >>
> >> >> cdrom_newpc_intr apparently never sets rq->sense_len.
> >> >>
> >> >
> >> > actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
> >> > example.
> >>
> >> Yes, it does, but it always adds zero.
> >
> > yep, true. Does that fix your dvd burning problem?
>
> Yes, sure.
>
> Andreas.
Bart,
please apply the enclosed patch since it fixes dvd burning with growisofs on
Pioneer drives as reported by Andreas.
Thanks.
---
From: Andreas Schwab <[email protected]>
Move counting of sense bytes into the transfer loop.
Signed-off-by: Andreas Schwab <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
---
drivers/ide/ide-cd.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.25-rc3.orig/drivers/ide/ide-cd.c 2008-02-25 01:03:31.000000000 +0100
+++ linux-2.6.25-rc3/drivers/ide/ide-cd.c 2008-02-25 22:54:42.000000000 +0100
@@ -1182,11 +1182,10 @@ static ide_startstop_t cdrom_newpc_intr(
else
rq->data += blen;
}
+ if (!write && blk_sense_request(rq))
+ rq->sense_len += blen;
}
- if (write && blk_sense_request(rq))
- rq->sense_len += thislen;
-
/*
* pad, if necessary
*/
--
Regards/Gru?,
Boris.
On Tuesday 26 February 2008, Borislav Petkov wrote:
> On Tue, Feb 26, 2008 at 03:52:13PM +0100, Andreas Schwab wrote:
> > Borislav Petkov <[email protected]> writes:
> >
> > > On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote:
> > >> Borislav Petkov <[email protected]> writes:
> > >>
> > >> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
> > >> >> "Kiyoshi Ueda" <[email protected]> writes:
> > >> >>
> > >> >> > I'm looking at this problem, but currently no idea why the conversion
> > >> >> > to blk_end_request causes it.
> > >> >>
> > >> >> cdrom_newpc_intr apparently never sets rq->sense_len.
> > >> >>
> > >> >
> > >> > actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for
> > >> > example.
> > >>
> > >> Yes, it does, but it always adds zero.
> > >
> > > yep, true. Does that fix your dvd burning problem?
> >
> > Yes, sure.
> >
> > Andreas.
>
> Bart,
>
> please apply the enclosed patch since it fixes dvd burning with growisofs on
> Pioneer drives as reported by Andreas.
>
> Thanks.
>
> ---
> From: Andreas Schwab <[email protected]>
>
> Move counting of sense bytes into the transfer loop.
>
> Signed-off-by: Andreas Schwab <[email protected]>
> Acked-by: Borislav Petkov <[email protected]>
applied, thanks!
Frans Pop wrote:
> Joerg Schilling wrote:
>> This fragment is much too short to allow to judge on possible reasons.
>> There is a high probability that your problem is caused by the cdrecord
>> fork called "wodim".
>
> There is also the 100% certainty that this reply was from a known troll and
> should just be ignored.
Actually he is the author of the software in question, and has
maintained it for a decade. Anyone who reads the cdwrite mailing list
knows that I have criticized his endless whining that Linux doesn't do
things right, but aside from the cosole output whining about Linux from
his program[1], and the fact that it must run as root[2], the real
cdrecord works in more cases, with more hardware, produces working burns
in more cases, and has more useful output, and is the software to use in
preference to wodim.
[1] cdrecord advises to use Linux 2.4 (and I think Solaris), and says
you should avoid using readable names for devices and use some
pseudo-SCSI numbers he likes instead.
[2] Linux developers filter commands sent to devices to protect them
from commands like erase BIOS. Joerg uses vendor proprietary commands
for greater functionality, and says if you have write on the device it
shouldn't be filtered and those commands should be permitted by the
filter. (That is a simplification, there are personal issues on both sides).
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot