it just freezes, I waited and clicked some keys, nothing, googling around made me know that `bcma-pci-bridge` is the wi-fi chip, but I couldn't find anyone facing the same problem, I even tried a different USB stick, same issue
Edit: this guy seems to have a similar issue but with ubuntu
]]>is it possible to boot into tty without nomodeset? if yes can you be so kind to share your kernel parameters, /etc/mkinitcpio.conf, and /etc/modprobe.d?
i can only boot into tty with nomodeset
fresh install on macbook pro 11,2 mid-2014, 5.8.5-arch1-1
managed to boot with linux-lts
]]>i can only boot into tty with nomodeset
fresh install on macbook pro 11,2 mid-2014, 5.8.5-arch1-1
]]>Codec: Cirrus Logic CS4208
]]>Hi all,
I recently upgraded to kernel 4.17.2-1.
I use to have "acpi_osi=" kernel parameter following wiki page. And up to 4.17 kernel it was effective to reduce power consumption.
With the upgrade to kernel 4.17 the acpi power got broken and I was not able to get battery recognized by the system.
Deleting "acpi_osi=" kernel parameter fixes the issue but the power consumption goes up.
Anybody had the same problem? If so did anybody found a solution?
Thanks
Ciao
Gianluca
Same thing here with a MacBook pro 2015 Retina
]]>Hi all,
I recently upgraded to kernel 4.17.2-1.
I use to have "acpi_osi=" kernel parameter following wiki page. And up to 4.17 kernel it was effective to reduce power consumption.
With the upgrade to kernel 4.17 the acpi power got broken and I was not able to get battery recognized by the system.
Deleting "acpi_osi=" kernel parameter fixes the issue but the power consumption goes up.
Anybody had the same problem? If so did anybody found a solution?
Thanks
Ciao
Gianluca
Hi Gianluca!
yes I have the exact same problem. I am running Arch on a Macbookair and had the acpi_osi Parameter. Battery was around 10-11h.
After the recent update I coulndt suspend anymore, had no Battery status and my Battery was around 5-7h without acpi_osi.
I hope someone can explain or fix this issue.
regards
]]>I recently upgraded to kernel 4.17.2-1.
I use to have "acpi_osi=" kernel parameter following wiki page. And up to 4.17 kernel it was effective to reduce power consumption.
With the upgrade to kernel 4.17 the acpi power got broken and I was not able to get battery recognized by the system.
Deleting "acpi_osi=" kernel parameter fixes the issue but the power consumption goes up.
Anybody had the same problem? If so did anybody found a solution?
Thanks
Ciao
Gianluca
I've been using Arch on my MBP for about 6 months and never had xhci_hcd timeout issue until a about two weeks ago. Since then the MBP erratically has a long pre-bootloader lag (~20 secs; I'm using systemd) and then there is no mouse or keyboard input and a few seconds latermy SDDM screen will freeze. I can change into another shell and reboot. Although shutting down tends to get a better chance of correctly booting.
When the pre-boot lags, I will get the following errors in dmesg.
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
usb 2-3: device not accepting address 4, error -62
I'm using 4.15.15-1-ARCH .
The latest changes I made, was attaching an external HDMI monitor and an USB hub for mouse, keyboard and wifi.
Is anybody else seeing these issues?
Thanks in advance
]]>plech.d wrote:Hi all.
I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.
Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.
(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)
Thanks for any comments!
Just popping in to confirm that it indeed works fine off the live USB from Feb 2018 (kernel 4.14.15.1) (systemctl suspend, wait a moment, then press power button, wakeup is immediate).
So I did some experiments on a clean installation without X (just after following installation guide and rebooting). Here are suspend/resume times in between kernel upgrades under the same conditions each time. I closed the lid and opened it again immediately after the logo light went off. The times are in between the last and the first entries in journalctl:
4.14.15: around 22 secs
4.15.1: around 30 secs
4.15.2: around 45 secs.
Downgrading the kernel back to the previous versions restored the same, faster resume times.
I don’t know what happened, but it sucks, because in the newest kernels resume is almost unusably slow.
]]>Hi all.
I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.
Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.
(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)
Thanks for any comments!
Just popping in to confirm that it indeed works fine off the live USB from Feb 2018 (kernel 4.14.15.1) (systemctl suspend, wait a moment, then press power button, wakeup is immediate).
]]>I have a problem with suspend / resume, suddenly it's taking eons to wake up (at least about a minute and a half). I thought it was somehow related to my setup, but I tried it directly on the 1st of March live USB (typed in systemctl suspend), waited for the fans to stop, pressed the power button, then had to wait for at least a minute.
Anyone else experiencing the problem? In the meantime, I'll try it on two older live USB's (Jan, Feb 2018), just to verify.
(By the way, I also use apple_set_os.efi + gpu-switch + outb's in grub menuentry + program to shut down gpu, and if and when I run the program to shut down the gpu and then suspend, wakeup doesn't happen at all after that, ever. However, I don't want to relate that necessarily to what I wrote above, because this is a specific hack. What I wrote above applies generally, like I said, even right off the live USB.)
Thanks for any comments!
]]>commit a062cb39594667bd3953f71cbcf7e0b276998f56
Author: Guenter Roeck <linux@roeck-us.net>
Date: Thu Mar 9 15:39:37 2017 +0200
usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers
commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 upstream.
Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
xhci controllers which can result in excessive timeouts, to the point where
the system reports a deadlock.
The same problem is seen with hot pluggable xhci controllers using the
xhci-plat driver, such as the driver used for Type-C ports on rk3399.
Similar to hot-pluggable PCI controllers, the driver for this chip
removes the xhci controller from the system when the Type-C cable is
disconnected.
The solution for PCI devices works just as well for non-PCI devices
and avoids the problem.
EDIT:
Seems issue was fixed in 4.12.4, commit a54408d0a004757789863d74e29c2297edae0b4d
See changelog
I do not experience this issue anymore. But not using Arch as main OS now, but I will try to switch on it again.