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

From: Graham Perrin <grahamperrin_at_gmail.com>
Date: Tue, 08 Feb 2022 06:38:51 UTC 
<html data-lt-installed="true">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body spellcheck="false" data-gramm="false">
    <p>On 06/02/2022 18:20, Warner Losh wrote:<br>
      <br>
    </p>
    <blockquote type="cite"
cite="mid:CANCZdfqG-+9dfFz-+eezZaqbPQN5-mQpw+214CkiKC+_kmW2ig@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">… So there's some tools you can use. For usb,
        there's usbdump that can
        <div class="gmail_quote">
          <div>get you the USB transactions. I've not used it enough to
            give more details</div>
          <div>here. This will let you know what's going on, and when,
            on the USB endpoint.</div>
          <div><br>
          </div>
          <div>You can also enable the CAM_IOSCHED stuff. This will
            allow you to get latency</div>
          <div>measurements for 'requests in the sim' which basically
            will tell you what your</div>
          <div>latency spread is for the drives. This will tell you if
            things are getting caught</div>
          <div>up in the USB layer, or after CAM's da driver completes
            the I/O request</div>
          <div>(granted, that's almost certainly not happening, but it
            will help you figure out</div>
          <div>what's going on and put numbers to the oddities you are
            seeing).</div>
          <div><br>
          </div>
          <div>Also, make sure you have good cables. I've had lots of
            hicups over the</div>
          <div>years from dodgy USB cables. Also make sure you have
            good, high quality</div>
          <div>enclosures. Many from the USB2 time-period are sketchy at
            best and I</div>
          <div>went through several at one point trying to find a good
            one. I'd be tempted to</div>
          <div>get USB 3 enclosures. I've had better luck with USB3 gear
            than USB2 gear</div>
          <div>here, but you need a USB-3 controller to get USB-3 speeds
            which might not</div>
          <div>be compatible with the NUC's built-in stuff (though my
            NUC has one USB3</div>
          <div>port, there's lots of different models).</div>
          <div><br>
          </div>
          <div>Usually, though, I see weirdness associated with dmesg
            messages from</div>
          <div>usb, cam, etc when the hardware is on the sketch end.</div>
          <div><br>
          </div>
          <div>Warner</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Thanks, I'll arm myself with those tools. <br>
    </p>
    <p>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 <i>no</i> exhaustion at the
      underlying storage level, is there a sysctl in the guest that
      might help to avoid the situation? <br>
    </p>
    <p><b>Underlying storage</b>: OpenZFS pool on an old but reasonably
      good mobile hard disk drive (the one that features in
      <a class="moz-txt-link-rfc2396E" href="https://github.com/openzfs/zfs/issues/13038">&lt;https://github.com/openzfs/zfs/issues/13038&gt;</a> with a
      hardware probe near the head of the opening post). <br>
    </p>
    <p>Whilst I have <i>not</i> yet found time to pay all due attention
      to VirtualBox logs, I <i>do</i> have a strong sense that these
      stalls of guests are <b>more likely to bug FreeBSD guests than,
        for example, my Windows 10 guest</b> with its .vhd in the same
      underlying pool. <br>
    </p>
  </body>
</html>