Driver problem with USB chipset VIA VL812-B2

Bug #1425803 reported by Warren
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Triaged
High
Unassigned

Bug Description

Presuming the system info you need is in the automatically generated collection from ubuntu-bug. Ubuntu 14.10, fully updated. Kernel 3.16.0-31-generic.

The problem described also exists in earlier kernels although I cannot say when it first appeared.

I have a HooToo HT-UH005 4-Port USB 3.0 hub (VIA VL812-B2 chipset) . I'm using it with a HP Pavilion 17-e049wm laptop. This computer has two USB 3.0 ports.

When the computer is quiescent the CPU consumed is normally 0% to 1%. That's the same whether there are USB 2.0 or 3.0 devices plugged into its onboard USB 3.0 ports, or not.

As soon as I plug the HT-UH005 hub into one of those USB 3.0 ports, a system process khubd appears and it takes about 7% of CPU. Also, several "kworker" and "ksoftirqd" threads appear which between them consume another 18% of CPU, for a total of 25% CPU load. That's just because the HT-UH005 was plugged in. No peripherals attached to the HT-UH005.

Stranger still, when I unplug the HT-UH005 the khubd, kworker, and ksoftirqd threads *continue* to consume 25% CPU. That's with the HT-UH005 disconnected after it was previously connected. This goes on indefinitely. The only way I can get things back to normal is to reboot or to manually stop and restart (unbind and then bind) the xhci_hcd driver that's servicing the internal hub that runs the computer's two USB 3.0 ports.

The listing from dmesg shows no apparent problems when the HT-UH005 is connected or disconnected. Listing from lsusb shows the HT-UH005 successfully connected to a port on the internal USB 3.0 hub using driver xhci_hcd.

This could be caused by some sort of incompatibility between the AMD internal hub and the VIA external hub. But, that the condition persists after the HT- UH005 is disconnected suggests it is almost surely a linux driver problem.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-31-generic 3.16.0-31.41
ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5
Uname: Linux 3.16.0-31-generic x86_64
NonfreeKernelModules: wl fglrx
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: warren 5539 F.... pulseaudio
 /dev/snd/controlC0: warren 5539 F.... pulseaudio
CurrentDesktop: Unity
Date: Wed Feb 25 22:12:53 2015
HibernationDevice: RESUME=UUID=d6ce9a82-d272-4efa-bfe4-e13c883b2418
InstallationDate: Installed on 2012-05-23 (1008 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: Hewlett-Packard HP Pavilion 17 Notebook PC
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-31-generic root=UUID=515bfe03-1a57-4762-9cc1-6896e081c4c5 ro quiet splash rootfstype=ext4 vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-31-generic N/A
 linux-backports-modules-3.16.0-31-generic N/A
 linux-firmware 1.138.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/04/2013
dmi.bios.vendor: Insyde
dmi.bios.version: F.31
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1984
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 01.13
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsyde:bvrF.31:bd12/04/2013:svnHewlett-Packard:pnHPPavilion17NotebookPC:pvr0880100003305B10000620100:rvnHewlett-Packard:rn1984:rvr01.13:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP Pavilion 17 Notebook PC
dmi.product.version: 0880100003305B10000620100
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
Warren (wseverin) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → High
Revision history for this message
Warren (wseverin) wrote :

NB. Computer BIOS updated from F.31 to F.35. Apparently no effect on this problem.

Revision history for this message
Warren (wseverin) wrote :

NB. VL812-B2 chipset firmware updated from version 9081 to 9091. Apparently no effect on this problem.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.0 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-rc1-vivid/

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Warren (wseverin)
tags: added: kernel-bug-exists-upstream
Revision history for this message
Warren (wseverin) wrote :

The bug still exists in kernel 4.0rc1. Tag added as requested. Intallation was very problematic, but I was able to boot into terminal mode. (Lack of flgrx prevented usual environment...). "htop" confirms bug as before, although I was not able to view the offending process names. CPU at 0.1 to 0.5 percent before plugging in the USB 3.0 hub. Plug in the hub, CPU goes to 25%. Unplug the hub remains at 25%. Unbind and then bind the xhci_hcd driver from the internal USB 3.0 hub and CPU drops back to the expected 0.1 to 0.5 percent.

Revision history for this message
Warren (wseverin) wrote :

This bug occurs with more than just one chipset. For chuckles I picked up a 7-port USB 3.0 hub that uses GenesysLogic 3520 (maybe 3521) chipsets. *SAME PROBLEM*.

I can confirm that this problem occurs with more than just the VIA VL812-B2 chipset. How many different chipsets, who knows. The VIA and GenesysLogic chipsets are the most popularly used for external hubs. It may well be the case that the xhci_hcd does not well handle the situation of USB 3.0 external hubs plugged into USB 3.0 internal hubs on a wide level. Probably the title of this bug report should be changed.

It smells like when an external USB 3.0 hub is plugged into the port of an internal USB 3.0 hub, the khubd process goes into spinlock and never comes out.

Revision history for this message
Warren (wseverin) wrote :

In scouring the internet I have found references to similar matter with bsd. Seems maybe the xhci driver folks maybe haven't quite got around to supporting non-root USB 3.0 hubs.
http://netbsd.2816.n7.nabble.com/Help-USB-3-0-xHCI-driver-does-not-support-non-root-hub-td308329.html

Warren (wseverin)
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

Warren, could you please test the latest mainline kernel 4.0-rc2 and advise to the results?

tags: added: bios-outdated-f.35
removed: 3.0 hub usb
tags: added: latest-bios-f.35 latest-firmware
removed: bios-outdated-f.35
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Warren (wseverin) wrote :

Kernel 4.0-rc2 tested. Problem remains.

In rc2 there was a minimal fglrx driver in the kernel so I was able to get a more usual desktop and use the graphical system monitor app. The manifestation of the problem is slightly different now. Total CPU usage still goes to 24 - 25% when a USB 3.0 hub is plugged in, but the khubd process does not seem to take excessive CPU time. Instead, the kworker and ksoftirqd processes take it all up. The kworker thread(s) take in total about 17% and the ksoftirqd thread(s) about 7%.

The problem remains the same in all other aspects. It is present with hubs using the VIA or Genesyslogic chipsets. Excessive CPU usage continues even after the external hubs are disconnected. The cure remains to unbind and then bind the xhci_hcd driver serving the internal USB 3.0 hub.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

Warren, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (linux-usb) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

tags: added: kernel-bug-exists-upstream-4.0-rc2
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Warren (wseverin) wrote :
Revision history for this message
Warren (wseverin) wrote :

Have just tested and bug exists in upstream 4.0-rc3. Notation left at upstream reporting point.

tags: added: kernel-bug-exists-upstream-4.0-rc3
removed: kernel-bug-exists-upstream-4.0-rc2
Revision history for this message
Warren (wseverin) wrote :

Not seeing a lot of value so far to submitting this upstream. Not even an acknowledgment, let alone triage or action. I subscribed to the Linux-usb thread and there seems to be no tracking system, no actual process what-so-ever. It's just talented people running around in 50 different directions trying to solve problems with no apparent coordinationor or methodology, exchanging a lot of email over the thread. God help us.

Revision history for this message
Dave Chiluk (chiluk) wrote :

@Warren,

Has this been resolved yet in upstream? *(I'm asking for selfish reasons as I almost just bought one of these).

Also if this still exists on the GenesysLogic 3520 (maybe 3521) hub that would likely require a separate change and as such should be a separate bug.

Revision history for this message
Dave Chiluk (chiluk) wrote :

"VIA Labs, Inc. (one of the largest manufacturers of USB 3.0 hub chipsets on the market) does not make an update program for Apple Mac OS X or Linux/Unix. "

Vote with your wallets people.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.