I’m wondering if anyone else is running openSUSE with an Astro Mixamp TR
A40 USB headset.
On 42.2, it worked perfectly fine.
On 42.3 an 15.0, I’m seeing random USB disconnects while using them. If
I restart the mixamp (it’s a USB-powered mini-mixer that the headset
plugs into), it reconnects and works for a little bit (5-10 minutes,
usually), and then it disconnects again.
From dmesg:
[61811.011524] hid-generic 0003:9886:0018.0008: hiddev96,hidraw3: USB HID
v1.00 Device [Astro Gaming Astro MixAmp Pro] on usb-0000:00:14.0-4/input6
[83175.877935] [drm:si_dpm_set_power_state [radeon]] *ERROR*
si_restrict_performance_levels_before_switch failed
[84719.369856] usb 1-4: USB disconnect, device number 13
[84727.185888] usb 1-4: new high-speed USB device number 14 using xhci_hcd
[84727.317900] usb 1-4: device descriptor read/64, error -71
[84727.553860] usb 1-4: device descriptor read/64, error -71
[84727.789866] usb 1-4: new high-speed USB device number 15 using xhci_hcd
[84727.921847] usb 1-4: device descriptor read/64, error -71
[84728.161867] usb 1-4: device descriptor read/64, error -71
[84728.269845] usb usb1-port4: attempt power cycle
[84728.921808] usb 1-4: new high-speed USB device number 16 using xhci_hcd
[84728.942711] usb 1-4: New USB device found, idVendor=9886,
idProduct=0018
[84728.942713] usb 1-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[84728.942714] usb 1-4: Product: Astro MixAmp Pro
[84728.942715] usb 1-4: Manufacturer: Astro Gaming
[84728.946802] hid-generic 0003:9886:0018.0009: hiddev96,hidraw3: USB HID
v1.00 Device [Astro Gaming Astro MixAmp Pro] on usb-0000:00:14.0-4/input6
That error -71 is constant when it disconnects.
Not even really sure how to start troubleshooting it - I’ve been having
this issue for months, and working around it by plugging the headphones
directly into the headphone jack (bypassing the mixer), but I’d rather
have the Dolby audio.
I do share this device with a USB switch between multiple systems, but I
also have seen this beahviour while plugged directly into the PC’s USB
port, so the A-B-C USB switch I have doesn’t seem to be a factor (I
include it here just for completeness).
On Wed, 13 Feb 2019 23:56:03 +0000, malcolmlewis wrote:
> Hi Jim A protocol error…
>
> Code:
> --------------------
>
> cat /usr/include/asm-generic/errno.h | grep 71 #define EPROTO
> 71 /* Protocol error */
>
> --------------------
>
> So these are all USB 3.0 ports… Is the device firmware up to date?
Should be, yeah. The strange thing is that it worked previously in 42.2
without any issues.
Also works fine with my Mac (not that that proves/disproves anything,
obviously) and my PS4 (which uses an optical cable for part of the audio).
On Fri, 15 Feb 2019 02:16:04 +0000, malcolmlewis wrote:
> Hi Likely using ehci_hcd, to me it’s probably a bug with the driver and
> needs a quirk added to fix it…
I’ll dig down and see if that’s what it’s using - if it is, any pointers
on what the ‘quirck’ is or would be? (I’ve not heard that term before in
this context).
Hi
It’s a hack for USB devices that are well, ‘quirky’
/sbin/modinfo xhci_hcd | grep parm
parm: link_quirk:Don't clear the chain bit on a link TRB (int)
parm: quirks:Bit flags for quirks to be enabled as default (ullong)
systool -vm xhci_hcd | grep quirk
link_quirk = "0"
quirks = "0"
On Fri, 15 Feb 2019 17:06:03 +0000, malcolmlewis wrote:
> hendersj;2894619 Wrote:
>> On Fri, 15 Feb 2019 02:16:04 +0000, malcolmlewis wrote:
>>
>> > Hi Likely using ehci_hcd, to me it’s probably a bug with the driver
>> and
>> > needs a quirk added to fix it…
>>
>> I’ll dig down and see if that’s what it’s using - if it is, any
>> pointers on what the ‘quirck’ is or would be? (I’ve not heard that
>> term before in this context).
>>
> Hi It’s a hack for USB devices that are well, ‘quirky’
>
>
> Code:
> --------------------
>
> /sbin/modinfo xhci_hcd | grep parm
>
> parm: link_quirk:Don’t clear the chain bit on a link TRB
> (int) parm: quirks:Bit flags for quirks to be enabled as
> default (ullong)
>
> systool -vm xhci_hcd | grep quirk
>
> link_quirk = “0”
> quirks = “0”
>
> --------------------
>
>
> Have a look here;
> https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c
Cool, that’s helpful. Now to figure out which quirk to enable -
confirmed that it is plugged into a USB 3.0 port (I’d moved it around a
bit, and while I see the same behaviour on USB 2.0, if this gets it going
on USB 3.0, that’s cool.)
So, strangely, I can fix the protocol errors (I found something that
suggested using “old_scheme_first” as part of usbcore, and now the
protocol errors don’t appear.
But the audio still gets stuck - so, for example, when I’m playing Youtube
videos, eventually the audio stops, and the Youtube player spins and
hangs up until I turn the device off and back on.
So still something weird going on, and the protocol error seems to be
hiding it. Now I need to dig deeper to determine what the actual root of
the problem is.
