FreeBSD guests behaving as if their boot disks have disappeared (was: USB Disk Stalls on -current)

[Graham Perrin]

On 06/02/2022 18:20, Warner Losh wrote: … So there's some tools you can use. For usb, there's usbdump that can get you the USB transactions. I've not used it enough to give more details here. This will let you know what's going on, and when, on the USB endpoint. You can also enable the CAM_IOSCHED stuff. This will allow you to get latency measurements for 'requests in the sim' which basically will tell you what your latency spread is for the drives. This will tell you if things are getting caught up in the USB layer, or after CAM's da driver completes the I/O request (granted, that's almost certainly not happening, but it will help you figure out what's going on and put numbers to the oddities you are seeing). Also, make sure you have good cables. I've had lots of hicups over the years from dodgy USB cables. Also make sure you have good, high quality enclosures. Many from the USB2 time-period are sketchy at best and I went through several at one point trying to find a good one. I'd be tempted to get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear here, but you need a USB-3 controller to get USB-3 speeds which might not be compatible with the NUC's built-in stuff (though my NUC has one USB3 port, there's lots of different models). Usually, though, I see weirdness associated with dmesg messages from usb, cam, etc when the hardware is on the sketch end. Warner Thanks, I'll arm myself with those tools. In the meantime (maybe more for freebsd-virtualization@ than here): where a VirtualBox guest running FreeBSD behaves as if its boot disk has disappeared, and no exhaustion at the underlying storage level, is there a sysctl in the guest that might help to avoid the situation? Underlying storage: OpenZFS pool on an old but reasonably good mobile hard disk drive (the one that features in <https://github.com/openzfs/zfs/issues/13038> with a hardware probe near the head of the opening post). Whilst I have not yet found time to pay all due attention to VirtualBox logs, I do have a strong sense that these stalls of guests are more likely to bug FreeBSD guests than, for example, my Windows 10 guest with its .vhd in the same underlying pool.