--- On Sun, 25/9/11, Mauro Carvalho Chehab <mche...@redhat.com> wrote: > Yes. Just after creating a device, udev tries to access it. > This bug is more sensitive on multi-CPU machines, as udev may run on > another CPU.
Heh, I have a hyper-threaded quad-core here. I suspect that counts as "multi-CPU" :-). However, I think we can agree that the first "plugging" event is not causing problems (in the modular case). The interesting thing about this first event is that it requests that the em28xx_dvb module be loaded, which in turn means that em28xx_init_extension() cannot invoke the dvb_init() function during em28xx_usb_probe(), thus avoiding the deadlock. So one of the following sequences of events must be occurring instead: Either: 1) em28xx_usb_probe() runs 2) em28xx_dvb module loads, invoking em28xx_register_extension() and dvb_init() 3) udev runs for V4L nodes Or: 1) em28xx_usb_probe() runs 2) udev runs for V4L nodes 3) em28xx_dvb module loads, invoking em28xx_register_extension() and dvb_init() The steps in both of these sequences are serialised by the dev->lock mutex. So wouldn't moving em28xx_init_extension() out of em28xx_init_dev() to the bottom of em28xx_usb_probe() (after the dev->lock mutex has been unlocked) be logically identical to the case where the em28xx-dvb module is loaded? Cheers, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
