Source of bug report: https://bugs.archlinux.org/task/48468 https://bbs.archlinux.org/viewtopic.php?id=209576 When startx is used to start Xorg on an Arch system booted to command line with radeon module, Xorg process is fully frozen and cannot be killed or terminated, with message: "waiting for X server to begin accepting connections... ... ..." etc. (CTRL-C 500 times to stop the polling, Xorg wrapper is unresponsive to kill -9) This is happening on both 4.1.18 LTS and 4.4.4 (latter is vanilla + grsec). It is not happening on 4.4.3 from distribution (but pure vanilla not tried). Does not occur if radeon is blacklisted and VESA used instead. Two reports so far. Mine is switchable : [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] Forum user: [AMD/ATI] Mars [Radeon HD 8730M] ... (see link) Forum user recorded a stack trace (from his link https://gist.github.com/Bernolt/ae162d69444f9937610d): [<ffffffff813f2151>] rpm_resume+0x171/0x660 [<ffffffff813f267f>] __pm_runtime_resume+0x3f/0x60 [<ffffffffa06b05c4>] radeon_dp_detect+0x64/0x2e0 [radeon] [<ffffffffa040c20a>] drm_helper_hpd_irq_event+0xaa/0x140 [drm_kms_helper] [<ffffffffa0688bec>] radeon_resume_kms+0x22c/0x420 [radeon] [<ffffffffa0686143>] radeon_pmops_runtime_resume+0x73/0xb0 [radeon] [<ffffffff8130517f>] pci_pm_runtime_resume+0x7f/0xc0 [<ffffffff813df139>] vga_switcheroo_runtime_resume+0x39/0x40 [<ffffffff813f10a4>] __rpm_callback+0x34/0x90 [<ffffffff813f1128>] rpm_callback+0x28/0x90 [<ffffffff813f2439>] rpm_resume+0x459/0x660 [<ffffffff813f267f>] __pm_runtime_resume+0x3f/0x60 [<ffffffffa068b016>] radeon_driver_open_kms+0x36/0x1d0 [radeon] [<ffffffffa035b7ef>] drm_open+0x1af/0x4c0 [drm] [<ffffffffa0362689>] drm_stub_open+0xa9/0x120 [drm] [<ffffffff811dc0e6>] chrdev_open+0xb6/0x1b0 [<ffffffff811d50a7>] do_dentry_open+0x227/0x330 [<ffffffff811d62e6>] vfs_open+0x56/0x60 [<ffffffff811e5bf4>] do_last.isra.11+0x344/0xf50 [<ffffffff811e6891>] path_openat+0x91/0x670 [<ffffffff811e82f9>] do_filp_open+0x49/0xd0 [<ffffffff811d66ed>] do_sys_open+0x14d/0x250 [<ffffffff811d680e>] SyS_open+0x1e/0x20 [<ffffffff8158256e>] system_call_fastpath+0x12/0x71 [<ffffffffffffffff>] 0xffffffffffffffff
Note there are NO Xorg.0.log produced, full freeze.
"It is not happening on 4.4.3 from distribution (but pure vanilla not tried)." (but note 4.4.2 was tried which was vanilla + grsec, and had no problems... so likely a change in 4.4.4 exactly triggers this bug)
Please attach your dmesg output and xorg log.
Created attachment 207961 [details] dmesg for radeon xorg lockup upon startx
I've attached my dmesg run under 4.1.18 LTS. This was a boot under a regular user (user doesn't matter, happens with root), and first command was "startx", which polls eternally, the CTRL+C 500 times, then saved dmesg output. There is no xorg log produced in any location.
Does radeon.runpm=0 on the kernel command line avoid the problem? Can you bisect?
Probably the same issue as reported here: https://lists.freedesktop.org/archives/dri-devel/2016-March/102379.html Does reverting dbb17a21c131eca94eb31136eee9a7fe5aff00d9 fix it?
(In reply to Michel Dänzer from comment #6) > Does radeon.runpm=0 on the kernel command line avoid the problem? Yes, I tried moments ago and radeon.runpm=0 allows x to start! Had no tried that. (In reply to Alex Deucher from comment #7) > Probably the same issue as reported here: > https://lists.freedesktop.org/archives/dri-devel/2016-March/102379.html > Does reverting dbb17a21c131eca94eb31136eee9a7fe5aff00d9 fix it? That sounds exactly the same. I can't compile tonight and may not get it to work for a couple days (non standard setup). I'll mention to the other guy.
(In reply to Alex Deucher from comment #7) > Probably the same issue as reported here: > https://lists.freedesktop.org/archives/dri-devel/2016-March/102379.html > Does reverting dbb17a21c131eca94eb31136eee9a7fe5aff00d9 fix it? Went a bit out my way to test this faster. I can now confirm reverting this commit on a 4.4.4-based kernel (arch linux-grsec 4.4.4.201603032158-1-grsec) allows startx to start again on my (non-standard) system. I don't know about the other guy. Thanks I will report on the arch bug. Will this be in 4.4.5?
The exact commit that was reverted is: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dbb17a21c131eca94eb31136eee9a7fe5aff00d9
Already reverted upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=256faedcfd646161477d47a1a78c32a562d2e845
I had the same issue and latest torvalds master (that contains reverted patch) fixed my problem.
This is now fixed in 4.4.6 (though not 4.1.20 yet), thank you.