[patch] block-highmem-all-18

[patch] block-highmem-all-18

[Jens Axboe]

Hi,

Version #18 of the patch, the prepare-for-inclusion version. Changes:

- Drop IPS and megaraid changes, too problematic. If anyone has the
  hardware to really test this and do it properly (aimed at IPS), please
  do so and send it on. (me)
- Add CONFIG_HIGHIO configure option, has same effect as the nohighio
  boot parameter (me)
- Add sym2 can_dma_32 flag (me)
- aic7xxx_old can_dma_32 flag (me)

Against 2.4.15-pre5, find it here:

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.15-pre5/block-highmem-all-18.bz2

-- 
Jens Axboe

Re: [patch] block-highmem-all-18

[Gérard Roudier]

On Fri, 16 Nov 2001, Jens Axboe wrote:

> Hi,
>
> Version #18 of the patch, the prepare-for-inclusion version. Changes:
>
> - Drop IPS and megaraid changes, too problematic. If anyone has the
>   hardware to really test this and do it properly (aimed at IPS), please
>   do so and send it on. (me)
> - Add CONFIG_HIGHIO configure option, has same effect as the nohighio
>   boot parameter (me)
> - Add sym2 can_dma_32 flag (me)
             ^^^^^^^^^^ Pooaaahhh!:) What's this utter oddity ?
Only dma 32 ? :-)

Just to make things clear about how DMA width can be configured on the
driver at the moment and will ever be:

1) The 3 DMA addressing modes (32 bit, 40 bit and 64 bit limited to 16*4Gb
   are compiled options. The handshaking with other kernel parts is based
   on the pci_set_dma_mask() interface.

2) This DMA adressing mode will probably be auto-configurable on some
   further driver version, but I donnot want any useless code to be
   neither compiled nor executed by the driver for the 99,9.. % of
   real machines  that only need legacy 32 bit DMA addressing (i.e.
   Mode 0 in the driver context).
   Other DMA modes will only apply to the few configurations that
   can be probed as needing larger DMA addressing, even if larger DMA
   addressing will not harm on machines that donnot need the feature.
   As a result the DMA addressing mode will stay a compilation option,
   optionnally auto-probed at 'make kernel|module' time.

Now that things are hopefully clearer:), I donnot see any relevance about
having any additionnal flag related to DMA addressing, at least as far as
the sym-2 driver is concerned.


> - aic7xxx_old can_dma_32 flag (me)
>
> Against 2.4.15-pre5, find it here:
>
> *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.15-pre5/block-highmem-all-18.bz2

Thanks a lot for your work (despite the odd 'may_dma_somewhat' flag I seem
not to like that much.:) )

  Gérard.

Re: [patch] block-highmem-all-18

[Gérard Roudier]

On Fri, 16 Nov 2001, David S. Miller wrote:

>    From: Gérard Roudier <groudier@free.fr>
>    Date: Fri, 16 Nov 2001 19:59:02 +0100 (CET)
>
>    On Fri, 16 Nov 2001, Jens Axboe wrote:
>
>    > - Add sym2 can_dma_32 flag (me)
>                 ^^^^^^^^^^ Pooaaahhh!:) What's this utter oddity ?
>    Only dma 32 ? :-)
>
> It is workaround for buggy drivers, when set it means that single SG
> list entry request will be handled correctly.  When clear it means
> that single entry SG lists are to be avoided by the block layer.
>
> Many devices would explode when given single entry scatterlist. :(
>
> It's naming is questionable... that I agree with.  The name should be
> more suggestive to what it really means.

For now, it humanly means that the device is able to dma decimal value 32
which does not look this great a feature, nor that serious a bug. :-) :o)

Thanks, anyway, for the clarification.

  Gérard.

Re: [patch] block-highmem-all-18

[David S. Miller]

   From: Gérard Roudier <groudier@free.fr>
   Date: Fri, 16 Nov 2001 19:59:02 +0100 (CET)
   
   On Fri, 16 Nov 2001, Jens Axboe wrote:
   
   > - Add sym2 can_dma_32 flag (me)
                ^^^^^^^^^^ Pooaaahhh!:) What's this utter oddity ?
   Only dma 32 ? :-)

It is workaround for buggy drivers, when set it means that single SG
list entry request will be handled correctly.  When clear it means
that single entry SG lists are to be avoided by the block layer.

Many devices would explode when given single entry scatterlist. :(

It's naming is questionable... that I agree with.  The name should be
more suggestive to what it really means.

Franks a lot,
David S. Miller
davem@redhat.com

Re: [patch] block-highmem-all-18

[Jens Axboe]

On Fri, Nov 16 2001, David S. Miller wrote:
>    From: Gérard Roudier <groudier@free.fr>
>    Date: Fri, 16 Nov 2001 19:59:02 +0100 (CET)
>    
>    On Fri, 16 Nov 2001, Jens Axboe wrote:
>    
>    > - Add sym2 can_dma_32 flag (me)
>                 ^^^^^^^^^^ Pooaaahhh!:) What's this utter oddity ?
>    Only dma 32 ? :-)
> 
> It is workaround for buggy drivers, when set it means that single SG
> list entry request will be handled correctly.  When clear it means
> that single entry SG lists are to be avoided by the block layer.
> 
> Many devices would explode when given single entry scatterlist. :(
> 
> It's naming is questionable... that I agree with.  The name should be
> more suggestive to what it really means.

Heh, actually Dave the single_sg_ok flag used to specify just that, but
Arjan noted that we never needed to trust that functionality when
!can_dma_32. So now can_dma_32 being set implies that the HBA driver
also gets the single sg entry correct.

To answer Gerard's question -- with can_dma_32 set, scsi_merge will set
the correct bounce value based on the PCI device DMA mask set. So dma_32
is indeed a misnomer, it was introduced before we supported full 64-bit
dma, and should now just be called can_highmem_io or something similar.

-- 
Jens Axboe

Re: [patch] block-highmem-all-18

[Jens Axboe]

On Fri, Nov 16 2001, Gérard Roudier wrote:
> Just to make things clear about how DMA width can be configured on the
> driver at the moment and will ever be:
> 
> 1) The 3 DMA addressing modes (32 bit, 40 bit and 64 bit limited to 16*4Gb
>    are compiled options. The handshaking with other kernel parts is based
>    on the pci_set_dma_mask() interface.
> 
> 2) This DMA adressing mode will probably be auto-configurable on some
>    further driver version, but I donnot want any useless code to be
>    neither compiled nor executed by the driver for the 99,9.. % of
>    real machines  that only need legacy 32 bit DMA addressing (i.e.
>    Mode 0 in the driver context).
>    Other DMA modes will only apply to the few configurations that
>    can be probed as needing larger DMA addressing, even if larger DMA
>    addressing will not harm on machines that donnot need the feature.
>    As a result the DMA addressing mode will stay a compilation option,
>    optionnally auto-probed at 'make kernel|module' time.
> 
> Now that things are hopefully clearer:), I donnot see any relevance about
> having any additionnal flag related to DMA addressing, at least as far as
> the sym-2 driver is concerned.

The can_dma_32 flag is purely a case of being very cautious and _only_
enabling highmem I/O to drivers that have been tested as good! In a
perfect world with perfect device drivers, it would not be needed and I
would happily be using just the pci dma mask while the lions and lambs
drink milk from the river. In the real world most drivers suck badly and
the lambs turn bloody :-)

BTW, I never expected sym2 to cause problems, at least the part I looked
at handled this perfectly as I've stated before.

> Thanks a lot for your work (despite the odd 'may_dma_somewhat' flag I seem
> not to like that much.:) )

Hope I've cleared up the misunderstanding there.

-- 
Jens Axboe

Re: [patch] block-highmem-all-18

[David S. Miller]

   From: Jens Axboe <axboe@suse.de>
   Date: Fri, 16 Nov 2001 23:45:55 +0100
   
   it was introduced before we supported full 64-bit
   dma, and should now just be called can_highmem_io or something
   similar.

I encourage you to make this change :-)

Re: [patch] block-highmem-all-18

[Jens Axboe]

On Fri, Nov 16 2001, David S. Miller wrote:
>    From: Jens Axboe <axboe@suse.de>
>    Date: Fri, 16 Nov 2001 23:45:55 +0100
>    
>    it was introduced before we supported full 64-bit
>    dma, and should now just be called can_highmem_io or something
>    similar.
> 
> I encourage you to make this change :-)

Change has been made, I'll roll out -18b once I flush a few more pending
changes (notably the ULL -> pfn lastdataend change so we can loose
page_to_phys) :-)

-- 
Jens Axboe