FS#46745 - [linux] Freeze on "Triggering uevents..." with AMD

Attached to Project: Arch Linux
Opened by Andrew Porter (link_the_programmer) - Thursday, 15 October 2015, 23:36 GMT
Last edited by Jan de Groot (JGC) - Tuesday, 17 October 2017, 12:34 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description: When booting Arch Linux 10.1-dual (I used x86_64, on laptop Toshiba Satellite C855D), linux freezes on "Triggering uevents...". This apparently is an AMD Radeon Driver problem. Evidence for this is at https://bbs.archlinux.org/viewtopic.php?pid=1193312#p1193312. Apparently this has been a problem for a long time. Suggests that this bug happens on any architecture that is using Radeon graphics.


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
Boot Arch Linux 10.1-dual onto an AMD Radeon HD-based computer ->
frozen cursor and system after "Triggering uevents", nothing special happens.
This task depends upon

Closed by  Jan de Groot (JGC)
Tuesday, 17 October 2017, 12:34 GMT
Reason for closing:  No response
Comment by Andrew Porter (link_the_programmer) - Friday, 16 October 2015, 10:38 GMT
should note this happened booting off of live usb with Rufus, then again usbwriter.
Comment by Andrew Porter (link_the_programmer) - Friday, 16 October 2015, 10:44 GMT
with loglevel=7 on kernel parameters, I noticed the last trigger was consistently WMI 95% of the time. acpi_backlight=vendor parameter somehow lets Arch Linux boot normally so here I am following the normal procedures and getting ready to wipe my Windows 10 drive and replace with Arch :)
Comment by Andrew Porter (link_the_programmer) - Friday, 16 October 2015, 10:46 GMT
acpi=off was a partial fix, and for a long time people used nomodeset for a "solution" to the problem, which on modern radeon does not work. acpi=off allowed me to boot into [rootfs] with some commands working.
Comment by Andrew Porter (link_the_programmer) - Friday, 16 October 2015, 20:55 GMT
acpi=off was a partial fix, and for a long time people used nomodeset for a "solution" to the problem, which on modern radeon does not work. acpi=off allowed me to boot into [rootfs] with some commands working.
Comment by Wilhelm Schuster (wlhlm) - Wednesday, 27 January 2016, 17:39 GMT
I have the same issue. It occurred after upgrading the mainboard of my desktop to one with integrated radeon graphics (Gigabyte MA785GM-US2H with AMD 785G chipset).

Workaround for me has been: adding "debug" to the kernel command line on boot ("acpi=off" as described by link_the_programmer also worked). "nomodeset" and "modeprobe.blacklist=radeon" as expected did not fix the hang.

This still happens with kernel 4.3
Comment by Britt Yazel (brittyazel) - Thursday, 04 February 2016, 08:34 GMT
I believe I too suffer from this bug. I have both Radeon r9 290 graphics and also an FX series chipset. Every 2-3 boots or so I can get to a working desktop, but it is extremely annoying. It makes my computer feel like a car that won't start.
Comment by Britt Yazel (brittyazel) - Thursday, 04 February 2016, 08:45 GMT
I can confirm that adding "debug" to my kernel boot options seems to get me into a bootable state thus far (5 boots in a row). However, I hate the way my boot process looks now. It looks like it could induce a seizure. Hopefully we can get back to normal soon.

Issue is still present in Kernel 4.4.1
Comment by Britt Yazel (brittyazel) - Thursday, 04 February 2016, 08:56 GMT
Do you guys have either gigabyte motherboards and DVD burners connected through SATA? I do, and this bug seems to fit my symtpoms:
https://bugzilla.kernel.org/show_bug.cgi?id=87581
Comment by Britt Yazel (brittyazel) - Thursday, 04 February 2016, 09:06 GMT
So oddly enough, setting my two SATA ports controlled by the MARVEL chipset (rather than the native AMD chipset) to IDE rather than AHCI seems to have solved this issue for me. I will report back in a few days to let you all know how it is going. Also, my boot process after changing that setting is immediately faster.
Comment by Andrey (Andrey) - Wednesday, 20 April 2016, 17:30 GMT
When loading linux 4.5.1-1 screen becomes black after "Started udev Kernel Device Manager". With debug screen fills the message flow: "** 134 printk messages dropped ** [ 132.604000 ] ACPI Error: No handler or method for GPE 0E, disabling event (20160108/evgpe-790)", each line changes the first three digits and two digits after the GPE.

Sorry, I am not carefully looking for a solution. Problem solved.
Comment by Wilhelm Schuster (wlhlm) - Thursday, 21 April 2016, 08:31 GMT
@Andrey This seems to be a recent problem with kernel 4.5: https://bbs.archlinux.org/viewtopic.php?pid=1620227

tl;dr: put "blacklist sp5100_tco" in /etc/modprobe.d/blacklist.conf or disable it on the cmdline: modprobe.blacklist=sp5100_tco

upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=114201

Unfortunately, this does not fix my particular problem. :(
Comment by Wilhelm Schuster (wlhlm) - Thursday, 21 April 2016, 08:39 GMT
I'm still at a loss with this one, still happening with kernel 4.5...

This looks like some race condition to me, since booting still works by just appending "debug" to the cmdline, so I think it "magically" works, because the kernel spends most time printing to the slow tty. I'm unable to find anything in the debug log (like ACPI errors).

If I find the time, I'll try downgrading the BIOS and see if that helps.
Comment by mattia (nTia89) - Monday, 02 October 2017, 20:09 GMT
is this issue still valid?

Loading...