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]
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"
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
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.
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.
--
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
