We’re trying to pin point the problem in the current xdma driver in order to understand exactly what is causing the panic.
In the old dts, pcie3 had only one range of 0x9040000000 memory configured in the dts:
ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
In the new dts, pcie3 now has three entries:
ranges =
<0x43000000 0xa4 0x00000000 0x94 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable /
<0x02000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>, / 32-Bit Window - non-prefetchable /
<0x01000000 0x00 0x00000000 0x90 0x10000000 0x00 0x00010000>; / 16-Bit IO Window */
Consequently, when the xdma driver was probed with data from the old dts, he received two bars to map - based on the first 0x9040000000 range:
[ 7.067819] xdma:map_single_bar: BAR0 at 0x9040000000 mapped at 0x(ptrval), length=65536(/65536)
[ 7.077306] xdma:map_single_bar: BAR2 at 0x9040010000 mapped at 0x(ptrval), length=65536(/65536)
this works.
When the same driver is probed with data from the new dts, the first bar he gets is from the new first range of 0x9400000000 (not 0x9040000000):
[ 296.231947] xdma:map_single_bar: BAR0 at 0x9400000000 mapped at 0x00000000540a24ba, length=65536(/65536)
The driver tries to ioread32 from that range, and the kernel immediately panics.
It’s not entirely clear that this is a driver bug - there are no limiting 32-bit variables or poor arithmetic involved, as shown in the post aforementioned. It’s quite simple: the driver calls pci_iomap, mapping that new 0x9400000000 range to a virtual address, followed by ioread32 trying to read from that address, and an immediate panic.
any chance it’s not legal to read from that new first 0x9400000000-based range?