Search Linux Wireless

Re: wifi breakage due to commit "wifi: brcmfmac: add support for vendor-specific firmware api"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Arend

Thanks for looking into it.

Your suspicion was spot on: we don’t have /sbin/modprobe (we don’t
even have /sbin!)

I addressed this issue by loading the brcmfmac-wcc module where we
also load the others:
https://github.com/gokrazy/wifi/commit/f611656338b68faa5f42bc2c8bbf1e0231a74a50

I’m not entirely sure why I concluded in my earlier testing that
loading the module doesn’t help.
Perhaps the issue was that I was manually loading the module after the
wifi program
tried to use the interface already and had it fail its firmware load —
in either case,
loading brcmfmac-wcc from the wifi program seems to work fine.

I also realize that the error message gives a number of pointers once
you know how to interpret it:

+ brcmfmac: brcmf_fwvid_request_module: mod=wcc: failed -2

I now understand this was trying to tell me that
request_module("brcmfmac-wcc") failed
with error code -2 (ENOENT), which means that the kernel’s
request_module() function
could not find CONFIG_MODPROBE_PATH.

For comparison, when the user space tool exists but fails, including
when it can’t find
the requested module (ENOENT), it always returns exit code 1:
https://salsa.debian.org/md/kmod/-/blob/7d761268ebb68245daf47167e418823c68c3eb98/tools/modprobe.c#L1025

I think it would be nice if the Linux kernel could print a more
descriptive error message in this case.
I’m not sure what the kernel conventions are: should the caller of
request_module() produce a good error message?
Ideally, the message would translate -2 into ENOENT, and mention the
name “brcmfmac-wcc”.

Or maybe we could have a kconfig option to indicate there is no
CONFIG_MODPROBE_PATH,
and instead make any request_module() call fail loudly with a
descriptive error in dmesg?

Thanks for considering
Best regards
Michael

On Wed, 15 Mar 2023 at 11:11, Arend van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
>
> On 3/15/2023 10:57 AM, Johannes Berg wrote:
> > On Wed, 2023-03-15 at 10:12 +0100, Arend van Spriel wrote:
> >>
> >> I think it works pretty similar to firmware loading. These days firmware
> >> loading does not rely on a user-space helper and I assumed the same is
> >> true for module loading. Will look into it.
> >>
> >
> > As far as I know you still need the modprobe helper in
> >
> > /proc/sys/kernel/modprobe
>
> Hi Michael,
>
> With hint from Johannes I found this Kconfig option:
>
> config MODPROBE_PATH
>          string "Path to modprobe binary"
>          default "/sbin/modprobe"
>          help
>            When kernel code requests a module, it does so by calling
>            the "modprobe" userspace utility. This option allows you to
>            set the path where that binary is found. This can be changed
>            at runtime via the sysctl file
>            /proc/sys/kernel/modprobe. Setting this to the empty string
>            removes the kernel's ability to request modules (but
>            userspace can still load modules explicitly).
>
> Now checking the .config that you sent it says:
>
> CONFIG_MODPROBE_PATH="/sbin/modprobe"
>
> So my suspicion is that modprobe is not at that given location?
>
> Regards,
> Arend




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux