[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    [BUG][x86_64]pci layer may report wrong iomem resources data to drivers
From:       thomas schorpp <t.schorpp () gmx ! de>
Date:       2007-03-23 19:35:44
Message-ID: 46042C10.3080407 () gmx ! de
[Download RAW message or body]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[prev in list] [next in list] [prev in thread] [next in thread]