Re: Timing issues with USB attached storage

[John Klos <john%ziaspace.com@localhost>]

> > This shouldn=E2=80=99t be needed at all.  The autoconfiguration =
> > infrastructure is supposed to ensure that all outstanding device =
> > discovery tasks are complete before the root file system is mounted.
>
> Unfortunately the autoconfiguration infrastructure cannot discover
> hot-plug devices that take some time to become discoverable.

When a USB bus is reset (initialized, whatever) at boot time, we don't 
even have a 2 second delay like we have for SCSI busses:

[     1.362918] uhub0 at usb0: NetBSD (0x0000) DWC2 root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
[     1.372916] uhub0: 1 port with 1 removable, self powered
[     1.992968] uhub1 at uhub0 port 1: vendor 0424 (0x0424) product 9514 (0x9514), class 9/0, rev 2.00/2.00, addr 2
...
[     2.002970] uhub1: multiple transaction translators
[     2.002970] uhub1: 5 ports with 4 removable, self powered
[     2.833047] usmsc0 at uhub1 port 1
[     3.553139] umass0 at uhub1 port 5 configuration 1 interface 0

Between uhub1 becoming known by the kernel and the umass0 device being 
seen is less than 1.6 seconds.

Does USB have an immediate scan-and-report-back function? Can it report 
things that are there, but haven't finished initalizing? Should a reset at 
boot time have an additional delay?

In the meanwhile, "options ROOTWAIT" will do:

[     2.885714] SLEEP 5 seconds
[     3.553139] umass0 at uhub1 port 5 configuration 1 interface 0
[     3.563141] umass0: SupTronics (0x0820) X820 V3.0 (0x0003), rev 2.10/1.00, addr 4
[     3.563141] umass0: using SCSI over Bulk-Only
[     3.563141] scsibus0 at umass0: 2 targets, 1 lun per target
[     3.573143] sd0 at scsibus0 target 0 lun 0: <SATA SSD, , 0> disk fixed
[     3.573143] sd0: 476 GB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 1000215216 sectors
[     7.883716] SLEPT 5 seconds
[     7.883716] boot device: sd0
[     7.883716] root on sd0a dumps on sd0b

John