It does suggest to me that the xhci_hcd driver may not be setting up MSI or MS-X interrupts properly, but I’m at the limits of my knowledge here, and way off target. Hopefully, a kernel developer will be able to identify the problem via a bug report.
A quick update: it seems the problem stems from the power control of the xhci-hcd driver, which, on battery, puts the USB on “suspend” and waits for ACPI to wake them up. It appears that ACPI does not do so, so the USB ports stay suspended for ever (until AC is plugged and USB starts working properly).
A temporary workaround is:
echo on > /sys/bus/pci/devices/0000\:00\:14.0/power/control
but it gets overridden every time the AC is plugged on/off.
If a more permanent workaround is find or a proper fix is released, I’ll try to remember and mention it there.
If a more permanent workaround is find or a proper fix is released, I’ll try to remember and mention it there.
The kernel power management for USB documentation might be relevant here. In particular
power/autosuspend_delay_ms
This file contains an integer value, which is the
number of milliseconds the device should remain idle
before the kernel will autosuspend it (the idle-delay
time). The default is 2000. 0 means to autosuspend
as soon as the device becomes idle, and negative
values mean never to autosuspend. You can write a
number to the file to change the autosuspend
idle-delay time.
Writing “-1” to power/autosuspend_delay_ms and writing “on” to
power/control do essentially the same thing – they both prevent the
device from being autosuspended. Yes, this is a redundancy in the
API.
So, I wonder if disabling autosuspend might do the trick here? Either by adding the following boot parameter to grub
usbcore.autosuspend=-1
or by using a custom file in /etc/modprobe.d/ eg /etc/modprobe.d/30-autosuspend.conf with
The kernel devs want me to rebuild the kernel with a patch to test whether it fixes my issue, but I don’t know how to do that. Could someone guide me though it? Would it be possible on OBS?
Hm… The kernel compiled, with the patch, but I can’t, for the hell of me manage to download the package. The publish flags are ON and build succeeded, but when I click on “Download package” I get “No data for kernel-default”. Anyone knows what is happening?
Hi
Until all the builds are finished, the package won’t publish, so disable the arm builds, else use osc to grab the binaries or finally look on this page (make sure your logged into OBS);
I’ve managed to download the package and install it, but now when booting, grub is angry and says kernel “has invalid signature”. I guess it does, since it’s not the official oS build, and I’m happy GRUB won’t let any piece of junk boot on my PC, but right now, this is MY junk that I’m trying to boot on!
Any idea about how to make GRUB more understanding? Sorry I’m being all noob about this…
The patch is in the file “pci.c.diff” and is applied in “kernel-default.spec” at line 461.
Yes, I just figured that out. Stupid me… Quite obvious wasn’t it?
OK, so, I managed to get it boot and the patch did indeed fix the issue!! I’ll let the devs know! \o/
(What a shame that ASUS won’t fix the firmware though… They basically replied that they don’t support Linux, even though their firmware is obviously faulty… Typical!)
Hi
You need to raise an openSUSE bug and ask if the fix can be backported otherwise you may need to run Kernel:HEAD if it’s included upstream, or keep patching/building the kernel…
Yes, I was wondering about that… It’s not really for me (starting the kernel with usb.autosuspend=-1 does the trick, whatever the kernel version), but in case other people are having the same issue.
