Re: Mass Storage Gadget Device Falls from SuperSpeed to High Speed
Hi, Rob Weber writes: > Hi linux-usb, > > My team and I are currently grappling with an issue where our custom > hardware cannot maintain a SuperSpeed connection to a host computer > while in device mode. After some time (as quickly as 5 seconds, or as > long as 5 minutes), the USB connection will often drop from a SuperSpeed > connection to a high speed connection. I would appreciate some help our > pointers in how to dig deeper into this issue. This bug is starting to > stretch my knowledge of USB, so any guidance is really appreciated. I've > gathered a lot of debug information and logs which I describe in more > detail below. > > Our custom design is based on the Intel CherryTrail z8550 processor. This > SoC uses the DWC3 UDC controller. The USB port in question on our board please collect dwc3 tracepoints. The procedure is described here: https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs > is a USB Type-C port that supports both UFP and DFP data roles, up to > 5V/1.5A as a power source, and up to 30W as a power sink during USB-PD > negotiations. We use a Cypress CCG3 for the USB-PD controller which is > configured and controlled via I2C from an STM32 microcontroller in our > design. We also use a SuperSpeed redriver and mux to re-condition the > signals that come in and out of the board and to multiplex the two SS > channels of the type-C connector into one port of the SoC based on the > cable orientation. When connecting our device to a host with a USB type > A cable, we configure our internal battery charger to draw 100mA of power > from the host. If PD negotiations occur, we will configure the charger to > pull the current that was requested/accepted during PD negotiations. > > Our device is running Linux kernel version 4.9.115 with a few backported Can you run v5.0 to see if the problem is reproduced there? > patches to support the intel-xhci-usb-sw role switch driver that was > introduced in version 4.17. We ported part of the following patchset for > this: https://lkml.org/lkml/2018/3/20/387. I am working on building our > OS with the 4.19.18 kernel to understand if this issue is reproducible > on more recent versions of the kernel. Thank you, that will help a lot :-) > We are able to reproduce this with the default configuration of the > legacy g_mass_storage module: > > echo device > /sys/class/usb_role/intel_xhci_usb_sw-role-switch/role > modprobe g_mass_storage file=/dev/nvme0n1p3 iSerialNumber=90405 > > We are also able to reproduce this issue using f_mass_storage and > configfs. I decided to provide the logs and debug information while > using g_mass_storage beccause it a standard gadget configuration available > to everyone. I've been using an Ubuntu 18.04 host with Linux kernel 4.15.0 > for most debugging as I'm able to capture the most debug information with > Linux, but this issue is reproducible with Mac OSX and Windows hosts as > well. > > I've attached an archive titled > "host-ss-to-hs-logs.tar.gz" that contains the xHCI dynamic debug logs > and demsg output during this event, as well as the output of lsusb -vv > for our the device. Here is a quick timeline of events from the host's > perspective: > [10598.165931] host controller detects new USB connection > [10600.773788] The ext4 filesystem exposed by the device gadget is mounted > [10680.442486] We start to see xhci_hcd activity again > [10684.534818] We receive the first "cannot enable" / "cannot set link > state" error > [10688.627381] We receive another "cannot enable" / "cannot set link > state" error > [10688.755190] We see the usb device be recognized as a high-speed device > instead > > I've attached another archive titled "device-ss-to-hs-logs.tar.gz" that > contains the dwc3 trace events for this event, the dmesg output, and the > dwc3 regdump before and after the superspeed-to-highspeed transition. The cool!! Before I had to ask :-) > dmesg output is short (4 lines) and is probably helpful to find the > meaningful timestamps of the dwc3 traces. The sequence of events on the > device seems to start around 1346 seconds and ends around 1436 seconds. right, from device perspective I see things behaving normally, then a "random" reset shows up. > Please note the "dwc3.1.auto: failed to enable ep0out" errors that are > occurring when we connect our device to a host. These errors occur > pretty regularly and we are not sure what is causing them. this shouldn't happen, actually; where do you see those? Anyway, here's the important part from dwc3 traces: > irq/23-dwc3-995 [000] d..1 1422.081846: dwc3_complete_trb: ep1in: 1/2 trb > 8800364327d0 buf 748ff000 size 0 ctrl 0c18 (hlcS:SC:normal) > irq/23-dwc3-995 [000] d..1 1422.081853: dwc3_gadget_giveback: ep1in: req > 880177cc4e40 length 16384/16384 zsI ==> 0 completed 16kiB transfer block > irq/23-dwc3-995 [000] d..1 1422.081890: dwc3_gadget_ep_cmd: ep1in: cmd
Mouse and keyboard attached to the ASMedia ASM1042A USB 3.0 controller in Dell Thunderbolt Dock TB16 freeze
I have a Dell XPS 9370 connected to a Dell Thunderbolt Dock TB16. Attached (via USB) to the latter I have my mouse and keyboard. Both freeze after some (random) time of usage (from minutes to hours) with no messages neither in dmesg nor in /var/log/messages or /var/log/syslog. The only way to reactivate the frozen USB connection is to detach and reattach the affected peripheral (usually it is the mouse that freezes and the keyboard remains active but sometimes it is the opposite). I tried disabling USB autosuspend entirely (usbcore.autosuspend=-1 in the kernel command line) but the problem remains. I installed Windows in my PC only to update all the drivers and firmware (i.e., the thunderbolt firmware) using the packages provided by dell. Again, with no success. I have the latest BIOS istalled (1.8.1). I compile the kernel myself, from the latest vanilla kernel (using kernel-package to build a debian package). I am currently running latest stable kernel 5.0.4. The problems also affects latest debian SID kernel (4.19.28). I understand I am not helping much in identifying the source of the problem but I do not know how to help better, especially because the problem is hard to reproduce. If anyone could give me any suggestion on how to better investigate the source of the problem (i.e., increasing logging verbosity or any other thing that I could do), I would be very happy to help. The issue is very annoying (I have to detach/reattach my keyboard/mouse at least a couple of times per day). Thanks in advance.
Re: USB OTG removal in musb
Bin Liu, Sorry for the delay and thank you for your reply! On 3/22/19 2:10 PM, Bin Liu wrote: > > The plan is to remove otg SRP/HNP protocol support from musb driver, > since it appears nobody uses it. But in currently kernel the protocols > are just disabled, the code is not removed yet. Oh, I see, so I was misunderstanding. I think the whole "dual role" functionality was going to be removed. > Do you use SRP or HNP? Can you please provide more details what stops > working? No, I don't, I just use the USBx_ID pin connected to the fifth pin of the MicroUSB connector. Upgrading from kernel 4.14.x to 4.19.x it stopped working and I wrongly deduced that it was related to you patch. In facts I now tried to revert it with no success. The pin stays in high impedance and it's never pulled up. I will now try to better troubleshoot the issue by manually read and write registers to understand what is happening and report you back! Thank you in the meantime! Bye, -- Daniele Orlandi smime.p7s Description: S/MIME Cryptographic Signature
RE: [PATCH v2 0/2] usb: typec: ucsi: Support for DP alt mode
Hi Heikki, > -Original Message- > From: linux-usb-ow...@vger.kernel.org On > Behalf Of Heikki Krogerus > Sent: Wednesday, March 20, 2019 4:45 AM > To: Ajay Gupta ; Michael Hsu > Cc: linux-usb@vger.kernel.org > Subject: [PATCH v2 0/2] usb: typec: ucsi: Support for DP alt mode > > Hi, > > This is the second version of my proposal to add alt mode handling to ucsi > driver. > The problem in the first version was that I was not using the port alt mode > that > was associated with the partner alt mode (and vise versa), but I was instead > searching the alt mode objects in every case separately. > > So in this version I'm now always using the already associated alternate mode > partner in every case, and as far as the UCSI driver (or any other USB Type-C > driver) is concerned, that is all that it needs to do. The problem of actually > associating the correct alt mode partner object belongs to the Type-C > subsystem > core code, and any improvements to that code are out side of the scope of this > series. > > I've prepared a patch that allows the alt mode drivers to find the correct > port alt > mode for the partner alt modes. That should cover SVIDs that define multiple > modes (note, DisplayPort Alt mode is not one of those). But as I mentioned > above, that is not related to this series. Thanks for the new set. It looks good to me. I tested it with UCSI CCG on NVIDIA GPU and it works. Tested-By: Ajay Gupta Thanks Ajay > nvpublic > You can check the v1 from here: > https://www.spinics.net/lists/linux-usb/msg176703.html > > thanks, > > Heikki Krogerus (2): > usb: typec: ucsi: Preliminary support for alternate modes > usb: typec: ucsi: Support for DisplayPort alt mode > > drivers/usb/typec/ucsi/Makefile | 15 +- > drivers/usb/typec/ucsi/displayport.c | 297 ++ > drivers/usb/typec/ucsi/trace.c | 12 + > drivers/usb/typec/ucsi/trace.h | 26 ++ > drivers/usb/typec/ucsi/ucsi.c| 366 ++- > drivers/usb/typec/ucsi/ucsi.h| 93 +++ > 6 files changed, 738 insertions(+), 71 deletions(-) create mode 100644 > drivers/usb/typec/ucsi/displayport.c > > -- > 2.20.1
[PATCH] USB: cp210x: add new device id
Lorenz Messtechnik has a device that is controlled by the cp210x driver,
so add the device id to the driver. The device id was provided by
Silicon-Labs for the devices from this vendor.
Reported-by: Uli
Signed-off-by: Greg Kroah-Hartman
Cc: stable
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fffe23ab0189..f01cd0ee5621 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -80,6 +80,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x804E) }, /* Software Bisque Paramount ME
build-in converter */
{ USB_DEVICE(0x10C4, 0x8053) }, /* Enfora EDG1228 */
{ USB_DEVICE(0x10C4, 0x8054) }, /* Enfora GSM2228 */
+ { USB_DEVICE(0x10C4, 0x8056) }, /* Lorenz Messtechnik devices */
{ USB_DEVICE(0x10C4, 0x8066) }, /* Argussoft In-System Programmer */
{ USB_DEVICE(0x10C4, 0x806F) }, /* IMS USB to RS422 Converter Cable */
{ USB_DEVICE(0x10C4, 0x807A) }, /* Crumb128 board */
Dear Friend,
Dear Friend, I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Gaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have an investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00) and i need an investment Manager/Partner and because of the asylum status i will authorize you the ownership of the funds, however, I am interested in you for investment project assistance in your country, may be from there, we can build a business relationship in the near future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated Please Reply me in my box. Best Regards Mrs Aisha Gaddafi
Re: Mass Storage Gadget Device Falls from SuperSpeed to High Speed
Hello, On Mon, Mar 25, 2019 at 09:34:38AM +0200, Felipe Balbi wrote: > > Hi, > > Rob Weber writes: > > Hi linux-usb, > > > > My team and I are currently grappling with an issue where our custom > > hardware cannot maintain a SuperSpeed connection to a host computer > > while in device mode. After some time (as quickly as 5 seconds, or as > > long as 5 minutes), the USB connection will often drop from a SuperSpeed > > connection to a high speed connection. I would appreciate some help our > > pointers in how to dig deeper into this issue. This bug is starting to > > stretch my knowledge of USB, so any guidance is really appreciated. I've > > gathered a lot of debug information and logs which I describe in more > > detail below. > > > > Our custom design is based on the Intel CherryTrail z8550 processor. This > > SoC uses the DWC3 UDC controller. The USB port in question on our board > > please collect dwc3 tracepoints. The procedure is described here: > > https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs > > > is a USB Type-C port that supports both UFP and DFP data roles, up to > > 5V/1.5A as a power source, and up to 30W as a power sink during USB-PD > > negotiations. We use a Cypress CCG3 for the USB-PD controller which is > > configured and controlled via I2C from an STM32 microcontroller in our > > design. We also use a SuperSpeed redriver and mux to re-condition the > > signals that come in and out of the board and to multiplex the two SS > > channels of the type-C connector into one port of the SoC based on the > > cable orientation. When connecting our device to a host with a USB type > > A cable, we configure our internal battery charger to draw 100mA of power > > from the host. If PD negotiations occur, we will configure the charger to > > pull the current that was requested/accepted during PD negotiations. > > > > Our device is running Linux kernel version 4.9.115 with a few backported > > Can you run v5.0 to see if the problem is reproduced there? > > > patches to support the intel-xhci-usb-sw role switch driver that was > > introduced in version 4.17. We ported part of the following patchset for > > this: https://lkml.org/lkml/2018/3/20/387. I am working on building our > > OS with the 4.19.18 kernel to understand if this issue is reproducible > > on more recent versions of the kernel. > > Thank you, that will help a lot :-) > > > We are able to reproduce this with the default configuration of the > > legacy g_mass_storage module: > > > > echo device > /sys/class/usb_role/intel_xhci_usb_sw-role-switch/role > > modprobe g_mass_storage file=/dev/nvme0n1p3 iSerialNumber=90405 > > > > We are also able to reproduce this issue using f_mass_storage and > > configfs. I decided to provide the logs and debug information while > > using g_mass_storage beccause it a standard gadget configuration available > > to everyone. I've been using an Ubuntu 18.04 host with Linux kernel 4.15.0 > > for most debugging as I'm able to capture the most debug information with > > Linux, but this issue is reproducible with Mac OSX and Windows hosts as > > well. > > > > I've attached an archive titled > > "host-ss-to-hs-logs.tar.gz" that contains the xHCI dynamic debug logs > > and demsg output during this event, as well as the output of lsusb -vv > > for our the device. Here is a quick timeline of events from the host's > > perspective: > > [10598.165931] host controller detects new USB connection > > [10600.773788] The ext4 filesystem exposed by the device gadget is > > mounted > > [10680.442486] We start to see xhci_hcd activity again > > [10684.534818] We receive the first "cannot enable" / "cannot set link > > state" error > > [10688.627381] We receive another "cannot enable" / "cannot set link > > state" error > > [10688.755190] We see the usb device be recognized as a high-speed > > device instead > > > > I've attached another archive titled "device-ss-to-hs-logs.tar.gz" that > > contains the dwc3 trace events for this event, the dmesg output, and the > > dwc3 regdump before and after the superspeed-to-highspeed transition. The > > cool!! Before I had to ask :-) > > > dmesg output is short (4 lines) and is probably helpful to find the > > meaningful timestamps of the dwc3 traces. The sequence of events on the > > device seems to start around 1346 seconds and ends around 1436 seconds. > > right, from device perspective I see things behaving normally, then a > "random" reset shows up. In what way does this show up? Does the host send a reset command, does the device request the host port to reset, or does the device appear to reset itself? > > Please note the "dwc3.1.auto: failed to enable ep0out" errors that are > > occurring when we connect our device to a host. These errors occur > > pretty regularly and we are not sure what is causing them. > > this shouldn't happen, actually; where do you see those? They are in the dmesg output o
Re: Mass Storage Gadget Device Falls from SuperSpeed to High Speed
Hi, Rob Weber writes: >> > dmesg output is short (4 lines) and is probably helpful to find the >> > meaningful timestamps of the dwc3 traces. The sequence of events on the >> > device seems to start around 1346 seconds and ends around 1436 seconds. >> >> right, from device perspective I see things behaving normally, then a >> "random" reset shows up. > > In what way does this show up? Does the host send a reset command, does > the device request the host port to reset, or does the device appear to > reset itself? this IRQ is generated based on Reset Signaling driven on the bus by the host. >> > Please note the "dwc3.1.auto: failed to enable ep0out" errors that are >> > occurring when we connect our device to a host. These errors occur >> > pretty regularly and we are not sure what is causing them. >> >> this shouldn't happen, actually; where do you see those? > > They are in the dmesg output on the device. I was assuming they line up huh? Here's what I have on device side dmesg: [ 1345.662238] dwc3 dwc3.1.auto: request 880177cc4e40 was not queued to ep1out [ 1346.581055] g_mass_storage gadget: super-speed config #1: Linux File-Backed Storage [ 1435.982257] dwc3 dwc3.1.auto: request 880177cc4d80 was not queued to ep1out [ 1436.264087] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage That's the entire thing. > with tracepoints in the dwc traces, but I wasn't sure what to look for. > This error occurs approximately 75% of the time while the device is > enumerating. odd. Really shouldn't happen. >> Anyway, here's the important part from dwc3 traces: >> >> > irq/23-dwc3-995 [000] d..1 1422.081846: dwc3_complete_trb: ep1in: 1/2 >> > trb 8800364327d0 buf 748ff000 size 0 ctrl 0c18 >> > (hlcS:SC:normal) >> > irq/23-dwc3-995 [000] d..1 1422.081853: dwc3_gadget_giveback: ep1in: >> > req 880177cc4e40 length 16384/16384 zsI ==> 0 >> >> completed 16kiB transfer block >> >> > irq/23-dwc3-995 [000] d..1 1422.081890: dwc3_gadget_ep_cmd: ep1in: cmd >> > 'Update Transfer' [196615] params --> status: >> > Successful >> > file-storage-994 [001] d..1 1422.081917: dwc3_ep_queue: ep1in: req >> > 880177cc4e40 length 0/13 zsI ==> -115 >> > file-storage-994 [001] d..1 1422.081928: dwc3_gadget: ep1in: req >> > 880177cc4e40 dma 74905000 length 13 >> > file-storage-994 [001] d..1 1422.081938: dwc3_prepare_trb: ep1in: 2/2 >> > trb 8800364327f0 buf 74905000 size 13 ctrl 0c19 >> > (HlcS:SC:normal) >> > file-storage-994 [001] d..1 1422.081972: dwc3_gadget_ep_cmd: ep1in: cmd >> > 'Update Transfer' [196615] params --> status: >> > Successful >> > irq/23-dwc3-995 [000] d..1 1422.081980: dwc3_event: event (00100301): >> > Link Change [U0] >> > irq/23-dwc3-995 [000] d..1 1422.081988: dwc3_event: event (00110301): >> > Link Change [U1] >> > irq/23-dwc3-995 [000] d..1 1422.081997: dwc3_event: event (4086): >> > ep1in: Transfer In-Progress >> > irq/23-dwc3-995 [000] d..1 1422.082000: dwc3_complete_trb: ep1in: 1/2 >> > trb 8800364327e0 buf 74903000 size 0 ctrl 0c18 >> > (hlcS:SC:normal) >> > irq/23-dwc3-995 [000] d..1 1422.082008: dwc3_gadget_giveback: ep1in: >> > req 880177cc4b40 length 8192/8192 zsI ==> 0 >> >> 8kiB block >> >> > irq/23-dwc3-995 [000] d..1 1422.082048: dwc3_gadget_ep_cmd: ep1in: cmd >> > 'Update Transfer' [196615] params --> status: >> > Successful >> > file-storage-994 [001] d..1 1422.082089: dwc3_ep_queue: ep1out: req >> > 880177cc4d80 length 0/1024 zsI ==> -115 >> > file-storage-994 [001] d..1 1422.082101: dwc3_gadget: ep1out: req >> > 880177cc4d80 dma 74905800 length 1024 >> > file-storage-994 [001] d..1 1422.082111: dwc3_prepare_trb: ep1out: 4/2 >> > trb 880036423780 buf 74905800 size 1024 ctrl 0c19 >> > (HlcS:SC:normal) >> > file-storage-994 [001] d..1 1422.082144: dwc3_gadget_ep_cmd: ep1out: >> > cmd 'Update Transfer' [131079] params --> >> > status: Successful >> > irq/23-dwc3-995 [000] d..1 1422.082147: dwc3_event: event (00100301): >> > Link Change [U0] >> > irq/23-dwc3-995 [000] d..1 1422.082155: dwc3_event: event (00110301): >> > Link Change [U1] >> > irq/23-dwc3-995 [000] d..1 1422.082160: dwc3_event: event (00100301): >> > Link Change [U0] >> > irq/23-dwc3-995 [000] d..1 1422.082167: dwc3_event: event (00110301): >> > Link Change [U1] >> > irq/23-dwc3-995 [000] d..1 1422.082173: dwc3_event: event (4086): >> > ep1in: Transfer In-Progress >> > irq/23-dwc3-995 [000] d..1 1422.082176: dwc3_complete_trb: ep1in: 0/2 >> > trb 8800364327f0 buf 74905000 size 0 ctrl 0c18 >> > (hlcS:SC:normal) >> > irq/23-dwc3-995 [000] d..1 1422.082181: dwc3_gadget_giveback: ep1in: >> > req 880177cc4e40 length 13/13 zsI ==> 0 >> >> CSW > > What is C
