Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
123 views
Skip to first unread message
Arnaud Rebillout
Mar 2, 2022, 10:10:03 PM3/2/22
to
Source: hw-detect
Version: 1.147
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Dear Maintainer,
A Kali Linux user reported a fail install on a Dell XPS 9510. For the
background, the Kali Linux installer is a super lightweight fork of the
Debian installer, kept in sync with Debian.
For additional references:
* The bug report against Kali Linux is at:
https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/47
* The user provided screenshots of the installer logs, available at:
https://imgur.com/a/QMDMWug. The 3 first screenshots are with an
unmodified installer, while for the later screenshots, the user
disabled /bin/check-missing-firmware with a 'exit 0'.
* The Debian installer is expected to work with this particular model of
laptop: https://wiki.debian.org/InstallingDebianOn/Dell/Dell_XPS_15_9510
I don't want to discuss the bug reported in Kali here, that is not the
intent.
The reason I'm opening this bug against Debian is because, while looking
at the logs, a few lines caught my eyes. This is in the screenshot #3 in
the imgur.com link above:
check-missing-firmware: removing-and-loading kernel module iwlwifi
check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use.
I wonder if those lines are harmless, or if it really indicates that the
iwlwifi module can't be reloaded, therefore the wifi is not functional.
Since someone documented on the Debian wiki that the firmware-iwlwifi is
needed, and then the WiFi works, it seems that either those lines are
harmless, or the iwlwifi is not always successfully reloaded.
Thanks!
Arnaud
Version: 1.147
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Dear Maintainer,
A Kali Linux user reported a fail install on a Dell XPS 9510. For the
background, the Kali Linux installer is a super lightweight fork of the
Debian installer, kept in sync with Debian.
For additional references:
* The bug report against Kali Linux is at:
https://gitlab.com/kalilinux/build-scripts/live-build-config/-/issues/47
* The user provided screenshots of the installer logs, available at:
https://imgur.com/a/QMDMWug. The 3 first screenshots are with an
unmodified installer, while for the later screenshots, the user
disabled /bin/check-missing-firmware with a 'exit 0'.
* The Debian installer is expected to work with this particular model of
laptop: https://wiki.debian.org/InstallingDebianOn/Dell/Dell_XPS_15_9510
I don't want to discuss the bug reported in Kali here, that is not the
intent.
The reason I'm opening this bug against Debian is because, while looking
at the logs, a few lines caught my eyes. This is in the screenshot #3 in
the imgur.com link above:
check-missing-firmware: removing-and-loading kernel module iwlwifi
check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use.
I wonder if those lines are harmless, or if it really indicates that the
iwlwifi module can't be reloaded, therefore the wifi is not functional.
Since someone documented on the Debian wiki that the firmware-iwlwifi is
needed, and then the WiFi works, it seems that either those lines are
harmless, or the iwlwifi is not always successfully reloaded.
Thanks!
Arnaud
Carsten Schoenert
Dec 13, 2023, 2:10:05 PM12/13/23
to
Hi,
Am Thu, Mar 03, 2022 at 10:04:55AM +0700 schrieb Arnaud Rebillout:
> A Kali Linux user reported a fail install on a Dell XPS 9510. For the
> background, the Kali Linux installer is a super lightweight fork of the
> Debian installer, kept in sync with Debian.
I experience the same issue with a shiny new Lenovo Thinkpad X1 Carbon
X11 using the net-installer from 2023-12-07.
This model is using a Intel Wi-Fi® 6E AX211, 802.11ax 2x2 Wi-Fi +
Bluetooth 5.3 hardware.
The full specs is availabe here:
https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Carbon_Gen_11/ThinkPad_X1_Carbon_Gen_11_Spec.pdf
...
module couldn't be removed as the module is still in use. This happens
as this modul has dependencies as it's used by iwlmvm.
# lsmod | grep iwl
iwlmvm 589824 0
mac80211 1392640 1 iwlmvm
iwlwifi 544768 1 iwlmvm
cfg80211 1343488 3 iwlmvm,iwlwifi,mac80211
rfkill 40960 2 iwlmvm,cfg80211
The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.
Doing so I was able to bring up a WLAN based interface on my X1 G11
after I provided the required firmware files for this chipset within the
installer was running.
I basically understand whats going on in check-missing-firmware.sh, I'm
not able to come up with a patch, if someone has some lines of code
where I can start with to dig deeper into I'm willing to work on this.
My guess is that once the needed firmware for the AX211 chipset is
included in the net-installer images the issue I currently see will not
be happen anymore. But in fact more users in the future will see this
issue as the unloading and new loading of the modules needs to be
handled differently to the current implementation.
Note: The needed firmware files for the X1 G11 are available by the
release of upstream linux-firmware 20231111
Regards
Carsten
Am Thu, Mar 03, 2022 at 10:04:55AM +0700 schrieb Arnaud Rebillout:
> A Kali Linux user reported a fail install on a Dell XPS 9510. For the
> background, the Kali Linux installer is a super lightweight fork of the
> Debian installer, kept in sync with Debian.
X11 using the net-installer from 2023-12-07.
This model is using a Intel Wi-Fi® 6E AX211, 802.11ax 2x2 Wi-Fi +
Bluetooth 5.3 hardware.
The full specs is availabe here:
https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Carbon_Gen_11/ThinkPad_X1_Carbon_Gen_11_Spec.pdf
...
> The reason I'm opening this bug against Debian is because, while looking
> at the logs, a few lines caught my eyes. This is in the screenshot #3 in
> the imgur.com link above:
>
> check-missing-firmware: removing-and-loading kernel module iwlwifi
> check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use.
>
> I wonder if those lines are harmless, or if it really indicates that the
> iwlwifi module can't be reloaded, therefore the wifi is not functional.
> Since someone documented on the Debian wiki that the firmware-iwlwifi is
> needed, and then the WiFi works, it seems that either those lines are
> harmless, or the iwlwifi is not always successfully reloaded.
No, these lines of course not harmless as they indicate that the iwlwifi
> at the logs, a few lines caught my eyes. This is in the screenshot #3 in
> the imgur.com link above:
>
> check-missing-firmware: removing-and-loading kernel module iwlwifi
> check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use.
>
> I wonder if those lines are harmless, or if it really indicates that the
> iwlwifi module can't be reloaded, therefore the wifi is not functional.
> Since someone documented on the Debian wiki that the firmware-iwlwifi is
> needed, and then the WiFi works, it seems that either those lines are
> harmless, or the iwlwifi is not always successfully reloaded.
module couldn't be removed as the module is still in use. This happens
as this modul has dependencies as it's used by iwlmvm.
# lsmod | grep iwl
iwlmvm 589824 0
mac80211 1392640 1 iwlmvm
iwlwifi 544768 1 iwlmvm
cfg80211 1343488 3 iwlmvm,iwlwifi,mac80211
rfkill 40960 2 iwlmvm,cfg80211
The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.
Doing so I was able to bring up a WLAN based interface on my X1 G11
after I provided the required firmware files for this chipset within the
installer was running.
I basically understand whats going on in check-missing-firmware.sh, I'm
not able to come up with a patch, if someone has some lines of code
where I can start with to dig deeper into I'm willing to work on this.
My guess is that once the needed firmware for the AX211 chipset is
included in the net-installer images the issue I currently see will not
be happen anymore. But in fact more users in the future will see this
issue as the unloading and new loading of the modules needs to be
handled differently to the current implementation.
Note: The needed firmware files for the X1 G11 are available by the
release of upstream linux-firmware 20231111
Regards
Carsten
Cyril Brulebois
Dec 13, 2023, 2:30:05 PM12/13/23
to
Carsten Schoenert <c.sch...@t-online.de> (2023-12-13):
the loop over $modules. You could try intercepting $module = iwlwifi,
and adding a modprobe -r theotherone beforehand.
Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
> The "trick" is to unload the iwlmvm module instead and load afterwards
> the module iwlwifi again.
See the very bottom of check-missing-firmware.sh (hw-detect repository),
> the module iwlwifi again.
the loop over $modules. You could try intercepting $module = iwlwifi,
and adding a modprobe -r theotherone beforehand.
Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Pascal Hambourg
Dec 13, 2023, 3:00:04 PM12/13/23
to
Hello,
Le 13/12/2023 à 20:16, Cyril Brulebois a écrit :
> Carsten Schoenert <c.sch...@t-online.de> (2023-12-13):
>> The "trick" is to unload the iwlmvm module instead and load afterwards
>> the module iwlwifi again.
>
> See the very bottom of check-missing-firmware.sh (hw-detect repository),
> the loop over $modules. You could try intercepting $module = iwlwifi,
> and adding a modprobe -r theotherone beforehand.
Wouldn't it be more generic to check /sys/module/${module}/holders like
is done for mhi ?
Note: iwldvm is also loaded by iwlwifi (for older hardware I guess) and
depends on it, but AFAICS it is not loaded when the requested firmware
is missing, so there is no need to unload it. Is it expected that the
behaviour is different with hardware using iwlmvm ?
Le 13/12/2023 à 20:16, Cyril Brulebois a écrit :
> Carsten Schoenert <c.sch...@t-online.de> (2023-12-13):
>> The "trick" is to unload the iwlmvm module instead and load afterwards
>> the module iwlwifi again.
>
> See the very bottom of check-missing-firmware.sh (hw-detect repository),
> the loop over $modules. You could try intercepting $module = iwlwifi,
> and adding a modprobe -r theotherone beforehand.
is done for mhi ?
Note: iwldvm is also loaded by iwlwifi (for older hardware I guess) and
depends on it, but AFAICS it is not loaded when the requested firmware
is missing, so there is no need to unload it. Is it expected that the
behaviour is different with hardware using iwlmvm ?
Cyril Brulebois
Dec 13, 2023, 3:20:05 PM12/13/23
to
Pascal Hambourg <pas...@plouf.fr.eu.org> (2023-12-13):
it helps, answering the question regarding where in the code one might
want to try something.
> Wouldn't it be more generic to check /sys/module/${module}/holders
> like is done for mhi ?
I was suggesting a quick and dirty way to get away with this, to see if
> like is done for mhi ?
it helps, answering the question regarding where in the code one might
want to try something.
Cyril Brulebois
Dec 15, 2023, 2:50:05 PM12/15/23
to
Carsten Schoenert <c.sch...@t-online.de> (2023-12-15):
> thank you very much for pointing me!
>
> I did play around a bit and was adding and testing the mentioned approach.
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e
>
> With these small modifications I can currently use the d-i on my X1 G11
> without further issues. A small exception, as the firmware-iwlwifi/testing
> can't provide the required firmware files right now they need to get
> provided on an additional inserted media.
Great, thanks. Do you actual need to modprobe $module at that point? I
thought the block right after that should modprobe -r/modprobe iwlwifi
on its own? (But it wasn't sufficient before you starting unloading
iwlmvm.)
> I did also same small s/space/tab modifications with no code changes
> afterwards in check-missing firmware.sh so the indentations are now unified
> to use tabs again and fixing also a small typo.
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/2a3c045a72b4f31fc818b7f639daf5c08b7e2e5a
>
> If you are fine I can raise a MR for easy pulling in. Otherwise feel free to
> comment on my changes.
I know mixed stuff isn't too nice, and unifying might be appealing, but
that makes cherry-picking stuff harder, so I tend to only unify things
when I'm actually changing code… Others might feel differently.
Well spotted, for the typo.
> thank you very much for pointing me!
>
> I did play around a bit and was adding and testing the mentioned approach.
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e
>
> With these small modifications I can currently use the d-i on my X1 G11
> without further issues. A small exception, as the firmware-iwlwifi/testing
> can't provide the required firmware files right now they need to get
> provided on an additional inserted media.
Great, thanks. Do you actual need to modprobe $module at that point? I
thought the block right after that should modprobe -r/modprobe iwlwifi
on its own? (But it wasn't sufficient before you starting unloading
iwlmvm.)
> I did also same small s/space/tab modifications with no code changes
> afterwards in check-missing firmware.sh so the indentations are now unified
> to use tabs again and fixing also a small typo.
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/2a3c045a72b4f31fc818b7f639daf5c08b7e2e5a
>
> If you are fine I can raise a MR for easy pulling in. Otherwise feel free to
> comment on my changes.
I know mixed stuff isn't too nice, and unifying might be appealing, but
that makes cherry-picking stuff harder, so I tend to only unify things
when I'm actually changing code… Others might feel differently.
Well spotted, for the typo.
Pascal Hambourg
Dec 15, 2023, 3:40:05 PM12/15/23
to
On 15/12/2023 at 20:27, Carsten Schoenert wrote:
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e
I think it would be better to add this stanza outside (before) the "for
driver" loop. There are two cases, depending on the controller model:
1) iwlmvm is loaded
modprobe -r $module # fail because iwlwifi is used by iwlmvm
modprobe $module # no-op
for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # ok, unloads iwlwifi too
modprobe $module # reloads iwlwifi
fi
...
2) iwlmvm is not loaded
modprobe -r $module -> ok
modprobe $module -> ok
for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op
modprobe $module # no-op
fi
...
It appears there are fail and/or no-op in both cases. This would be simpler:
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op if not loaded
fi
modprobe -r $module # no-op if unloaded with iwlmvm, but safe
modprobe $module
for driver in $(find /sys/bus/*/drivers -name "$module"); do
...
>
> https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e
I think it would be better to add this stanza outside (before) the "for
driver" loop. There are two cases, depending on the controller model:
1) iwlmvm is loaded
modprobe -r $module # fail because iwlwifi is used by iwlmvm
modprobe $module # no-op
for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # ok, unloads iwlwifi too
modprobe $module # reloads iwlwifi
fi
...
2) iwlmvm is not loaded
modprobe -r $module -> ok
modprobe $module -> ok
for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op
modprobe $module # no-op
fi
...
It appears there are fail and/or no-op in both cases. This would be simpler:
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op if not loaded
fi
modprobe -r $module # no-op if unloaded with iwlmvm, but safe
modprobe $module
for driver in $(find /sys/bus/*/drivers -name "$module"); do
...
0 new messages