in-kernel drivers and firmware loader
Hi Kay,
To my memory (which fails from time to time) you posted a message on using the asynchronous API for firmware loading as some drivers were blocking on it in the module initialization. So for our driver we decoupled the initialization from probe and subsequently the firmware request. Assuming this solves the udev issue, but I am currently looking into a somewhat related issue with our driver built-in.
I am testing on a PandaBoard which boots a linux kernel without a initrd and our device is detected before the root filesystem is mounted. I was expecting the async firmware request to get called back immediatly with firmware pointer being NULL. The behaviour is slightly different as this callback is coming after 60 seconds, which is the timeout. I guess the uevent just gets lost without the kernel knowing it. Is that correct?
Gr. AvS
Quoted 7 lines · Arend van Spriel
To my memory (which fails from time to time) you posted a message on using the asynchronous API for firmware loading as some drivers were blocking on it in the module initialization. So for our driver we decoupled the initialization from probe and subsequently the firmware request. Assuming this solves the udev issue, but I am currently looking into a somewhat related issue with our driver built-in.
Quoted 6 lines
I am testing on a PandaBoard which boots a linux kernel without a initrd and our device is detected before the root filesystem is mounted. I was expecting the async firmware request to get called back immediatly with firmware pointer being NULL. The behaviour is slightly different as this callback is coming after 60 seconds, which is the timeout. I guess the uevent just gets lost without the kernel knowing it. Is that correct?
It's probably sent, but nothing see it because there is no userspace that would have subscribed.
If udev is started later during bootup, and the coldplug triggers all events again, the firmware request should be found and be fulfilled by userspace -- at least that's the theory.
Can you reach the box with a login before the 60 seconds are reached?
Do you see a firmware request (directory) still hanging around in /sys/class/firmware/ ?
Kay
Quoted 7 lines · Kay Sievers
Quoted 6 lines
I am testing on a PandaBoard which boots a linux kernel without a initrd and our device is detected before the root filesystem is mounted. I was expecting the async firmware request to get called back immediatly with firmware pointer being NULL. The behaviour is slightly different as this callback is coming after 60 seconds, which is the timeout. I guess the uevent just gets lost without the kernel knowing it. Is that correct?
Quoted 6 lines
It's probably sent, but nothing see it because there is no userspace that would have subscribed.
If udev is started later during bootup, and the coldplug triggers all events again, the firmware request should be found and be fulfilled by userspace -- at least that's the theory.
I haven't really read all of the message, but we've also had users who observed in some cases that the coldplug doesn't properly trigger firmware load requests. Unfortunately, I don't have any details.
johannes
Quoted 22 lines · Kay Sievers
Quoted 7 lines · Arend van Spriel
To my memory (which fails from time to time) you posted a message on using the asynchronous API for firmware loading as some drivers were blocking on it in the module initialization. So for our driver we decoupled the initialization from probe and subsequently the firmware request. Assuming this solves the udev issue, but I am currently looking into a somewhat related issue with our driver built-in.
Quoted 6 lines
I am testing on a PandaBoard which boots a linux kernel without a initrd and our device is detected before the root filesystem is mounted. I was expecting the async firmware request to get called back immediatly with firmware pointer being NULL. The behaviour is slightly different as this callback is coming after 60 seconds, which is the timeout. I guess the uevent just gets lost without the kernel knowing it. Is that correct?
It's probably sent, but nothing see it because there is no userspace that would have subscribed.
If udev is started later during bootup, and the coldplug triggers all events again, the firmware request should be found and be fulfilled by userspace -- at least that's the theory.
Quoted 7 lines
Can you reach the box with a login before the 60 seconds are reached?
Do you see a firmware request (directory) still hanging around in
/sys/class/firmware/?Kay
Thanks, Kay
Here is the
# cd /sys/class/firmware/mmc1\:0001\:2/ # ls data device loading power subsystem uevent # cat uevent FIRMWARE=brcm/brcmfmac-sdio.bin TIMEOUT=60 ASYNC=1 # cat loading 0
Not sure if loading content means anything or it presence is indicating it is in progress. Below also the dmesg output.
Gr. AvS
[ 6.801452] brcmfmac: brcmf_sdbrcm_probe: completed!! [ 6.801483] brcmfmac: brcmf_sdbrcm_probe: request firmware "brcm/brcmfmac-sdio.bin" [ 6.802703] brcmfmac: brcmf_ops_sdio_probe: Enter [ 6.802703] brcmfmac: brcmf_ops_sdio_probe: func->class=2 [ 6.802734] brcmfmac: brcmf_ops_sdio_probe: sdio_vendor: 0x02d0 [ 6.802734] brcmfmac: brcmf_ops_sdio_probe: sdio_device: 0x4329 [ 6.802734] brcmfmac: brcmf_ops_sdio_probe: Function#: 0x0003 [ 6.895507] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, ca:2a:a4:72:d9:6b [ 6.908111] drivers/usb/core/inode.c: creating file '003' [ 6.921234] mmc2: card claims to support voltages below the defined range. These will be ignored. [ 6.940582] mmc2: queuing unknown CIS tuple 0x91 (3 bytes) [ 6.947418] mmc2: new SDIO card at address 0001 [ 7.001281] kjournald starting. Commit interval 5 seconds [ 7.014190] EXT3-fs (mmcblk0p2): using internal journal [ 7.019714] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode [ 7.027038] VFS: Mounted root (ext3 filesystem) on device 179:2. [ 7.036437] devtmpfs: mounted [ 7.039764] Freeing init memory: 236K [ 8.119812] hub 2-0:1.0: hub_suspend [ 8.120025] usb usb2: bus auto-suspend, wakeup 1 [ 8.120056] ohci-omap3 ohci-omap3.0: suspend root hub [ 9.666809] usb 1-1.1: link qh8-0001/ee2cc700 start 2 [1/0 us] [ 11.448059] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 [ 67.573059] brcmfmac: brcmf_sdbrcm_fw_callback: enter [ 67.573059] brcmfmac: brcmf_sdbrcm_fw_callback: firmware not found [ 67.573059] brcmfmac: brcmf_sdbrcm_release: Enter
Quoted 24 lines · Arend van Spriel
Quoted 11 lines · Kay Sievers
It's probably sent, but nothing see it because there is no userspace that would have subscribed.
If udev is started later during bootup, and the coldplug triggers all events again, the firmware request should be found and be fulfilled by userspace -- at least that's the theory.
Can you reach the box with a login before the 60 seconds are reached?
Do you see a firmware request (directory) still hanging around in
/sys/class/firmware/?# cd /sys/class/firmware/mmc1\:0001\:2/ # ls data device loading power subsystem uevent # cat uevent FIRMWARE=brcm/brcmfmac-sdio.bin TIMEOUT=60 ASYNC=1 # cat loading 0
Quoted 2 lines
Not sure if loading content means anything or it presence is indicating it is in progress. Below also the dmesg output.
Yeah, that looks good. The request is still around and waits for userspace to get handled.
Quoted 2 lines
[ 11.448059] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, [ 67.573059] brcmfmac:
brcmf_sdbrcm_fw_callback: enter
Seems userspace is not doing anything here, it's just the kernel timeout that we run into.
If you can manage to do this before the timeout triggers, it should show if things *can* work:
Start:
udevd --daemon
if it's not already running.
Trigger 'fake' events for all devices in the system, so that udev 'thinks' the firmware request just came in:
udevadm trigger --action=add
Normally, all that should be handled by the base system, and not need any custom setup.
Kay