why no option for 'ide=nocddma'?

why no option for 'ide=nocddma'?

[Jack Howarth]

   It appears that the current Linux kernel still has trouble
verifying installation CDs for Fedora Core even in the FC5
release unless users pass the 'ide=nodma' kernel option. If
the problem with CDs using dma isn't going to be fully resolved,
why can't we have a 'ide=nocddma' kernel option that would only
apply to CD/DVD drives? The current situation is unfortunate
because installations end up with 'ide=nodma' in grub.conf
which severely slows down disk i/o. Thanks in advance for
any information on this issue.
                  Jack
ps Does this issue with dma and CD/DVD drives only apply to reads
or are writes effected as well?

Re: why no option for 'ide=nocddma'?

[Alan Cox]

On Gwe, 2006-03-24 at 13:43 -0500, Jack Howarth wrote:
> release unless users pass the 'ide=nodma' kernel option. If
> the problem with CDs using dma isn't going to be fully resolved,
> why can't we have a 'ide=nocddma' kernel option that would only

It is nothing to do with DMA. See the postings in 2004 on the subject.
EOF handling in the block layer and IDE layer don't work for the case
where the size of a block device is not precisely defined

None fo the current block layer maintainers care about fixing it and
nobody else has submitted changes. Feel free to do that.

Fortunately the drivers/ide layer will hopefully be going away soon

Alan

Re: why no option for 'ide=nocddma'?

[Bartlomiej Zolnierkiewicz]

On 3/26/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2006-03-24 at 13:43 -0500, Jack Howarth wrote:
> > release unless users pass the 'ide=nodma' kernel option. If
> > the problem with CDs using dma isn't going to be fully resolved,
> > why can't we have a 'ide=nocddma' kernel option that would only
>
> It is nothing to do with DMA. See the postings in 2004 on the subject.
> EOF handling in the block layer and IDE layer don't work for the case
> where the size of a block device is not precisely defined
>
> None fo the current block layer maintainers care about fixing it and
> nobody else has submitted changes. Feel free to do that.
>
> Fortunately the drivers/ide layer will hopefully be going away soon

EOF handling error has nothing to do with IDE layer,
the same problem can be reproduced using libata+PATA patches.

Bartlomiej

Re: why no option for 'ide=nocddma'?

[Alan Cox]

On Iau, 2006-03-30 at 11:10 +0200, Bartlomiej Zolnierkiewicz wrote:
> EOF handling error has nothing to do with IDE layer,
> the same problem can be reproduced using libata+PATA patches.

I've never been able to reproduce it with libata+PATA patches, with
ide-scsi or with scsi devices. One clear reason for that is they handle
partial write returns correctly which unpatched drivers/ide does not.

So ide-cd goes  "Read 64K" and the CD goes "umm erp splat have 8K" and
it tells the block layer "failed". ide-scsi goes "here is 8K, fail 56K"
and also adjusts the volume size (without proper locking)

The underlying problem is the block layer certainly but ide-cd is an
offender too. One simple hack for ide-cd would be to return success and
fill the excess buffer space with "JensAxboeAteMyComputer"[1] or similar
as padding providing the write fail is coming from end of media in the
last 150K or so.

Alan

[1] I'm kidding about this, zero would be the right padding.

Re: why no option for 'ide=nocddma'?

[Jack Howarth]

Alan,
   Any hack to eliminate the error would be welcome because there
are endless threads created each time a new Fedora release comes
out and the installer disk verification or the actual linux installation
fails due to this bug. It really would increase the signal to noise
on the mailing lists.
               Jack