Linux 2.4.18: short dd read from IDE cdrom

Linux 2.4.18: short dd read from IDE cdrom

[Jonathan Woithe]

Hi

For a number of years now I have duplicated cds using
  dd if=/dev/cdrom of=foo.iso
  cdrecord ... foo.iso

Here, /dev/cdrom is a symlink to an IDE CDROM (usually /dev/hdc).  This has
worked on all versions of Linux I have used to date, up to 2.2.19.

Today I tried the same trick under 2.4.18 and struck a problem: the kernel
would not read the complete CD image.  The CD I was testing this with was
64016 sectors long (1 sector = 2048 bytes): when mounted, df reported a size
of 128032 blocks and the image size created by mkisofs was 64016 extends. 
However, the above dd command would *only* read 63972 sectors - 44 sectors
at the end of the disk were unread.  If the disc was mounted, the full
contents of the CDROM could be read, so the problem seems to be associated
with reading the raw bitstream via the /dev/ device entry.

If the image created by the dd command was mounted (on a CD after burning or
via loopback) at least one file per CD was unreadable (I'm guessing it's the
files at the end of the CD occupying those last 44 sectors).

I tried this in two different 2.4.18 boxes with the same result.  A 2.2.19
box with an IDE CDROM read the 64016 sectors with no trouble.  A closing I/O
error was reported, but the full 64016 were successfully transferred to the
output file.

A *SCSI* CD writer drive under 2.4.18 also read the full 64016 sectors like
2.2.19+IDE drive did.

Thus it seems that there is a problem accessing the last few sectors (44 in
our case above) of a cdrom directly when 2.4.18 is used with an IDE CD
drive.

Is there any way around this problem?  Is it a known problem and is a fix
available?

Please CC me any replies since I read the list via a web archive which has
missed individual postings in the past.  Thanks.

Best regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *

Re: Linux 2.4.18: short dd read from IDE cdrom

[Jonathan Woithe]

Hi all

Yesterday I reported a problem to lkml I observed with `dd' and ide cds:
> For a number of years now I have duplicated cds using
>   dd if=/dev/cdrom of=foo.iso
>   cdrecord ... foo.iso
> :
> Today I tried the same trick under 2.4.18 and struck a problem: the kernel
> would not read the complete CD image. ...

After further testing, it seems that turning off dma using "hdparm -d 0
/dev/hdc" allows things to work as expected - the full disk can be read and
the resulting image is intact.  It appears therefore that the problem may
lie in the ide DMA error recovery code.  Alan Cox eluded to this possibility
in Dec 2001 (lkml, 28 Dec 2001, subject "Re: dd cdrom error") but it's not
clear whether the issue was pursued by anyone at that time.  Does anyone
know whether this is now being addressed by Andre in his latest round of
patches via the ac tree, or has already been fixed?

Please CC me any replies.  Thanks.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *

Re: Linux 2.4.18: short dd read from IDE cdrom

[Erik Andersen]

On Tue Sep 03, 2002 at 04:49:12PM +0930, Jonathan Woithe wrote:
> Hi all
> 
> Yesterday I reported a problem to lkml I observed with `dd' and ide cds:
> > For a number of years now I have duplicated cds using
> >   dd if=/dev/cdrom of=foo.iso
> >   cdrecord ... foo.iso
> > :
> > Today I tried the same trick under 2.4.18 and struck a problem: the kernel
> > would not read the complete CD image. ...
> 
> After further testing, it seems that turning off dma using "hdparm -d 0
> /dev/hdc" allows things to work as expected - the full disk can be read and
> the resulting image is intact.  It appears therefore that the problem may

Interesting.  When DMA is enabled does running 
    blockdev --setra 0 /dev/cdrom
make any difference?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.18: short dd read from IDE cdrom

[Jonathan Woithe]

> On Tue Sep 03, 2002 at 04:49:12PM +0930, Jonathan Woithe wrote:
> > Hi all
> > 
> > Yesterday I reported a problem to lkml I observed with `dd' and ide cds:
> > > For a number of years now I have duplicated cds using
> > >   dd if=/dev/cdrom of=foo.iso
> > >   cdrecord ... foo.iso
> > > :
> > > Today I tried the same trick under 2.4.18 and struck a problem: the kernel
> > > would not read the complete CD image. ...
> > 
> > After further testing, it seems that turning off dma using "hdparm -d 0
> > /dev/hdc" allows things to work as expected - the full disk can be read and
> > the resulting image is intact.  It appears therefore that the problem may
> 
> Interesting.  When DMA is enabled does running 
>     blockdev --setra 0 /dev/cdrom
> make any difference?

None at all that I can tell:
  baxter:~> hdparm -d 0 /dev/hdc
  /dev/hdc:
   setting using_dma to 0 (off)
   using_dma    =  0 (off)
  baxter:~> dd if=/dev/hdc of=/dev/null bs=2k skip=64008 count=8
  8+0 records in
  8+0 records out
  baxter:~> hdparm -d 1 /dev/hdc
  /dev/hdc:
   setting using_dma to 1 (on)
   using_dma    =  1 (on)
  baxter:~> dd if=/dev/hdc of=/dev/null bs=2k skip=64008 count=8
  dd: reading /dev/hdc': Input/output error
  4+0 records in
  4+0 records out
  baxter:~> blockdev --setra 0 /dev/hdc
  baxter:~> dd if=/dev/hdc of=/dev/null bs=2k skip=64008 count=8
  dd: reading /dev/hdc': Input/output error
  4+0 records in
  4+0 records out

The CD concerned definitely has 64016 data blocks as reported by isosize:
  baxter:~> isosize -x /dev/hdc
  sector count: 64016, sector size: 2048

When the read succeeds, the messages log gives
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256068

This is expected - 256068 is beyond the last data sector and would be one of
those unreadable runout sectors that CDs have.

When the command fails with DMA turned on, we get:
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256048
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256052
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256056
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256060
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256064
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256068

Again, it can't read 512 byte) sector 256068, but appears to fail the four
2048 byte CDROM sectors leading up to the first leadout sector as well.

Interestingly enough, if I seek 64012 blocks in and read 4 blocks, things
work:
  baxter:~> dd if=/dev/hdc of=/dev/null bs=2k skip=64012 count=4
  4+0 records in
  4+0 records out
with 
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256064
  hdc: command error: status=0x51 { DriveReady SeekComplete Error }
  hdc: command error: error=0x50
  end_request: I/O error, dev 16:00 (hdc), sector 256068
appearing in the logs.

This is the only way to read those last 4 2k blocks: reading them from any
other skip offset (or as part of a complete disc read) results in them being
flagged with an I/O error.

Regards
  jonathan
-- 
* Jonathan Woithe    jwoithe@physics.adelaide.edu.au                        *
*                    http://www.physics.adelaide.edu.au/~jwoithe            *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"                              **
*  "...you wouldn't recognize a subtle plan if it painted itself purple and *
*   danced naked on a harpsichord singing 'subtle plans are here again'"    *