On Sat, 3 Mar 2018, tech-lists wrote:
On 03/03/2018 00:23, Dimitry Andric wrote:
Indeed. I have had the following for a few years now, due to USB drives
with ZFS pools:
--- /usr/src/etc/rc.d/zfs 2016-11-08 10:21:29.820131000 +0100
+++ /etc/rc.d/zfs 2016-11-08 12:49:52.971161000 +0100
@@ -25,6 +25,8 @@
zfs_start_main()
{
+ echo "Sleeping for 10 seconds to let USB devices settle..."
+ sleep 10
zfs mount -va
zfs share -a
if [ ! -r /etc/zfs/exports ]; then
For some reason, USB3 (xhci) controllers can take a very, very long time
to correctly attach mass storage devices: I usually see many timeouts
before they finally get detected. After that, the devices always work
just fine, though.
I have one that works for an old USB hard drive but never works for a not
so old USB flash drive and a new SSD in a USB dock (just to check the SSD
speed when handicapped by USB). Win7 has no problems with the xhci and
USB flash drive combination, and FreeBSD has no problems with the drive
on other systems.
Whether this is due to some sort of BIOS handover trouble, or due to
cheap and/or crappy USB-to-SATA bridges (even with brand WD and Seagate
disks!), I have no idea. I attempted to debug it at some point, but
a well-placed "sleep 10" was an acceptable workaround... :)
That fixed it, thank you again :D
That won't work for the boot drive.
When no boot drive is detected early enough, the kernel goes to the
mountroot prompt. That seems to hold a Giant lock which inhibits
further progress being made. Sometimes progress can be made by trying
to mount unmountable partitions on other drives, but this usually goes
too fast, especially if the USB drive often times out.
Bruce
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
