lkml.org 
[lkml]   [2006]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.16-rc4: known regressions


    On Wed, 22 Feb 2006, Gabor Gombas wrote:
    >
    > I don't think isnmod is broken. It's job is to load a chunk of code into
    > the kernel, and it's doing just that.
    >
    > The asynchronous device discovery is caused/required by hotplug. If you
    > can recreate the problem with a kernel that has CONFIG_HOTPLUG disabled,
    > then I agree that this is a kernel bug which should be fixed.

    I think it currently can happen without HOTPLUG too. In fact,
    CONFIG_HOTPLUG is really a "special drivers that do hot-plugging", not
    about "devices that show up on their own".

    The thing is, "insmod" really just tends to introduce the driver to the
    kernel. It leaves it pretty open what that driver will actually _do_. And
    a lot of drivers tend to do discovery independently of actually plugging
    in the driver.

    For example, any USB host driver will always discover its devices
    asynchronously, and has no dependency on CONFIG_HOTPLUG. It can take
    several seconds for all the hubs to have powered up and discovered what is
    behind them.

    The same is true of most SCSI buses - CONFIG_HOTPLUG may talk about
    whether the actual _controller_ is hotpluggable, but not about whether a
    disk is, or how disk discovery takes place.

    Now, arguably "insmod" (both the user binary and the kernel side) is doing
    the right thing: it's inserting the driver. The fact that all the devices
    that the driver uses may not be immediately available is not insmod's
    issue. That's a very valid way to look at it.

    At the same time, it's also arguable that from an ease of use standpoint,
    "insmod" should generally try to wait until the driver has enumerated what
    it knows about. That's a totally non-technical argument, but it's an
    equally valid standpoint.

    Of course, the technical argument is that discovery can take a long long
    time (minutes to wait for disks to spin up etc), so if insmod were to wait
    for it all, we'd be really screwed and our bootup times would go through
    the roof.

    The usability argument is that right now we don't have any easy way at all
    to wait for bus scanning to have finished, and that's a very valid
    argument. You could wait for the hotplug event, but since you don't even
    _know_ that you'll get such an event, that's really not a very good answer
    either.

    We could improve.

    I _think_ that in this particular case, the best particular choice might
    be for the "mount" binary to be taught to re-try after a few seconds:
    either with a command line argument, or with just the early bootup initrd
    code being encouraged to have a loop like

    if (mounting root failed)
    echo "Please press F1 to continue"
    do
    read-keyboard-with-5-second-timeout
    while (mounting root failed)
    endif

    so that the user would have to press a key (or we'd just re-try every five
    seconds).

    That way, the boot wouldn't just fail immediately over something that can
    be fixed (sometimes the root partition might just be hot-pluggable too:
    "insert disk and continue" can be a valid way to handle issues).

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:4.016 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site