From: Arjan van de Ven <arjan@infradead.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linux USB kernel mailing list <linux-usb@vger.kernel.org>,
Greg KH <greg@kroah.com>, Alan Stern <stern@rowland.harvard.edu>,
LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: USB storage no-boot regression (bisected)
Date: Tue, 14 Apr 2009 20:09:52 -0700 [thread overview]
Message-ID: <20090414200952.1714f1c5@infradead.org> (raw)
In-Reply-To: <49E54B12.8040303@garzik.org>
On Tue, 14 Apr 2009 22:48:50 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Arjan van de Ven wrote:
> > On Tue, 14 Apr 2009 22:30:28 -0400
> > Jeff Garzik <jeff@garzik.org> wrote:
> >
> >> Arjan van de Ven wrote:
> >>> This change just made it go faster enough for you to be out of
> >>> luck; fundamentally your userland needs to wait if the device it
> >>> wants is not there.
> >> All these drivers are in-kernel, and the root device is passed via
> >> command line. There is no userland at that point, that needs to
> >> wait.
> >
> > ok fair; but that does not change that the kernel does not know if a
> > device is coming.
> > Yes that sucks; sadly USB is just this way, you don't know when no
> > new devices will come from a certain bus.
>
> Perhaps -- but I can say that kernels <= 2.6.27 booted with 100%
> reliability.
>
> Now, Kernels >= 2.6.28 always fail.
> d
> The ONLY variable is the kernel.
yes.
and you can get the old behavior back by just sticking an
msleep(100 * <number of USB ports you have minus one>);
back in near the end of the boot.
that really is not the right answer.
by your argument if anything else gets faster and your system is then
booting too fast again that has to get reverted as well.
If there was some reasonable way to wait on USB scanning being done
we'd do that. Not a nanosecond doubt about that.
But since there isn't, this "race who's faster" is an unsolvable
problem other than by you saying "wait for root to be there please".
rootwait [KNL] Wait (indefinitely) for root device to show up.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
that option has been there for a really long time, and has technically be required
for your case. You got lucky so far by pure timing... until recently.
It's not nice to not boot suddenly, I sympathize with that. But there's nothing
we can realistically do other than using the option that is there for exactly your case.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
next prev parent reply other threads:[~2009-04-15 3:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 21:06 Jeff Garzik
2009-04-15 1:38 ` Arjan van de Ven
2009-04-15 2:30 ` Jeff Garzik
2009-04-15 2:44 ` Arjan van de Ven
2009-04-15 2:48 ` Jeff Garzik
2009-04-15 3:09 ` Arjan van de Ven [this message]
2009-04-15 8:40 ` Alan Cox
2009-04-15 1:49 ` Greg KH
2009-04-15 2:35 ` Jeff Garzik
2009-04-15 2:46 ` Arjan van de Ven
2009-04-15 5:09 ` Greg KH
2009-04-15 13:46 ` Jeff Garzik
2009-04-15 14:25 ` Mark Lord
2009-04-15 14:30 ` Arjan van de Ven
2009-04-15 15:37 ` Mark Lord
2009-04-15 19:58 ` Arjan van de Ven
2009-04-15 21:55 ` Mark Lord
2009-04-16 1:32 ` Arjan van de Ven
2009-04-16 2:14 ` Mark Lord
2009-04-16 2:54 ` Greg KH
2009-04-16 10:51 ` Alan Cox
2009-04-16 13:34 ` Arjan van de Ven
2009-04-16 13:49 ` Mark Lord
2009-04-16 2:17 ` Hal Murray
2009-04-16 3:42 ` Jeff Garzik
2009-04-15 15:01 ` Alan Cox
2009-04-15 15:47 ` Alan Stern
2009-04-15 15:49 ` Mark Lord
2009-04-15 17:06 ` VomLehn
2009-04-15 17:32 ` Alan Cox
2009-04-15 20:06 ` Arjan van de Ven
2009-04-15 20:20 ` VomLehn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090414200952.1714f1c5@infradead.org \
--to=arjan@infradead.org \
--cc=greg@kroah.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®