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

[Isaac Dunham]

On Tue, Mar 17, 2015 at 05:51:39PM -0600, James Bowlin wrote:
> 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.

Is this manifested as "the root device never shows up"?

> > 
> > 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 

As the one who probably posted this, I can comment further:
I've heard of one computer where this was an issue, a couple years ago;
a number of people on the Puppy Linux forums were experimenting with
mdev, and one reported that the modalias file was missing with
a Broadcom wireless card.

> 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

I'm not aware of any cases where /sys/devices was problematic,
and that was another method that was recommended on the Puppy
Linux forums.

However, you may find it worth noting that "find /sys" will get
its list of files slightly later than globbing will.

> 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
<snip>
>  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.

Do you wait for the boot device to show up?

I know the kernel has a rootwait parameter for similar issues with
usb drives.
Of course, the root device may be unknown depending on what you're
doing, which would make waiting properly rather difficult.

(What I'd be inclined to do is check for the root and if it fails,
coldplug a second time/blindly load sd_mod and usb_storage)
 
> 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).

HTH,
Isaac Dunham