Bug 70439

Summary: Mobility 4570: System freezes after ~5s of enabling audio via xrandr
Product: DRI Reporter: Mohammad AlSaleh <CE.Mohammad.AlSaleh>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg (current run with DPM)
none
Xorg.0.log (current run with DPM)
none
dmesg (audio+dpm)
none
dmesg (audio + no dpm)
none
possible fix
none
partial kernel log (3.12rc5 + patch 87616)
none
possible fix none

Description Mohammad AlSaleh 2013-10-13 23:40:44 UTC
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.
Comment 1 Alex Deucher 2013-10-14 02:20:54 UTC
Please attach your xorg log and dmesg output.  If this is a regression can you use git to bisect?
Comment 2 Christian König 2013-10-14 07:58:44 UTC
Did you started audio before enabling it with "xrandr --output HDMI-0 --set audio auto" ?
Comment 3 Mohammad AlSaleh 2013-10-14 11:22:46 UTC
Created attachment 87590 [details]
dmesg (current run with DPM)
Comment 4 Mohammad AlSaleh 2013-10-14 11:32:26 UTC
Created attachment 87591 [details]
Xorg.0.log (current run with DPM)
Comment 5 Mohammad AlSaleh 2013-10-14 11:38:36 UTC
(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.
Comment 6 Mohammad AlSaleh 2013-10-14 11:59:50 UTC
(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.
Comment 7 Mohammad AlSaleh 2013-10-14 12:00:49 UTC
Created attachment 87593 [details]
dmesg (audio+dpm)
Comment 8 Mohammad AlSaleh 2013-10-14 12:01:32 UTC
Created attachment 87594 [details]
dmesg (audio + no dpm)
Comment 9 Mohammad AlSaleh 2013-10-14 12:07:01 UTC
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.
Comment 10 Alex Deucher 2013-10-14 16:19:27 UTC
(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.
Comment 11 Alex Deucher 2013-10-14 17:22:47 UTC
Created attachment 87616 [details] [review]
possible fix

Please try this patch and append radeon.audio=1 to the kernel command line in grub.
Comment 12 Mohammad AlSaleh 2013-10-14 19:34:14 UTC
(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.
Comment 13 Mohammad AlSaleh 2013-10-14 22:39:36 UTC
Created attachment 87633 [details]
partial kernel log (3.12rc5 + patch 87616)
Comment 14 Mohammad AlSaleh 2013-10-14 22:50:00 UTC
(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.
Comment 15 Christian König 2013-10-15 10:52:35 UTC
> 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.
Comment 16 Mohammad AlSaleh 2013-10-16 21:58:23 UTC
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
Comment 17 Alex Deucher 2013-10-17 20:13:51 UTC
Created attachment 87798 [details] [review]
possible fix

Does this patch fix the issue?
Comment 18 Mohammad AlSaleh 2013-10-18 13:41:13 UTC
(In reply to comment #17)
> Created attachment 87798 [details] [review] [review]
> possible fix
> 
> Does this patch fix the issue?

As expected, yes.

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.