dd cdrom error

dd cdrom error

[Leung Yau Wai]

Dear all,

	I come across a problem which seem exist in kernel 2.4.x but not
in 2.2.x.

	The problem is that, when I try to using dd to create a ISO image
of a cdrom then around dumping the end of the disc it will give out the
following error message:

e.g. dd if=/dev/cdrom of=n.iso

Dec 22 16:53:25 rainbow kernel: hdd: command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 22 16:53:25 rainbow kernel: hdd: command error: error=0x54
Dec 22 16:53:25 rainbow kernel: end_request: I/O error, dev 16:40 (hdd),
sector 1324148
Dec 22 16:56:51 rainbow kernel: hdd: command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 22 16:56:51 rainbow kernel: hdd: command error: error=0x54
Dec 22 16:56:51 rainbow kernel: end_request: I/O error, dev 16:40 (hdd),
sector 1323912
Dec 22 16:56:51 rainbow kernel: hdd: command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 22 16:56:51 rainbow kernel: hdd: command error: error=0x54
Dec 22 16:56:51 rainbow kernel: end_request: I/O error, dev 16:40 (hdd),
sector 1323916


	However, the problem will gone if I trun off the DMA support of my
cdrom under kernel 2.4.x.

e.g. hdparm -d0 /dev/hdd


	Then I recheck everything, keeping the same OS, the same machine
except booting the 2.2.X kernel (with UDMA patch to support my Promise
UDMA 66 controller). Then everything will run fine even turn on the DMA
support of the cdrom.

	Could anyone tell me what happened? Or, anything I missed? or I
should give which information to get some help?


My machine is a
Asus P3BF
with Promise UDMA66 add-on-card

cutting a part of dmesg from booting 2.4.17 hope can help
------------------------------------------------------------------
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:DMA
PDC20262: IDE controller on PCI bus 00 dev 58
PCI: Found IRQ 5 for device 00:0b.0
PDC20262: chipset revision 1
PDC20262: not 100% native mode: will probe irqs later
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
    ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:DMA, hdf:DMA
    ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:DMA
hdd: CD-S500/A, ATAPI CD/DVD-ROM drive
hde: IBM-DPTA-372050, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xb400-0xb407,0xb002 on irq 5
hde: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=39770/16/63, UDMA(66)

---------------------------------------------------------------------

	Thanks your attention


Chris

Re: dd cdrom error

[Alan Cox]

> 	But, why turning off DMA 'hdparm -d0 /dev/hdd' then everything
> work fine? Do you mean if turning off DMA then 2.4 kernel also knows that
> errors in the last few blocks of an ISO image are not in fact to be
> counted as errors and retried?  Also Jens knows?

No idea. I'd venture the IDE DMA error recovery is broken in the 2.4 tree.
Andre has implied that is the case but since he's having a silly fight with
Linus someone else will have to fix it.

So long as it works in 2.2 I'm not worried. I'm not 2.4 maintainer 8)

Alan

Re: dd cdrom error

[Leung Yau Wai]

On Fri, 28 Dec 2001, Alan Cox wrote:

> > 	BTW, why kernel 2.2.X will success create the ISO image of the
> > same disc with the same command?
> 
> The 2.2 kernel knows that errors in the last few blocks of an ISO image are
> not in fact to be counted as errors and retried. Apparently that got lost
> somewhere. Maybe Jens knows ?

	But, why turning off DMA 'hdparm -d0 /dev/hdd' then everything
work fine? Do you mean if turning off DMA then 2.4 kernel also knows that
errors in the last few blocks of an ISO image are not in fact to be
counted as errors and retried?  Also Jens knows?


Chris

Re: dd cdrom error

[Alan Cox]

> 	BTW, why kernel 2.2.X will success create the ISO image of the
> same disc with the same command?

The 2.2 kernel knows that errors in the last few blocks of an ISO image are
not in fact to be counted as errors and retried. Apparently that got lost
somewhere. Maybe Jens knows ?

Re: dd cdrom error

[Leung Yau Wai]

On Thu, 27 Dec 2001, Douglas Gilbert wrote:

> Leung Yau Wai <chris@gist.q-station.net> wrote:
> > I come across a problem which seem exist in kernel 
> > 2.4.x but not in 2.2.x.
> >
> > The problem is that, when I try to using dd to create 
> > a ISO image of a cdrom then around dumping the end of 
> > the disc it will give out the following error message:
> >
> > e.g. dd if=/dev/cdrom of=n.iso
> 
> If dd is used like that, it is surprising you do not get
> more errors. An iso9660 image does not necessarily fill
> the track. So the IDE equivalent of the SCSI READ CAPACITY 
> command will often report a size that includes unwritten 
> sectors at the end. Those unwritten sectors can/will cause
> IO errors when an attempt is made to read them.
> 
> A very useful program called "isosize" has made a return to
> util-linux-2.10s (and later). Execute:
>   isosize -x /dev/cdrom
> to find the number of sectors and the sector size of the iso9660
> fs held _within_ the first track. Then use those numbers as the 
> "count=" and "bs=" arguments to dd respectively.
> 
> 
> If you still have problems try turning DMA off via hdparm
> or set the DMA mode back to 33 MHz (-X34).

	So, why problem will be happened when using DMA?

	Do you mean when not using DMA then the sectors at the end of the
disc will be auto-filled (padded)? ( I think it is impossible )

	BTW, why kernel 2.2.X will success create the ISO image of the
same disc with the same command?

	Thx your reply!

Re: dd cdrom error

[Douglas Gilbert]

Leung Yau Wai <chris@gist.q-station.net> wrote:
> I come across a problem which seem exist in kernel 
> 2.4.x but not in 2.2.x.
>
> The problem is that, when I try to using dd to create 
> a ISO image of a cdrom then around dumping the end of 
> the disc it will give out the following error message:
>
> e.g. dd if=/dev/cdrom of=n.iso

If dd is used like that, it is surprising you do not get
more errors. An iso9660 image does not necessarily fill
the track. So the IDE equivalent of the SCSI READ CAPACITY 
command will often report a size that includes unwritten 
sectors at the end. Those unwritten sectors can/will cause
IO errors when an attempt is made to read them.

A very useful program called "isosize" has made a return to
util-linux-2.10s (and later). Execute:
  isosize -x /dev/cdrom
to find the number of sectors and the sector size of the iso9660
fs held _within_ the first track. Then use those numbers as the 
"count=" and "bs=" arguments to dd respectively.


If you still have problems try turning DMA off via hdparm
or set the DMA mode back to 33 MHz (-X34).

Doug Gilbert