On Tue, Aug 14, 2018 at 9:36 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <gregkh@xxxxxxxxxxxxxxxxxxx> 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 0000:01:00.1: registered PHC device on eth1
>> >> [ 8.186213] ixgbe 0000:01:00.1 eth1: NIC Link is Up 1 Gbps, Flow
>> >> Control: RX/TX
>> >> [ 8.218386] NET: Registered protocol family 10
>> >> [ 8.691077] ixgbe 0000:01:00.0 eth0: NIC Link is Down
>> >> [ 9.090808] ixgbe 0000:01:00.1 eth1: NIC Link is Down
>> >> [ 9.893587] ixgbe 0000:01:00.0 eth0: NIC Link is Up 1 Gbps, Flow
>> >> Control: RX/TX
>> >> [ 10.317939] ixgbe 0000: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/pci0000:00/0000: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-0000: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
