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
