block-highmem-all-18

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

             ^^^^^^^^^^ 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.

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

Gérard.

From: Gérard Roudier <[email protected]>
Date: Fri, 16 Nov 2001 19:59:02 +0100 (CET)

                ^^^^^^^^^^ 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
[email protected]

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

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.

Hope I've cleared up the misunderstanding there.

Jens Axboe

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.

From: Jens Axboe <[email protected]>
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