From: Greg KH <greg@kroah.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linux USB kernel mailing list <linux-usb@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: USB storage no-boot regression (bisected)
Date: Tue, 14 Apr 2009 18:49:44 -0700 [thread overview]
Message-ID: <20090415014930.GA29413@kroah.com> (raw)
In-Reply-To: <49E4FAC6.1030400@garzik.org>
On Tue, Apr 14, 2009 at 05:06:14PM -0400, Jeff Garzik wrote:
>
> Once of the x86-64 machines I use for testing runs off of two 2GB USB
> flash drives, one for Fedora 10 userland, and one for kernel repository
> + builds.
>
> It boots correctly in 2.6.27, but fails with the same symptoms in
> 2.6.28, 2.6.29 and 2.6.30-rc1:
>
> 1) The kernel boots
> 2) After time passes, kernel begins executing initramfs
> userland
> 3) the kernel prints out probe messages for the USB keyboard,
> SCSI probe messages for the two USB flash drives
>
> Or IOW, the keyboard and two SCSI drives appear after initramfs begins
> booting. And this is for drivers built into the kernel (though same
> behavior with modules).
>
> This no-boot regression is 100% reproducible, and neatly bisects down to
>
> > commit 8520f38099ccfdac2147a0852f84ee7a8ee5e197
> > Author: Alan Stern <stern@rowland.harvard.edu>
> > Date: Mon Sep 22 14:44:26 2008 -0400
> >
> > USB: change hub initialization sleeps to delayed_work
> >
> > This patch (as1137) changes the hub_activate() routine, replacing the
> > power-power-up and debounce delays with delayed_work calls. The idea
> > is that on systems where the USB stack is compiled into the kernel
> > rather than built as modules, these delays will no longer block the
> > boot thread. At least 100 ms is saved for each root hub, which can
> > add up to a significant savings in total boot time.
> >
> > Arjan van de Ven was very pleased to see that this shaved 700 ms off
> > his computer's boot time. Since his total boot time is on the order
> > of two seconds, the improvement is considerable.
> >
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Tested-by: Arjan van de Ven <arjan@infradead.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>
> My preliminary guess is that this made things --too-- asynchronous, and
> for some reason userland begins executing before the SCSI core
> initializes the USB storage as Linux block devices.
>
> In any case, I cannot boot because of the above commit :)
Like Arjan said, this is because we are initializing faster now, and
things are a bit more asynchronous. Use the root_delay boot option,
that's what I use for my USB-based systems, and have not had a problem
with that at all.
thanks,
greg k-h
next prev parent reply other threads:[~2009-04-15 1:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 21:06 USB storage no-boot regression (bisected) 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
2009-04-15 8:40 ` Alan Cox
2009-04-15 1:49 ` Greg KH [this message]
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=20090415014930.GA29413@kroah.com \
--to=greg@kroah.com \
--cc=arjan@infradead.org \
--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