Hans Petter Selasky wrote:
On 2019-12-20 13:54, Denver Hull wrote:
Hans Petter Selasky wrote:
On 2019-12-19 01:11, Denver Hull wrote:
Hello,
I have several different microcontroller boards that are supposed
to appear as storage devices when plugged in. They work fine on
Linux systems, but on FreeBSD 11.3 and 12.1 they don't show up at
all. Here's what dmesg shows for one of them:
ugen1.3: <Adafruit Industries LLC PyPortal> at usbus1
umodem0 on uhub1
umodem0: <CircuitPython CDC control> on usbus1
umodem0: data interface 1, has no CM over data, has no break
umass3 on uhub1
umass3: <CircuitPython Mass Storage> on usbus1
umass3: SCSI over Bulk-Only; quirks = 0x0000
umass3:5:3: Attached to scbus5
uaudio0 on uhub1
uaudio0: <CircuitPython Audio> on usbus1
uaudio0: No playback.
uaudio0: No recording.
uaudio0: MIDI sequencer.
uaudio0: No HID volume keys found.
ums2 on uhub1
ums2: <CircuitPython HID> on usbus1
ums2: 16 buttons and [XYZ] coordinates ID=2
(da3:umass-sim3:3:0:0): got CAM status 0x44
(da3:umass-sim3:3:0:0): fatal error, failed to attach to device
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
g_access(944): provider da3 has error 6 set
There's a definite delay after the last ums message. I used
camcontrol debug in single user mode on a bare 12.1 system to get a
little more information about what was happening. It looks like the
initial Inquiry and Test Unit Ready commands succeed, but the next
Mode Sense command times out, as well as all subsequent commands.
There are several seconds of inactivity between retries, and
there's no sense data, so I'm assuming that indicates timeout.
At this point I'm not sure how best to proceed to get these devices
to work, so any help will be appreciated.
Did you try setting one or more quirks for these devices using
usbconfig?
UQ_MSC_NO_TEST_UNIT_READY
UQ_MSC_NO_RS_CLEAR_UA
UQ_MSC_NO_START_STOP
UQ_MSC_NO_GETMAXLUN
UQ_MSC_NO_INQUIRY
UQ_MSC_NO_INQUIRY_EVPD
UQ_MSC_NO_PREVENT_ALLOW
UQ_MSC_NO_SYNC_CACHE
UQ_MSC_SHUTTLE_INIT
UQ_MSC_ALT_IFACE_1
UQ_MSC_FLOPPY_SPEED
UQ_MSC_IGNORE_RESIDUE
UQ_MSC_WRONG_CSWSIG
UQ_MSC_RBC_PAD_TO_12
UQ_MSC_READ_CAP_OFFBY1
UQ_MSC_FORCE_SHORT_INQ
If you run "usbdump -i usbusX -f Y -s 65536 -vvv" you might see the
last failing SCSI command. X.Y are numbers after ugen for your device.
Likely your device has a software bug in its USB/SCSI
implementation, which is quite common unfortunately.
--HPS
After I sent the previous message I did try
UQ_MSC_NO_TEST_UNIT_READY. Although the system reports "quirks =
0001", the initial TUR is still being issued during the probe
sequence. I tried the usbdump command you suggested, and I can
clearly see where the timeouts are, and frames that begin with "USBC"
seem to contain a SCSI CDB. But there's a lot of other stuff in
between that I haven't been able to figure out, so I've attached a
sample. Hopefully it will help.
Hi,
All the USBC's are raw SCSI commands, which use the following layout:
/* Command Block Wrapper */
typedef struct {
uDWord dCBWSignature;
#define CBWSIGNATURE 0x43425355
uDWord dCBWTag;
uDWord dCBWDataTransferLength;
uByte bCBWFlags;
#define CBWFLAGS_OUT 0x00
#define CBWFLAGS_IN 0x80
uByte bCBWLUN;
uByte bCDBLength;
#define CBWCDBLENGTH 16
uByte CBWCDB[CBWCDBLENGTH];
} __packed umass_bbb_cbw_t;
We had a SoC to add support for the usbdump format to wireshark:
https://wiki.freebsd.org/SummerOfCode2017/usbdump-wireshark
You might find that useful.
My first suspicion is that your device is not fully USB class
compliant, and that's why it is STALLING and failing to recover.
--HPS
I checked on a Linux system, and the negotiation follows a slightly
different pattern, but as far as I can see, the biggest difference is
that Linux uses 6 byte Mode Sense commands instead of 10 byte. I wonder
if that's all that's making the device choke? How hard would it be to
change things to use 0x1a instead of 0x5a temporarily? Alternatively, I
could see if I can figure out how to issue arbitrary SCSI commands on
Linux. I used to have something for that purpose that worked on a
variety of platforms, but it's been ages since I needed it. In any
case, I'll attach the Linux wireshark trace. The negotiation seems to
begin at frame 2331.
Thanks,
Denver
_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
