On Fri, May 11, 2012 at 2:16 PM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: > On 05/11/2012 01:03 PM, Kay Sievers wrote: >> 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 > > 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. > [ 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
