Kernel: 3.12rc3 Enabling audio by executing: $ xrandr --output HDMI-0 --set audio auto This causes the system to fully freeze after seconds forcing me to hard reset. Audio actually works in those few seconds. Bug present with and without DPM. ----- I don't know how to gather more info with such freezes. Feel free to point me into the right direction.
Please attach your xorg log and dmesg output. If this is a regression can you use git to bisect?
Did you started audio before enabling it with "xrandr --output HDMI-0 --set audio auto" ?
Created attachment 87590 [details] dmesg (current run with DPM)
Created attachment 87591 [details] Xorg.0.log (current run with DPM)
(In reply to comment #1) > Please attach your xorg log and dmesg output. If this is a regression can > you use git to bisect? I don't think I have enough free space to clone the kernel. So bisection is not easy for me unless there is a submoduled repository I'm not aware of.
(In reply to comment #2) > Did you started audio before enabling it with "xrandr --output HDMI-0 --set > audio auto" ? radeon.audio=1 seems to have no effect! Passing it does not enable audio. And using xrandr later causes the same freeze.
Created attachment 87593 [details] dmesg (audio+dpm)
Created attachment 87594 [details] dmesg (audio + no dpm)
It is worth noting that the (frozen) frame is still signaled and audio starts looping after the freeze. Which maybe indicate an endless loop. Also, when the freeze is not instant, audio keeps working seconds after the display is frozen. Then, it starts looping.
(In reply to comment #6) > (In reply to comment #2) > > Did you started audio before enabling it with "xrandr --output HDMI-0 --set > > audio auto" ? Had you started audio playback in the application before enabling it with xrandr? If so, do you still get the hang if you enable audio with xrandr first, and then start playback in the application? > > radeon.audio=1 seems to have no effect! > radeon.audio=1 is the default now.
Created attachment 87616 [details] [review] possible fix Please try this patch and append radeon.audio=1 to the kernel command line in grub.
(In reply to comment #10) > (In reply to comment #6) > > (In reply to comment #2) > > > Did you started audio before enabling it with "xrandr --output HDMI-0 --set > > > audio auto" ? > > Had you started audio playback in the application before enabling it with > xrandr? If so, do you still get the hang if you enable audio with xrandr > first, and then start playback in the application? > > > > > radeon.audio=1 seems to have no effect! > > > > radeon.audio=1 is the default now. Upgraded to 3.12rc5. I get the hang in all cases. Even if I don't use an application at all. The hang sometimes happens so fast before xrandr exiting. And sometimes it takes ~90s. But I always get a hang at the end. I'll test with the patch now.
Created attachment 87633 [details] partial kernel log (3.12rc5 + patch 87616)
(In reply to comment #11) > Created attachment 87616 [details] [review] [review] > possible fix > > Please try this patch and append radeon.audio=1 to the kernel command line > in grub. There appears to be a serious regression here. System hangs (black screens) if the HDMI monitor is connected before xinit. And hangs if the monitor is attached after xinit when enabled via xrandr. In the latter case, the hanged frame is displayed on the monitor, but before being resized to occupy the whole screen and with noise artifacts. Note: Everything works correctly with 3.11.5. 'radeon.audio=1' works with and without DPM.
> Note: Everything works correctly with 3.11.5. 'radeon.audio=1' works with > and without DPM. Then please bisect what patch introduced this problem since it doesn't seems to be releated to the xrandr property change.
Okay. Enabling audio at run time is indeed not the underlying cause of the hang. The offending commit is: 0ffae60c8976fb407de04cebd8c4cfae932bc671 Setting audio via xrandr works as expected after reverting: 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a c1cbee0ec0697c531778fbaf34aa358c0f5ef00e 0ffae60c8976fb407de04cebd8c4cfae932bc671
Created attachment 87798 [details] [review] possible fix Does this patch fix the issue?
(In reply to comment #17) > Created attachment 87798 [details] [review] [review] > possible fix > > Does this patch fix the issue? As expected, yes.
Fix committed: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b7495770cc4a4e7973ea8079dd15d2618f3636a Marking as RESOLVED.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.