Linux host (running Client) halts when USB audio device is selected

4 posts / 0 new
Last post
servernoj
Linux host (running Client) halts when USB audio device is selected

Hello,

I am running USB Server on RasPi2 and Client part on Ubuntu Mate 15.04 64-bit (with latest updates). I have an old (purchased about 10 years ago, no docs, no nothing) USB audio adapter that normally is plugged into Ubuntu host as the main audio device.

I played with USB Server running on Pi2 with USB keypad (wireless keyboard + touchpad with USB dongle) attached and it worked like a charm. I used GUI Linux client running on Ubuntu with root privilege and was able to use that USB keypad to control Ubuntu desktop.

I then plugged USB audio into Pi2 (after closing previous session and rebooting Pi2) and attempted to attach Ubuntu box into it following the same path. When I selected "USB Audio" in the list of devices displayed in Linux GUI client, my Ubuntu box halted. Actually it got frozen: monitor was showing the last screen, it did not react to keyboard and mouse. I could no longer control it and had to shutdown it by pressing power button for a number of seconds.

I repeated this experiment several time (Pi2 has also been restarted every time) and it was consistent.

I don't have much of experience in debugging such situations. My best guess was to look at syslog file just before it started the new session. The last things that I can see there are enclosed below:

Oct 17 22:30:55 ocean dbus[714]: [system] Activating service name='org.mate.SettingsDaemon.DateTimeMechanism' (using servicehelper)
Oct 17 22:30:55 ocean dbus[714]: [system] Successfully activated service 'org.mate.SettingsDaemon.DateTimeMechanism'
Oct 17 22:31:14 ocean kernel: [ 61.068468] usbip_core: USB/IP Core v1.0.0
Oct 17 22:31:14 ocean kernel: [ 61.073173] vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
Oct 17 22:31:14 ocean kernel: [ 61.073181] vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 3
Oct 17 22:31:14 ocean kernel: [ 61.075956] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
Oct 17 22:31:14 ocean kernel: [ 61.075962] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Oct 17 22:31:14 ocean kernel: [ 61.075965] usb usb3: Product: USB/IP Virtual Host Controller
Oct 17 22:31:14 ocean kernel: [ 61.075969] usb usb3: Manufacturer: Linux 3.19.0-26-generic vhci_hcd
Oct 17 22:31:14 ocean kernel: [ 61.075971] usb usb3: SerialNumber: vhci_hcd
Oct 17 22:31:14 ocean kernel: [ 61.076398] hub 3-0:1.0: USB hub found
Oct 17 22:31:14 ocean kernel: [ 61.076420] hub 3-0:1.0: 8 ports detected
Oct 17 22:31:14 ocean kernel: [ 61.076788] vhci_hcd: USB/IP 'Virtual' Host Controller (VHCI) Driver v1.0.0
Oct 17 22:31:14 ocean systemd[1]: Starting Stop ureadahead data collection...
Oct 17 22:31:14 ocean systemd[1]: Stopped Read required files in advance.
Oct 17 22:31:14 ocean systemd[1]: Started Stop ureadahead data collection.

I could re-run experiment to retrieve some other logs if needed.

Is there anything that I can do to setup USB server/client to make it compatible with my USB audio? Thank you.

Michael
If it locks its definitely a

If it locks its definitely a kernel bug, seems you are using 3.19-026, try something 4+

If that doesnt work, waiting for the linux kernel to be fixed by a kernel developer is the only option...

servernoj
Why then this USB audio

Why then this USB audio adapter works when it is "normally" plugged into a USB socket on the same host? Can it be somehow sourced by improper configuration of Pi2 (it reports 4.1-xx kernel when I run "uname -a" but when I try to install "linux-headers" package it shows only installation candidates for 3.xx kernel)? That Pi2 is running on the latest Raspbian Jessie v8.0 and here is what uname -a returns:

Linux ra 4.1.10-v7+ #821 SMP PREEMPT Sat Oct 10 00:16:28 BST 2015 armv7l GNU/Linux

To be honest, time to time when this USB audio is plugged into Ubuntu host it (the Ubuntu box) hangs with the same symptoms. Up till now I thought it was caused due to overheating because it is a fan-less unit from a purely recognized vendor called Shuttle (http://www.shuttle.eu/products/slim/xs36v4/) and usually it happened when I used it to watch multimedia content. Is there any way to test that tproblem is really caused by that USB audio adapter?

Michael
No you dont need to update

No you dont need to update the pi, its the kernel of the client. Looks like you cannot update that if its from a commercial vendor. What is probably happening is that the kernel driver is suspending "interrupts" while it reads the audio and then the interrupts are not reenabled. Usually with linux if its a memory error it will panic the kernel at some point soon after.

When the usb is directly plugged into the host its using different usb drivers in the kernel, however you are noticing that even plugging the device in directly to the USB socket, the kernel locks sometimes with that device, so there is definately a bug in the kernel.

The kernel should never lock, it should return an error if it doesnt like what the device is returning...

Log in or register to post comments