| Bug ID | 100577 |
|---|---|
| Summary | DC + TearFree display lock |
| Product | DRI |
| Version | DRI git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | adf.lists@gmail.com |
Created attachment 1=
30688 [details]
dmesg with errors and trace
This one may be hard to reproduce for some as it seems to rely a bit on cpu=
freq
ondemand being a bit rubbish on my old cpu. Lowest is 800MHz for me (high 3=
.4
GHz).
I don't use a compositing desktop and vids played in my browser (seamonkey)
don't get vsync.
Turning on TearFree gets me vsync, but while testing I got a screen lock. S=
eems
to involve timing luck - I couldn't reproduce with the browser in a sane
timescale so invented a different test that could run while AFK.
mpv -fs --vo=3Dx11 a720p60video --loop=3Dinf
Will usually lock in < 15 minutes with cpufreq ondemand.
It was still going after an hour with cpufreq set to perf.
Also seems OK with amdgpu.dc=3D0 on same kernel =3D amd-staging-4.9
As I've only recently started running DC, and never tried this test before,=
I
have no idea whether it ever worked.
xserver is latest release ddx is git.
dmesg attached shows errors and a trace starting with
[ 2009.442985] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]]
*ERROR* [CRTC:39:crtc-0] flip_done timed out
[ 2013.027575] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper=
]]
*ERROR* [CRTC:39:crtc-0] flip_done timed out
[ 2013.027727] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR*
dm_dc_surface_commit: acrtc 0, already busy
| What | Removed | Added |
|---|---|---|
| CC | michel@daenzer.net |
Removing myself from CC, I get notifications via the mailing l= ist.
Same problem here. It was definitely working fine several week= s ago. I'll try to bisect the issue if I'll find reliable reproducer.
Created attachment 131193 [details]<=
/span>
dmesg
Bisected to this commit: https://cgit.freed= esktop.org/~agd5f/linux/commit/?h=3Damd-staging-4.9&id=3Dafbeb2d0961b21= 39bcf6553a710e6a8ae5d09d34 Which makes me think I'm experiencing a different issue, because this bug w= as reported long before that commit emerged. My reproducer is to fill the screen with two xterm windows next to each oth= er and generate random lines of text in both of them, using command like this = for example: tr -dc a-z1-4 </dev/urandom | tr 1-2 ' \n' | awk 'length=3D=3D0 || lengt= h>50' | tr 3-4 ' ' | sed 's/^ *//' | cat -s | sed 's/ / /g' | fmt The screen lock will occur in a couple of minutes.
(In reply to Nikola Forr=C3=B3 from comment #4) > Which makes me think I'm experiencing a differen= t issue, because this bug > was reported long before that commit emerged. Indeed; please file your own report.
Testing current amd-staging-4.9 + patch from Bug 101053 I can't reproduce this anymore. It was a couple of hours running, I'll try longer and with 4.11 over the ne= xt few days and either reconfirm or close this.
This might've been fixed by Mario's patches plus Andrey's scan=
line change
d58f8724e636 Mario Kleiner
drm/amd/display: Prevent premature pageflip when comitting in vblank. (=
v3)=20=20
8494f61e14ff Mario Kleiner
drm/amd/display: Fix race between vblank irq and pageflip irq. (v2)
I can still reproduce this. Seems I may just get lucky runs - one 90 mins no issue, stopped and started again later and it locked after 20.
Can't reproduce this on current amd-staging-4.11 will keep try= ing and close soon if OK. One nit I notice is I may not be comparing like with like as current and so= me older 4.11s I still have around all seem to peg memory clock high. 3.7s I s= till have don't do this, neither does non DC current kernel. I'll search/file a separate bug for this one in coming days, it causes +10 degrees idle GPU temp.
(In reply to Andy Furniss from comment #9) > One nit I notice is I may not be comparing like = with like as current and > some older 4.11s I still have around all seem to peg memory clock high= . 3.7s Ugh, not 3.7s, I mean amd-staging-4.9s didn't peg memclk high. I don't still have all the 4.11s I've ever built so don't know when this started for them= .
(In reply to Andy Furniss from comment #10) > Ugh, not 3.7s, I mean amd-staging-4.9s didn't pe= g memclk high. I don't still > have all the 4.11s I've ever built so don't know when this started for= them. What sort of display(s) do you have and what modes are you using? Mclk dpm= is disabled if there are multiple monitors or if the vblank period is too shor= t to support mclk switching.
Hmm, so I just booted back into current staging to get a dmesg= and xrandr and ended up noticing 2 more issues. My monitor is 1920x1080 and can do 120Hz but pref and used by default is 60= Hz. Issue 1 - I can't see 120Hz with xrandr, I normally can - but then I normal= ly use non DC kernels. Issue 2 I see a few errors at the end of the dmesg =3D [drm] dc_get_validate_context:resource validation failed, dc_status:6
Created attachment 132465 [details]
dmesg on current staging memclk is stuck high + some errors
Created a=
ttachment 132466 [details]
xrandr --verbose higher clocks missing
It seems the errors in the dmesg are created when I do xrandr = --verbose.
Created attachment 132467 [detail=
s]
xrandr --verbose on 4.14-wip showing all modes
This is xrandr on 4.14-wip - the higher modes are shown, though the clocks
aren't precise 100/110/120 - it's always been like this, I live in hope th=
at
may get better one day!
I forgot to put earlier WRT 2 monitors, that HDMI-A-0 is physically connect=
ed,
but not seen as the TV is off, and as I said, 4.9 DC and all non DC kernels=
for
ages don't peg memclk high with the same setup.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | WORKSFORME |
| Status | NEW | RESOLVED |
Testing with amd-staging-drm-next, which doesn't peg memclk hi= gh I can't reproduce this anymore.