Bug 99881

Created attachment 129782 [details]
lspci.log

It sounds like you have the environment variable DRI_PRIME=1 set for all applications?

Those dmesg messages are normal when the dedicated GPU is powered up, which takes some time. With runpm enabled, it's powered off automatically when nothing uses it for a while.

Hi Michel,

Just a slight correction to my description - I am running Ubuntu Gnome 16.04.2.

This is a fresh install and I have not set that env var anywhere. Where could I check for that?

Does that mean with radeon.runpm=0 the laptop would be using more power & generating more heat?

Thanks

Matthew

(In reply to Matthew Fox from comment #3)
> This is a fresh install and I have not set that env var anywhere. Where
> could I check for that?

What does

 env | grep DRI_

say?


> Does that mean with radeon.runpm=0 the laptop would be using more power &
> generating more heat?

Yes (assuming the dedicated GPU is off most of the time with runpm on).

> What does
> 
>  env | grep DRI_
> 
> say?

That printed nothing.

My session with runtime pm enabled (no radeon.runpm=0 in cmdline) had been running for a couple of hours without problem (apart from a bit of freezing at the start). However, just after running that command, some new radeon errors appeared in dmesg that I haven't seen before. I think they were ring test failures. The PC has locked up now anyway so I can only hard shut it down. I was switching ttys with CTRL+ALT at the same time which might have caused it.

Note that you should run

 env | grep DRI_

in an X terminal, not in a console TTY.

(In reply to Michel Dänzer from comment #6)
> Note that you should run
> 
>  env | grep DRI_
> 
> in an X terminal, not in a console TTY.

Same result in both :/

Please attach the corresponding Xorg log file.

(In reply to Michel Dänzer from comment #8)
> Please attach the corresponding Xorg log file.

Hi,

The only Xorg logs I have are for my new session. They weren't in /var/log/ but

/home/matthew/.local/share/xorg/Xorg.1.log
/var/lib/gdm3/.local/share/xorg/Xorg.0.log

for some reason. They are attached.

Also attached is a dmesg log for my current session.

When I said:

With previous ubuntu/kernel versions, the main issue was the freezing which would happen every seven seconds with the corresponding dmesg block. This would continue ad infinitum, although on rare occasions it would stop after many freezes. However with my current kernel this pattern doesn't seem to occur - it freezes a few times before the freezing stops and the freezes do not occur at regular intervals.

- this seems to be true of my current kernel. From the current dmesg.log, the 'Disabling via vga_switcheroo' happened at 14, 33, 41 and finally 48 (seven seconds apart, except 14-33):

[   14.146303] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
[   15.586313] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[   15.588655] [drm] PCIE GART of 512M enabled (table at 0x000000000014C000).
[   15.588728] radeon 0000:02:00.0: WB enabled
[   15.588731] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff90180fa71c00
[   15.588733] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff90180fa71c0c
[   15.589099] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffbdbf41a1c418
[   15.605265] [drm] ring test on 0 succeeded in 1 usecs
[   15.605270] [drm] ring test on 3 succeeded in 2 usecs
[   15.791907] [drm] ring test on 5 succeeded in 1 usecs
[   15.791914] [drm] UVD initialized successfully.
[   15.791956] [drm] ib test on ring 0 succeeded in 0 usecs
[   15.791986] [drm] ib test on ring 3 succeeded in 0 usecs
[   16.482332] [drm] ib test on ring 5 succeeded
[   16.515177] snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo
[   16.619344] snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535

[   33.089549] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
[   33.389563] snd_hda_intel 0000:02:00.1: Cannot lock devices!
[   34.733597] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[   34.735932] [drm] PCIE GART of 512M enabled (table at 0x000000000014C000).
[   34.736006] radeon 0000:02:00.0: WB enabled
[   34.736009] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff90180fa71c00
[   34.736011] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff90180fa71c0c
[   34.736378] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffbdbf41a1c418
[   34.753251] [drm] ring test on 0 succeeded in 1 usecs
[   34.753256] [drm] ring test on 3 succeeded in 2 usecs
[   34.939919] [drm] ring test on 5 succeeded in 1 usecs
[   34.939926] [drm] UVD initialized successfully.
[   34.939969] [drm] ib test on ring 0 succeeded in 0 usecs
[   34.940006] [drm] ib test on ring 3 succeeded in 0 usecs
[   35.617560] [drm] ib test on ring 5 succeeded
[   35.650390] snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo
[   35.753848] snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535

[   41.025246] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
[   41.325632] snd_hda_intel 0000:02:00.1: Cannot lock devices!
[   42.665278] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[   42.667593] [drm] PCIE GART of 512M enabled (table at 0x000000000014C000).
[   42.667666] radeon 0000:02:00.0: WB enabled
[   42.667670] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff90180fa71c00
[   42.667671] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff90180fa71c0c
[   42.668038] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffbdbf41a1c418
[   42.684185] [drm] ring test on 0 succeeded in 1 usecs
[   42.684189] [drm] ring test on 3 succeeded in 2 usecs
[   42.870780] [drm] ring test on 5 succeeded in 1 usecs
[   42.870784] [drm] UVD initialized successfully.
[   42.870821] [drm] ib test on ring 0 succeeded in 0 usecs
[   42.870850] [drm] ib test on ring 3 succeeded in 0 usecs
[   43.553259] [drm] ib test on ring 5 succeeded
[   43.582109] snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo
[   43.685717] snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535

[   48.960919] snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
[   49.261324] snd_hda_intel 0000:02:00.1: Cannot lock devices!

Created attachment 129783 [details]
dmesg.log 2

Created attachment 129784 [details]
Xorg.1.log

Created attachment 129785 [details]
Xorg.0.log

Please attach the output of xrandr.

With runpm enabled, if you run xrandr, does the dedicated GPU turn on and the corresponding messages appear in dmesg?

Hi,

It's rare that the PC doesn't lock up with runpm enabled so I've only been able to test this a couple of times.

In the first try, the PC had stabilized (stopped freezing) after a while. I then ran xrandr. Immediately after I cat /sys/kernel/debug/vgaswitcheroo/switch and the discrete gpu had powered up. dmesg showed 1 block of gpu initialization lines. A few seconds later vgaswitcheroo/switch showed the discrete gpu as being off. dmesg also showed 2 or 3 blocks of the gpu initialization. It looked like the gpu was being enabled and disabled repeatedly. The computer then locked up a few seconds later. I don't have any logs for this session.

In the second try, the PC had stabilized. I ran xrandr and vgaswitcheroo/switch had changed from 'DynOff' to 'DynPwr' for the discrete gpu. dmesg showed 1 block of the gpu initialization. The computer locked up a few seconds later. The logs I have were captured straight after xrandr had run so the 'dmesg after' log only shows one of the gpu initialization blocks but I suspect the gpu was being enabled and disabled repeatedly before the PC locked up. I wasn't able to run dmesg again before the lockup to confirm.

Created attachment 129808 [details]
xrandr.log

Created attachment 129809 [details]
Xorg log before xrandr

Created attachment 129810 [details]
Xorg log after xrandr

Created attachment 129811 [details]
vgaswitcheroo switch before xrandr

Created attachment 129812 [details]
vgaswitcheroo switch after xrandr

Created attachment 129813 [details]
dmesg before xrandr

Created attachment 129814 [details]
dmesg after xrandr

I suspect what happens is that some client occasionally asks the X server to probe  the connected displays, similar to xrandr. This powers up the dGPU, in order to probe its display connectors. That takes some time, during which the X server freezes.

Assuming you don't need the dGPU display outputs, adding the below to /etc/X11/xorg.conf may serve as a workaround. You can still use the dGPU for applications by setting the environment variable DRI_PRIME=1.

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
EndSection

Section "Device"
        Identifier "Device0"
        Option  "AccelMethod" "glamor"
        Option  "DRI" "3"
EndSection

That workaround doesn't seem to have any effect so I'll run with radeon.runpm=0

Thanks for your help any way.

(In reply to Matthew Fox from comment #23)
> That workaround doesn't seem to have any effect [...]

At the very least, it should have visible effects in the Xorg log file and xrandr output. Please attach those with the attempted workaround.

Hi,

/etc/X11/xorg.conf didn't exist so I created it with the contents you specified.

So I'm now running with runpm enabled and the xorg.conf in place.

Created attachment 129854 [details]
xrandr.log 2

Created attachment 129855 [details]
Xorg.0.log

Created attachment 129856 [details]
Xorg.1.log

Created attachment 129857 [details]
dmesg

Just to confirm, the freezes and hard lockups still occur and the corresponding messages in dmesg which I also attached.

This may be more sound related but I previously found in the kernel source (file http://lxr.free-electrons.com/source/sound/pci/hda/hda_intel.c?v=4.8):

1182 static int register_vga_switcheroo(struct azx *chip)
1183 {
1184         struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
1185         int err;
1186 
1187         if (!hda->use_vga_switcheroo)
1188                 return 0;
1189         /* FIXME: currently only handling DIS controller
1190          * is there any machine with two switchable HDMI audio controllers?
1191          */
1192         err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops,
1193                                                    VGA_SWITCHEROO_DIS);
1194         if (err < 0)
1195                 return err;
1196         hda->vga_switcheroo_registered = 1;
1197 
1198         /* register as an optimus hdmi audio power domain */
1199         vga_switcheroo_init_domain_pm_optimus_hdmi_audio(chip->card->dev,
1200                                                          &hda->hdmi_pm_domain);
1201         return 0;
1202 } 

In dmesg, these lines always appear along with the gpu init lines:

snd_hda_intel 0000:02:00.1: Enabling via vga_switcheroo
snd_hda_intel 0000:02:00.1: CORB reset timeout#2, CORBRP = 65535
snd_hda_intel 0000:02:00.1: Disabling via vga_switcheroo
snd_hda_intel 0000:02:00.1: Cannot lock devices!

'CORB reset timeout#2, CORBRP = 65535' appears red in dmesg and
'Cannot lock devices!' appears white in dmesg.

0000:02:00.1 is the Discrete audio attached to the discrete GPU (the discrete GPU is 02:00.0)

From lspci, there's another audio device:
00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40)

Now in the function above, it says '...is there any machine with two switchable HDMI audio controllers?' - I wonder if that's the case here? Which might be causing problems and the associated sound messages in dmesg?

(In reply to Matthew Fox from comment #30)
> Just to confirm, the freezes and hard lockups still occur and the
> corresponding messages in dmesg which I also attached.

Weird; the xrandr output and Xorg log file show that the workaround is working as intended, Xorg is no longer using the dGPU; not sure why it's still getting powered on.


I'm not sure about the sound messages, but I'd guess they're a symptom of the dGPU powering on, not its cause. You could try if radeon.audio=0 on the kernel command line makes any difference though, just in case.

Does your kernel have this patch?
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/gpu/drm/radeon/radeon_device.c?id=066f1f0b4719eb4573ef09bfc63c2bbb6f7676ca

Hi,

With runpm enabled & radeon.audio=0, the computer locks up requiring a hard shutdown.

With runpm enabled & radeon.audio=0 & xorg.conf workaround, ditto. Except sometimes instead the computer will lock up for 10 seconds or so during which time the caps lock will toggle on/off, pressed keys will not be printed on screen. Mouse cursor will move on screen but clicks will not happen. After the freeze, the key presses that didn't print, print and same for the mouse clicks.

Alex - yes it does.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/774.