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 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. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Thu, 14 Jun 2018 12:47:19 +0300 Wirz 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 pgpozOgBVOgfT.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Wed, 13 Jun 2018 16:07:02 +0300 Wirz 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 pgpzb4fseWuOD.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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.
signature.asc
Description: OpenPGP digital signature
___
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Wed, 13 Jun 2018 13:09:05 +0200
Michael Büsch wrote:
> On Wed, 13 Jun 2018 14:01:53 +0300
> Wirz 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
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);
pgpBui50TXFv1.pgp
Description: OpenPGP digital signature
___
b43-dev mailing list
b43-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Wed, 13 Jun 2018 14:01:53 +0300 Wirz 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 pgpAvPYzJ6TPE.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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 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. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Wed, 13 Jun 2018 12:25:16 +0300 Wirz 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 pgpmJ10YXfr5w.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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 wrote: > >> the bisection leads to >> >> 142a27f0a731ddcf467546960a5585970ca98e21 is the first bad commit >> commit 142a27f0a731ddcf467546960a5585970ca98e21 >> Author: PrasannaKumar Muralidharan >> 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 >> reviewed-by: Harald Freudenberger >> Signed-off-by: Herbert Xu >> >> :04 04 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. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Mon, 11 Jun 2018 23:09:06 +0300 Wirz wrote: > the bisection leads to > > 142a27f0a731ddcf467546960a5585970ca98e21 is the first bad commit > commit 142a27f0a731ddcf467546960a5585970ca98e21 > Author: PrasannaKumar Muralidharan > 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 > reviewed-by: Harald Freudenberger > Signed-off-by: Herbert Xu > > :04 04 f61e5cc501c99fb09bae5f203528b9f4c3479f8a > 785262813cfb02c9606fd72274f0f7b44f2289d7 Mdrivers 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 pgpUz_XAvyW9j.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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 ssb49152 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 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 reviewed-by: Harald Freudenberger Signed-off-by: Herbert Xu :04 04 f61e5cc501c99fb09bae5f203528b9f4c3479f8a 785262813cfb02c9606fd72274f0f7b44f2289d7 M drivers cheers, lukas -- Do not believe the naysayers who say it cannot be done. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Sat, 9 Jun 2018 22:46:58 +0300 Wirz 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 pgptpDZxIwETC.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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 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. signature.asc Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
Re: b43 crashes on rmmod (bcm4331)
On Sat, 9 Jun 2018 15:08:24 +0300 Wirz 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 pgp34hdk4zBwQ.pgp Description: OpenPGP digital signature ___ b43-dev mailing list b43-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/b43-dev
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: [#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:a8638448fe50 EFLAGS: 00010207 > [27542.009311] RAX: 96325b9a4a01 RBX: b842b70420b5828a RCX: > 0001820001cc > [27542.009314] RDX: 0001820001cd RSI: e590d16e6900 RDI: > 69d18000 > [27542.009316] RBP: 96325cadd0a0 R08: 96325b9a4bf8 R09: > 0001820001cc > [27542.009320] R10: 02e0f2141882d600 R11: 9631d987d100 R12: > c080a122 > [27542.009323] R13: c10850f8 R14: 96325cadd100 R15: > > [27542.009327] FS: 7f82c0a95b80() GS:96326f28() > knlGS: > [27542.009330] CS: 0010 DS: ES: CR0: 80050033 > [27542.009333] CR2: 559625d724a8 CR3: 0003d9990001 CR4: > 001606e0 > [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:7ffc133187c8 EFLAGS: 0206 ORIG_RAX: > 00b0 > [27542.009422] RAX: ffda RBX: 7ffc13318828 RCX: > 7f82c03bb5e7 > [27542.009426] RDX: 000a RSI: 0800 RDI: > 56430c000808 > [27542.009428] RBP: 56430c0007a0 R08: 7ffc13317741 R09: > > [27542.009431] R10: 7f82c042b960 R11: 0206 R12: > 7ffc133189f0 > [27542.009434] R13: 7ffc13318edd R14: 56430c000260 R15: > 56430c0007a0 > [27542.009437] Code: 00 80 49 01 da 0f 82 39 01 00 00 48 c7 c
