Re: Problem with 2.4.14prex and qlogicfc

[Arjan van de Ven <arjanv@redhat.com>]

"David S. Miller" wrote:
> 
>    From: Jens Axboe <axboe@suse.de>
>    Date: Wed, 17 Oct 2001 08:18:37 +0200
> 
>    On Tue, Oct 16 2001, DICKENS,CARY (HP-Loveland,ex2) wrote:
>    > I'm seeing a problem on all the kernels that are 2.4.13pre1 and up.
> 
>    This smells like a bug in the pci64 conversion of qlogicfc. Maybe davem
>    has an idea, I'll take a look too.
> 
> Not if it broke in pre1 since the pci64 stuff went into pre2 :-)

since it broke as of pre2, the following things are suspect:

if  BITS_PER_LONG > 32
#define pci_dma_lo32(a) (a & 0xffffffff)
#define pci_dma_hi32(a) ((a >> 32) & 0xffffffff)
#else
#define pci_dma_lo32(a) (a & 0xffffffff)
#define pci_dma_hi32(a) 0
#endif


#if  BITS_PER_LONG <= 32
#define  VIRT_TO_BUS_LOW(a) (uint32_t)virt_to_bus(((void *)a))
#define  VIRT_TO_BUS_HIGH(a) (uint32_t)(0x0)
#else
#define  VIRT_TO_BUS_LOW(a) (uint32_t)(0xffffffff & virt_to_bus((void
*)(a)))
#define  VIRT_TO_BUS_HIGH(a) (uint32_t)(0xffffffff & (virt_to_bus((void
*)(a))>
#endif#

if BITS_PER_LONG > 32
        uint64_t request_dma;        /* Physical address. */
#else
        uint32_t request_dma;        /* Physical address. */
#endif

the later is abused instead of dma_addr_t and friends, and is used for
several other physical address
variables as well.