PROBLEM: when booting from USB-HDD device kernel 2.4.21 is trying to mount root file system too early before usb device is found on the usb-bus

PROBLEM: when booting from USB-HDD device kernel 2.4.21 is trying to mount root file system too early before usb device is found on the usb-bus

[Ilia A. Petrov]

When kernel is mounting root file system it is doing it too fast so 
usb-support have not ime to scan bus for mass-storage devices and 
connect them.

i've tested bios usb support, so i've checked how fine different OSes 
boot from USB mass-storage divices. here is my linux test:
	kernel 2.4.21, with compiled-in usb support (core, HID and mass-storage 
devices) and scsi generic support
	USB-HDD device supports bulk-only & scsi commands
	PC with BIOS that supports USB-booting

i've executed "rdev" to point kernel that root file system will be on 
/dev/sda1 (cause USB-HDD uses scsi commands, it's seen as an SCSI drive)

but when i tried to boot it i've found that kernel tries to mount root 
file system before is scans usb-bus for devices so it falls to panic :(

when i checked sources i've found that there is no way to delay this 
like it's doing when mounting floppy RAMDISK.

here is my system:

Linux version 2.4.21 (root@ejik) (gcc version 2.95.3 20010315 (release)) 
#4 Thu Jun 19 19:41:08 MSD 2003

Linux ejik 2.4.21 #4 Thu Jun 19 19:41:08 MSD 2003 i686 unknown

Gnu C                  2.95.3
Gnu make               3.79.1
binutils               2.11.90.0.19
util-linux             2.11f
mount                  2.11b
modutils               2.4.6
e2fsprogs              1.22
reiserfsprogs          3.x.0j
pcmcia-cs              3.1.26
PPP                    2.4.1
Linux C Library        2.2.3
Dynamic linker (ldd)   2.2.3
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0
Modules Loaded         nvidia vmnet vmmon 3c59x

bash-2.05# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 1
model name      : Intel(R) Pentium(R) 4 CPU 1.70GHz
stepping        : 2
cpu MHz         : 1716.958
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3420.97

bash-2.05# cat /proc/modules
nvidia               1540272  10 (autoclean)
vmnet                  21120   9
vmmon                  20000   0 (unused)
3c59x                  25120   1

bash-2.05# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
5000-500f : Intel Corp. 82801BA/BAM SMBus
c000-c07f : 3Com Corporation 3c905C-TX/TX-M [Tornado]
   c000-c07f : 02:03.0
d000-d01f : Intel Corp. 82801BA/BAM USB (Hub #1)
   d000-d01f : usb-uhci
d800-d81f : Intel Corp. 82801BA/BAM USB (Hub #2)
   d800-d81f : usb-uhci
dc00-dcff : Intel Corp. 82801BA/BAM AC'97 Audio
   dc00-dcff : Intel ICH2
e000-e03f : Intel Corp. 82801BA/BAM AC'97 Audio
   e000-e03f : Intel ICH2
f000-f00f : Intel Corp. 82801BA IDE U100
   f000-f007 : ide0
   f008-f00f : ide1

bash-2.05# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000d0000-000d07ff : Extension ROM
000f0000-000fffff : System ROM
00100000-0ffeffff : System RAM
   00100000-002df321 : Kernel code
   002df322-0039c1b7 : Kernel data
0fff0000-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fffffff : ACPI Tables
e0000000-e7ffffff : PCI Bus #01
   e0000000-e7ffffff : nVidia Corporation NV11 [GeForce2 MX]
     e0000000-e0bfffff : vesafb
e8000000-ebffffff : Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge
ec000000-edffffff : PCI Bus #01
   ec000000-ecffffff : nVidia Corporation NV11 [GeForce2 MX]
ef000000-ef00007f : 3Com Corporation 3c905C-TX/TX-M [Tornado]
fec00000-ffffffff : reserved

bash-2.05# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
   Vendor: IC25N020 Model: ATCS04-0         Rev: CA2O
   Type:   Direct-Access                    ANSI SCSI revision: 02


i've made a temporary solution- just copied a code that prints "insert 
floppy with ramdisk and press enter" a waits for keypress:

from function "change_floppy" in init/do_mounts.c:

	struct termios termios;
	char c;
	int fd;
	printk(KERN_NOTICE "VFS: Insert %s and press ENTER\n", buf);
	fd = open("/dev/console", O_RDWR, 0);
	if (fd >= 0) {
		sys_ioctl(fd, TCGETS, (long)&termios);
		termios.c_lflag &= ~ICANON;
		sys_ioctl(fd, TCSETSF, (long)&termios);
		read(fd, &c, 1);
		termios.c_lflag |= ICANON;
		sys_ioctl(fd, TCSETSF, (long)&termios);
		close(fd);
	}

to function "mount_block_root" in init/do_mounts.c before 
"get_fs_names(fs_names)" call.

it works fine: i wait for message that kernel found USB mass-storage 
device and then press enter, but i think it isn't a best solution.
first u always need press a key to boot
second - if pc has only usb-keyboard connected and no pc\2 or com- user 
couldn't mount root fs because it waits input in /dev/console

so i think it's better to add some kind of delay before mounting root, 
or, imho better way, - when completing init of usb bus, first scans it 
and connect all devices and only after all devices were connected 
returns to main kernel code.

regards,
	Ilia Petrov

Re: [linux-usb-devel] PROBLEM: when booting from USB-HDD device kernel 2.4.21 is trying to mount root file system too early before usb device is found on the usb-bus

[David Brownell]

Ilia A. Petrov wrote:
> When kernel is mounting root file system it is doing it too fast so 
> usb-support have not ime to scan bus for mass-storage devices and 
> connect them.
> ...
> or, imho better way, - when completing init of usb bus, first scans it 
> and connect all devices and only after all devices were connected 
> returns to main kernel code.

That might not entirely solve the problem, since the relevant device
could drop off the bus temporarily, but it seems like it'd be a step
forward.  How would you make root hub ("bus") initialization do that?

- Dave

Re: [linux-usb-devel] PROBLEM: when booting from USB-HDD device kernel 2.4.21 is trying to mount root file system too early before usb device is found on the usb-bus

[Ilia A. Petrov]

David Brownell wrote:
> Ilia A. Petrov wrote:
> 
>> When kernel is mounting root file system it is doing it too fast so 
>> usb-support have not ime to scan bus for mass-storage devices and 
>> connect them.
>> ...
>> or, imho better way, - when completing init of usb bus, first scans it 
>> and connect all devices and only after all devices were connected 
>> returns to main kernel code.
> 
> 
> That might not entirely solve the problem, since the relevant device
> could drop off the bus temporarily, but it seems like it'd be a step
> forward.  How would you make root hub ("bus") initialization do that?

i'm not familiar with linux usb implementation so may be it's wrong:
after sending global reset over the bus you can manually check (not 
trough the hub driver) root port connection status and call enumeration 
if needed.

another way- add an option to kernel for booting from usb mass-storage, 
where place an input-waiting code, because my current solution adds such 
delay for all boots (ide,scsi,usb)

Re: [linux-usb-devel] PROBLEM: when booting from USB-HDD device kernel 2.4.21 is trying to mount root file system too early before usb device is found on the usb-bus

[David Brownell]

Ilia A. Petrov wrote:
> David Brownell wrote:
>> Ilia A. Petrov wrote:
>>
>>> When kernel is mounting root file system it is doing it too fast so 
>>> usb-support have not ime to scan bus for mass-storage devices and 
>>> connect them.
>>> ...
>>> or, imho better way, - when completing init of usb bus, first scans 
>>> it and connect all devices and only after all devices were connected 
>>> returns to main kernel code.
>>
>>
>>
>> That might not entirely solve the problem, since the relevant device
>> could drop off the bus temporarily, but it seems like it'd be a step
>> forward.  How would you make root hub ("bus") initialization do that?
> 
> 
> i'm not familiar with linux usb implementation so may be it's wrong:
> after sending global reset over the bus you can manually check (not 
> trough the hub driver) root port connection status and call enumeration 
> if needed.

I had in mind an explanation that works with "patch -p1" ... :)

There's already a call to register a root hub.  It'd be dangerous
to have some other thread try to share responsibilities with khubd,
so that call would likely need to be modified.  (Although there's
been a bit of discussion about actually getting rid of that specific
single-point-of-failure, since not all hub operations need to be
serialized.)

- Dave