LinuxLists.cc - b43 crashes on rmmod (bcm4331)

2018-06-11 20:09:37

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

Hi,

>>> Is is possible for you to create a git bisect to find the change that
>>> actually broke this?
>>> That would be really helpful.
>>
>> I can try that. What is the most efficient way to unload/recompile/load
>> a single module without rebooting the machine too often? And it'll be a
>> lot of hard resets ...
>
> A git bisect is really only possible in the full kernel tree.
> But it won't take a lot of steps to get a result, because you already
> narrowed it down to 4.14-4.15. It might take 10 iterations or so (git
> will tell you). Due to incremental builds that can be done pretty
> quickly. As the whole kernel is searched for a change, a reboot is
> usually needed after each iteration step.

Ah, yes. I had for a moment thought I might get away with recompiling
just the b43 module, but that does not work of course.

I did the bisection, it was 13 steps. My metric was to say 'modprobe
b43; rmmod b43'. If the rmmod returns it's good, otherwise bad. (I
booted every kernel only once, so I hope there is no randomness
involved.) In the latter case the machine had to be hard-reset. Also,
in the latter case 'lsmod | grep b43' returns after the failed rmmod:

b43 348160 -1
ssb 49152 1 b43
mac80211 688128 1 b43
cfg80211 540672 2 b43,mac80211
bcma 49152 1 b43
led_class 16384 4 b43,applesmc,sdhci,input_leds

the bisection leads to

142a27f0a731ddcf467546960a5585970ca98e21 is the first bad commit
commit 142a27f0a731ddcf467546960a5585970ca98e21
Author: PrasannaKumar Muralidharan <[email protected]>
Date: Fri Oct 27 22:34:04 2017 +0530

hwrng: core - Reset user selected rng by writing "" to rng_current

User is able to select a chosen rng by writing its name to rng_current
but there is no way to reset it without unbinding the rng. Let user
write "" to rng_current and delesect the chosen rng.

Signed-off-by: PrasannaKumar Muralidharan <[email protected]>
reviewed-by: Harald Freudenberger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

:040000 040000 f61e5cc501c99fb09bae5f203528b9f4c3479f8a
785262813cfb02c9606fd72274f0f7b44f2289d7 M drivers

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 13:07:35

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

>>>> CONFIG_B43_HWRNG completely switches off hwrng support in b43.
>>>> I don't see how a change in hwrng core could still lead to a crash in
>>>> b43 with this option switched off.
>>>>
>>>> What do you mean by "manually in the .config"?
>>>
>>> What I meant is, that I have outcommented the line 'CONFIG_B43_HWRNG=y'
>>> in .config.
>>>
>>>> Can you try to properly switch off the setting with make menuconfig and
>>>> then recompile everything from scratch (make clean)?
>>>
>>> I was intending to do that before, but I cannot find the option for
>>> that. Searching for b43_hwrng in menuconfig only shows the dependencies
>>> of that option, and the Kconfig file where it is defined, but not the
>>> path in menuconfig. Do I indirectly set CONFIG_B43_HWRNG through the
>>> parameters it depends on? I'm sorry, but this is obviously above my
>>> level of expertise ...
>>
>> Whoops, sorry. You are right. This is an automatic config option.
>> That also means your manual editing of .config would be overridden.
>>
>> You can edit drivers/net/wireless/broadcom/b43/Kconfig
>> go to the section config B43_HWRNG
>> and change 'default y' to 'default n'
>>
>> That should disable it.
>
>
>
> Could you please also try the attached patch?
> There seems to be a problem in hwrng core in that it does not disable
> the current RNG, if the new RNG fails to initialize.
> I don't know if that's the problem here, though.

Ok. Do I apply your patch to the first version that fails for me, and
revert my change to Kconfig?

At the moment the test without B43_HWRNG compiles, I will test that later.

> diff --git a/drivers/char/hw_random/core.c
> b/drivers/char/hw_random/core.c index 91bb98c42a1c..aaf9e5afaad4 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -516,11 +516,18 @@ EXPORT_SYMBOL_GPL(hwrng_register);
>
> void hwrng_unregister(struct hwrng *rng)
> {
> + int err;
> +
> mutex_lock(&rng_mutex);
>
> list_del(&rng->list);
> - if (current_rng == rng)
> - enable_best_rng();
> + if (current_rng == rng) {
> + err = enable_best_rng();
> + if (err) {
> + drop_current_rng();
> + cur_rng_set_by_user = 0;
> + }
> + }
>
> if (list_empty(&rng_list)) {
> mutex_unlock(&rng_mutex);
>
>
>

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 10:28:08

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Wed, 13 Jun 2018 12:25:16 +0300
Wirz <[email protected]> wrote:

> > This commit introduces a bug, if b43 is the only RNG in the system. But
> > that is unlikely on modern systems and it's fixed by
> > 0e4b52942b1c76f89e0dcb829f72e123d0678f54, which is in 4.16.
> >
> > Other than that I currently can't see why this crashes.
> >
> > But the crash should go away, if you disable CONFIG_B43_HWRNG.
> > That's not a solution, but it may help, if you would like to get rid of
> > the crashes.
> > Could you please verify whether disabling CONFIG_B43_HWRNG avoids the
> > crash, just to make sure we are not after a red herring here?
>
> It seems the bug I'm seeing is separate from the one you are describing.
> The 4.16 kernels that ship with debian testing crash for me as well. I
> tested the 142a27f0a version with CONFIG_B43_HWRNG switched off
> (manually in the .config): it still crashes is the same way. I also
> just verified that the version one before that really is good.

CONFIG_B43_HWRNG completely switches off hwrng support in b43.
I don't see how a change in hwrng core could still lead to a crash in
b43 with this option switched off.

What do you mean by "manually in the .config"?
Can you try to properly switch off the setting with make menuconfig and
then recompile everything from scratch (make clean)?

--
Michael

Attachments:

2018-06-11 20:47:27

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Mon, 11 Jun 2018 23:09:06 +0300
Wirz <[email protected]> wrote:

> the bisection leads to
>
> 142a27f0a731ddcf467546960a5585970ca98e21 is the first bad commit
> commit 142a27f0a731ddcf467546960a5585970ca98e21
> Author: PrasannaKumar Muralidharan <[email protected]>
> Date: Fri Oct 27 22:34:04 2017 +0530
>
> hwrng: core - Reset user selected rng by writing "" to rng_current
>
> User is able to select a chosen rng by writing its name to rng_current
> but there is no way to reset it without unbinding the rng. Let user
> write "" to rng_current and delesect the chosen rng.
>
> Signed-off-by: PrasannaKumar Muralidharan <[email protected]>
> reviewed-by: Harald Freudenberger <[email protected]>
> Signed-off-by: Herbert Xu <[email protected]>
>
> :040000 040000 f61e5cc501c99fb09bae5f203528b9f4c3479f8a
> 785262813cfb02c9606fd72274f0f7b44f2289d7 M drivers

Thanks a lot for bisecting this.

This commit introduces a bug, if b43 is the only RNG in the system. But
that is unlikely on modern systems and it's fixed by
0e4b52942b1c76f89e0dcb829f72e123d0678f54, which is in 4.16.

Other than that I currently can't see why this crashes.

But the crash should go away, if you disable CONFIG_B43_HWRNG.
That's not a solution, but it may help, if you would like to get rid of
the crashes.
Could you please verify whether disabling CONFIG_B43_HWRNG avoids the
crash, just to make sure we are not after a red herring here?

Thanks.

--
Michael

Attachments:

2018-06-14 16:27:40

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Thu, 14 Jun 2018 12:47:19 +0300
Wirz <[email protected]> wrote:

> >>>> You can edit drivers/net/wireless/broadcom/b43/Kconfig
> >>>> go to the section config B43_HWRNG
> >>>> and change 'default y' to 'default n'
> >>>>
> >>>> That should disable it.
> >>>
> >>>
> >>>
> >>> Could you please also try the attached patch?
> >>> There seems to be a problem in hwrng core in that it does not disable
> >>> the current RNG, if the new RNG fails to initialize.
> >>> I don't know if that's the problem here, though.
> >>
> >> Ok. Do I apply your patch to the first version that fails for me, and
> >> revert my change to Kconfig?
> >
> >
> > Yes, please test the patch with a version that would otherwise fail.
> > You can use 4.16 or the latest kernel for that. I created it with latest
> > linus' version.
>
> I tested both suggested cases. When I disable B43_HWRNG by editing
> Kconfig, 'rmmod b43' succeeds in the first version where it previously
> failed. When I apply your patch on top of an unmodified 4.16 it also
> succeeds.

Thank you _very_ much for testing.

I will submit this patch to the hw_random maintainers.

--
Michael

Attachments:

2018-06-09 20:02:41

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Sat, 9 Jun 2018 22:46:58 +0300
Wirz <[email protected]> wrote:

> > Is is possible for you to create a git bisect to find the change that
> > actually broke this?
> > That would be really helpful.
>
> I can try that. What is the most efficient way to unload/recompile/load
> a single module without rebooting the machine too often? And it'll be a
> lot of hard resets ...

A git bisect is really only possible in the full kernel tree.
But it won't take a lot of steps to get a result, because you already
narrowed it down to 4.14-4.15. It might take 10 iterations or so (git
will tell you). Due to incremental builds that can be done pretty
quickly. As the whole kernel is searched for a change, a reboot is
usually needed after each iteration step.

There are a couple of howtos on the web regarding git bisect:
https://duckduckgo.com/?q=git+bisect+kernel

--
Michael

Attachments:

2018-06-09 19:47:18

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

Hi Michael,

On 09/06/18 18:11, Michael Büsch wrote:
> On Sat, 9 Jun 2018 15:08:24 +0300
> Wirz <[email protected]> wrote:
>
>> The regression I reported a few weeks ago for 4.15, exists also in 4.16.
>> That is, with a bcm4331/ht-phy b43 can be loaded and used without
>> problems, but the driver crashes when it gets unloaded (making a hard
>> reset of the machine necessary). This problem has been introduced
>> between 4.14 and 4.15.
>
> Thanks for your report.
>
> I just checked the diff between 4.14 and 4.15 for b43 and bcma. It's
> pretty small and there's no obvious candidate to me that could cause
> such a regression.
> This might be a change outside of b43 and bcma that triggered this
> behavior.
>
> Is is possible for you to create a git bisect to find the change that
> actually broke this?
> That would be really helpful.

I can try that. What is the most efficient way to unload/recompile/load
a single module without rebooting the machine too often? And it'll be a
lot of hard resets ...

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 11:10:16

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Wed, 13 Jun 2018 14:01:53 +0300
Wirz <[email protected]> wrote:

> > CONFIG_B43_HWRNG completely switches off hwrng support in b43.
> > I don't see how a change in hwrng core could still lead to a crash in
> > b43 with this option switched off.
> >
> > What do you mean by "manually in the .config"?
>
> What I meant is, that I have outcommented the line 'CONFIG_B43_HWRNG=y'
> in .config.
>
> > Can you try to properly switch off the setting with make menuconfig and
> > then recompile everything from scratch (make clean)?
>
> I was intending to do that before, but I cannot find the option for
> that. Searching for b43_hwrng in menuconfig only shows the dependencies
> of that option, and the Kconfig file where it is defined, but not the
> path in menuconfig. Do I indirectly set CONFIG_B43_HWRNG through the
> parameters it depends on? I'm sorry, but this is obviously above my
> level of expertise ...

Whoops, sorry. You are right. This is an automatic config option.
That also means your manual editing of .config would be overridden.

You can edit drivers/net/wireless/broadcom/b43/Kconfig
go to the section config B43_HWRNG
and change 'default y' to 'default n'

That should disable it.

--
Michael

Attachments:

2018-06-14 09:48:01

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

>>>> You can edit drivers/net/wireless/broadcom/b43/Kconfig
>>>> go to the section config B43_HWRNG
>>>> and change 'default y' to 'default n'
>>>>
>>>> That should disable it.
>>>
>>>
>>>
>>> Could you please also try the attached patch?
>>> There seems to be a problem in hwrng core in that it does not disable
>>> the current RNG, if the new RNG fails to initialize.
>>> I don't know if that's the problem here, though.
>>
>> Ok. Do I apply your patch to the first version that fails for me, and
>> revert my change to Kconfig?
>
>
> Yes, please test the patch with a version that would otherwise fail.
> You can use 4.16 or the latest kernel for that. I created it with latest
> linus' version.

I tested both suggested cases. When I disable B43_HWRNG by editing
Kconfig, 'rmmod b43' succeeds in the first version where it previously
failed. When I apply your patch on top of an unmodified 4.16 it also
succeeds.

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 12:02:36

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Wed, 13 Jun 2018 13:09:05 +0200
Michael Büsch <[email protected]> wrote:

> On Wed, 13 Jun 2018 14:01:53 +0300
> Wirz <[email protected]> wrote:
>
> > > CONFIG_B43_HWRNG completely switches off hwrng support in b43.
> > > I don't see how a change in hwrng core could still lead to a crash in
> > > b43 with this option switched off.
> > >
> > > What do you mean by "manually in the .config"?
> >
> > What I meant is, that I have outcommented the line 'CONFIG_B43_HWRNG=y'
> > in .config.
> >
> > > Can you try to properly switch off the setting with make menuconfig and
> > > then recompile everything from scratch (make clean)?
> >
> > I was intending to do that before, but I cannot find the option for
> > that. Searching for b43_hwrng in menuconfig only shows the dependencies
> > of that option, and the Kconfig file where it is defined, but not the
> > path in menuconfig. Do I indirectly set CONFIG_B43_HWRNG through the
> > parameters it depends on? I'm sorry, but this is obviously above my
> > level of expertise ...
>
> Whoops, sorry. You are right. This is an automatic config option.
> That also means your manual editing of .config would be overridden.
>
> You can edit drivers/net/wireless/broadcom/b43/Kconfig
> go to the section config B43_HWRNG
> and change 'default y' to 'default n'
>
> That should disable it.

Could you please also try the attached patch?
There seems to be a problem in hwrng core in that it does not disable
the current RNG, if the new RNG fails to initialize.
I don't know if that's the problem here, though.

diff --git a/drivers/char/hw_random/core.c
b/drivers/char/hw_random/core.c index 91bb98c42a1c..aaf9e5afaad4 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -516,11 +516,18 @@ EXPORT_SYMBOL_GPL(hwrng_register);

void hwrng_unregister(struct hwrng *rng)
{
+ int err;
+
mutex_lock(&rng_mutex);

list_del(&rng->list);
- if (current_rng == rng)
- enable_best_rng();
+ if (current_rng == rng) {
+ err = enable_best_rng();
+ if (err) {
+ drop_current_rng();
+ cur_rng_set_by_user = 0;
+ }
+ }

if (list_empty(&rng_list)) {
mutex_unlock(&rng_mutex);

--
Michael

Attachments:

(No filename) (2.14 kB)
rng_new_init_fail.patch (598.00 B)
(No filename) (833.00 B)
OpenPGP digital signature Download all attachments

2018-06-14 19:19:25

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On 14/06/18 19:26, Michael Büsch wrote:
> On Thu, 14 Jun 2018 12:47:19 +0300
> Wirz <[email protected]> wrote:
>
>>>>>> You can edit drivers/net/wireless/broadcom/b43/Kconfig
>>>>>> go to the section config B43_HWRNG
>>>>>> and change 'default y' to 'default n'
>>>>>>
>>>>>> That should disable it.
>>>>>
>>>>>
>>>>>
>>>>> Could you please also try the attached patch?
>>>>> There seems to be a problem in hwrng core in that it does not disable
>>>>> the current RNG, if the new RNG fails to initialize.
>>>>> I don't know if that's the problem here, though.
>>>>
>>>> Ok. Do I apply your patch to the first version that fails for me, and
>>>> revert my change to Kconfig?
>>>
>>>
>>> Yes, please test the patch with a version that would otherwise fail.
>>> You can use 4.16 or the latest kernel for that. I created it with latest
>>> linus' version.
>>
>> I tested both suggested cases. When I disable B43_HWRNG by editing
>> Kconfig, 'rmmod b43' succeeds in the first version where it previously
>> failed. When I apply your patch on top of an unmodified 4.16 it also
>> succeeds.
>
>
> Thank you _very_ much for testing.
>
> I will submit this patch to the hw_random maintainers.

Great, thank you! I look forward to using a current kernel again.

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 11:02:12

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On 13/06/18 13:27, Michael Büsch wrote:
> On Wed, 13 Jun 2018 12:25:16 +0300
> Wirz <[email protected]> wrote:
>
>>> This commit introduces a bug, if b43 is the only RNG in the system. But
>>> that is unlikely on modern systems and it's fixed by
>>> 0e4b52942b1c76f89e0dcb829f72e123d0678f54, which is in 4.16.
>>>
>>> Other than that I currently can't see why this crashes.
>>>
>>> But the crash should go away, if you disable CONFIG_B43_HWRNG.
>>> That's not a solution, but it may help, if you would like to get rid of
>>> the crashes.
>>> Could you please verify whether disabling CONFIG_B43_HWRNG avoids the
>>> crash, just to make sure we are not after a red herring here?
>>
>> It seems the bug I'm seeing is separate from the one you are describing.
>> The 4.16 kernels that ship with debian testing crash for me as well. I
>> tested the 142a27f0a version with CONFIG_B43_HWRNG switched off
>> (manually in the .config): it still crashes is the same way. I also
>> just verified that the version one before that really is good.
>
>
> CONFIG_B43_HWRNG completely switches off hwrng support in b43.
> I don't see how a change in hwrng core could still lead to a crash in
> b43 with this option switched off.
>
> What do you mean by "manually in the .config"?

What I meant is, that I have outcommented the line 'CONFIG_B43_HWRNG=y'
in .config.

> Can you try to properly switch off the setting with make menuconfig and
> then recompile everything from scratch (make clean)?

I was intending to do that before, but I cannot find the option for
that. Searching for b43_hwrng in menuconfig only shows the dependencies
of that option, and the Kconfig file where it is defined, but not the
path in menuconfig. Do I indirectly set CONFIG_B43_HWRNG through the
parameters it depends on? I'm sorry, but this is obviously above my
level of expertise ...

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 09:25:50

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On 11/06/18 23:46, Michael Büsch wrote:
> On Mon, 11 Jun 2018 23:09:06 +0300
> Wirz <[email protected]> wrote:
>
>> the bisection leads to
>>
>> 142a27f0a731ddcf467546960a5585970ca98e21 is the first bad commit
>> commit 142a27f0a731ddcf467546960a5585970ca98e21
>> Author: PrasannaKumar Muralidharan <[email protected]>
>> Date: Fri Oct 27 22:34:04 2017 +0530
>>
>> hwrng: core - Reset user selected rng by writing "" to rng_current
>>
>> User is able to select a chosen rng by writing its name to rng_current
>> but there is no way to reset it without unbinding the rng. Let user
>> write "" to rng_current and delesect the chosen rng.
>>
>> Signed-off-by: PrasannaKumar Muralidharan <[email protected]>
>> reviewed-by: Harald Freudenberger <[email protected]>
>> Signed-off-by: Herbert Xu <[email protected]>
>>
>> :040000 040000 f61e5cc501c99fb09bae5f203528b9f4c3479f8a
>> 785262813cfb02c9606fd72274f0f7b44f2289d7 M drivers
>
>
> Thanks a lot for bisecting this.
>
> This commit introduces a bug, if b43 is the only RNG in the system. But
> that is unlikely on modern systems and it's fixed by
> 0e4b52942b1c76f89e0dcb829f72e123d0678f54, which is in 4.16.
>
> Other than that I currently can't see why this crashes.
>
> But the crash should go away, if you disable CONFIG_B43_HWRNG.
> That's not a solution, but it may help, if you would like to get rid of
> the crashes.
> Could you please verify whether disabling CONFIG_B43_HWRNG avoids the
> crash, just to make sure we are not after a red herring here?

It seems the bug I'm seeing is separate from the one you are describing.
The 4.16 kernels that ship with debian testing crash for me as well. I
tested the 142a27f0a version with CONFIG_B43_HWRNG switched off
(manually in the .config): it still crashes is the same way. I also
just verified that the version one before that really is good.

cheers, lukas

--
Do not believe the naysayers who say it cannot be done.

Attachments:

2018-06-13 13:28:42

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Wed, 13 Jun 2018 16:07:02 +0300
Wirz <[email protected]> wrote:

> >>>> CONFIG_B43_HWRNG completely switches off hwrng support in b43.
> >>>> I don't see how a change in hwrng core could still lead to a crash in
> >>>> b43 with this option switched off.
> >>>>
> >>>> What do you mean by "manually in the .config"?
> >>>
> >>> What I meant is, that I have outcommented the line 'CONFIG_B43_HWRNG=y'
> >>> in .config.
> >>>
> >>>> Can you try to properly switch off the setting with make menuconfig and
> >>>> then recompile everything from scratch (make clean)?
> >>>
> >>> I was intending to do that before, but I cannot find the option for
> >>> that. Searching for b43_hwrng in menuconfig only shows the dependencies
> >>> of that option, and the Kconfig file where it is defined, but not the
> >>> path in menuconfig. Do I indirectly set CONFIG_B43_HWRNG through the
> >>> parameters it depends on? I'm sorry, but this is obviously above my
> >>> level of expertise ...
> >>
> >> Whoops, sorry. You are right. This is an automatic config option.
> >> That also means your manual editing of .config would be overridden.
> >>
> >> You can edit drivers/net/wireless/broadcom/b43/Kconfig
> >> go to the section config B43_HWRNG
> >> and change 'default y' to 'default n'
> >>
> >> That should disable it.
> >
> >
> >
> > Could you please also try the attached patch?
> > There seems to be a problem in hwrng core in that it does not disable
> > the current RNG, if the new RNG fails to initialize.
> > I don't know if that's the problem here, though.
>
> Ok. Do I apply your patch to the first version that fails for me, and
> revert my change to Kconfig?

Yes, please test the patch with a version that would otherwise fail.
You can use 4.16 or the latest kernel for that. I created it with latest
linus' version.

--
Michael

Attachments:

2018-06-09 15:12:19

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

On Sat, 9 Jun 2018 15:08:24 +0300
Wirz <[email protected]> wrote:

> The regression I reported a few weeks ago for 4.15, exists also in 4.16.
> That is, with a bcm4331/ht-phy b43 can be loaded and used without
> problems, but the driver crashes when it gets unloaded (making a hard
> reset of the machine necessary). This problem has been introduced
> between 4.14 and 4.15.

Thanks for your report.

I just checked the diff between 4.14 and 4.15 for b43 and bcma. It's
pretty small and there's no obvious candidate to me that could cause
such a regression.
This might be a change outside of b43 and bcma that triggered this
behavior.

Is is possible for you to create a git bisect to find the change that
actually broke this?
That would be really helpful.

--
Michael

Attachments:

2018-06-09 12:08:56

by Wirz

[permalink] [raw]

Subject: Re: b43 crashes on rmmod (bcm4331)

Hi,

The regression I reported a few weeks ago for 4.15, exists also in 4.16.
That is, with a bcm4331/ht-phy b43 can be loaded and used without
problems, but the driver crashes when it gets unloaded (making a hard
reset of the machine necessary). This problem has been introduced
between 4.14 and 4.15.

Does anyone have an idea about that? Is there any information I can
provide to trace this down?

cheers, lukas

On 04/05/18 22:55, Wirz wrote:
> Hi,
>
> I'm using b43 to operate a BCM4331 (on a MacBookPro 9,2). At the moment
> I'm using the kernels that are shipped with debian testing.
>
> On all three versions of 4.15 (what debian called 4.15.4, 4.15.11, and
> 4.15.17) that were available as well as the current 4.16.5 I can load
> b43 and successfully use it, but the kernel crashes when unloading the
> driver, see the trace below.
> I had no such problems under 4.14.17.
>
> Is that a known problem? Can I provide any more information to trace
> this down?
>
> cheers, lukas
>
>
>
> [27541.758851] wlan0: deauthenticating from f4:6b:ef:5f:1b:e5 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [27542.009123] general protection fault: 0000 [#1] SMP PTI
> [27542.009129] Modules linked in: ctr ccm cpufreq_conservative bnep
> cpufreq_userspace cpufreq_powersave binfmt_misc dm_crypt algif_skcipher
> af_alg btusb btrtl btbcm btintel hid_appleir hid_apple bluetooth
> jitterentropy_rng drbg ansi_cprng ecdh_generic hid_generic usbhid
> bcm5974 hid arc4 b43(-) joydev uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_v4l2 mac80211 videobuf2_common videodev media
> cfg80211 intel_rapl x86_pkg_temp_thermal intel_powerclamp efi_pstore ssb
> rfkill pcmcia pcmcia_core coretemp rng_core nls_ascii kvm_intel kvm
> irqbypass nls_cp437 iTCO_wdt iTCO_vendor_support vfat fat
> crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi evdev
> snd_hda_codec_cirrus dm_mod snd_hda_codec_generic applesmc input_polldev
> ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf pcspkr
> efivars snd_hda_intel
> [27542.009199] snd_hda_codec snd_hda_core snd_hwdep bcma snd_pcm_oss
> i915 snd_mixer_oss snd_pcm drm_kms_helper snd_timer mei_me snd drm sg
> soundcore mei i2c_algo_bit shpchp lpc_ich sbs apple_gmux sbshc acpi_als
> kfifo_buf industrialio video apple_bl ac button loop firewire_sbp2
> parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4
> crc16 mbcache jbd2 fscrypto ecb btrfs zstd_decompress zstd_compress
> xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor
> async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath
> linear md_mod sr_mod cdrom sd_mod crc32c_intel ahci libahci sdhci_pci
> cqhci sdhci firewire_ohci libata tg3 aesni_intel libphy xhci_pci
> aes_x86_64 ehci_pci firewire_core crypto_simd crc_itu_t xhci_hcd
> ehci_hcd cryptd glue_helper mmc_core i2c_i801 scsi_mod
> [27542.009284] usbcore usb_common thunderbolt
> [27542.009293] CPU: 1 PID: 30802 Comm: rmmod Not tainted 4.16.0-1-amd64
> #1 Debian 4.16.5-1
> [27542.009295] Hardware name: Apple Inc.
> MacBookPro9,2/Mac-6F01561E16C75D06, BIOS MBP91.88Z.00D3.B0C.1509111653
> 09/11/2015
> [27542.009304] RIP: 0010:kfree+0x4f/0x180
> [27542.009307] RSP: 0018:ffffa8638448fe50 EFLAGS: 00010207
> [27542.009311] RAX: ffff96325b9a4a01 RBX: b842b70420b5828a RCX:
> 00000001820001cc
> [27542.009314] RDX: 00000001820001cd RSI: ffffe590d16e6900 RDI:
> 000069d180000000
> [27542.009316] RBP: ffff96325cadd0a0 R08: ffff96325b9a4bf8 R09:
> 00000001820001cc
> [27542.009320] R10: 02e0f2141882d600 R11: ffff9631d987d100 R12:
> ffffffffc080a122
> [27542.009323] R13: ffffffffc10850f8 R14: ffff96325cadd100 R15:
> 0000000000000000
> [27542.009327] FS: 00007f82c0a95b80(0000) GS:ffff96326f280000(0000)
> knlGS:0000000000000000
> [27542.009330] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [27542.009333] CR2: 0000559625d724a8 CR3: 00000003d9990001 CR4:
> 00000000001606e0
> [27542.009336] Call Trace:
> [27542.009349] bcma_device_remove+0x22/0x30 [bcma]
> [27542.009357] device_release_driver_internal+0x15a/0x220
> [27542.009364] driver_detach+0x39/0x70
> [27542.009369] bus_remove_driver+0x51/0xd0
> [27542.009385] b43_exit+0x18/0xcaf [b43]
> [27542.009392] SyS_delete_module+0x18f/0x290
> [27542.009398] ? task_work_run+0x38/0xb0
> [27542.009404] do_syscall_64+0x6c/0x130
> [27542.009411] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [27542.009415] RIP: 0033:0x7f82c03bb5e7
> [27542.009418] RSP: 002b:00007ffc133187c8 EFLAGS: 00000206 ORIG_RAX:
> 00000000000000b0
> [27542.009422] RAX: ffffffffffffffda RBX: 00007ffc13318828 RCX:
> 00007f82c03bb5e7
> [27542.009426] RDX: 000000000000000a RSI: 0000000000000800 RDI:
> 000056430c000808
> [27542.009428] RBP: 000056430c0007a0 R08: 00007ffc13317741 R09:
> 0000000000000000
> [27542.009431] R10: 00007f82c042b960 R11: 0000000000000206 R12:
> 00007ffc133189f0
> [27542.009434] R13: 00007ffc13318edd R14: 000056430c000260 R15:
> 000056430c0007a0
> [27542.009437] Code: 00 80 49 01 da 0f 82 39 01 00 00 48 c7 c7 00 00 00
> 80 48 2b 3d 7b 5c e2 00 49 01 fa 49 c1 ea 0c 49 c1 e2 06 4c 03 15 59 5c
> e2 00 <49> 8b 42 20 48 8d 50 ff a8 01 4c 0f 45 d2 49 8b 52 20 48 8d 42
> [27542.009505] RIP: kfree+0x4f/0x180 RSP: ffffa8638448fe50
> [27542.009508] ---[ end trace 564977d3706dc719 ]---
>
>

--
Do not believe the naysayers who say it cannot be done.

Attachments: