Re: Oops with latest bluetooth-next kernel.

[Martin Townsend <martin.townsend@xsilon.com>]

Hi Alex,

On 07/05/15 18:00, Alexander Aring wrote:
> Hi,
>
> On Thu, May 07, 2015 at 04:27:18PM +0100, Martin Townsend wrote:
>> 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.
>>
> ok.
>
> I also note on your outputs that the MIB defaults different what we have
> currently.
>
>          Interface wpan2
>                  ifindex 12
>                  wpan_dev 0x200000002
>                  extended_addr 0x1013749720940844
>                  short_addr 0xffff
>                  pan_id 0xffff
>                  type node
>                  max_frame_retries 4
> hehe, our mib default is -1 (no aret/csma-ca).
>                  min_be 4
> also here.
>                  max_be 9
> here as well.
>                  max_csma_backoffs 8
> we have 4 here.
>                  lbt 0
>
>
> Did you change that inside the kernel, so you have some patches on top
> of bluetooth-next?
Not that I know of, all of our patches apart from setting the tx queue 
to 50 have been pushed into bluetooth-next.  But I will check tomorrow 
to see why this is :)
Out of interest has there been much change in raw sockets since 
3.16/3.17 as this is where the RPL code could be tripping up.
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
- Martin