OpenWrt Forum Archive

Topic: Cambria crashes when sending data

The content of this topic has been archived on 3 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi everyone, I am having a problem with my new 2358-4 cambria platform. I have been using openwrt for a while now and it works great on the avila platforms, but with my new cambria boards whenever I send data wirelessly the kernel panics and reboots. It happens with the openwrt that comes with the boards and all the other revisions that I have tried. I have many pt to pt links up working great with the avila's, but with the cambria i can ping fine but when I iperf or ftp over the wireless link it crashes. I have tried it bridged and out of the bridge and still the same. I've tried using the ath5k driver and regular madwifi driver and still the same thing. My programmers and I have exhausted pretty much every idea, if anyone has any ideas or needs more info PLEASE LET ME KNOW. I have 20 of these boards and they are pretty much paper weights at this point. Thanks

I don't have such issues and was wondering, how could I reproduce the problem.

Client connecting to 10.0.1.10, TCP port 5001
TCP window sizeUnable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1]
Modules linked in: spi_gpio spi_bitbang uvcvideo quickcam gspca hci_usb hci_uart bnep rfcomm sco l2cap bluei
CPU: 0    Tainted: P           (2.6.26.8 #1)
pc : [<c0028a4c>]    lr : [<bf3440a4>]    psr: 80000093
sp : c01ede2c  ip : 00000001  fp : c01ede48
r10: 00000000  r9 : ffffffe8  r8 : c7230360
r7 : c7c120c0  r6 : 00000c20  r5 : c682c8c0  r4 : c7c1444c
r3 : 00000000  r2 : c682c540  r1 : 03c39000  r0 : a0000093
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 000039ff  Table: 07d9c000  DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc01ec260)
Stack: (0xc01ede2c to 0xc01ee000)
de20:                            c7250a8c c682fe34 c7250a8c 00000001 c01ede70
de40: c01ede4c bf3440a4 c00289b4 c7230360 c01edeb0 00000000 c7230360 00000002
de60: c723274c c01ede88 c01ede74 bf344148 bf343ff0 60000013 01d4a3e8 c01ede9c
de80: c01ede8c bf3442c8 bf344128 00000000 c01ededc c01edea0 bf34dfe8 bf3442b8
dea0: 01d4a3e8 00000001 c71c4000 00000000 c7250a8c 00000013 00000002 c7230360
dec0: c723274c 00000001 69054041 0001c1ec c01edf04 c01edee0 bf34fd94 bf34daa8
dee0: 00000002 c7d61518 c020a50c 00000009 c01f005c 0001c358 c01edf18 c01edf08
df00: c0035240 bf34fd24 00000009 c01edf34 c01edf1c c00350f0 c00351d4 0000001c
df20: c01fa704 00000000 c01edf44 c01edf38 c003547c c00350a0 c01edf60 c01edf48
df40: c001f048 c0035444 ffffffff 0000001f 10000000 c01edfc0 c01edf64 c001f664
df60: c001f00c c0205770 c7311800 c01ec000 60000013 c0020ae4 c01ec000 c001def8
df80: c01f005c 0001c358 69054041 0001c1ec c01edfc0 c01edfac c01edfac c00209a8
dfa0: c00209a8 60000013 ffffffff c020cf50 c0204e70 c01edfd0 c01edfc4 c01a8bb0
dfc0: c002097c c01edff4 c01edfd4 c0008b80 c01a8b68 c00083c4 c001def8 000039fd
dfe0: c0205330 c001e2fc 00000000 c01edff8 00008034 c0008908 00000000 00000000
Backtrace:
Function entered at [<c00289a8>] from [<bf3440a4>]
r7:00000001 r6:c7250a8c r5:c682fe34 r4:c7250a8c
Function entered at [<bf343fe4>] from [<bf344148>]
Function entered at [<bf34411c>] from [<bf3442c8>]
r5:01d4a3e8 r4:60000013
Function entered at [<bf3442ac>] from [<bf34dfe8>]
r4:00000000
Function entered at [<bf34da9c>] from [<bf34fd94>]
Function entered at [<bf34fd18>] from [<c0035240>]
r8:0001c358 r7:c01f005c r6:00000009 r5:c020a50c r4:c7d61518
Function entered at [<c00351c8>] from [<c00350f0>]
r4:00000009
Function entered at [<c0035094>] from [<c003547c>]
r6:00000000 r5:c01fa704 r4:0000001c
Function entered at [<c0035438>] from [<c001f048>]
Function entered at [<c001f000>] from [<c001f664>]
Exception stack(0xc01edf64 to 0xc01edfac)
df60:          c0205770 c7311800 c01ec000 60000013 c0020ae4 c01ec000 c001def8
df80: c01f005c 0001c358 69054041 0001c1ec c01edfc0 c01edfac c01edfac c00209a8
dfa0: c00209a8 60000013 ffffffff                                             
r6:10000000 r5:0000001f r4:ffffffff
Function entered at [<c0020970>] from [<c01a8bb0>]
r5:c0204e70 r4:c020cf50
Function entered at [<c01a8b5c>] from [<c0008b80>]
Function entered at [<c00088fc>] from [<00008034>]
r6:c001e2fc r5:c0205330 r4:000039fd
Code: 0a000029 e595300c e1530006 13a03000 (15833000)
: 16.0 KByte (default)
----------------------------------------Kernel panic - not syncing: Fatal exception in interrupt
--------------------
[  3] local 10.0.1.11 port 47211 connectedRebooting in 3 seconds.. with 10.0.1.10 port 5001

It happens when you do an iperf across the boards, from the boards, as well as from computers connected to the ethernet port, in both a routed, and bridged setup..

Does the problem go away if you limit the kernel memory to 64MB (add "mem=64M" to the kernel command line)?

worked like a charm...any ideas why we have to limit the boards to 64m?

Thanks a lot Kaloz they are working FINALLY! I owe you a beer..

It's a long standing issue with PCI on IXP4xx devices with more then 64MB of memory.. There were attempts to fix this, and they work most of the time, but hopefully a real fix will follow soon. I will post a reply here when it's fixed.

Hey USMC03,
Can you please tell what wireless chipset and card you used ?
We read in some forum that there are some issues with atheros chipsets[WLM54AG] on the IXP platform using the ath5k.ko
We plan to use mac80211 stack on the ath5k driver.

The discussion might have continued from here.