Bug 105308

Created attachment 137718 [details]
Kernel log

(In reply to Bob Ham from comment #0)
> 
> [   668.860] (WW) AMDGPU(0): flip queue failed in amdgpu_scanout_flip:
> Invalid argument, TearFree inactive until next modeset

Did anything in particular happen, or did you do anything in particular, around this time (about 11 minutes after system boot)?


> The kernel also reported this although I've no idea when in relation to
> other events:
> 
> [57903.995504] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
> amdgpu_cs_list_validate(validated) failed.
> [57903.995539] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process the
> buffer list -22!

The timestamps should be comparable, so this happened much later and is probably not directly related. Looks like the kernel ran out of memory or some other resource while processing GPU commands.


Please attach the output of

 xrandr --verbose

while the problem is occurring.

Created attachment 137719 [details]
Output of xrandr --verbose

(In reply to Michel Dänzer from comment #2)
> (In reply to Bob Ham from comment #0)
> > 
> > [   668.860] (WW) AMDGPU(0): flip queue failed in amdgpu_scanout_flip:
> > Invalid argument, TearFree inactive until next modeset
> 
> Did anything in particular happen, or did you do anything in particular,
> around this time (about 11 minutes after system boot)?

Not that I recall, no.  FYI, current uptime is 2 days, 17:25.


> Please attach the output of
> 
>  xrandr --verbose
> 
> while the problem is occurring.

I'll attach the output as requested.  It's from the same X session but I ran "truncate /var/log/Xorg.0.log" and since then the file has been at 0 size so I can only assume the problem is still occurring.

Thanks,

Bob

While the problem is occurring, and the screen contents are being updated at least once per second, please run the following as root:

 echo 255 >/sys/module/drm/parameters/debug"; sleep 1; echo 0 >/sys/module/drm/parameters/debug

and attach the resulting dmesg output.

Created attachment 137723 [details]
Kernel output while setting /sys/module/drm/parameters/debug to 255

This was done while playing video on the display.

There's nothing in there that would correspond to the Xorg log messages. Please make sure the problem is actually occurring when you capture the dmesg debugging output.

(In reply to Michel Dänzer from comment #6)
> Please make sure the problem is actually occurring when you capture the
> dmesg debugging output.

I've discovered that the problem occurs when the monitor is switched off.  With just the monitor off, the "get vblank counter failed: Invalid argument" error appears.  With the monitor off while playing a video, both the aforementioned error and "drmmode_wait_vblank failed for scanout update: Invalid argument" appears.  I'll attach two kernel logs as instructed, one for each condition.

Created attachment 137774 [details]
Kernel output while setting /sys/module/drm/parameters/debug to 255 with monitor off

Created attachment 137775 [details]
Kernel output while setting /sys/module/drm/parameters/debug to 255 with monitor off while playing video

Created attachment 137776 [details]
Output of xrandr --verbose

Output of xrandr --verbose while the error is really occurring

Created attachment 137777 [details]
First 1000 lines of /var/log/Xorg.0.log (2018-03-04)

Here is an updated version of the Xorg.0.log.  The "flip queue failed in amdgpu_scanout_flip" error is present again.

This might work better if you enable DC with

 amdgpu.dc=1

on the kernel command line.

https://patchwork.freedesktop.org/patch/209464/ fixes this for me with DC disabled.

So, I'm not 100% sure yet, I need time to rebuild 4.14.28 with Michel's patch and run it for a bit, but at this point I'm about 90% certain that a patch in 4.14.29 introduces a regression, as described in bug 106529. And from reading the changelog and looking at the code, it does seem to me that this patch is the most likely culprit.

Short version of what's wrong: on a multi-monitor setup, if the primary display is on DP and this code toggles it off/on, the window manager doesn't take it well and you end up with windows all over the place. 

(I don't know if this is the same codepath as is used with amdgpu.dc=1 on more recent kernels, though I do now the same bug occurs on 4.16+ with dc=1.)

Resolving this report, as it should be fixed or at least much better with the kernel change referenced in comment 13.

Mariusz, please keep the discussion about your issue on bug 106529, or maybe file a new report for the non-DC case.