P2041 issue accessing dma thru pcie

[danielmartins]

My board wich was derived from the p2041rdb, has a broadcom trident+ switch attached to p2040 pci.

U-boot is a 36 bit version of the sdk1.3.2 and Kernel hás the phys_64bit on.

When the broadcom switch tryes to allocate memmory to run his threads, the Kernel crash.

It worked on a previous mpc8544 board with a 32 bit adressing.

Is there any possibility to have a 32 bit dts and u-boot for p2040?

What do you  think the problem may be?

here is the dump :

[ 1131.322055] linux-kernel-bde (738): LTX: Enabled pci device : vendor_id = 14e4, device_id = b846

[ 1131.330886] linux-kernel-bde (738): LTX: Adjusted _pci_mem_start

[ 1131.336910] linux-kernel-bde (738): LTX: Adjusted _pci_mem_end

[ 1131.342774] linux-kernel-bde (738): LTX: Will parse PCI_CAPABILITY_LIST

[ 1131.349438] linux-kernel-bde (738): LTX: BCM: Mapped the device

[ 1131.355380] linux-kernel-bde (738): LTX: BCM: Reached end of _probe

[ 1131.361924] ------------[ cut here ]------------

[ 1131.366548] kernel BUG at mm/slab.c:2978!

[ 1131.370565] Oops: Exception in kernel mode, sig: 5 [#1]

[ 1131.375794] SMP NR_CPUS=8 P2041 RDB

[ 1131.379287] Modules linked in: linux_kernel_bde(+)

[ 1131.384091] NIP: c0508ae0 LR: c05088fc CTR: c00bf364

[ 1131.389064] REGS: e9931be0 TRAP: 0700   Not tainted  (3.0.51-rt75)

[ 1131.395251] MSR: 00021002 <ME,CE>  CR: 24022442  XER: 20000000

[ 1131.401112] TASK = e90f2ab0[738] 'insmod' THREAD: e9930000 CPU: 3

[ 1131.407043] GPR00: 00000000 e9931c90 e90f2ab0 e90025c8 00100100 00200200 e97a6568 00000000

[ 1131.415441] GPR08: c06f7a08 00000000 c06f7a14 00000000 24002442 100fe6bc 7fe3f560 00000000

[ 1131.423839] GPR16: c0000a00 00000014 100f0000 00000000 00000004 00000001 e90025d0 e90025c0

[ 1131.432237] GPR24: 00000004 c0720000 00000020 c0717d80 e9930000 c0718b80 e905b340 e9000ac0

[ 1131.440822] NIP [c0508ae0] cache_alloc_refill+0x28c/0x580

[ 1131.446229] LR [c05088fc] cache_alloc_refill+0xa8/0x580

[ 1131.451459] Call Trace:

[ 1131.453915] [e9931c90] [c01f99ec] ida_get_new_above+0x74/0x238 (unreliable)

[ 1131.460899] [e9931cd0] [c00bf474] __kmalloc+0x110/0x120

[ 1131.466151] [e9931cf0] [f1273b5c] _pgalloc+0xec/0x530 [linux_kernel_bde]

[ 1131.472873] [e9931d60] [f12740f4] _alloc_mpool+0xa4/0x110 [linux_kernel_bde]

[ 1131.479943] [e9931d80] [f1274fac] _init+0xdbc/0x1020 [linux_kernel_bde]

[ 1131.486577] [e9931e60] [f12580c4] init_module+0xc4/0x160 [linux_kernel_bde]

[ 1131.493558] [e9931e70] [c0002078] do_one_initcall+0x148/0x1a8

[ 1131.499318] [e9931ea0] [c006c428] sys_init_module+0xf40/0x1c40

[ 1131.505169] [e9931f40] [c000ebf8] ret_from_syscall+0x0/0x3c

Regards

Daniel

[scottwood]

BUG at mm/slab.c:2978 means that invalid flags were requested for a slab allocation.  These invalid flags are defined in GFP_SLAB_BUG_MASK in include/linux/gfp.h, and include __GFP_DMA32 and __GFP_HIGHMEM (which should only be used on page allocations).

The only connection to 36-bit physical I can see is if the driver is determining the flags to request based on the size of phys_addr_t, and is inappropriately specifing GFP_DMA32.  In any case, this seems to be a problem with the Broadcom driver; I suggest contacting Broadcom if you're unable to fix it.

It should also be noted that, even the driver switches to page allocations, GFP_DMA32 is not currently supported on powerpc.  Ordinary GFP_DMA should be used.

As for whether you can create a 32-bit address map, it's possible but we don't support or test it.  You'll need to modify the U-Boot config file to not define CONFIG_PHYS_64BIT, and you'll need to modify the device tree to match.  There may be bugs (especially in the U-Boot config file) that need to be fixed, since again this isn't a configuration we support or test.