On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
> Hi Oliver & Alan,
>
>
>
> Thanks for your inputs.
>
>
>
> I enabled the dynamic debugging for USB HC driver. Please correct me
> if I am wrong.
Debugging the kernel (or doing anything else to the kernel, for that
matter) won't solve the problem if it is caused by a buggy hub.
Alan Stern
On Tue, 28 Oct 2014, Naveen Kumar Parna wrote:
> >> You should also run a similar test when you connect the device through
> >> a USB-2 hub. In fact, you should run two tests. In one test, connect
> >> the analyzer to the cable segment between the computer and the hub; in
> >> the other test, connect the analyzer to the cable segment between the
> >> hub and the device.
> >>
> >
>
> I connected the USB analyzer to the cable segment between the computer
> and the external USB-2 hub(devices are attached to this external USB-2
> hub). In this scenario , got the stall in usbmon trace, but not in
> analyzer log. But USB analyzer log shows “Incomplete IN transaction”.
> Please check the attached "Elisys_Usb_log.png".
>
>
>
> Incomplete IN transaction 2 1
> INCOMPLETE HS No data 884.626 273 217
> Does it gives any clue?
Not really. I think your analyzer output is incomplete. For example,
a high-speed Interrupt transaction to a full-speed device should have a
Start Split packet and a Complete Split packet. I don't see either of
those in your picture.
> For the second test(connect the analyzer to the cable segment between
> the hub and the device): Is it possible with single external USB hub?
Of course it is. What's the difficulty?
Alan Stern
>
>> You should also run a similar test when you connect the device through
>> a USB-2 hub. In fact, you should run two tests. In one test, connect
>> the analyzer to the cable segment between the computer and the hub; in
>> the other test, connect the analyzer to the cable segment between the
>> hub and the device.
>>
>
I connected the USB analyzer to the cable segment between the computer
and the external USB-2 hub(devices are attached to this external USB-2
hub). In this scenario , got the stall in usbmon trace, but not in
analyzer log. But USB analyzer log shows “Incomplete IN transaction”.
Please check the attached "Elisys_Usb_log.png".
Incomplete IN transaction 2 1
INCOMPLETE HS No data 884.626 273 217
Incomplete IN transaction 2 1
INCOMPLETE HS No data 884.882 309 000
Incomplete IN transaction 2 1
INCOMPLETE HS No data 885.138 344 750
Incomplete IN transaction 2 1
INCOMPLETE HS No data 885.394 380 533
Incomplete IN transaction 2 1
INCOMPLETE HS No data 885.650 416 300
Incomplete IN transaction 2 1
INCOMPLETE HS No data 885.906 452 050
Incomplete IN transaction 2 1
INCOMPLETE HS No data 886.162 487 833
Incomplete IN transaction 2 1
INCOMPLETE HS No data 886.418 523 583
Incomplete IN transaction 2 1
INCOMPLETE HS No data 886.674 559 367
Incomplete IN transaction 2 1
INCOMPLETE HS No data 886.930 595 117
Incomplete IN transaction 2 1
INCOMPLETE HS No data 887.186 630 883
Incomplete IN transaction 2 1
INCOMPLETE HS No data 887.442 666 667
Incomplete IN transaction 2 1
INCOMPLETE HS No data 887.698 702 417
Does it gives any clue?
For the second test(connect the analyzer to the cable segment between
the hub and the device): Is it possible with single external USB hub?
Thanks,
Naveen
On Thu, Oct 16, 2014 at 7:39 PM, Alan Stern <[email protected]> wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > Indeed. However, it is possible to use an additional in between your
>> > devices and the internal hub.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>>
>> Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
>> 10) and got the same result.
>>
>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>
>> |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
>>
>> |__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
>
> This is not what Oliver meant. You have to use a USB-2 hub. And
> having one of them is enough; you don't need two.
>
> Alan Stern
>
As suggested, I connected USB-2 hub(Dev 87) in between my devices and
the internal hub. In this scenario also observed the STALL packets.
I am interested in understanding the objective of this test, can you
please help me?
[lowerlayers@banunxcas29 ~]$ lsusb -t
1-1.5.1:1.2: No such file or directory
1-1.5.3:1.2: No such file or directory
1-1.5.4:1.2: No such file or directory
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
|__ Port 5: Dev 87, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 1: Dev 88, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 1: Dev 88, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 1: Dev 88, If 2, Class=app., Driver=, 12M
|__ Port 3: Dev 90, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 90, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 90, If 2, Class=app., Driver=, 12M
|__ Port 4: Dev 89, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 89, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 89, If 2, Class=app., Driver=, 12M
[root@banunxcas29 ~]# cat /sys/kernel/debug/usb/usbmon/1u
ffff8800b2036540 2419900733 C Ii:1:090:1 -32:1 0
ffff8800b2036540 2419900753 S Ii:1:090:1 -115:1 16 <
ffff8800b2036540 963424773 C Ii:1:090:1 -32:1 0
ffff8800b2036540 963424792 S Ii:1:090:1 -115:1 16 <
ffff8800b2036540 963448864 C Ii:1:090:1 -32:1 0
ffff8800b2036540 963448880 S Ii:1:090:1 -115:1 16 <
/var/log/kernel
Oct 27 13:21:15 banunxcas29 kernel: [1017571.251514] hci2 urb
ffff8800b2036540 status -32 count 0
Oct 27 14:05:15 banunxcas29 kernel: [1020211.003086] hci2 urb
ffff8800b2036540 status -32 count 0
Oct 27 14:05:15 banunxcas29 kernel: [1020211.027178] hci2 urb
ffff8800b2036540 status -32 count 0
Thanks,
Naveen
On Thu, Oct 16, 2014 at 7:46 PM, Alan Stern <[email protected]> wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > It's entirely possible that the stall packets are created by the hub.
>> > When a full-speed device is connected to a USB-2 hub, and the device
>> > fails to respond to a packet sent by the host, the hub reports this
>> > failure as a stall.
>>
>> Here I don’t think device fails to respond to a packet sent by the
>> host. I verified this by connecting Ellisys USB analyser in between
>> host and devices.
>>
>> For example Look at the attached(Sample_HciEvt.png) HCI event captured
>> by Ellisys USB analyser. It is a valid HCI event from device to Host.
>> IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
>> 00 00 A9 EE 0F)
>> IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
>> 00 00 00 00 00)
>> IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
>> 8E 05 28 00 01)
>> IN transaction 96 1 ACK FS 1 byte (00)
>
> This doesn't prove anything. All it means is that the device responded
> properly on these four occasions. What if the device failed to respond
> on some other occasion? You have to compare the output of the analyzer
> with the output from usbmon. If usbmon shows a STALL and the analyzer
> shows a valid reply for the very same packet, then you'll know the
> device isn't at fault.
>
I forgot to post usbmon log, but usbmon shows a STALL and the analyser
shows a valid reply for the very same packet.
I tried this many number of times and always got same result.
But did not get STALL on OHCI-USB host controller on PCI card with
internal USB 1.1 hub. In both the scenario’s I used same devices.
> You should also run a similar test when you connect the device through
> a USB-2 hub. In fact, you should run two tests. In one test, connect
> the analyzer to the cable segment between the computer and the hub; in
> the other test, connect the analyzer to the cable segment between the
> hub and the device.
>
Ok, I will try and update you on this.
Thanks,
Naveen
Ok, I will do this and update you.
But Currently I am on long leave and I can update you on 27th Oct.
Thanks,
Naveen
On Thu, Oct 16, 2014 at 7:39 PM, Alan Stern <[email protected]> wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > Indeed. However, it is possible to use an additional in between your
>> > devices and the internal hub.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>>
>> Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
>> 10) and got the same result.
>>
>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>
>> |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
>>
>> |__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
>
> This is not what Oliver meant. You have to use a USB-2 hub. And
> having one of them is enough; you don't need two.
>
> Alan Stern
>
On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
> > It's entirely possible that the stall packets are created by the hub.
> > When a full-speed device is connected to a USB-2 hub, and the device
> > fails to respond to a packet sent by the host, the hub reports this
> > failure as a stall.
>
> Here I don’t think device fails to respond to a packet sent by the
> host. I verified this by connecting Ellisys USB analyser in between
> host and devices.
>
> For example Look at the attached(Sample_HciEvt.png) HCI event captured
> by Ellisys USB analyser. It is a valid HCI event from device to Host.
> IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
> 00 00 A9 EE 0F)
> IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
> 00 00 00 00 00)
> IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
> 8E 05 28 00 01)
> IN transaction 96 1 ACK FS 1 byte (00)
This doesn't prove anything. All it means is that the device responded
properly on these four occasions. What if the device failed to respond
on some other occasion? You have to compare the output of the analyzer
with the output from usbmon. If usbmon shows a STALL and the analyzer
shows a valid reply for the very same packet, then you'll know the
device isn't at fault.
You should also run a similar test when you connect the device through
a USB-2 hub. In fact, you should run two tests. In one test, connect
the analyzer to the cable segment between the computer and the hub; in
the other test, connect the analyzer to the cable segment between the
hub and the device.
Alan Stern
On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
> > Indeed. However, it is possible to use an additional in between your
> > devices and the internal hub.
> >
> > Regards
> > Oliver
> >
> >
>
>
> Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
> 10) and got the same result.
>
> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>
> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>
> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>
> |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
>
> |__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
This is not what Oliver meant. You have to use a USB-2 hub. And
having one of them is enough; you don't need two.
Alan Stern
On Thu, Oct 16, 2014 at 2:45 PM, Oliver Neukum <[email protected]> wrote:
>
> On Wed, 2014-10-15 at 12:11 -0400, Alan Stern wrote:
> > > If the hub is the problem… what will be the better solution? Is it
> > > possible to change internal hub?
> >
> > No, it is not possible.
>
> Indeed. However, it is possible to use an additional in between your
> devices and the internal hub.
>
> Regards
> Oliver
>
>
Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
10) and got the same result.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
|__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
|__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
|__ Port 1: Dev 11, If 0, Class=vend., Driver=, 12M
|__ Port 2: Dev 12, If 0, Class=vend., Driver=, 12M
|__ Port 3: Dev 13, If 0, Class=vend., Driver=, 12M
|__ Port 4: Dev 14, If 0, Class=vend., Driver=, 12M
|__ Port 5: Dev 15, If 0, Class=vend., Driver=, 12M
|__ Port 6: Dev 16, If 0, Class=vend., Driver=, 12M
|__ Port 7: Dev 17, If 0, Class=hub, Driver=hub/2p, 12M
|__ Port 1: Dev 21, If 0, Class=vend., Driver=, 12M
|__ Port 2: Dev 22, If 0, Class=vend., Driver=, 12M
|__ Port 2: Dev 5, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 2: Dev 5, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 2: Dev 5, If 2, Class=app., Driver=, 12M
|__ Port 3: Dev 6, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 6, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 6, If 2, Class=app., Driver=, 12M
|__ Port 4: Dev 7, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 7, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 7, If 2, Class=app., Driver=, 12M
|__ Port 5: Dev 8, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 5: Dev 8, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 5: Dev 8, If 2, Class=app., Driver=, 12M
|__ Port 6: Dev 9, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 6: Dev 9, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 6: Dev 9, If 2, Class=app., Driver=, 12M
|__ Port 7: Dev 10, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 1: Dev 18, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 1: Dev 18, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 1: Dev 18, If 2, Class=app., Driver=, 12M
|__ Port 2: Dev 19, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 2: Dev 19, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 2: Dev 19, If 2, Class=app., Driver=, 12M
|__ Port 3: Dev 20, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 3: Dev 20, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M
|__ Port 3: Dev 20, If 2, Class=app., Driver=, 12M
On Wed, 2014-10-15 at 12:11 -0400, Alan Stern wrote:
> > If the hub is the problem… what will be the better solution? Is it
> > possible to change internal hub?
>
> No, it is not possible.
Indeed. However, it is possible to use an additional in between your
devices and the internal hub.
Regards
Oliver
> It's entirely possible that the stall packets are created by the hub.
> When a full-speed device is connected to a USB-2 hub, and the device
> fails to respond to a packet sent by the host, the hub reports this
> failure as a stall.
Here I don’t think device fails to respond to a packet sent by the
host. I verified this by connecting Ellisys USB analyser in between
host and devices.
For example Look at the attached(Sample_HciEvt.png) HCI event captured
by Ellisys USB analyser. It is a valid HCI event from device to Host.
IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
00 00 A9 EE 0F)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
00 00 00 00 00)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
8E 05 28 00 01)
IN transaction 96 1 ACK FS 1 byte (00)
Due to spurious stall packets , sometimes btusb driver is not
receiving this full event , instead it got STALL packet instead of
first 16 bytes plus rest of other 33 bytes.
> When the device is connected to an OHCI controller, such failures would
> be reported in a different way, such as a -EPROTO or -EILSEQ status.
>
I did not observed -EPROTO or -EILSEQ status in OHCI controller scenario.
Thanks,
Naveen
On Wed, 15 Oct 2014, Naveen Kumar Parna wrote:
> Hi Oliver,
>
> I tried this test in two different set of hardware configurations.
>
>
>
> i) I tried in multiple test systems which has
> EHCI-USB host controller on PCI card and internal USB 2.0
> hub("rate-matching" hub). All the test systems with this configuration
> gives spurious stall packets.
>
> [lowerlayers@banunxcas29 ~]$ lspci | grep -i usb
>
> 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
> USB2 Enhanced Host Controller (rev 05)
>
> 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
> USB2 Enhanced Host Controller (rev 05)
>
>
> lsusb:
>
> Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
>
> Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
>
>
>
> ii) I found different test systems which has
> OHCI-USB host controller on PCI card and internal USB 1.1 hub. All the
> test systems with this configuration are not producing stall packets.
>
> [lowerlayers@camunxcas11 ~]$ lspci | grep -i usb
>
> 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
>
> 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
>
>
> lsusb:
>
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
> Bus 002 Device 002: ID 0451:2077 Texas Instruments, Inc. TUSB2077 Hub
>
>
>
>
> My device is a full-speed device. So , stall packets are due to buggy
> USB 2.0 hub?
It's entirely possible that the stall packets are created by the hub.
When a full-speed device is connected to a USB-2 hub, and the device
fails to respond to a packet sent by the host, the hub reports this
failure as a stall.
When the device is connected to an OHCI controller, such failures would
be reported in a different way, such as a -EPROTO or -EILSEQ status.
> Is there a chance of getting stall packets “If the device runs at low
> speed or full speed and is connected through a USB-2.0 hub”? If so it
> looks like hub driver issue right?
If the problem is that the device fails to respond to a packet then it
is an issue with the device.
> If the hub is the problem… what will be the better solution? Is it
> possible to change internal hub?
No, it is not possible.
Alan Stern
Hi Oliver,
I tried this test in two different set of hardware configurations.
i) I tried in multiple test systems which has
EHCI-USB host controller on PCI card and internal USB 2.0
hub("rate-matching" hub). All the test systems with this configuration
gives spurious stall packets.
[lowerlayers@banunxcas29 ~]$ lspci | grep -i usb
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
lsusb:
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ii) I found different test systems which has
OHCI-USB host controller on PCI card and internal USB 1.1 hub. All the
test systems with this configuration are not producing stall packets.
[lowerlayers@camunxcas11 ~]$ lspci | grep -i usb
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
lsusb:
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0451:2077 Texas Instruments, Inc. TUSB2077 Hub
My device is a full-speed device. So , stall packets are due to buggy
USB 2.0 hub?
Is there a chance of getting stall packets “If the device runs at low
speed or full speed and is connected through a USB-2.0 hub”? If so it
looks like hub driver issue right?
If the hub is the problem… what will be the better solution? Is it
possible to change internal hub?
Thanks,
Naveen
On Wed, Oct 15, 2014 at 6:39 PM, Naveen Kumar Parna
<[email protected]> wrote:
> EHCI controller on PCI card and hub("rate-matching" hub) also internal.
>
> Is it possible to change the internal hub?
>
>
>
> Thanks,
> Naveen
>
> On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum <[email protected]> wrote:
>> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>>
>>> > Hi Oliver & Alan,
>>> >
>>> >
>>> >
>>> > Thanks for your inputs.
>>> >
>>> >
>>> >
>>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>>> > if I am wrong.
>>>
>>> Debugging the kernel (or doing anything else to the kernel, for that
>>> matter) won't solve the problem if it is caused by a buggy hub.
>>
>> Indeed. Could you just try a different hub?
>>
>> Regards
>> Oliver
>>
>>
>>
EHCI controller on PCI card and hub("rate-matching" hub) also internal.
Is it possible to change the internal hub?
Thanks,
Naveen
On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum <[email protected]> wrote:
> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>
>> > Hi Oliver & Alan,
>> >
>> >
>> >
>> > Thanks for your inputs.
>> >
>> >
>> >
>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>> > if I am wrong.
>>
>> Debugging the kernel (or doing anything else to the kernel, for that
>> matter) won't solve the problem if it is caused by a buggy hub.
>
> Indeed. Could you just try a different hub?
>
> Regards
> Oliver
>
>
>
On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>
> > Hi Oliver & Alan,
> >
> >
> >
> > Thanks for your inputs.
> >
> >
> >
> > I enabled the dynamic debugging for USB HC driver. Please correct me
> > if I am wrong.
>
> Debugging the kernel (or doing anything else to the kernel, for that
> matter) won't solve the problem if it is caused by a buggy hub.
Indeed. Could you just try a different hub?
Regards
Oliver