Thanks for your reply Alex, after a bit of debugging I've tracked it down to our RPL application. If I disable this at startup there are no lock ups. As soon as I start the daemon it brings the Kernel down so I need to investigate why this happens. I'll have a go at updating the fakelb as it's useful for RPL and MPL. - Martin On 07/05/15 13:24, Alexander Aring wrote: > Hi Martin, > > welcome back. > > On Thu, May 07, 2015 at 11:41:15AM +0100, Martin Townsend wrote: >> Hi, >> >> I've recently upgraded my kernel to bluetooth-net-next with the latest lrwpan-tools and find that I get the following Oops: >> >> We have 3 wpan interfaces, a powerline, a wireless, and a fakelb interface. If I disable the wireless interface everything is fine. If I disable the fakelb interface all is well. The problem seems to be when all 3 interfaces are up. This used to work in our 3.16 Kernel. >> Aslo we never saw the IPv6: fakelowpan: IPv6 duplicate address fe80::203:9a00:2:12c detected! message in the old build. >> >> Starting 802.15.4 loopback: > Again, I would not trust the fakelb driver. Because I see some things > which goes wrong in this driver. See below. > >> [ 25.215772] ieee802154fakelb ieee802154fakelb: added ieee802154 hardware >> iwpan phy phy2 interface add wpan2 type node 00:03:9a:00:00:02:01:2c >> ip link add link wpan2 name fakelowpan type lowpan >> ifconfig fakelowpan up >> ifconfig wpan2 up >> [ 26.839092] IPv6: fakelowpan: IPv6 duplicate address fe80::203:9a00:2:12c detected! > This occurs because the fakelb driver transmit a frame and also receive > the same frame, this should not happen. I think this is an easy fix, but > no time and too lazy such things to fix that. Also the fakelb driver > should be easily to change it to xmit_async behaviour. > > Meanwhile I think to told everytime that I declare the fakelb driver as > broken costs more time to implement a new one. :-) > >> [ 27.109497] Unable to handle kernel NULL pointer dereference at virtual address 00000004 >> [ 27.117623] pgd = c0004000 >> [ 27.120369] [00000004] *pgd=00000000 >> [ 27.123937] Internal error: Oops: 17 [#1] PREEMPT SMP ARM >> [ 27.129300] Modules linked in: fakelb mrf24j40 adc7923(O) hanadu(O) ansi_cprng >> [ 27.136547] CPU: 0 PID: 19 Comm: kworker/u4:1 Tainted: G O 4.0.0-rc7-brian #2 >> [ 27.144783] Hardware name: Xilinx Zynq Platform >> [ 27.149337] task: df49c500 ti: df4c0000 task.ti: df4c0000 >> [ 27.154766] PC is at process_one_work+0x24/0x330 >> [ 27.159373] LR is at worker_thread+0x4c/0x474 >> [ 27.163722] pc : [<c0035810>] lr : [<c0036214>] psr: 40000093 >> [ 27.163722] sp : df4c1f08 ip : 00000000 fp : df42b400 >> [ 27.175185] r10: df470900 r9 : c071c223 r8 : 00000088 >> [ 27.180396] r7 : 00000000 r6 : df42b400 r5 : c0755818 r4 : df470900 >> [ 27.186905] r3 : 00000004 r2 : 00000080 r1 : c0755818 r0 : df470900 >> [ 27.193426] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel >> [ 27.200797] Control: 18c5387d Table: 1ef3c04a DAC: 00000015 >> [ 27.206527] Process kworker/u4:1 (pid: 19, stack limit = 0xdf4c0210) >> [ 27.212859] Stack: (0xdf4c1f08 to 0xdf4c2000) >> [ 27.217226] 1f00: df4c0000 df42b400 00000001 df42b400 df470918 df42b414 >> [ 27.218183] mrf24j40 spi32765.0: SPI transfer timed out >> [ 27.218296] mrf24j40 spi32765.0: SPI write Failed for TX buf > Did you saw this here? > > Smells like a wrong error handling. I don't see in the other message no > where exactly the NULL pointer dereference is. > > I see many workqueue things, the mrf24j40 uses still the xmit_sync > callback so the tx handling of mac802154 uses a workqueue there but I > see no issues with some memory leaking in memory handling. > > I need more debug output, then I can maybe say what's wrong here. > > > btw: I noticed now, that the isr of mrf24j40 calls spi_sync, which > scares me a little bit. > > ... >> Also noticed that the extended address reported by iwpan doesn't look right > yep, that's true I recently sent a patch to this list for fixing this issue. > > - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
