On 01/14/2012 09:25 AM, Kay Sievers wrote:
Hey, just a heads-up, when bug reports are coming in now. The kernel log might look like a kernel failure, but it's caused by recent userspace changes. We changed udev to strictly enforce sequence order and dependency handling of events. This seems to break some netdev drivers which block in modprobe until the firmware from userspace is loaded into the driver. I think it's out of question, that nothing must block in module init and rely on a userspace transaction to be fulfilled to finish the init_module() syscall. If userspace is not running properly, nothing will work. Built-in drivers and the transition from initramfs to the real root can't be handled properly that way. These drivers need to be fixed to load their firmware during ifup, which would be the most flexible solution. That way, it should also work if the driver is built-in, or is loaded from initramfs and no firmware is available. Alternatively, the firmware request should be able to use the aync firmware_request API and not the blocking one. We might need to work around that in the current udev for now, but these drivers will definitely break in future udev versions. Userspace, these days, should not be in charge of papering over obvious kernel bugs like this. These are the drivers we received bug reports so far. We didn't look into any of details of the drivers, but according to the logs, they seem to block for 60 seconds in modprobe, when userspace is not behaving like expected: bnx2/bnx2-mips-06-6.2.1.fw rtlwifi/rtl8192sefw.bin brcm/bcm43xx-0.fw
Thanks for the heads-up. Do you have a reference for the problem with rtlwifi/rtl8192sefw.bin? Google did not find anything that looked appropriate.
Thanks, Larry -- 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
