Bug 225794 - VM images for 12.0-CURRENT have problem with USB 3.0 ports
Summary: VM images for 12.0-CURRENT have problem with USB 3.0 ports
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Andriy Gapon
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-02-09 19:45 UTC by David.Boyd49
Modified: 2019-01-11 11:44 UTC (History)
6 users (show)

See Also:


Attachments
output of camcontrol devlist before USB drive is inserted (13.48 KB, image/png)
2018-02-09 19:45 UTC, David.Boyd49
no flags Details
output of camcontrol devlist after USB drive is inserted (15.81 KB, image/png)
2018-02-09 19:46 UTC, David.Boyd49
no flags Details
Output of time gpart show da0 (15.07 KB, image/png)
2018-02-09 19:47 UTC, David.Boyd49
no flags Details
Output of camcontrol devlist after failure (15.68 KB, image/png)
2018-02-09 19:48 UTC, David.Boyd49
no flags Details
Output of gpart show da0 after camcontrol debug -c -p -I -P 3:0:0 (3.23 KB, text/plain)
2018-02-20 14:49 UTC, David.Boyd49
no flags Details
Output of sg3_utils commands (1.17 KB, text/plain)
2018-02-21 03:55 UTC, David.Boyd49
no flags Details
Output of sg3_utils commands on CentOS EL 7.1708 host (4.42 KB, text/plain)
2018-02-21 03:57 UTC, David.Boyd49
no flags Details
Verify camcontrol devlist output for pass3 device (44.65 KB, image/png)
2018-02-21 15:13 UTC, David.Boyd49
no flags Details
Output of camcontrol modepage commands (58.33 KB, image/png)
2018-02-22 19:59 UTC, David.Boyd49
no flags Details
Output of camcontrol modepage commands on system with NEC chipset (61.04 KB, image/png)
2018-02-22 21:57 UTC, David.Boyd49
no flags Details
USB attach on CentOS guest (2.62 KB, image/png)
2018-02-27 18:23 UTC, David.Boyd49
no flags Details
USB attach on CentOS guest (with data) (1.21 KB, text/plain)
2018-02-27 18:42 UTC, David.Boyd49
no flags Details
Output: USB attach, gpart show after kern.cam.da.0.minimum_cmd_size=6 (15.56 KB, image/png)
2018-03-01 23:47 UTC, David.Boyd49
no flags Details
Use MODE SENSE (6) for USB (2.41 KB, patch)
2018-03-02 09:43 UTC, Andriy Gapon
no flags Details | Diff
Log of errors generated by gpart show da0 after your patch was applied (3.46 KB, text/plain)
2018-03-03 16:21 UTC, David.Boyd49
no flags Details
Console input/output after your patch was applied (3.23 KB, text/plain)
2018-03-03 16:23 UTC, David.Boyd49
no flags Details
Correct console output after your patch was applied (11.06 KB, image/png)
2018-03-03 16:25 UTC, David.Boyd49
no flags Details
do not try to use any 16-byte commands (475 bytes, patch)
2018-03-05 09:07 UTC, Andriy Gapon
no flags Details | Diff
Output after additional patch was applied (3.25 KB, text/plain)
2018-03-06 22:18 UTC, David.Boyd49
no flags Details
camcontrol debug after local patch (2.03 KB, text/plain)
2018-03-15 19:34 UTC, David.Boyd49
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David.Boyd49 2018-02-09 19:45:13 UTC
Created attachment 190466 [details]
output of camcontrol devlist before USB drive is inserted

Beginning with 12.0-CURRENT VM image:

        FreeBSD-12.0-CURRENT-amd64-20180118-r328126.vmdk.xz

and continuing with 12.0-CURRENT VM images:

        FreeBSD-12.0-CURRENT-amd64-20180125-r328383.vmdk.xz
        FreeBSD-12.0-CURRENT-amd64-20180131-r328637.vmdk.xz
        FreeBSD-12.0-CURRENT-amd64-20180208-r329009.vmdk.xz

when a USB flash drive inserted into a USB 3.0 port is accessed (in this case via gpart show), the console hangs for 10-12 minutes then emits the
error messages seen in the attachment.

The UFS filesystem on the USB flash drive cannot be mounted.

If the USB flash drive is connected via the attached USB 2.0
controller, everything is good.

This problem is not manifested in any 10.4-STABLE or 11.1-STABLE VM
images.

The host system is CentOS EL7 7.1708.

VirtualBox version is 5.2.6.

The USB 3.0 controller uses a VIA chipset.

System is for test purposes only, so it is easy to try anything that
might help resolve this problem.


Thanks.
Comment 1 David.Boyd49 2018-02-09 19:46:30 UTC
Created attachment 190467 [details]
output of camcontrol devlist after USB drive is inserted
Comment 2 David.Boyd49 2018-02-09 19:47:22 UTC
Created attachment 190468 [details]
Output of time gpart show da0
Comment 3 David.Boyd49 2018-02-09 19:48:04 UTC
Created attachment 190469 [details]
Output of camcontrol devlist after failure
Comment 4 Jeremy Chadwick 2018-02-17 02:02:02 UTC
freebsd-stable mailing list also has this, indicating an MFC has now caused this problem in -STABLE: https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088393.html

"VM image for 11.1-STABLE began exhibiting same dislike for USB 3.0
ports as problem reported in PR 225794 for 12.0-CURRENT.

Prior to FreeBSD-11.1-STABLE-amd64-20180215-r329320.vmdk.xz no such
problem was observed."

CAM status 0x44 refers to done_ccb->ccb_h.status per sys/cam/scsi/scsi_da.c, function dadone().  done_ccb is declared as "union ccb *done_ccb".  Field ccb_h is likely declared as "struct ccb_hdr ccb_h" (this is commonplace).  Field status is therefore "u_int32_t status" per sys/cam/scsi/cam_ccb.h, which should correlate with the cam_status enum per sys/cam/scsi/cam.h.  I had to write a small program to dump all the enum names and values because the ordering and mid-struct value assignments result in hard-to-read code.  Text strings come directly from cam_status_table[] per sys/cam/cam.c, except for QFRZN, which comes from the .h file itself.

0x04 = CAM_REQ_CMP_ERR = CCB request completed with an error
0x40 = CAM_DEV_QFRZN   = The DEV queue is frozen w/this err

Suggest involving avg@, hselasky@, and emaste@  You will probably be asked to try older commits to try and narrow down what exact commit broke things.

stable/11 commits: http://www.freshbsd.org/search?branch=RELENG_11&project=freebsd
HEAD commits: http://www.freshbsd.org/?branch=HEAD&project=freebsd
Comment 5 David.Boyd49 2018-02-17 23:39:42 UTC
Based on Jeremy's assessment, I looked for revisions from 4 weeks ago that were MFC'd this week.  I came up with r327996 which was MFC'd to 11.1-STABLE as r329316.

I built 11.1-STABLE as of r329310 and the problem appears to be resolved.

All of this is without any understanding of the intent of the original (r327996) fix.
Comment 6 Andriy Gapon freebsd_committer 2018-02-19 18:13:29 UTC
Could you please run this command after attaching the device and before running the gpart command?
# camcontrol debug -c -p -I -P 3:0:0
Where 3:0:0 is taken from bus, target, lun reported by camcontrol devlist.

I hope that this will enable debugging messages that will tell us more about what is going on.
Comment 7 David.Boyd49 2018-02-20 14:49:28 UTC
Created attachment 190827 [details]
Output of gpart show da0 after camcontrol debug -c -p -I -P 3:0:0

Output of gpart show da0 after camcontrol devlist debug -c -p -I -P 3:0:0

I had to extract this text from dmesg -a due to size exceeding VirtualBox screenshot limit.
Comment 8 Andriy Gapon freebsd_committer 2018-02-20 18:34:24 UTC
(In reply to David.Boyd49 from comment #7)
This is valuable information, thank you!

Could you please install sg3_utils package?
And then run the following commands (after attaching the USB device):

sg_modes -p 63 -vvvvv /dev/pass2
sg_modes -p 63 -m 192 -vvvvv /dev/pass2
sg_modes -p 63 -6 -vvvvv /dev/pass2

It might be helpful to run the same commands (adjusted for the device name) on the host to see if VirtualBox causes any trouble (unlikely).
Comment 9 Andriy Gapon freebsd_committer 2018-02-20 18:37:32 UTC
And for completeness:
sg_modes -a -vvvvv /dev/pass2
Comment 10 David.Boyd49 2018-02-21 03:55:11 UTC
Created attachment 190845 [details]
Output of sg3_utils commands

I ran the commands requested. The output looks truncated by error conditions.  Maybe that is significant in itself.
Comment 11 David.Boyd49 2018-02-21 03:57:02 UTC
Created attachment 190847 [details]
Output of sg3_utils commands on CentOS EL 7.1708 host

The VirtualBox host is CentOS EL 7.1708.  I ran the sg commands there as well.
Comment 12 Andriy Gapon freebsd_committer 2018-02-21 06:45:45 UTC
(In reply to David.Boyd49 from comment #10)
Are you sure that you used the correct pass device?
You used pass3 while previously the USB device had pass2.
Just double-checking...  It's very strange that even inquiry command failed and mode sense command has not been even tried.
Comment 13 Andriy Gapon freebsd_committer 2018-02-21 06:49:47 UTC
(In reply to David.Boyd49 from comment #11)
The host results look good.
Comment 14 David.Boyd49 2018-02-21 15:13:27 UTC
Created attachment 190860 [details]
Verify camcontrol devlist output for pass3 device

Andriy,

I verified pass3 as the USB device (see screenshot).

I followed up on your suggestion that this might be VirtualBox.  I tested with CentOS and openSUSE guest.  Neither had any problem mounting and accessing the USB flash drive but both had similar errors trying to run sg_modes commands.

A comment made in January (and overlooked since then) indicated that this occurred in a FreeBSD guest running FreeBSD-12.0-CURRENT-amd64-20180118-r328126.vmdk.xz where the host was using a Via chipset (VL805 to be exact).

I will test this as soon as possible on a host that has a NEC chipset (D72020x) to see if that actually makes any difference.

I'll let you know.
Comment 15 Andriy Gapon freebsd_committer 2018-02-21 19:08:21 UTC
(In reply to David.Boyd49 from comment #14)

Perhaps the device genuinely does not support INQUIRY command...

Maybe camcontrol would be a better option in this case.
Could you please try this?
# camcontrol modepage /dev/pass3 -m 63
# camcontrol modepage /dev/pass3 -l
Comment 16 David.Boyd49 2018-02-21 21:23:40 UTC
Andriy,

I will run the camcontrol modepage commands as soon as possible.

In order to "get something done", I carried the USB flash drive to a production VirtualBox server that has an NEC D720201 chipset for USB 3.0 ports.

There I ran the following command "sg_modes -a -vvvvv /dev/passX" against the latest FreeBSD 12.0-CURRENT image.

I did not have any issues with the command output being truncated due to errors.

I also ran the command "sg_modes -a -vvvvv /dev/sdX" on several Linux-based VM's without incident. These were LinuxMint 18.3 and CentOS EL 6.9 systems.

The test machine (where the problem was originally observed) has a VIA VL805 chipset.  On that machine I ran the command "sg_modes -a -vvvvv /dev/sdX" on several Linux-based VM's.  Each of them displayed error(s) (similar to 12.0-CURRENT) trying to run the command.  These were LinuxMint 18.3, openSUSE Leap 42.3, and CentOS EL 7.1708 systems.
Comment 17 David.Boyd49 2018-02-22 19:59:34 UTC
Created attachment 190901 [details]
Output of camcontrol modepage commands

Andriy,

I ran the camcontrol modepage commands as you requested.  I didn't see any significant output.

I will run the same commands on the VirtualBox guest where the NEC chipset is used to see if there is any difference.
Comment 18 David.Boyd49 2018-02-22 21:57:59 UTC
Created attachment 190908 [details]
Output of camcontrol modepage commands on system with NEC chipset

Same USB drive

Same FreeBSD 12.0-CURRENT version

Different USB chipset (NEC D720201)
Comment 19 Andriy Gapon freebsd_committer 2018-02-26 07:02:22 UTC
(In reply to David.Boyd49 from comment #18)

So, it seems that MODE SENSE (10) command completely wedges the device (or maybe the controller) and it stops accepting any subsequent commands.
I wonder if it would work better with MODE SENSE (6) or if any form of MODE SENSE is broken.
Are you set up for compiling and testing kernel code patches?
Or would you prefer that I send you pre-built kernels?

But before that, could you please obtain a log from a working Linux guest with the problematic controller?
I am not sure how to get the log that I want as I am not very experienced with Linux, but it should look something like this:
[ 3902.887849] usb 4-6: new SuperSpeed USB device number 6 using xhci_hcd
[ 3902.904584] usb 4-6: New USB device found, idVendor=152d, idProduct=0567
[ 3902.904586] usb 4-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3902.904587] usb 4-6: Product: JMS567
[ 3902.904588] usb 4-6: Manufacturer: JMicron
[ 3902.904588] usb 4-6: SerialNumber: DB123456789B1D
[ 3902.906862] scsi host13: uas
[ 3902.907595] scsi 13:0:0:0: Direct-Access     Samsung  SSD 850 PRO 256G 0117 PQ: 0 ANSI: 6
[ 3902.908426] sd 13:0:0:0: Attached scsi generic sg4 type 0
[ 3902.908574] sd 13:0:0:0: [sde] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[ 3902.908575] sd 13:0:0:0: [sde] 4096-byte physical blocks
[ 3902.909089] sd 13:0:0:0: [sde] Write Protect is off
[ 3902.909091] sd 13:0:0:0: [sde] Mode Sense: 53 00 10 08
[ 3902.909368] sd 13:0:0:0: [sde] Disabling FUA
[ 3902.909370] sd 13:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3902.910769]  sde: sde1
[ 3902.912446] sd 13:0:0:0: [sde] Attached SCSI disk

I guess that this requires setting kernel log level to debug before attaching the device and then extracting the logs from the appropriate place (dmesg?, systemd journal?).
Comment 20 David.Boyd49 2018-02-26 16:06:01 UTC
Andriy,

I can build kernels with patches.

I will try using usbmon to get the information you want.

I may not be able to do this until tomorrow.
Comment 21 David.Boyd49 2018-02-27 18:23:26 UTC
Created attachment 191060 [details]
USB attach on CentOS guest

dmesg output showing USB attach on CentOS EL 7.1708 VirtualBox guest
Comment 22 David.Boyd49 2018-02-27 18:42:10 UTC
Created attachment 191063 [details]
USB attach on CentOS guest (with data)

USB attach on CentOS EL 7.1708 VirtualBox guest (with actual data)
Comment 23 Andriy Gapon freebsd_committer 2018-02-28 17:35:12 UTC
(In reply to David.Boyd49 from comment #22)

Thank you!

I am working on a patch.
Meanwhile, could you please test setting
kenv kern.cam.da.0.minimum_cmd_size=6
on the command line before plugging in the USB device for the first time?
Alternatively, you can add kern.cam.da.0.minimum_cmd_size=6 to /boot/loader.conf and reboot.
This assumes that the disk attaches as "da0" as it did before.
Comment 24 David.Boyd49 2018-03-01 23:47:13 UTC
Created attachment 191120 [details]
Output: USB attach, gpart show after kern.cam.da.0.minimum_cmd_size=6

Andriy,

I haven't had much/any luck getting the USB flash drive to attach and be available after kenv kern.cam.da.0.minimum_cmd_size=6.

This was again VM image FreeBSD-12.0-CURRENT-amd64-20180226-r330034.vmdk.xz

I have tommorrow free, so just let me know what you want me to do.

Thanks.
Comment 25 Andriy Gapon freebsd_committer 2018-03-02 09:43:36 UTC
Created attachment 191128 [details]
Use MODE SENSE (6) for USB

Could you please test this patch?
Also, while testing could you please execute the camcontrol debug before the gpart command?

I've just now realized another strange thing.  Apparently, MODE SENSE works fine the first time when the disk is probed, but it causes the trouble the second time when the disk gets opened.
Comment 26 David.Boyd49 2018-03-03 16:21:27 UTC
Created attachment 191171 [details]
Log of errors generated by gpart show da0 after your patch was applied

Log of errors generated by gpart show da0 after your patch was applied
Comment 27 David.Boyd49 2018-03-03 16:23:16 UTC
Created attachment 191172 [details]
Console input/output after your patch was applied

Console output after your patch was applied  ...  just to verify that I did things correctly.
Comment 28 David.Boyd49 2018-03-03 16:25:44 UTC
Created attachment 191173 [details]
Correct console output after your patch was applied

Please ignore the duplicate message log output ... this is the actual console output.
Comment 29 Andriy Gapon freebsd_committer 2018-03-05 09:07:04 UTC
Created attachment 191215 [details]
do not try to use any 16-byte commands

(In reply to David.Boyd49 from comment #26)

Disappointing.
Okay, let's try to attack the issue from a different angle.
Comment 30 David.Boyd49 2018-03-06 22:18:42 UTC
Created attachment 191268 [details]
Output after additional patch was applied

Andriy,

Here is the debug output after the second patch was applied.

I don't know what I'm looking at, but I didn't see much difference.

I'm ready to do whatever you need.
Comment 31 Andriy Gapon freebsd_committer 2018-03-07 07:02:28 UTC
(In reply to David.Boyd49 from comment #30)
So, that was not it.

Another thing to try. Could you please try to comment out the call to dareprobe() in daopen() ?
Comment 32 David.Boyd49 2018-03-08 16:14:12 UTC
Andriy,

No joy.  After commenting the dareprobe() (assuming that I did it properly), when I enter gpart show da0 the system hangs forever with no debug output.

Please let me know how you want me to proceed.
Comment 33 Andriy Gapon freebsd_committer 2018-03-12 08:35:49 UTC
(In reply to David.Boyd49 from comment #32)
Bummer.  I am really out of ideas now.  I think that we have tried every quirk that Linux may use and nothing works...
One idea is trying the previous patches in combinations...

I would like to see SCSI debug messages that are produced during the original probing.  The problem with getting them is that the only way to get them is to enable debug messages for all devices.  And that means noise from ada0 and ada1.

Maybe you could the following:
1. stop syslogd, so that the kernel log is not written to disk causing the positive feedback loop
1a. alternatively, boot to single user mode and do things there
2. camcontrol debug -c -p -I -P all
3. plug the device
4. wait until CAM messages settle down
5. camcontrol debug off
6. check the captured messages in dmesg output
Comment 34 Andriy Gapon freebsd_committer 2018-03-12 08:49:55 UTC
(In reply to David.Boyd49 from comment #32)
Oh, before you consider comment #33... have you also commented out cam_periph_sleep("dareprobe") ? If not, then that would explain the hang (endless wait for something that's not happening).
Comment 35 David.Boyd49 2018-03-12 16:40:28 UTC
Andriy,

I did not comment the cam_periph_sleep("dareprobe") statement.  I will do that as soon as possible.

Which, if any, of the preceding patches would you like me to include in the build?
Comment 36 Andriy Gapon freebsd_committer 2018-03-14 17:58:32 UTC
(In reply to David.Boyd49 from comment #35)
Let's try first without any extra patches.
Comment 37 David.Boyd49 2018-03-15 19:34:15 UTC
Created attachment 191533 [details]
camcontrol debug after local patch

Andriy,

This is the output after the local patch was applied to scsi_da.c.

I issued camcontrol debug -c -p -I -P all in single-user mode.


Possibly of interest:  when I rebooted the system into multi-user mode, the USB flash drive was detected and usable (fsck, gpart show, mount).

I don't know what that means, but I thought I would let you know.
Comment 38 Andriy Gapon freebsd_committer 2018-03-27 11:30:50 UTC
(In reply to David.Boyd49 from comment #37)

That's interesting and puzzling.
When you rebooted to multi-user, did you still have the patched kernel?
If so, then maybe when you booted the hardware (or VirtualBox) was already wedged?
Because single-user vs multi-user mode should not have any effect on CAM and USB.

So, I'd like to double-check with you if the patch helps.
And, if yes, could you please repeat the single user mode test again?
Comment 39 David.Boyd49 2018-03-27 21:18:44 UTC
Andriy,

Yes, the patch disabling dareprobe(s) was/is applied to the kernel in both single-user and multi-user mode.

In single-user mode the error condition in the dmesg output only appears if the device is attached after the "camcontrol debug -c -p -I -P all" statement is issued.

Just booting into single-user mode, but without issuing the debug command, allows access to the USB flash drive (gpart show da0, mount/unmount, fsck, etc.).

As stated, with the patch disabling dareprobe(s), booting into multi-user mode allows access as above.
Comment 40 Warner Losh freebsd_committer 2018-03-27 21:34:16 UTC
What revision of FreeBSD were the latest tests done by?

I've fixed some locking bugs ending with r331435... dareprobe suggests this may help, but I'm unsure.
Comment 41 Andriy Gapon freebsd_committer 2018-03-28 08:37:02 UTC
(In reply to Warner Losh from comment #40)
Warner, it is unlikely that it had to do with locking, but not impossible, of course.  If you look at attachment 191533 [details] you can see that INQUIRY ccb was failing for some unknown reason, but that happened only when CAM debugging (via camcontrol debug ... all) was enabled. Quite strange.
Comment 42 Andriy Gapon freebsd_committer 2018-03-28 08:41:34 UTC
(In reply to David.Boyd49 from comment #39)

David, thank you for the clarification.  I am quite at loss about why dareprobe plus WP-detection would cause the problems that you experienced.  I hoped to get to the bottom of the issue, but the puzzling problem with CAM debug makes that very hard.

I guess I'll just work on a patch that would add an ability to disable WP-detection.  And then you'll be able to just set a tunable or sysctl to get that.
I do not have any better idea.  Not for working around the problem, not for  debugging it.
Comment 43 David.Boyd49 2018-04-06 15:58:31 UTC
Andriy,

More and more I am becoming convinced that this is a problem in VirtualBox.

I think that your patch (r327996) uncovered this bug in the way that vbox maps real USB controller(s) to virtual USB controller(s).

In an attempt to prove this point, I ordered several Renesas (NEC) USB 3.0 controllers (uPD720201 chipset) to replace the VIA USB 3.0 controllers (VL805 chipset).

Some of the motherboard being used have Renesas (NEC) USB 3.0 controller(s) built-in.

All other motherboards do not have built-in USB 3.0 controller(s) and use an add-on PCI-e card to add 2, 4, 5 or 7 ports.

I am using "sg_modes -a -vvvvv <device>" as a control.

In all cases where FreeBSD (and various Linux flavors) were running on the "bare metal", no problems with either controller type were noticed.

When FreeBSD (and the Linux systems) is running as a VirtualBox guest, no issues are seen when the Renesas USB 3.0 controller is used

****  Continued on next comment.  ****
Comment 44 Hans Petter Selasky freebsd_committer 2018-04-06 16:18:04 UTC
Hi,

Try also to exclude the timing of the SCSI commands as a source of USB errors. When you are using bare metal, the commands execute more quickly. Sometimes, it might happen that the USB firmware in the peer has blind eye, which cause it to hang or lose the transferred command.


The following sysctl might be useful testing this.
hw.usb.umass.throttle: 0

Further there is:
/usr/src/tools/tools/usbtest/

Which can be used to test mass storage device to quickly reveal known issues.

--HPS
Comment 45 David.Boyd49 2018-04-06 16:43:29 UTC
****  Continued from previous comment.  ****

When the VIA USB 3.0 controllers are in play, the FreeBSD (and Linux) guests show the problems that we have been chasing.  But, again, only when running as VirtualBox guest(s).

VirtualBox presents the both the Renesas and VIA USB 3.0 controller(s) as an Intel 7 Series/C210 xHCI USB Controller.  Based on our testing and observation this presentation is not consistent across the Renesas and VIA types.

I have no problem with being told that I am wrong.

If you can agree with my conclusions, I want to open a Bug Report with VirtualBox.

If there is anyone in the FreeBSD community who has a connection with the folks at VirtualBox, I would be most appreciative for any assistance that they may offer.

Andriy, it might be useful to include a few words describing what you were addressing with the patch that uncovered this problem.

If you agree with my conclusions, please feel free to close this PR.

David.
Comment 46 Andriy Gapon freebsd_committer 2018-12-17 16:01:04 UTC
(In reply to David.Boyd49 from comment #45)

David,
sorry that this fell of my plate, so to speak.

Thank you for all the testing and analysis.
It indeed appears to be a problem with VirtualBox.  It would be a good idea to file a bug for it.  The essence of scsi_da change in r327996 is that the driver now issues MODE SENSE command for the all pages page (0x3f).

I am adding a tunable that disables the new functionality, so that the problem can be worked around.
Comment 47 commit-hook freebsd_committer 2018-12-17 16:02:02 UTC
A commit references this bug:

Author: avg
Date: Mon Dec 17 16:01:38 UTC 2018
New revision: 342169
URL: https://svnweb.freebsd.org/changeset/base/342169

Log:
  add a knob that disables detection of write protected disks

  It has been reported that on some systems (with real hardware passed
  through to a virtual machine) the WP detection causes USB disk probing
  failures.

  While here, also fix the selection of the next state in the case
  of malloc failure in DA_STATE_PROBE_WP.  It was DA_STATE_PROBE_RC
  unconditionally even when it should have been DA_STATE_PROBE_RC16.

  PR:		225794
  Reported by:	David Boyd <David.Boyd49@twc.com>
  MFC after:	3 weeks
  Differential Revision: https://reviews.freebsd.org/D18496

Changes:
  head/sys/cam/scsi/scsi_da.c
Comment 48 commit-hook freebsd_committer 2019-01-11 11:42:41 UTC
A commit references this bug:

Author: avg
Date: Fri Jan 11 11:42:26 UTC 2019
New revision: 342938
URL: https://svnweb.freebsd.org/changeset/base/342938

Log:
  MFC r342169: add a knob that disables detection of write protected disks

  PR:		225794

Changes:
_U  stable/12/
  stable/12/sys/cam/scsi/scsi_da.c
Comment 49 commit-hook freebsd_committer 2019-01-11 11:43:45 UTC
A commit references this bug:

Author: avg
Date: Fri Jan 11 11:43:37 UTC 2019
New revision: 342939
URL: https://svnweb.freebsd.org/changeset/base/342939

Log:
  MFC r342169: add a knob that disables detection of write protected disks

  PR:		225794

Changes:
_U  stable/11/
  stable/11/sys/cam/scsi/scsi_da.c