On Sat, Aug 09, 2014 at 10:33:47AM +0200, Luis R. Rodriguez wrote: > On Sat, Aug 09, 2014 at 09:42:36AM +0200, Kay Sievers wrote: > > On Sat, Aug 9, 2014 at 4:16 AM, Luis R. Rodriguez > > <mcg...@do-not-panic.com> wrote: > > > The purpose of commit e64fae55 (January 2012) on systemd was > > > to introduce a timeout send to hell drivers that are not using > > > asynch firmware loading. That commit actually would not have > > > triggered in full effect on udev's usage of kmod for module > > > loading until commit 786235ee was merged on Linux (Nov 2013). > > > > > > As it is today [ systemd e64fae55 + kernel e64fae55 ] will trigger > > > a SIGKILL to udev's usage of kmod for module loading after a 30 > > > second timeout. Hannes modified systemd through commit 9719859c > > > to enable a custom timeout. A different timeout value can only > > > prevent a kill after a maximum amount of time is known to be > > > required for a system. > > > > > > Penalizing a device driver for not using asynch firmware loading > > > by killing it and preventing it from loading *might* have originally > > > been reasonable but its not the only reason why some drivers might > > > take more than 30 seconds to load. Some drivers might actually > > > require take over 30 seconds on just writing the firmware to the > > > hardware. The worst case scenario however would be to run into > > > storage drivers which might go over the timeout value in which > > > case currently the system would simply be unbootable. Fixing > > > drivers should be our *top priority* but the current state of > > > affairs has proven to make it very difficult to debug why a > > > driver is failing to load. > > > > > > Instead of always forcing a kill lets only warn for workers > > > handling kmod. This should enable easier methods for determining > > > which drivers need fixing and the logic would only be used on > > > workers dealing with kmod module loading. > > > > Nobody wanted to send anything to hell, penalize or force anything > > anywhere. This kind of language is absolutely not welcome here. > > > > Every operation in systemd, unless specified otherwise, has and needs > > to have a timeout. The 30 seconds were arbitrarily chosen just to be > > smaller than the kernel's own 60 second timeout for the userspace > > firmware loader. Now that userspace firmware loading is gone, this > > does not apply anymore. > > > > Like everywhere else, we should keep the timeout handling by default. > > If 60 seconds are too short, we might want to set it to something > > else. > > Putting emphasis only on firmware loading is exactly what took us to where we > are today with the current timeout. As we have seen though firmware loading > though is not what actually takes a lot of time, at times actually writing the > firmware to hardware can take more time. There are other scenarios which have > creeped up as well such as delays on other areas of network drivers and > storage > drivers. We're all in agreement all this needs to be fixed on drivers, > however > in light of these other circumstances and given that it will take time to fix > these drivers, and given that its hard to debug the cause to current driver > failures on the timeout a warning for kmod loading would do much more to help > use fix drivers than a kill.
"time to fix these drivers"? I posted a 10 line patch to do so for any driver that has a problem, and another core kernel developer agreed with it and said it should be made even more general, and easier to use for all drivers (resulting in only a 1-2 line change per driver affected.) What happened to that work, has it been dropped for some reason? Was it tested and found to not work properly? Was it rejected by a subsystem maintainer that I didn't see? thanks, greg k-h _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
