[BUG][x86_64]pci layer may report wrong iomem resources data to drivers

[BUG][x86_64]pci layer may report wrong iomem resources data to drivers

[thomas schorpp]

lo,

aic7xxx driver mmio / dma on x86_64 linux broken here.

i need some comments and further investigation advice on this:

> thomas schorpp wrote:
>> James Bottomley wrote:
>>> On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
>>>>> i agree for this to be a 32bit dma busmaster chip, since
>>>>> pci_resource_flags and lspci say 64bit mem resource type
>>>>> 
>>>>> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>>>>> 
>> 
>> static int ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc, 
>> u_long *bus_addr, uint8_t __iomem **maddr) { //      u_long  start;
>>  u_long  len; int     error; uint64_t start; ... 
>> printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
>> 0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
>> PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp return (error);
>> 
>> aic7xxx: pci_resource_start 0xffffff000 mem64 0x4 
>> -----------------------------------------------^
>> 
>> just to doublecheck the situation, posted lspci already.
>> 
>> will check next, if len = pci_resource_len(ahc->dev_softc, 1); if
>> (start != 0) { *bus_addr = start; //              if
>> (request_mem_region(start, 0x1000, "aic7xxx") == 0) if
>> (request_mem_region(start, len, "aic7xxx") == 0)
>> 
>> succeeds.
> 
> no. so the pci layer reports wrong start:
> 
> start = pci_resource_start(ahc->dev_softc, 1); len =
> pci_resource_len(ahc->dev_softc, 1); if (start != 0) { *bus_addr =
> start; //              if (request_mem_region(start, 0x1000,
> "aic7xxx") == 0) if (request_mem_region(start, len, "aic7xxx") == 0) 
> error = ENOMEM; printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x
> memlen 0x%lx \n", error, len ); //schorpp
> 
> tom1:~# dmesg |grep aic aic7xxx: DMA_32BIT_MASK aic7xxx:
> req_mem_region 0x0 memlen 0x1000 aic7xxx: pci_resource_start
> 0xffffff000 *maddr 0x20000 mem64 0x4 aic7xxx: PCI Device 0:6:0 failed
> memory mapped test.  Using PIO. aic7892: Ultra160 Wide Channel A,
> SCSI Id=7, 32/253 SCBs
> 
> 
>> 
>>>>> we've a bug in the x86_64 linux pci config, BIOS is ok, the
>>>>> hardware worked fine in a winxp_x64 test setup a few months
>>>>> ago.
>>>>> 
>>>>> will ask LKML.
>>>>> 
>>>>> y tom
>>>> sorry, wrong according to
>>>> http://download.adaptec.com/pdfs/aic7892.pdf.
>>>> 
>>>> "66 MHz, 64-bit, PCI interface that supports zero wait-state
>>>> memory; also operates on 33 MHz, 32-bit PCI busses"
>>>> 
>>>> this chip is capable of 64bit addressing, as pci_resource_nnnn
>>>> (checking this) on x86_64 platform and lspci on x86_64 *and*
>>>> AMDK7 configured kernels reports, even on PCI/32, right? or is
>>>> it impossible to do multiplexed 64bit mem addressing on PCI/32?
>>>> 
>>> 
>>> It can only do 37 bit addressing ... only the aic79xx can do the
>>> full 64 bits, so I suspect it should never get a 64 bit BAR,
>>> since it wouldn't be able to decode the full 32 bits.  I can fix
>>> the mmio check not to hang, but the card won't actually work mmio
>>> until whatever's assigning the BAR above 32 bits is fixed (that
>>> could either be a kernel PCI bug or a BIOS bug).
>>> 
>> 
>> ok, i trust in that. adaptor bios and mainboard bios *are* out,
>> winxp_x64 driver handled all. so agree on kernel pci hal issue. but
>> what for         const uint64_t   mask_39bit = 0x7FFFFFFFFFULL; 
>> then?
>> 
>>>> 
>>>> can adaptec.inc pls comment? since the aha19160 card is still
>>>> in production state, i assume they want to have a linux x86_64
>>>> dma capable driver. so far it is not, or can other users having
>>>> this card pls confirm my pci system broken?
>>> 
>>> James
>>> 
>>> 
>> 
>> y tom
>> 
>> - To unsubscribe from this list: send the line "unsubscribe
>> linux-scsi" in the body of a message to majordomo@vger.kernel.org 
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

[BUG][x86_64]pci layer may report wrong iomem resources data to drivers

[thomas schorpp]

lo,

aic7xxx driver mmio / dma on x86_64 linux broken here.

i need some comments and further investigation advice on this:

(resend, mozilla misconfig )

> thomas schorpp wrote:
>> James Bottomley wrote:
>>> On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
>>>>> i agree for this to be a 32bit dma busmaster chip,
>>>>> since pci_resource_flags and lspci say 64bit mem resource type
>>>>>
>>>>> aic7xxx: pci_resource_start fffff000 *maddr 20000 mem64 4
>>>>>
>>
>> static int
>> ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
>>                                 u_long *bus_addr,
>>                                 uint8_t __iomem **maddr)
>> {
>> //      u_long  start;
>>        u_long  len;
>>        int     error;
>>        uint64_t start;
>> ...
>>        printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) & PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
>>        return (error);
>>
>> aic7xxx: pci_resource_start 0xffffff000 mem64 0x4
>> -----------------------------------------------^
>>
>> just to doublecheck the situation, posted lspci already.
>>
>> will check next, if
>>       len = pci_resource_len(ahc->dev_softc, 1);
>>        if (start != 0) {
>>                *bus_addr = start;
>> //              if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
>>                if (request_mem_region(start, len, "aic7xxx") == 0)
>>
>> succeeds.
> 
> no. so the pci layer reports wrong start:
> 
>        start = pci_resource_start(ahc->dev_softc, 1);
>        len = pci_resource_len(ahc->dev_softc, 1);
>        if (start != 0) {
>                *bus_addr = start;
> //              if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
>                if (request_mem_region(start, len, "aic7xxx") == 0)
>                        error = ENOMEM;
>        printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x memlen 0x%lx \n", error, len ); //schorpp
> 
> tom1:~# dmesg |grep aic
> aic7xxx: DMA_32BIT_MASK
> aic7xxx: req_mem_region 0x0 memlen 0x1000
> aic7xxx: pci_resource_start 0xffffff000 *maddr 0x20000 mem64 0x4
> aic7xxx: PCI Device 0:6:0 failed memory mapped test.  Using PIO.
>        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> 
> 
>>
>>>>> we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware worked fine in a winxp_x64 test setup a few months ago.
>>>>>
>>>>> will ask LKML.
>>>>>
>>>>> y
>>>>> tom
>>>> sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
>>>>
>>>> "66 MHz, 64-bit, PCI interface that
>>>> supports zero wait-state memory;
>>>> also operates on 33 MHz, 32-bit
>>>> PCI busses"
>>>>
>>>> this chip is capable of 64bit addressing, as pci_resource_nnnn (checking this) on x86_64 platform and lspci on x86_64 *and* AMDK7 configured kernels reports, even on PCI/32, right?
>>>> or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
>>>
>>> It can only do 37 bit addressing ... only the aic79xx can do the full 64
>>> bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
>>> be able to decode the full 32 bits.  I can fix the mmio check not to
>>> hang, but the card won't actually work mmio until whatever's assigning
>>> the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
>>> a BIOS bug).
>>>
>>
>> ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64 driver handled all.
>> so agree on kernel pci hal issue.
>> but what for         const uint64_t   mask_39bit = 0x7FFFFFFFFFULL;
>> then?
>>
>>>>
>>>> can adaptec.inc pls comment? since the aha19160 card is still in production state, i assume they want to have a linux x86_64 dma capable driver. so far it is not, or can other users having this card pls confirm my pci system broken?
>>>
>>> James
>>>
>>>
>>
>> y
>> tom
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html