linux-kernel - Re: USB storage no-boot regression (bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090415014930.GA29413@kroah.com>
Date:	Tue, 14 Apr 2009 18:49:44 -0700
From:	Greg KH <greg@...ah.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Linux USB kernel mailing list <linux-usb@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: USB storage no-boot regression (bisected)

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@...land.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@...land.harvard.edu>
> >     Tested-by: Arjan van de Ven <arjan@...radead.org>
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/