Re: USB: ftdi_sio: not detecting
On Tue, Aug 14, 2018 at 7:33 PM, Alan Stern wrote: > On Tue, 14 Aug 2018, Muni Sekhar wrote: > >> On Mon, Aug 13, 2018 at 7:52 PM, Muni Sekhar wrote: >> > On Mon, Aug 13, 2018 at 6:57 PM, Oliver Neukum wrote: >> >> On Mo, 2018-08-13 at 18:44 +0530, Muni Sekhar wrote: >> >>> [ Please keep me in CC as I'm not subscribed to the list] >> >>> >> >>> Hello All, >> >>> >> >>> I’ve a FTDI serial device and it is not recognized if I connect >> >>> directly to computer. However if I connect via an external USB hub >> >>> it’s fine and I can see the FTDI serial device. What could be the >> >>> issue and how to resolve this? >> If I connect the FTDI device directly to computer I don't see any >> dmesg log, but after enabling the dynamic debugging for usbcore and >> hcd's driver then I see kernel log flooded with the below mentioned >> logs. Is it a bug in the hcd's driver? The same device works fine if I >> connect via an external USB hub. >> >> [14045.942047] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14045.942156] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14046.102357] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14046.158579] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14046.158692] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14046.318662] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14046.374689] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14046.374798] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14046.535001] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14046.591050] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14046.591161] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14046.751382] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14046.807415] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14046.807527] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14046.967725] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14047.023761] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >> [14047.023872] usb usb2-port2: status 0100, change 0001, 12 Mb/s >> [14047.184025] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 >> [14047.240078] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > > These messages indicate the device is electronically detaching itself > from the bus and then reattaching itself, over and over again, about > four times per second. Thanks for this information. > > Have you tried using this device on another computer? Do you have > another full-speed device you can try plugging into that port? It connects perfectly to my virtual box running Linux. Right now I don't have any other full-speed device to verify this. > > Alan Stern > -- Thanks, Sekhar
Re: USB: ftdi_sio: not detecting
On Tue, 14 Aug 2018, Muni Sekhar wrote: > On Mon, Aug 13, 2018 at 7:52 PM, Muni Sekhar wrote: > > On Mon, Aug 13, 2018 at 6:57 PM, Oliver Neukum wrote: > >> On Mo, 2018-08-13 at 18:44 +0530, Muni Sekhar wrote: > >>> [ Please keep me in CC as I'm not subscribed to the list] > >>> > >>> Hello All, > >>> > >>> I’ve a FTDI serial device and it is not recognized if I connect > >>> directly to computer. However if I connect via an external USB hub > >>> it’s fine and I can see the FTDI serial device. What could be the > >>> issue and how to resolve this? > If I connect the FTDI device directly to computer I don't see any > dmesg log, but after enabling the dynamic debugging for usbcore and > hcd's driver then I see kernel log flooded with the below mentioned > logs. Is it a bug in the hcd's driver? The same device works fine if I > connect via an external USB hub. > > [14045.942047] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14045.942156] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.102357] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.158579] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.158692] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.318662] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.374689] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.374798] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.535001] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.591050] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.591161] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.751382] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.807415] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.807527] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.967725] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.023761] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.023872] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14047.184025] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.240078] hub 2-0:1.0: state 7 ports 6 chg evt 0004 These messages indicate the device is electronically detaching itself from the bus and then reattaching itself, over and over again, about four times per second. Have you tried using this device on another computer? Do you have another full-speed device you can try plugging into that port? Alan Stern
Re: usb typec not doing handling in-kernel
Hi Heikki, Am Montag, 13. August 2018, 15:36:37 CEST schrieb Heikki Krogerus: > On Mon, Aug 13, 2018 at 12:36:55PM +0200, Heiko Stuebner wrote: > > I'm currently trying to wrap my head around the new typec subsystem and > > also how to do it correctly on Rockchip rk3399 devices. > > > > The issue (and Guenter might know quite a bit about that) is that on > > ChromeOS devices the embedded controller hides the whole tcpm/vdm > > logic from the operating system and just provides a custom interface to > > query things like cable state, display-port hotplug status and so on. > > > > So right now the rk3399-typec-phy uses that extcon-based interface to > > get all status changes but that of course leaves out all systems directly > > talking to a fusb302. I did a small drawing to showcase that: > > > > --- > > | typec-phy || extcon-cros-ec |\ > > --- \ > > |\ \ > > - \ -- \ --- > > | cdn-dp | \| ? |-| fusb302 | > > --- --- > > > > So to bring everything on the same page, I guess the cros-ec extcon > > (drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec > > functions instead of implementing an extcon? > > I don't think the two necessary exclude each other. You can continue > to register the extcon device and use it for communication with the > phy driver, and also register your Type-C port(s), partners, and > optionally the port and partner alternate modes. I guess Guenter has > patches for that already? The issue is less with the working ChromeOS devices :-) . What I'm trying to fit in there are all the other boards directly talking to a fusb302 via i2c and needing to do all these negotiations. So the rockchip typec phy would need to handle both cases. In the Rockchip vendor kernel they bolted the extcon export onto their fusb302 driver but I don't think that is really future proof ;-) . Hence the easiest way would probably be to have everything use the newer typec APIs and not try to make the Rockchip typec-phy handle both cases. And looking at Guenters mail, it seems like he had the same idea as well in the past, so I'll hope for his archeology-skills :-) . > It looks to me like that phy driver could just register a Type-C > switch for the orientation, and mux for the mode. Those seem to be the > only details the driver needs from extcon-usbc-cros-ec. Looks like it - I'm still trying to find my way through the typec subsystem though. > > But from reading into the typec code, it somehow looks like the > > typec framework expects to be in control of things like altmode > > negotiations, or am I misreading something? > > The alternate mode drivers will assume they are in control of the > negotiation with the partner, but note that you will not always need > them. The rest of the code in the framework doesn't expect to be in > control of the communication. > > If the EC (or some other microcontroller) firmware is taking care of > the actual entering and configuring of the alternate modes, the port > driver (so extcon-usbc-cros-ec in your case) will need to "emulate" > the VDM communication if the alt mode drivers need to be used, and > that means they need to do so with every supported alternate mode > separately. > > Of course if the details that for example the DisplayPort alt mode > driver supplies to the user space is not relevant on your system, and > there is no requirement to allow the user to be able to reconfigure > the DisplayPort alt mode (note: you will also be unable to exit the > mode from sysfs in this case), you can still register the partner alt > mode device and simply allow the binding to the driver fail, or don't > register the partner alt modes with the USB Type-C framework at all. As said above, I'm mainly trying to make the typec framework usable for all the rk3399 boards using the "standard" setup of talking directly to the fusb302 but of course want to pull the cros-ec special case along, to not create to much overhead anywhere. Thankfully it is really only the DisplayPort Alt Mode that is supported on the rk3399. While the extcon driver doesn't seem to use it right now, looking through the ec-commands shows that muxes, roles etc seem configurable from the host side. > I've prepared patches for the ucsi driver that add displayport alt > mode support to it. UCSI is just a standardised firmware interface for > USB Type-C conncetors, so the situation is exactly the same as with > extcon-usbc-cros-ec. I was planning to send the patches out for review > after next -rc1, but I guess I could send a RFC already. With UCSI we > do have a requirement to allow the user to reconfigure the DisplayPort > alternate mode if needed. That might be helpful. But you don't really have to hurry that much. -rc1 isn't that far away and I do have enough individual
Re: [PATCH] usb: hide usb_of_get_companion_dev for CONFIG_USB=n
On Mon, 13 Aug 2018, Arnd Bergmann wrote:
> The renesas UDC implementation now calls usb_of_get_companion_dev(),
> which is only defined when CONFIG_USB is enabled:
>
> drivers/usb/gadget/udc/renesas_usb3.o: In function `renesas_usb3_probe':
> renesas_usb3.c:(.text+0xa34): undefined reference to
> `usb_of_get_companion_dev'
>
> To avoid the build error, we need two changes:
>
> - usb_of_get_companion_dev must be stubbed out when CONFIG_USB is
> disabled, so it the udc driver can be built for a gadget-only
> mode kernel
> - With CONFIG_USB=m, we must not attempt to have USB_RENESAS_USB3
> built-in, so we need a soft dependency on USB.
>
> Fixes: 39facfa01c9f ("usb: gadget: udc: renesas_usb3: Add register of usb
> role switch")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/usb/gadget/udc/Kconfig | 1 +
> include/linux/usb/of.h | 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
> index 0a16cbd4e528..663a8bd67a7b 100644
> --- a/drivers/usb/gadget/udc/Kconfig
> +++ b/drivers/usb/gadget/udc/Kconfig
> @@ -193,6 +193,7 @@ config USB_RENESAS_USB3
> tristate 'Renesas USB3.0 Peripheral controller'
> depends on ARCH_RENESAS || COMPILE_TEST
> depends on EXTCON
> + depends on USB || !USB
Is this some weird standard idiom? It looks really strange.
Alan Stern
gegenseitiger Nutzen
Lieber Freund Gruß mein guter Freund, wie geht es dir und Familie heute? Ich bin Rechtsanwalt Martin Larcher, Rechtsanwalt und ich habe Sie wegen einer Erbschaftstransaktion kontaktiert, die mit Ihrem Nachnamen zusammenhängt, von dem beide Familien profitieren. Ich werde Ihnen mehr Details über die Transaktion geben, wenn Sie von Ihnen hören. Hier ist meine private Adresse (martin.larcher...@gmail.com) Freundliche Grüße Barr Martin Larcher
Re: USB: ftdi_sio: not detecting
On Di, 2018-08-14 at 14:49 +0530, Muni Sekhar wrote: > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M > > |__ Port 2: Dev 91, If 0, Class=Hub, Driver=hub/4p, 480M > > |__ Port 2: Dev 100, If 0, Class=Hub, Driver=hub/3p, 480M > > |__ Port 1: Dev 101, If 0, Class=Vendor Specific Class, > Driver=ftdi_sio, 12M > > |__ Port 2: Dev 102, If 0, Class=Vendor Specific Class, > Driver=ftdi_sio, 12M > > |__ Port 3: Dev 103, If 0, Class=Vendor Specific Class, > Driver=ftdi_sio, 12M In this case XHCI. But you need the failing case. Presumably also XHCI, but that is not guaranteed. In case lsusb -t fails in the failure case, attach another device into the port your serial devices fails at. Regards Oliver
Re: USB: ftdi_sio: not detecting
On Tue, Aug 14, 2018 at 2:39 PM, Oliver Neukum wrote: > On Di, 2018-08-14 at 14:29 +0530, Muni Sekhar wrote: >> >> Is there any way to know which HC I’m is using? I checked the >> /sys/kernel/debug/usb/devices file and I see three HC’s. >> >> >> >> T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1 > > Match the 'Bus' number or use 'lsusb -t' $ lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M |__ Port 2: Dev 91, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 100, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 101, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 2: Dev 102, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 3: Dev 103, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 4: Dev 2, If 0, Class=Communications, Driver=cdc_acm, 480M |__ Port 4: Dev 2, If 1, Class=CDC Data, Driver=cdc_acm, 480M |__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/5p, 480M |__ Port 5: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M > > HTH > Oliver > -- Thanks, Sekhar
Re: USB: ftdi_sio: not detecting
On Di, 2018-08-14 at 14:29 +0530, Muni Sekhar wrote: > > Is there any way to know which HC I’m is using? I checked the > /sys/kernel/debug/usb/devices file and I see three HC’s. > > > > T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1 Match the 'Bus' number or use 'lsusb -t' HTH Oliver
[PATCH] USB: serial: io_ti: array underflow in edge_interrupt_callback()
A malicious USB device could set port_number to -3 and we would
underflow the edge_serial->serial->port[] array.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 6d1d6efa3055..fa2af18c6efe 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1629,7 +1629,7 @@ static void edge_interrupt_callback(struct urb *urb)
struct device *dev;
unsigned char *data = urb->transfer_buffer;
int length = urb->actual_length;
- int port_number;
+ unsigned int port_number;
int function;
int retval;
__u8 lsr;
Re: USB: ftdi_sio: not detecting
On Tue, Aug 14, 2018 at 2:02 PM, Oliver Neukum wrote: > On Di, 2018-08-14 at 12:17 +0530, Muni Sekhar wrote: >> On Mon, Aug 13, 2018 at 7:52 PM, Muni Sekhar wrote: >> > On Mon, Aug 13, 2018 at 6:57 PM, Oliver Neukum wrote: >> > > On Mo, 2018-08-13 at 18:44 +0530, Muni Sekhar wrote: >> > > > [ Please keep me in CC as I'm not subscribed to the list] >> > > > >> > > > Hello All, >> > > > >> > > > I’ve a FTDI serial device and it is not recognized if I connect >> > > > directly to computer. However if I connect via an external USB hub >> > > > it’s fine and I can see the FTDI serial device. What could be the >> > > > issue and how to resolve this? >> >> If I connect the FTDI device directly to computer I don't see any >> dmesg log, but after enabling the dynamic debugging for usbcore and >> hcd's driver then I see kernel log flooded with the below mentioned >> logs. Is it a bug in the hcd's driver? The same device works fine if I >> connect via an external USB hub. > > Hi, > > you are looking at an issue with the HC driver. Unfortunately you have > castrated the logs to an extent that prevents me from telling which > HC you are using. However, in any case, you need to find out and > contact its driver's maintainer. Is there any way to know which HC I’m is using? I checked the /sys/kernel/debug/usb/devices file and I see three HC’s. T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 4.04 S: Manufacturer=Linux 4.4.0-28-generic xhci-hcd S: Product=xHCI Host Controller S: SerialNumber=:00:14.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 4.04 S: Manufacturer=Linux 4.4.0-28-generic xhci-hcd S: Product=xHCI Host Controller S: SerialNumber=:00:14.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 4.04 S: Manufacturer=Linux 4.4.0-28-generic ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > HTH > Oliver > -- Thanks, Sekhar
Re: USB: ftdi_sio: not detecting
On Di, 2018-08-14 at 12:17 +0530, Muni Sekhar wrote: > On Mon, Aug 13, 2018 at 7:52 PM, Muni Sekhar wrote: > > On Mon, Aug 13, 2018 at 6:57 PM, Oliver Neukum wrote: > > > On Mo, 2018-08-13 at 18:44 +0530, Muni Sekhar wrote: > > > > [ Please keep me in CC as I'm not subscribed to the list] > > > > > > > > Hello All, > > > > > > > > I’ve a FTDI serial device and it is not recognized if I connect > > > > directly to computer. However if I connect via an external USB hub > > > > it’s fine and I can see the FTDI serial device. What could be the > > > > issue and how to resolve this? > > If I connect the FTDI device directly to computer I don't see any > dmesg log, but after enabling the dynamic debugging for usbcore and > hcd's driver then I see kernel log flooded with the below mentioned > logs. Is it a bug in the hcd's driver? The same device works fine if I > connect via an external USB hub. Hi, you are looking at an issue with the HC driver. Unfortunately you have castrated the logs to an extent that prevents me from telling which HC you are using. However, in any case, you need to find out and contact its driver's maintainer. HTH Oliver
Re: USB: ftdi_sio: not detecting
On Mon, Aug 13, 2018 at 7:52 PM, Muni Sekhar wrote: > On Mon, Aug 13, 2018 at 6:57 PM, Oliver Neukum wrote: >> On Mo, 2018-08-13 at 18:44 +0530, Muni Sekhar wrote: >>> [ Please keep me in CC as I'm not subscribed to the list] >>> >>> Hello All, >>> >>> I’ve a FTDI serial device and it is not recognized if I connect >>> directly to computer. However if I connect via an external USB hub >>> it’s fine and I can see the FTDI serial device. What could be the >>> issue and how to resolve this? If I connect the FTDI device directly to computer I don't see any dmesg log, but after enabling the dynamic debugging for usbcore and hcd's driver then I see kernel log flooded with the below mentioned logs. Is it a bug in the hcd's driver? The same device works fine if I connect via an external USB hub. [14045.942047] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14045.942156] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14046.102357] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14046.158579] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14046.158692] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14046.318662] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14046.374689] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14046.374798] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14046.535001] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14046.591050] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14046.591161] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14046.751382] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14046.807415] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14046.807527] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14046.967725] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14047.023761] hub 2-0:1.0: state 7 ports 6 chg evt 0004 [14047.023872] usb usb2-port2: status 0100, change 0001, 12 Mb/s [14047.184025] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 [14047.240078] hub 2-0:1.0: state 7 ports 6 chg evt 0004 >>> >>> >>> Also one more behaviour, when I ran “lsusb” it hangs forever and ‘ps’ >>> command output shows the state as “Dl+”. Any reasons for this >>> behaviour? >> >> Impossible to tell. Switch on dynamic debugging for usbcore and your >> hcd's driver and post dmesg. >> Sysrq-T during the hang would also help. > After enabling the dynamic debugging, I'm getting the below mentioned log: > > [14045.942047] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14045.942156] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.102357] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.158579] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.158692] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.318662] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.374689] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.374798] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.535001] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.591050] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.591161] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.751382] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14046.807415] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14046.807527] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14046.967725] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.023761] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.023872] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14047.184025] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.240078] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.240189] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14047.400373] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.456425] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.456537] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14047.616685] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.672654] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.672749] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14047.833074] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14047.888951] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14047.889006] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14048.049388] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14048.105450] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14048.105560] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14048.265730] usb usb2-port2: debounce total 125ms stable 100ms status 0x101 > [14048.321776] hub 2-0:1.0: state 7 ports 6 chg evt 0004 > [14048.321892] usb usb2-port2: status 0100, change 0001, 12 Mb/s > [14048.482047] usb usb2-port2: debounce total 125ms
Re: Delayed "registered new interface driver snd-usb-audio"
On Tue, Aug 14, 2018 at 9:36 AM, Greg KH wrote:
> On Tue, Aug 14, 2018 at 09:29:26AM +0300, Ran Shalit wrote:
>> On Mon, Aug 13, 2018 at 9:57 PM, Greg KH wrote:
>> > On Mon, Aug 13, 2018 at 09:34:37PM +0300, Ran Shalit wrote:
>> >> Hello,
>> >>
>> >> I have a strange behabiour with sound card usb.
>> >> I use kernel 3.18.11-rt7 (real-time kernel )
>> >
>> > Ugh, please go get support from whomever is forcing you to use such an
>> > old and obsolete kernel version. You are paying them for support,
>> > there's nothing that we can do about this :(
>> >
>> >> It takes 10 (!) seconds between detection of usb device till it is
>> >> registered ("registered new interface driver snd-usb-audio") in
>> >> kernel.
>> >> We take the usb device out of reset using another HW.
>> >>
>> >> See below dmesg:
>> >>
>> >> [7.911220] ixgbe :01:00.1: registered PHC device on eth1
>> >> [8.186213] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
>> >> Control: RX/TX
>> >> [8.218386] NET: Registered protocol family 10
>> >> [8.691077] ixgbe :01:00.0 eth0: NIC Link is Down
>> >> [9.090808] ixgbe :01:00.1 eth1: NIC Link is Down
>> >> [9.893587] ixgbe :01:00.0 eth0: NIC Link is Up 1 Gbps, Flow
>> >> Control: RX/TX
>> >> [ 10.317939] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
>> >> Control: RX/TX
>> >> [ 38.171328] random: nonblocking pool is initialized
>> >> [ 260.380461] usb 1-2: new full-speed USB device number 2 using xhci_hcd
>> >> [ 260.545907] usb 1-2: config 1 has an invalid descriptor of length
>> >> 0, skipping remainder of the config
>> >> [ 260.546471] usb 1-2: New USB device found, idVendor=0451,
>> >> idProduct=9010
>> >> [ 260.546478] usb 1-2: New USB device strings: Mfr=1, Product=2,
>> >> SerialNumber=3
>> >> [ 260.546484] usb 1-2: Product: TI C55 Ver 6.00
>> >> [ 260.546488] usb 1-2: Manufacturer: Texas Instruments
>> >> [ 260.546491] usb 1-2: SerialNumber: 320001
>> >> [ 260.594916] input: Texas Instruments TI C55 Ver 6.00 as
>> >> /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.3/0003:0451:9010.0001/input/input3
>> >> [ 260.595084] hid-generic 0003:0451:9010.0001: input,hidraw0: USB HID
>> >> v1.11 Device [Texas Instruments TI C55 Ver 6.00] on
>> >> usb-:00:14.0-2/input3
>> >> [ 260.595153] usbcore: registered new interface driver usbhid
>> >> [ 260.595157] usbhid: USB HID core driver
>> >> [ 345.706843] usbcore: registered new interface driver snd-usb-audio
>> >>
>> >> Is there any idea what can cause this delay ?
>> >
>> > You are loading a new driver from somewhere, that takes time. Odds are
>> > this is a userspace issue.
>> >
>> Thanks for the hint, which print did you refer to about the loading module ?
>
> Your last one, that happens when the snd-usb-audio driver is loaded into
> the kernel, it was not present before that. Go read up on how kernel
> modules are automatically loaded when hardware is found, it's a long
> kernel->userspace->kernel chain of events that happens.
>
>> I will try to build the modules into kernel and see if it changes.
>
> It will. But again, go bug the vendor that is forcing you to use such
> an old ad obsolete kernel version for a new device please. That should
> not be happening.
>
One last thing.
The kernel is RT linux, I also suspected that there might be some rt
thread that *always* gets inside just before the module is loaded (the
last delay message), and that's always takes 10 seconds.
But using top/htop I haven't find any special thread which gets in in
this 10 seconds.
I'm not sure I can update kernel now, so I'll have to try the other suggestions.
Thanks a lot,
ranran
>> We also noticed that in another kernel (and different ditribution too)
>> the time is immediate, but it could be that the module was build
>> inside kernel in that distribution. we also noticed that in the other
>> distribution it is ehci_hcd, while in this (the slower) it is
>> xhci_hcd. So that also might explain, right ?
>
> No, the host controller driver should not matter at all.
>
> good luck!
>
> greg k-h
Re: Delayed "registered new interface driver snd-usb-audio"
On Tue, Aug 14, 2018 at 09:29:26AM +0300, Ran Shalit wrote:
> On Mon, Aug 13, 2018 at 9:57 PM, Greg KH wrote:
> > On Mon, Aug 13, 2018 at 09:34:37PM +0300, Ran Shalit wrote:
> >> Hello,
> >>
> >> I have a strange behabiour with sound card usb.
> >> I use kernel 3.18.11-rt7 (real-time kernel )
> >
> > Ugh, please go get support from whomever is forcing you to use such an
> > old and obsolete kernel version. You are paying them for support,
> > there's nothing that we can do about this :(
> >
> >> It takes 10 (!) seconds between detection of usb device till it is
> >> registered ("registered new interface driver snd-usb-audio") in
> >> kernel.
> >> We take the usb device out of reset using another HW.
> >>
> >> See below dmesg:
> >>
> >> [7.911220] ixgbe :01:00.1: registered PHC device on eth1
> >> [8.186213] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [8.218386] NET: Registered protocol family 10
> >> [8.691077] ixgbe :01:00.0 eth0: NIC Link is Down
> >> [9.090808] ixgbe :01:00.1 eth1: NIC Link is Down
> >> [9.893587] ixgbe :01:00.0 eth0: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [ 10.317939] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
> >> Control: RX/TX
> >> [ 38.171328] random: nonblocking pool is initialized
> >> [ 260.380461] usb 1-2: new full-speed USB device number 2 using xhci_hcd
> >> [ 260.545907] usb 1-2: config 1 has an invalid descriptor of length
> >> 0, skipping remainder of the config
> >> [ 260.546471] usb 1-2: New USB device found, idVendor=0451, idProduct=9010
> >> [ 260.546478] usb 1-2: New USB device strings: Mfr=1, Product=2,
> >> SerialNumber=3
> >> [ 260.546484] usb 1-2: Product: TI C55 Ver 6.00
> >> [ 260.546488] usb 1-2: Manufacturer: Texas Instruments
> >> [ 260.546491] usb 1-2: SerialNumber: 320001
> >> [ 260.594916] input: Texas Instruments TI C55 Ver 6.00 as
> >> /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.3/0003:0451:9010.0001/input/input3
> >> [ 260.595084] hid-generic 0003:0451:9010.0001: input,hidraw0: USB HID
> >> v1.11 Device [Texas Instruments TI C55 Ver 6.00] on
> >> usb-:00:14.0-2/input3
> >> [ 260.595153] usbcore: registered new interface driver usbhid
> >> [ 260.595157] usbhid: USB HID core driver
> >> [ 345.706843] usbcore: registered new interface driver snd-usb-audio
> >>
> >> Is there any idea what can cause this delay ?
> >
> > You are loading a new driver from somewhere, that takes time. Odds are
> > this is a userspace issue.
> >
> Thanks for the hint, which print did you refer to about the loading module ?
Your last one, that happens when the snd-usb-audio driver is loaded into
the kernel, it was not present before that. Go read up on how kernel
modules are automatically loaded when hardware is found, it's a long
kernel->userspace->kernel chain of events that happens.
> I will try to build the modules into kernel and see if it changes.
It will. But again, go bug the vendor that is forcing you to use such
an old ad obsolete kernel version for a new device please. That should
not be happening.
> We also noticed that in another kernel (and different ditribution too)
> the time is immediate, but it could be that the module was build
> inside kernel in that distribution. we also noticed that in the other
> distribution it is ehci_hcd, while in this (the slower) it is
> xhci_hcd. So that also might explain, right ?
No, the host controller driver should not matter at all.
good luck!
greg k-h
Re: Delayed "registered new interface driver snd-usb-audio"
On Mon, Aug 13, 2018 at 9:57 PM, Greg KH wrote:
> On Mon, Aug 13, 2018 at 09:34:37PM +0300, Ran Shalit wrote:
>> Hello,
>>
>> I have a strange behabiour with sound card usb.
>> I use kernel 3.18.11-rt7 (real-time kernel )
>
> Ugh, please go get support from whomever is forcing you to use such an
> old and obsolete kernel version. You are paying them for support,
> there's nothing that we can do about this :(
>
>> It takes 10 (!) seconds between detection of usb device till it is
>> registered ("registered new interface driver snd-usb-audio") in
>> kernel.
>> We take the usb device out of reset using another HW.
>>
>> See below dmesg:
>>
>> [7.911220] ixgbe :01:00.1: registered PHC device on eth1
>> [8.186213] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
>> Control: RX/TX
>> [8.218386] NET: Registered protocol family 10
>> [8.691077] ixgbe :01:00.0 eth0: NIC Link is Down
>> [9.090808] ixgbe :01:00.1 eth1: NIC Link is Down
>> [9.893587] ixgbe :01:00.0 eth0: NIC Link is Up 1 Gbps, Flow
>> Control: RX/TX
>> [ 10.317939] ixgbe :01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
>> Control: RX/TX
>> [ 38.171328] random: nonblocking pool is initialized
>> [ 260.380461] usb 1-2: new full-speed USB device number 2 using xhci_hcd
>> [ 260.545907] usb 1-2: config 1 has an invalid descriptor of length
>> 0, skipping remainder of the config
>> [ 260.546471] usb 1-2: New USB device found, idVendor=0451, idProduct=9010
>> [ 260.546478] usb 1-2: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [ 260.546484] usb 1-2: Product: TI C55 Ver 6.00
>> [ 260.546488] usb 1-2: Manufacturer: Texas Instruments
>> [ 260.546491] usb 1-2: SerialNumber: 320001
>> [ 260.594916] input: Texas Instruments TI C55 Ver 6.00 as
>> /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.3/0003:0451:9010.0001/input/input3
>> [ 260.595084] hid-generic 0003:0451:9010.0001: input,hidraw0: USB HID
>> v1.11 Device [Texas Instruments TI C55 Ver 6.00] on
>> usb-:00:14.0-2/input3
>> [ 260.595153] usbcore: registered new interface driver usbhid
>> [ 260.595157] usbhid: USB HID core driver
>> [ 345.706843] usbcore: registered new interface driver snd-usb-audio
>>
>> Is there any idea what can cause this delay ?
>
> You are loading a new driver from somewhere, that takes time. Odds are
> this is a userspace issue.
>
Thanks for the hint, which print did you refer to about the loading module ?
I will try to build the modules into kernel and see if it changes.
We also noticed that in another kernel (and different ditribution too)
the time is immediate, but it could be that the module was build
inside kernel in that distribution. we also noticed that in the other
distribution it is ehci_hcd, while in this (the slower) it is
xhci_hcd. So that also might explain, right ?
Thanks,
ran
> good luck!
>
> greg k-h
