From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com ([74.125.82.49]:35847 "EHLO mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbbEGMYy (ORCPT ); Thu, 7 May 2015 08:24:54 -0400 Received: by wgiu9 with SMTP id u9so41715361wgi.3 for ; Thu, 07 May 2015 05:24:51 -0700 (PDT) Date: Thu, 7 May 2015 14:24:45 +0200 From: Alexander Aring Subject: Re: Oops with latest bluetooth-next kernel. Message-ID: <20150507122441.GA17485@omega> References: <554B414B.50408@xsilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <554B414B.50408@xsilon.com> Sender: linux-wpan-owner@vger.kernel.org List-ID: To: Martin Townsend Cc: linux-wpan@vger.kernel.org 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 : [] lr : [] 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