| Message ID | 1373574654-32427-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Superseded |
| Headers | show |
Hi Gustavo, On Thu, Jul 11, 2013 at 10:30 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > Register mdev as hotplug helper for many goodies and expected behaviour > (like automatic firmware loading). > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> > --- > package/busybox/S10mdev | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/busybox/S10mdev b/package/busybox/S10mdev > index c06aa20..c41f166 100644 > --- a/package/busybox/S10mdev > +++ b/package/busybox/S10mdev > @@ -6,6 +6,7 @@ > case "$1" in > start) > echo "Starting mdev..." > + echo /sbin/mdev 2>/dev/null >/proc/sys/kernel/hotplug > /sbin/mdev -s > ;; > stop) In linux/linux.mk, there mdev is already set as hotplug helper in the kernel configuration. How does this change relate to it? At first sight, it seems unnecessary. I did notice that setting mdev as hotplug helper in the kernel configuration, can seriously impact boot performance. On a board with a not so fast single core processor (around 500MHz) boot time until userspace became about 10 seconds coming from 2s. We solved this by setting no helper in the kernel configuration (and telling buildroot to use just devtmpfs instead of mdev), and manually copying S10mdev to the rootfs. Then, mdev is run once during userspace init. This doesn't give automatic firmware loading, but that would be solved by your above patch, I think. Did anyone else notice such slowdown behavior? Best regards, Thomas
On 07/12/2013 04:01 AM, Thomas De Schampheleire wrote: > In linux/linux.mk, there mdev is already set as hotplug helper in the > kernel configuration. > How does this change relate to it? At first sight, it seems unnecessary. > > I did notice that setting mdev as hotplug helper in the kernel > configuration, can seriously impact boot performance. On a board with > a not so fast single core processor (around 500MHz) boot time until > userspace became about 10 seconds coming from 2s. We solved this by > setting no helper in the kernel configuration (and telling buildroot > to use just devtmpfs instead of mdev), and manually copying S10mdev to > the rootfs. Then, mdev is run once during userspace init. > This doesn't give automatic firmware loading, but that would be solved > by your above patch, I think. > > Did anyone else notice such slowdown behavior? I actually came up with this patch because a user on a pandaboard had issues getting the wifi up (wl127x, needs firmware). At first he was running a static device tree configuration which explained the problem. He then switched to mdev and things didn't work, and switching to udev did make it work. So i looked at S10mdev and saw that the hotplug helper wasn't registered. It's likely that he didn't make clean between switching to mdev and the kernel hence didn't get reconfigured/rebuilt and that was the problem. However as you say, if the kernel has pre-registered the hotplug helper in the configuration all the hotplug events at boot time are probably getting called (all the bus interfaces and whatnot). I tend to use my own initscripts tree since it's quite tweaked regarding the bare default (i basically nuke all of buildroots initscripts and replace them with my own), and on an arm920t (slow really, 180 mhz) i have no major delay when using this method. The only "drawback" would be missing usb devices if they're already plugged in and the usb controller driver isn't a module - but really that's coldplug-world. Regards.
Hi, On Fri, Jul 12, 2013 at 12:27 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > On 07/12/2013 04:01 AM, Thomas De Schampheleire wrote: >> In linux/linux.mk, there mdev is already set as hotplug helper in the >> kernel configuration. >> How does this change relate to it? At first sight, it seems unnecessary. >> >> I did notice that setting mdev as hotplug helper in the kernel >> configuration, can seriously impact boot performance. On a board with >> a not so fast single core processor (around 500MHz) boot time until >> userspace became about 10 seconds coming from 2s. We solved this by >> setting no helper in the kernel configuration (and telling buildroot >> to use just devtmpfs instead of mdev), and manually copying S10mdev to >> the rootfs. Then, mdev is run once during userspace init. >> This doesn't give automatic firmware loading, but that would be solved >> by your above patch, I think. >> >> Did anyone else notice such slowdown behavior? > > I actually came up with this patch because a user on a pandaboard had > issues getting the wifi up (wl127x, needs firmware). > At first he was running a static device tree configuration which > explained the problem. > He then switched to mdev and things didn't work, and switching to udev > did make it work. > So i looked at S10mdev and saw that the hotplug helper wasn't registered. > It's likely that he didn't make clean between switching to mdev and the > kernel hence didn't get reconfigured/rebuilt and that was the problem. > However as you say, if the kernel has pre-registered the hotplug helper > in the configuration all the hotplug events at boot time are probably > getting called (all the bus interfaces and whatnot). > I tend to use my own initscripts tree since it's quite tweaked regarding > the bare default (i basically nuke all of buildroots initscripts and > replace them with my own), and on an arm920t (slow really, 180 mhz) i > have no major delay when using this method. > The only "drawback" would be missing usb devices if they're already > plugged in and the usb controller driver isn't a module - but really > that's coldplug-world. > Regards. > So what do we do with this patch? I ask it because it's still marked as 'New' in patchwork: http://patchwork.ozlabs.org/patch/258619/ If we agree that it shouldn't be needed, I suggest to mark it as such. If someone can come up with a proven failure scenario, we can still reopen it. What do you think? Thanks, Thomas
On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote: > So what do we do with this patch? > I ask it because it's still marked as 'New' in patchwork: > http://patchwork.ozlabs.org/patch/258619/ > If we agree that it shouldn't be needed, I suggest to mark it as such. > If someone can come up with a proven failure scenario, we can still reopen it. > > What do you think? Proven failure: not building a kernel with buildroot. Regards.
On Sun, Jul 28, 2013 at 1:28 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote: > >> So what do we do with this patch? >> I ask it because it's still marked as 'New' in patchwork: >> http://patchwork.ozlabs.org/patch/258619/ >> If we agree that it shouldn't be needed, I suggest to mark it as such. >> If someone can come up with a proven failure scenario, we can still reopen it. >> >> What do you think? > > Proven failure: not building a kernel with buildroot. Agreed. So in this case, the patch can be helpful. One question then about it: what is the purpose of the 2>/dev/null ? How would echo fail? Thanks, Thomas
On 07/28/2013 08:56 AM, Thomas De Schampheleire wrote: > Agreed. So in this case, the patch can be helpful. > > One question then about it: what is the purpose of the 2>/dev/null ? > How would echo fail? No hotplug support in the kernel. Regards.
On Sun, Jul 28, 2013 at 1:57 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > On 07/28/2013 08:56 AM, Thomas De Schampheleire wrote: > >> Agreed. So in this case, the patch can be helpful. >> >> One question then about it: what is the purpose of the 2>/dev/null ? >> How would echo fail? > > No hotplug support in the kernel. Alright, you win ;-) Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
On 07/28/2013 09:09 AM, Thomas De Schampheleire wrote: > Alright, you win ;-) > > Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Actually users who don't do the kernel in buildroot win, i usually do. And even if i didn't i use my own set of customs scripts :) Thanks. Regards.
Dear Gustavo Zacarias, On Sun, 28 Jul 2013 08:28:55 -0300, Gustavo Zacarias wrote: > On 07/28/2013 05:33 AM, Thomas De Schampheleire wrote: > > > So what do we do with this patch? > > I ask it because it's still marked as 'New' in patchwork: > > http://patchwork.ozlabs.org/patch/258619/ > > If we agree that it shouldn't be needed, I suggest to mark it as such. > > If someone can come up with a proven failure scenario, we can still reopen it. > > > > What do you think? > > Proven failure: not building a kernel with buildroot. Not really an argument: if you select 'devtmpfs' as the /dev management method and you build your kernel outside of Buildroot, you have to enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't work. I don't see what it shouldn't be the same for the hotplug helper selection: if you're building the kernel with Buildroot, then things are taken care of automatically, otherwise you're on your own. Best regards, Thomas
On 07/28/2013 10:14 AM, Thomas Petazzoni wrote: >> Proven failure: not building a kernel with buildroot. > > Not really an argument: if you select 'devtmpfs' as the /dev management > method and you build your kernel outside of Buildroot, you have to > enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't > work. I don't see what it shouldn't be the same for the hotplug helper > selection: if you're building the kernel with Buildroot, then things are > taken care of automatically, otherwise you're on your own. Then we should just ditch the device managment options if the user isn't building a kernel? Double-edged knife there :) For mdev that can be solved, at worst it'll be an (almost) no-op, devtmpfs is another story. Regards.
Dear Gustavo Zacarias, On Sun, 28 Jul 2013 10:38:06 -0300, Gustavo Zacarias wrote: > >> Proven failure: not building a kernel with buildroot. > > > > Not really an argument: if you select 'devtmpfs' as the /dev management > > method and you build your kernel outside of Buildroot, you have to > > enable CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT, otherwise things won't > > work. I don't see what it shouldn't be the same for the hotplug helper > > selection: if you're building the kernel with Buildroot, then things are > > taken care of automatically, otherwise you're on your own. > > Then we should just ditch the device managment options if the user isn't > building a kernel? No because it also controls whether the device_table_dev.txt is use to create static devices or not. It also controls whether the udev package is built, etc. So clearly the device management options aren't just controlling the kernel configuration, but a lot of other things as well. > For mdev that can be solved, at worst it'll be an (almost) no-op, > devtmpfs is another story. That's true. Thomas
On 07/28/2013 10:51 AM, Thomas Petazzoni wrote: >> For mdev that can be solved, at worst it'll be an (almost) no-op, >> devtmpfs is another story. > > That's true. It basically boils down to helping people or not on alternate scenarios. Some random guy in #pandaboard was having issues loading firmware on a prebuilt kernel (which sometimes happens to be a sore PITA to build a working kernel with some vendors/for some people, no point in arguing that no matter how much we wish everything were upstreamed/vanilla) for WiFi support and (obviously) mdev wasn't working. Solution was get your kernel source/config right, or fix the script. The script was a quick way out without bad side effects. On a personal level i don't care about the patch, it was just a quick and painless way of fixing a common problem. Regards.
Dear Gustavo Zacarias, On Sun, 28 Jul 2013 11:01:29 -0300, Gustavo Zacarias wrote: > It basically boils down to helping people or not on alternate scenarios. > Some random guy in #pandaboard was having issues loading firmware on a > prebuilt kernel (which sometimes happens to be a sore PITA to build a > working kernel with some vendors/for some people, no point in arguing > that no matter how much we wish everything were upstreamed/vanilla) for > WiFi support and (obviously) mdev wasn't working. > Solution was get your kernel source/config right, or fix the script. > The script was a quick way out without bad side effects. > On a personal level i don't care about the patch, it was just a quick > and painless way of fixing a common problem. Right. But then maybe the 2>/dev/null should be removed, so that if the sysctl file to set the hotplug helper doesn't exist, the user sees that something is wrong? (That said, I think CONFIG_HOTPLUG has become mandatory in recent kernels, so it shouldn't be a big problem.) Thomas
On 07/28/2013 11:03 AM, Thomas Petazzoni wrote: > Right. But then maybe the 2>/dev/null should be removed, so that if the > sysctl file to set the hotplug helper doesn't exist, the user sees that > something is wrong? > > (That said, I think CONFIG_HOTPLUG has become mandatory in recent > kernels, so it shouldn't be a big problem.) Yes, it's been for a while it seems, not completely cleaned up from the kernel though (it's still mentioned in Documentation, several defconfigs and a couple of source files). Ok, i'll resend without the stderr pipe. Regards.
diff --git a/package/busybox/S10mdev b/package/busybox/S10mdev index c06aa20..c41f166 100644 --- a/package/busybox/S10mdev +++ b/package/busybox/S10mdev @@ -6,6 +6,7 @@ case "$1" in start) echo "Starting mdev..." + echo /sbin/mdev 2>/dev/null >/proc/sys/kernel/hotplug /sbin/mdev -s ;; stop)
Register mdev as hotplug helper for many goodies and expected behaviour (like automatic firmware loading). Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- package/busybox/S10mdev | 1 + 1 file changed, 1 insertion(+)