2014-12-26 04:30:06

by Christopher Chavez

[permalink] [raw]
Subject: Re: p54usb kernel panic on recent mainline kernels

Larry Finger <Larry.Finger@...> writes:
> In any case, file a bug report at bugzilla.kernel.org, mark it as a regression,
> and post the bug number here. If you are able to finish the bisection, that
> would be helpful.

Reported.
https://bugzilla.kernel.org/show_bug.cgi?id=90331



2014-12-26 14:35:37

by Christian Lamparter

[permalink] [raw]
Subject: Re: p54usb kernel panic on recent mainline kernels

On Friday, December 26, 2014 04:23:21 AM Christopher Chavez wrote:
> Larry Finger <Larry.Finger@...> writes:
> > In any case, file a bug report at bugzilla.kernel.org, mark it as a regression,
> > and post the bug number here. If you are able to finish the bisection, that
> > would be helpful.
>
> Reported.
> https://bugzilla.kernel.org/show_bug.cgi?id=90331

According to what Larry wrote, this bug should disappear, if
the hw crypto offloading is disabled.

Christopher, can you please load the p54common kernel module
with the module parameter "nohwcrypt=1" and report back?

Regards,

Christian


2014-12-26 19:05:45

by Larry Finger

[permalink] [raw]
Subject: Re: p54usb kernel panic on recent mainline kernels

On 12/26/2014 08:35 AM, Christian Lamparter wrote:
> On Friday, December 26, 2014 04:23:21 AM Christopher Chavez wrote:
>> Larry Finger <Larry.Finger@...> writes:
>>> In any case, file a bug report at bugzilla.kernel.org, mark it as a regression,
>>> and post the bug number here. If you are able to finish the bisection, that
>>> would be helpful.
>>
>> Reported.
>> https://bugzilla.kernel.org/show_bug.cgi?id=90331
>
> According to what Larry wrote, this bug should disappear, if
> the hw crypto offloading is disabled.
>
> Christopher, can you please load the p54common kernel module
> with the module parameter "nohwcrypt=1" and report back?

Christian,

I can confirm that the skb panic goes away if hardware encryption is disabled.

My bisection led to a branch commit d17ec4d as the "bad" commit. Rather than
finding out where the bisection went bad, I added code to check skb->tail,
skb->end, and the length to be added. At the time of the call that panics, there
are 6 bytes between tail and end with 8 bytes needed.

I will be looking for the place where the driver calculates how large the skb
should be.

Larry