On Sun, Feb 15, 2009 at 02:20:40AM -0500, Pavel Roskin wrote: > Quoting Grant Grundler <grundler@xxxxxxxxxxxxxxxx>: > > >> I don't see how the driver could be doing anything wrong. I believe > >> CardBus devices simply don't understand addresses beyond the first 4 > >> gigabytes. > > > > That can be proven by dumping the PCI config space for that device. > > Can you post the output of "lspci -xs 04:00.0" and "lspci -vs 04:00.0" ? > > Sure. To activate the device, I loaded ath9k but it failed to bind to > the device. > > # lspci -xs 04:00.0 > 04:00.0 Network controller: Atheros Communications Inc. AR5008 > Wireless Network Adapter (rev 01) > 00: 8c 16 23 00 02 00 b0 02 01 00 80 02 10 a8 00 00 > 10: 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 d1 07 09 3a > 30: 00 00 00 00 40 00 00 00 00 00 00 00 12 01 00 00 > > # lspci -vs 04:00.0 > 04:00.0 Network controller: Atheros Communications Inc. AR5008 > Wireless Network Adapter (rev 01) > Subsystem: Device 07d1:3a09 > Flags: 66MHz, medium devsel, IRQ 18 > Memory at 130000000 (32-bit, non-prefetchable) [size=64K] Note that the host physical address != PCI bus physical address. BAR 0 (offset 0x10) contains 0x30000000 and the PCI bus controller has remapped that to +4G higher. > Capabilities: [40] #80 [0000] > Kernel modules: ath9k > > > If the BIOS is the one that assigned the > 32-bit address range, > > it expected the Cardbus bridge could support that. However, normal PCI > > or PCI-X bridges only support one 32-bit MMIO and one 64-bit > > "prefetchable" MMIO range. > > I don't know how to determine if BIOS did it. I actually doubt it. I > get the same results with "pci=assign-busses". Besides, why would the > kernel respect BIOS settings with "pci=cbmemsize=32M", but not with > "pci=cbmemsize=32M" I don't think BIOS is the problem here. Seems some confusion is caused by the 32-bit PCI bus addresses getting remapped above 32-bit range in the host phys address space. > Perhaps it would be better if the prefetchable MMIO range was > allocated over the 4G boundary, rather than the normal range. But > actually it's the normal range that is allocated over 4G: > > [ 0.916422] pci 0000:03:01.0: CardBus bridge, secondary bus 0000:04 > [ 0.916466] pci 0000:03:01.0: IO window: 0x00e000-0x00e0ff > [ 0.916511] pci 0000:03:01.0: IO window: 0x00e400-0x00e4ff > [ 0.916557] pci 0000:03:01.0: PREFETCH window: 0xd8000000-0xdbffffff > [ 0.916603] pci 0000:03:01.0: MEM window: 0x130000000-0x133ffffff MEM window is host physical address ranges and not PCI bus addresses. The "MEM window" is a 32-bit address defined by the PCI spec. > >> It turns out the CardBus device gets another region: > >> d8000000-dbffffff : PCI CardBus 0000:04 > > > > And this suggests both types have been allocated. > > The "lspci" output will tell us. > > Right, both types have been allocated. > > I believe allocations over 4G should never succeed for devices that > don't support 64-bit addressing (unless perhaps an upstream bridge > takes care of the upper address lines). That would make it possible > for the callers to take some measures, e.g. reduce the memory windows. > At least the drivers for the downstream devices (like ath9k) won't > be blamed for non being 64-bit clean. In this case, I don't think it's an ath9k problem. It's the victim of some sort of bug in the card-bus controller support that is confusing the host address space with the PCI bus address space. > Also, I noticed that pci_cardbus_mem_size is only used in one function > pci_bus_size_cardbus. I understand that the resource allocation is > done in several passes, so maybe not enough memory is allocated for > CardBus bridges in the initial pass, which results in one window being > pushed above 4G. > > If it will make any difference, the non-prefetch window should get > priority over the prefetch window, so that it has better chances to > land below the 4H limit. The prefetchable window seems to have been allocated above 4G anyway. Can you dump "lspci -xs 03:01.0" and "lspci -vs 03:01.0" in the failing case? This is to confirm the CardBus range registers match what we see in the ath9k device. ISTR we've had problems in the past with Cardbus Bridge resource allocation and linus was involved in that discussion. hth, grant > -- > Regards, > Pavel Roskin > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
