hotplug and modalias handling (WAS: Re: RFD: Rework/extending functionality of mdev)

James Bowlin bitjam at gmail.com
Tue Mar 17 23:51:39 UTC 2015


On Mon, Mar 16, 2015 at 09:55 AM, Natanael Copa said:
> On Fri, 13 Mar 2015 13:12:56 -0600
> James Bowlin <bitjam at gmail.com> wrote:
> 
> > TL;DR: the current busybox (or my code) seems to be broken on one
> > or two systems out of thousands; crucial modules don't get loaded
> > using hotplug + coldplug.  Please give me a runtime option so I
> > can give my users a boot-time option to try the new approach.
> 
> Do you use mdev as kernel helper?

Yes.  We specifically use it to load modules associated with newly
discovered hardware when our live system first boots. This is working
99+% of the time just fine.

> Alpine linux initramfs currently does:
> 
>   find /sys -name modalias | xargs sort -u | xargs modprobe -a
> 
> using busybox modprobe.

That expression doesn't look right for several reasons.  About
six weeks ago I thought a suggestion from the following
alpinelinux post would solve my problems:
http://article.gmane.org/gmane.linux.distributions.alpine.devel/2791

> Or it could be the kernel creating the uevent but not the
> modalias file--which is a known issue with some hardware; the
> workaround is to use something like this:

> find /sys -name uevent -exec grep -h MODALIAS= '{}' + \
>    | sort -u | cut -c 10- | xargs modprobe -a 

But that wasn't the answer.  The find -exec sed code I gave
previously is a streamlined version of this.  As I said, it made
no difference.  Also, I was curious if you found that using /sys
was ever better than using /sys/devices.  It is certainly slower,
but I haven't seen any systems where scanning /sys/ gives any
more information than scanning /sys/devices after passing the
aliases through sort -u.  It didn't make a difference on two
systems I looked at that had problems hotplugging modules needed
for booting.

> Since loading the modules might trigger new MODALIAS events you
> need your hotplugger to handle those. You can use this line in
> mdev.conf:
> 
>   $MODALIAS=.*    root:root       0660    @modprobe -b "$MODALIAS"

Yes.  ISTM that without such a line the mdev hotplugger would never
load modules, although maybe I am doing something else bone-headed.

I suspected one system had a problem loading the sd-mod module even
though the alias for this module showed up in the output of:

    find /sys/devices -name modalias -exec cat '{}' +

on their system.  One strange thing that makes me wonder if busybox
might be at fault is that if I run:

    modprobe -D sd-mod

Then the standard modprobe lists 5 modules that should get loaded:

    crc-t10dif
    crct10dif-common
    crct10dif-generic
    scsi-mod
    sd-mod

The actual output is more verbose but this is the essence.  The
busybox version of modprobe omits "crct10dif-generic" although it
does *load* all five modules when there is no "-D".  Af first I
thought I had tracked down the problem until I tested to verify
that the modules loaded were the same as the -D output.  They
were not.  The modules loaded correctly.

The relevant lines in modules.dep are the same when generated by
the kmod depmod (in Gentoo) and busybox depmod:

$ grep crct10dif_ modules.dep 
live/crc-t10dif.ko: live/crct10dif_common.ko
live/crct10dif_generic.ko: live/crct10dif_common.ko
live/crct10dif_common.ko:
live/sd_mod.ko: live/crc-t10dif.ko live/crct10dif_common.ko
live/scsi_mod.ko

So far this seems like a oddity and a strange coincidence; not
quite enough meat for a bug report.  I'm not even sure sd-mod
was the missing module.  It may well have been the usb-storage
module which I know was was missing (not loaded) on a 2nd system
with problems.

In the past few days I've got my hands on a system where
depending on the hardware (usb device used and usb slot used) the
usb-storage module sometimes does not get loaded which means the
boot device does not show up.

My current plan is to make repeated coldplugging the default
method for loading modules since in every case I've been able to
investigate, an alias for the missing module(s) is in the output
of the find command I gave above.  I haven't yet done exhaustive
testing but every test with repeated coldplugging has worked even
on the system where the hotplugging is flaky (and which is now
out of my reach).

I don't know why hotplugging works most of the time but not all
the time.  ISTM as long as I start the hotplugging before I do
the first (and used to be only) coldplug, there is not a lot I
can mess up.  Another check is that  with hotplugging disabled
and only a single coldplug then there are very few (if any?)
situations where it will boot since it usually takes a few
seconds for the boot device to show up and that first cold plug
is done ASAP.


Peace, James


More information about the busybox mailing list