Fixing Motherboard Audio/USB Problems (Ubuntu)
Have you ever purchased a faulty motherboard? Is your OS causing you hardware grief? Did you decide the pain of workarounds was a better alternative to addressing your problems, so you put it off until that last "my tower ceased to recognise my microphone in the middle of a meeting" straw?
I knew I had a USB issue when my mouse stopped working. My HD audio jacks would not recognise jack (hehe). Hell, even the bloody motherboard cover would not fit to the case properly. I have included a picture of the culprit for easier identification.
Figure 1. Front panel USB/HD audio ports
Most of my gratitude goes to this thread. I go right to the solution in this piece, so if you prefer a deeper dive check that out after. First, let's check the kernel logs which will tell us what hardware is nagging us.
Aside: yes, this is in markdown syntax. I am hoping one day I will have the energy to format code in Blogger properly. Suggestions welcomed.
```
dmesg --follow
[ 6878.058968] hub 1-4.3:1.0: hub_ext_port_status failed (err = -110)
[ 6892.010955] usb 2-4.1: Failed to suspend device, error -110
[ 8581.101134] usb 1-3: device descriptor read/8, error -110
[ 8581.209035] usb usb1-port3: unable to enumerate USB device
```
So definitely a USB issue. Specifically, I am having issues with my front panel, so I will run `lsusb -t` twice, once with something plugged into a front panel USB port and once without.
```
# With
engi@rock ~ % lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid [shortened]
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 3, If 5, Class=Communications, Driver=cdc_ncm, 5000M [shortened]
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
|__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1M [shortened]
# Without
engi@rock ~ % lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M [shortened]
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
```
Bus 01 and Bus 02 show no devices once I have disconnected everything from the front panel. I will re-register these.
Extra fact: Bus 01 is USB 2.0 (see 480M) and Bus 02 is USB 3.0 (see 10000M). Looking at my front panel, I can see one black (2.0) and one blue (3.0) USB port. I can also confirm this with the tower manual.
Let's start with bus 01. We need two things
- Bus driver type (varies between USB 1.1, 3.0, etc...)
- Root hub address
1. I can see above that the driver for Bus 01 is Driver=xhci_hcd
2. We want the root hub address for Bus 01:Port 01, so below we will use 01:01. If you want bus 2:port 1, use 02:01, etc... Only the bus number (left of colon) should change, you will always use port 1 because it is always the root hub for that bus.
```
engi@rock ~ % sudo sh # you are now entering the all-powerful sudo state. <insert typical admin warning>
# lsusb -v -s 01:01 | grep iSerial
can't get device qualifier: Resource temporarily unavailable # ignore
can't get debug descriptor: Resource temporarily unavailable # ignore
iSerial 1 0000:03:00.0
```
Our root hub address is 0000:03:00.0. While still in sudo-land, let's re-register it. Notice, I use driver/xhci_hcd/bind. Replace xhci_hcd with your driver.
```
# echo -n "0000:03:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
# echo -n "0000:03:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
```
Let's check the kernel logs
```
engi@rock ~ % dmesg --follow
[ 8608.297399] xhci_hcd 0000:03:00.0: USB bus 1 deregistered
[ 8679.324123] xhci_hcd 0000:03:00.0: xHCI Host Controller
[ 8679.324131] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 1
[ 8679.379477] xhci_hcd 0000:03:00.0: hcc params 0x0200ef81 hci version 0x110 quirks 0x0000000000000410
[ 8679.379716] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[many more "X detected" things below. Yay!]
```
Not only does my mouse work, but for the first time ever so do my front panel HD audio ports. The spammy error -110 kernel logs are also gone. Huzzah!
[Update 20210301]
I was getting frustrated by inputting the tedious manual fix every time this happen, so I wrote a cronjob to check system logs every minute for the error message.
```
engi@rock ~ % sudo vim /usr/local/bin/usbfix
#!/bin/bash
FILE="/var/log/kern.log"
PROBLEM="error -110"
NTAIL=10 # should be smaller to avoid re-detecting same PROBLEM
reset_usb() {
sudo sh -c 'echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/unbind'
sleep 2
sudo sh -c 'echo -n "0000:03:00.0" > /sys/bus/pci/drivers/xhci_hcd/bind'
}
check_file() {
tail -$NTAIL $FILE | while read line; do
if [[ $line == *"$PROBLEM"* ]]; then
echo "Problem found in kernel logs: $PROBLEM. Resetting" | sudo tee /dev/kmsg
reset_usb
exit 0
fi
done
echo "Checked dmesg for usb issue" | sudo tee /dev/kmsg
}
check_file
```
This code is checking the last 10 lines in your kernel log and looking for the string "error -110". If found, it runs the fix. Every time the script is called, it will print once to your kernel logs. To call this script on a 1-minute-period loop.
```
engi@rock ~ % sudo crontab -e
*/1 * * * * /usr/local/bin/usbfix
```
Use sudo crontab -l to check it saved properly. To watch kernel logs: `dmesg -wH`. You should see:
Comments
Post a Comment