Bug 6596

Summary: Slow bootup if mdev is chosen
Product: buildroot Reporter: Andreas Koop <andreas.koop>
Component: OtherAssignee: unassigned
Status: RESOLVED FIXED    
Severity: minor CC: buildroot
Priority: P5    
Version: 2013.08   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Host: Target:
Build:
Attachments: disable CONFIG_UEVENT_HELPER_PATH option

Description Andreas Koop 2013-10-24 06:41:22 UTC
Created attachment 5090 [details]
disable CONFIG_UEVENT_HELPER_PATH option

When I choose mdev my Nios II based board stalls for about two minutes during boot up. Then it proceeds again and boots normally. I've tracked the issue down. It's because buildroot sets CONFIG_UEVENT_HELPER_PATH to "/sbin/mdev" during kernel configuration. When I set it to an empty string Linux (3.10.0) boots up as usual again.
If you look at the kernel's own description of CONFIG_UEVENT_HELPER_PATH it states it shouldn't be used today anymore since it creates a high system load on bootup.
Mdev still works after it's startup script has been run. It writes "/sbin/mdev" to /proc/sys/kernel/hotplug which causes the kernel to inform mdev about new events.
Comment 1 Thomas De Schampheleire 2013-10-24 08:19:22 UTC
We have had a discussion about this topic in the past:
http://lists.busybox.net/pipermail/buildroot/2013-July/075148.html

I indeed have noticed the same slowdown, and our solution was the same (setting the UEVENT_HELPER to empty).

Given that the mentioned thread changed S10mdev to set mdev as helper after boot, I don't think we still need/want the in-kernel option.

Would you mind sending this change as a proper patch to the mailing list, including description and Signed-off-by? This would provide you with the necessary credit, and also facilitates discussion on the patch.
Comment 2 Thomas De Schampheleire 2014-02-07 08:43:41 UTC
Patch sent to the mailing list, awaiting integration, after which this bug can be closed...
Comment 3 Peter Korsgaard 2014-02-09 22:17:00 UTC
Committed in git (05e2e35715d104e9dd67b4013d9b16a47b8eb3c0), thanks