Wrong frame timing/jerkiness with 120Hz display on 6.12 (bisected)

added Phoenix label

Would it be the same issue as one in https://bugzilla.kernel.org/show_bug.cgi?id=219468 ?

No, it isn't the same issue. I don't get any flickering but the frame timings are wrong. This results in jerkiness/juddering.

@mamarley Can you see if disabling PSR fixes the issue (you can do so by setting amdgpu.dcdebugmask=0x10 in the kernel cmdline)? If it does please share the display's EDID.

marked this issue as related to #3658 (closed)

Yes, that works around the issue. The EDID is attached.framework_2.8k.bin

I also tried the patch you posted in the related issue and that seems to resolve the problem for me as well.

I wonder if replay is playing into this, so please try reverting https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be64336307a6c3ee71fe1337c1b9f0495aa83c50 and retest with PSR enabled.

Reverting that commit makes no difference; the problem still occurs.

mentioned in issue #3760

added PSR label

Can reproduce with amd-gpu-firmware-20241110 on Fedora 41 KDE on Plasma Wayland on the following hardware:

Processors: 16 × AMD Ryzen 7 7840U w/ Radeon™ 780M Graphics
Memory: 14.9 GB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: HP
Product Name: HP Pavilion Plus Laptop 14-ey0XXX

amd-gpu-firmware-20241017 is fine.

mentioned in issue #3773 (closed)

Is this the same as #3658 (closed)?

It shouldn't be, I left a comment there explaining why.

The patch from that bug does solve/workaround the issue for me though.

By W/A you mean https://gitlab.freedesktop.org/-/project/4522/uploads/fb09dab585cdf987115e330f93a41c23/0001-drm-amd-display-WIP-increase-vblank-off-delay.patch right?

So let me try to explain better. We had panel replay enabled on Framework 16, but there was a problem and it got disabled. When panel replay is disabled then PSR is used instead. Panel replay got re-enabled in Framework 16 it should no longer be exposed to this issue. If that's wrong and it exposed, that's a bit surprising and it means that panel replay isn't immune.

The various panels for Framework 13 don't support panel replay.

Yes, that's the one. I have a Framework 13 (with the 2.8k panel, not that that matters). I suffer from the bug reported in this issue and the patch you linked resolves the issue for me.

@hwentland, @effective-light it's just a workaround though for root causing, not the fix right?

Yup, it isn't an actual fix. Though, I wasn't able to repo the issue on a 120 hz PSR panel, so it appears that something else is the culprit (VRR?).

Yeah @sinatosk seems to be showing that too with jittery with VRR + PR in #3658 (closed)

mentioned in issue #3658 (closed)

marked #3773 (closed) as a duplicate of this issue

marked this issue as related to #3773 (closed)

@mamarley Can you try to see if this patch helps with VRR disabled?

0001-XXX-Use-user-specified-timing-to-calculate-vblank-of.patch

Currently, I think the bisected issue, and the PSR/Replay + VRR issue, are separate. If this patch helps when VRR is disabled, I'd expect VRR enabled to still be jittery.

Sadly, that patch does not seem to have any effect on the issue.

This patch doesn't help with VRR disabled on my 180Hz monitor either (nor does it help my 60Hz external monitor that doesn't support VRR, but is still affected by this issue).

Hmm, good to know. A few more questions:

If you boot with no external displays connected (i.e. shutdown laptop, unplug all external displays, boot laptop), is the stuttering still reproducible on the internal display?
If answer to #1 is "yes": if you boot with an external display connected (i.e. shutdown laptop, connect a external display, boot laptop), is the stuttering worse than #1?
In dmesg, when the stuttering occurs, do you see a warning stackdump? If so, what is the offending function?

I can only reproduce on my two external displays. The laptop display doesn't seem to have the issue for me (the graphics might be more sluggish than when it's working correctly, but it's not obvious the way the stutters on the external displays are). The configuration in which I've booted the laptop doesn't seem to affect the stuttering on the external monitors once I've plugged them in.
n/a
No, I don't see anything in dmesg when the stuttering occurs.

@mamarley , @danielrparks , can you give the attached patch a try to see if it helps?0001-HACK-Do-not-promote-to-full-update-on-mem_type-chang.patch

That patch also has no effect on the issue for me.

Looks like what I reproduced was not what you saw... Can you apply this patch that prints out some psr-related debug info, reproduce the issue, then copy the dmesg here? Thanks. 0001-XXX-Print-some-debug-info.patch

Sure, here you go: dmesg.log

There was an external monitor connected during the test too, but the problem reproduces on the internal monitor even when the external one is connected.

Hmm it looks like your panel may only support PSR1, which puts this into a separate category of issues. Initially I thought this was related to PSR SU.

What is the output of cat /sys/kernel/debug/dri/0/eDP-1/psr_capability? (It may be on a different index, /dri/1/)

michael@mamarley-laptop:~$ sudo cat /sys/kernel/debug/dri/1/eDP-1/psr_capability
Sink support: yes [0x03]
Driver support: yes

Thanks, can you give this patch a try to see if it helps?0001-XXX-Do-not-wait-for-PSR-disable-on-vbl-enable.patch

That patch might have a slight improvement, but the jerkiness definitely still occurs.

To confirm, the jerkiness is occurring even with VRR disabled? Does combining this patch with the previous one (#3742 (comment 2689252)) change anything?

Yes. I just tried it again with both of those patches and the jerkiness occurs with the KDE VRR control set to both Never and Automatic (which only enables VRR when there is a full-screen application). Just for kicks, I tried it in Always mode and the jerkiness actually doesn't occur then.

Hi @mamarley, can you give v2 of this patch a try? v2-0001-XXX-Do-not-wait-for-PSR-disable-on-vbl-enable.patch

If v2 isn't an improvement over v1, can you grab a ftrace of some relevant functions using trace-cmd? It should be available from your package manager:

[as root] trace-cmd record -p function_graph -g amdgpu_dm_crtc_vblank_control_worker -g amdgpu_dm_atomic_commit_tail -g amdgpu_dm_atomic_check -l 'amdgpu_dm*'

First, run the above. When it prints "CTRL+C to terminate" or something similar, go ahead and reproduce the issue. ~5s is more than enough. Then just hit CTRL+C to stop recording. It should output a trace.dat file in the cwd, which you can upload here.

P.S. Thanks for helping me collect more data. I don't have a configuration that can repro this, so appreciate the help!

Nope, still happening, sorry. Here's the output you requested: trace.dat

It also output the following on the console:

CPU0 data recorded at offset=0x31e000
    330 bytes in size (4096 uncompressed)
CPU1 data recorded at offset=0x31f000
    123 bytes in size (4096 uncompressed)
CPU2 data recorded at offset=0x320000
    156 bytes in size (4096 uncompressed)
CPU3 data recorded at offset=0x321000
    0 bytes in size (0 uncompressed)
CPU4 data recorded at offset=0x321000
    16130 bytes in size (65536 uncompressed)
CPU5 data recorded at offset=0x325000
    0 bytes in size (0 uncompressed)
CPU6 data recorded at offset=0x325000
    49537 bytes in size (237568 uncompressed)
CPU7 data recorded at offset=0x332000
    21830 bytes in size (106496 uncompressed)
CPU8 data recorded at offset=0x338000
    45165 bytes in size (196608 uncompressed)
CPU9 data recorded at offset=0x344000
    0 bytes in size (0 uncompressed)
CPU10 data recorded at offset=0x344000
    20228 bytes in size (86016 uncompressed)
CPU11 data recorded at offset=0x349000
    0 bytes in size (0 uncompressed)
CPU12 data recorded at offset=0x349000
    3766 bytes in size (16384 uncompressed)
CPU13 data recorded at offset=0x34a000
    0 bytes in size (0 uncompressed)
CPU14 data recorded at offset=0x34a000
    0 bytes in size (0 uncompressed)
CPU15 data recorded at offset=0x34a000
    97271 bytes in size (516096 uncompressed)

I definitely understand how hard it is to fix a bug you can't reproduce. Thanks for your persistence.

I've also noticed another worse behavior that also seems to be caused by the bisected commit. After some amount of uptime (anywhere between 2 hours and 2 days), the framerate will suddenly drop to 1-2spf (making the system unusable) and a kworker task will spin 1 thread of the CPU. This continues even if I switch to a VT. Rebooting the system causes it to (temporarily) return to normal. Reverting the bisected commit seems to resolve the issue, but neither of the other patches does.

This affects 60 Hz displays too, at least it does my built-in Framework 13 display, using sway. I independently bisected to the same bad commit (58a261bfc96763a851cb48b203ed57da37e157b8).

mentioned in issue #3797 (closed)

I also hit this issue and independently bisected to the same commit. However, it manifests a little differently for me.

Every second, my external monitor drops several frames. I've attached a video file demonstrating the problem. dropped_frames The refresh rate of the monitor is 180Hz; this video was recorded at 90fps and slowed down to 30fps to make the issue easier to spot. I can only notice this problem on my two external monitors (180Hz: LG Electronics LG ULTRAGEAR connected via USB-C to DisplayPort and 60Hz: Acer Technologies R240HY connected via USB-C to HDMI); the built-in 60Hz screen on the laptop doesn't obviously have this issue. Fractional scaling is enabled (1.25x) on the laptop screen but not on the external monitors.

I am using an AMD Framework Laptop 13 with a Ryzen 5 7640U on Arch Linux. I am using Sway for my window manager, and the bar at the top is Waybar. Waybar is visible at the top of each monitor.

The frame drops occur reliably every second, but only while Waybar is running. I think this means the frame drops are somehow caused (or at least encouraged) by the surface update caused by the seconds changing in Waybar's clock. The problem also goes away if I disable the clock module.

Furthermore, running graphical programs influences the issue. Running glxgears on the laptop screen or the 180Hz monitor makes the problem go away. Running glxgears on the 60Hz monitor does not, and it will also drop frames every second; however, if I also run glxgears on the 180Hz monitor or the laptop display, the issue goes away and glxgears does not drop frames on the 60Hz monitor. When recording the video, I had to put OBS on a workspace that was not visible because the problem was not reproducible while OBS was visible.

Disabling PSR also fixes the issue for me, even though the external monitor doesn't appear to support PSR.

mentioned in issue #3743 (closed)

For individuals experiencing this issue, can you give this series a try? Note it's 3 patches formatted into 1 file (apply using git am --empty=drop xxx.patch). Of course, if you've set amdgpu.dcdebugmask, remember to clear it before testing. 0000-Fix-some-PSR-Replay-stuttering-issues.patch

The series as-is is ready for review and merge. But I'd like to short-circuit the process to get some feedback from folks who can reproduce the issue (I can't seem to reproduce the exact reported issues with the panels I have on hand).

It's formatted on Alex's amd-staging-drm-next branch.

p.s. @mamarley This likely won't improve from where we left off in another thread. I'm waiting to get my hands on a framework to take another look.

Indeed it doesn't fix the problem for me, but it doesn't seem to make anything worse either. Thanks for your continued effort and I will be more than happy to test firmware blobs when the time comes.

I tried these patches applied to 6.12.5. It doesn't fix it for me either. I almost want to say it feels slightly better though, but that's possibly just my imagination.

OK, after switching back and forth a few times, I can say the patch definitely does improve things for me, but doesn't fix it fully.

The most noticeable symptom for me is moving the cursor around in sway. Without the patch there is a delay before the cursor jumps to where it should be and starts moving. With the patch, the delay is still there but much shorter.

I did some more testing as well and I agree, it is a bit better. It still isn't what it should be though.

@mamarley Can you give this patch a try to see if it helps with the remaining bits of stuttering? 0001-drm-amd-display-Increase-vblank-offdelay-for-PSR-pan.patch

@movq to confirm, are you also on a framework 13 with the hi-res panel?

This patch is definitely an improvement over previously and takes away a lot of the "laggy SSH connection" feeling I was getting while typing. I'm not sure how much of a tradeoff between power and responsiveness this is, but having a little more responsive might be nice though.

Oh, and to clarify, while I was using the new 2.8k panel when I originally reported this bug, a couple of months ago I decided the original panel better suited my needs and put that one back in, so my recent testing has been with the original one.

I have the 60 Hz 2256x1504 display.

I tried the new patch too. These are my thoughts:

6.13.5 (vanilla), no dcdebugmask: noticeable input latency when typing in the foot terminal on sway, and there's a delay before the cursor updates if I leave it still for a few seconds and then move it.
6.13.5 (with patch above), no dcdebugmask: Typing latency in foot is improved vs vanilla, but still not as good as with dcdebugmask=0x10. The cursor lag feels maybe slightly better too, but it's very subtle and hard to tell for sure.

Copied from #3658 (comment 2731997):

I use a 7640U + 760M Framework 13 (60 Hz, no VRR), and I also started noticing slight stutters after 6.12, but more that something felt off sometimes in animations, and I didn't really think much of it. Currently on 6.12.8.

But my main issue was very bad audio crackling/stutter on the built-in headphone output, with pw-top reporting a lot of ERR (underruns/xruns looking at journalctl -f), sometimes multiple per second. I can say that these dropouts seem to occur when the GPU is close to idle, so this could be related to downclocking? For example, if the audio is from a video in an active Firefox tab, I'm not getting the dropouts, but when the tab is in the background I do.

I don't know if I should file a separate issue for this, but amdgpu.dcdebugmask=0x10 completely solves my audio problem too, so this has to be PSR related too then?

Found this via https://community.frame.work/t/whole-system-freezes-when-not-moving-mouse/63243/4

Somehow, the option amdgpu.dcdebugmask=0x10 also completely solves my bluetooth problems: I was getting an intermittent lag spike with my bluetooth mouse Logitech MX Anywhere 3S, and also bluetooth audio skips (intermittent xruns in journalctl). My machine is a 7840HS Framework 16 with the RX 7700S dGPU, two external 60Hz screens, laptop screen closed. I'm adding this comment mainly so that someone else with the same symptoms might find it.

It's possible that my mouse wasn't lagging, but I was getting dropped video frames instead. I don't know why the bluetooth audio would also xrun though.

Linux lavender 6.12.11-200.fc41.x86_64 #1 (closed) SMP PREEMPT_DYNAMIC Fri Jan 24 04:59:58 UTC 2025 x86_64 GNU/Linux

Seems to be fixed for me in:

Fedora Linux (6.12.13-200.fc41.x86_64) 41 (Cinnamon)

The mouse skips are gone. The bluetooth audio skips still happen, but rare, and it's probably a different issue.

Well I figured out why I was getting the tiny mouse micro-freezes and tiny audio skips. I had been running a "sensors" applet in my desktop environment to report temperatures and fan speed and so on. This was waking up my dGPU in the framework 16 every few seconds, and when that happened I'd get a small mouse skip and an audio skip (bluetooth). I could clearly see how everything coincided while running sudo watch -n 0.5 cat /sys/class/drm/card1/device/power_state in one term, while also having journalctl tailed in another, and listening to music. Now with the sensors app closed, I don't get the wakeups (oscillating between D0 and D3cold), and my other symptoms don't happen. So my issue had nothing to do with this report.

mentioned in issue pipewire/pipewire#4473 (closed)

@cjrh You're a running a newer version than me, which should have fixed the issue: #3796 (comment 2758864)

Did you try without that flag on your current kernel? I'm still on 6.12.10, hopefully it will be upgraded soon.

It looks like that linked 6.12.11 commit only applies for systems that use VRR. My 60 Hz variant does not, so I don't think it's fully fixed? I need to test that.

I am now less sure that the kernel parameter fixed it for me, and I'm still getting frame drops but less frequently. However, a super curious thing is that when I have a gnome app called "mission center" open, I don't get the frame drops and my bluetooth audio doesn't stutter. I've read many of these issues and this seems like a very complex issue. Given that 6.13 is out, I'm just going to wait until that shows up in Fedora and check again. Sorry for the noise.

Upgraded to 6.12.13 today and it appears to be fixed for me.

Fedora Linux (6.12.13-200.fc41.x86_64) 41 (Cinnamon)

I can now tentatively confirm that using amdgpu.dcdebugmask=0x10 has fixed completely broken audio for my 7840HS based laptop on Linux 6.12.10:

c3:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller [1002:1640]
c3:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller [1022:15e3]

It's worth mentioning that I've also updated the DMCUB firmware, but AFAIK it doesn't contain any fixes related to PSR:

cat /sys/kernel/debug/dri/128/amdgpu_firmware_info 
VCE feature version: 0, firmware version: 0x00000000
UVD feature version: 0, firmware version: 0x00000000
MC feature version: 0, firmware version: 0x00000000
ME feature version: 35, firmware version: 0x00000028
PFP feature version: 35, firmware version: 0x00000030
CE feature version: 0, firmware version: 0x00000000
RLC feature version: 1, firmware version: 0x00000080
RLC SRLC feature version: 0, firmware version: 0x00000000
RLC SRLG feature version: 0, firmware version: 0x00000000
RLC SRLS feature version: 0, firmware version: 0x00000000
RLCP feature version: 1, firmware version: 0x0000000f
RLCV feature version: 0, firmware version: 0x00000000
MEC feature version: 35, firmware version: 0x00000028
IMU feature version: 0, firmware version: 0x0b012d00
SOS feature version: 0, firmware version: 0x00000000
ASD feature version: 553648363, firmware version: 0x210000eb
TA XGMI feature version: 0x00000000, firmware version: 0x00000000
TA RAS feature version: 0x00000000, firmware version: 0x00000000
TA HDCP feature version: 0x00000000, firmware version: 0x17000042
TA DTM feature version: 0x00000000, firmware version: 0x12000018
TA RAP feature version: 0x00000000, firmware version: 0x00000000
TA SECUREDISPLAY feature version: 0x00000000, firmware version: 0x00000000
SMC feature version: 0, program: 0, firmware version: 0x004c5700 (76.87.0)
SDMA0 feature version: 60, firmware version: 0x00000015
VCN feature version: 0, firmware version: 0x09117008
DMCU feature version: 0, firmware version: 0x00000000
DMCUB feature version: 0, firmware version: 0x08004b01
TOC feature version: 0, firmware version: 0x0000000b
MES_KIQ feature version: 6, firmware version: 0x00000073
MES feature version: 1, firmware version: 0x0000006f
VPE feature version: 0, firmware version: 0x00000000
VBIOS version: 113-PHXGENERIC-001

Can you please try amdgpu.dcdebugmask=0x600 and get the same improved result? This will disable PSR-SU (and panel replay; but that doesn't matter for your panel).

@superm1

Rebooted with amdgpu.dcdebugmask=0x600, stuttering is back though it's seemingly not as egregious as without any options.

Edit: no, it's as bad as before. As soon as the system becomes relatively idle, I get buffer underruns non-stop.

Can you please check 6.12.11? There are 3 PSR related fixes.

f6be6248d649 drm/amd/display: Do not wait for PSR disable on vbl enable
0f0c5ca1863e drm/amd/display: Disable replay and psr while VRR is enabled
583d3a42b2bf drm/amd/display: Fix PSR-SU not support but still call the amdgpu_dm_psr_enable

On the hardware from #3742 (comment 2735265), I just updated to 6.12.11, removed amdgpu.dcdebugmask=0x10 entirely, and rebooted.

The audio problems seem entirely gone now. Which of the commits solved this I don't know, I don't have VRR in any case.

I've upgraded to 6.12.12, confirming fixed. Finally. I endured the issue for two months.

closed

I don't think this is completely fixed. (For what it is worth, I now put the original 60hz panel back in my laptop because it was just a better fit for my needs.) Now most things are fine, but I still observe a delay when the screen hasn't been changing for a while and screen updates start happening again. It can be noticed both when moving the mouse and when holding down a key in the terminal. In both cases, there is a slight delay and the cursor jumps a bit before it begins moving smoothly.

Unfortunately it indeed isn't fixed, and many others are still reporting this issue on 6.12.12.

This seems to be related to framerate timing, which causes audio to become out of sync (see Pipewire issue tracker). It also causes tearing and other rendering issues (delays a lot).

When downgrading to 6.11, you'll notice it runs a lot better, which makes me think this is a kernel issue. I didn't try 6.13/6.14 yet, as this also seem to have commit related to this, which may not have been backported to 6.12.

You can increase buffers on Pipewire, but it doesn't really solve the issue, because it's just dropping frames left and right. The suggested flag doesn't solve this issue, maybe tearing, but it basically allows damages to happen, which isn't a real fix either.

I've also been following this issue because I have some stuttering while playing some movies, and this is still present on linux 6.13.2 (Arch).

I have the same hardware as original poster, but with the 60 Hz panel.

The stuttering appears on some specific videos (displayed on the laptop's screen), as soon as the video player's control overlay is automatically hidden, and stops as soon as I move the mouse (the control overlay reappears). If I play the video on my external monitor, there is no stuttering.

Here is video for which the stuttering appears: https://www.youtube.com/watch?v=EF2PGnZmXCI. This is the only one I found to be affected (lucky random proposal that youtube popped to me!).

I can workaround this issue with amdgpu.dcdebugmask=0x10.

reopened

Framework 13 (7840u) user checking in here, got here from the community forums. I was initially using amdgpu.dcdebugmask=0x10 to mitigate this issue.

However on 6.12.13-200.fc41.x86_64 this is no longer needed. Its working great without it now.

I have the same issue on Lenovo ThinkPad P14s Gen 5, AMD Ryzen 7 PRO 8840HS, Radeon 780M, 120 Hz display, Linux 6.13.2, linux-firmware 20250210.5bc5868b, GNOME, Wayland. It's very visible when typing in gnome-terminal, or jumping by words with Ctrl+arrows, or by looking at the cursor blinking (blinks are skipped).

Here are the workarounds that mitigate it for me (these are 3 different workarounds, each of which alone helps):

Switch to Xorg (but I need Wayland for 200% scale on the internal display and 100% scale on the external ones).
echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level (but it increases power consumption by 1 W, and power-profiles-daemon resets it to auto every time I plug in the charger).
amdgpu.dcdebugmask=0x10 kernel parameter, which disables PSR, according to /sys/kernel/debug/dri/1/eDP-1/psr_capability (it also doesn't seem to affect power consumption, showing the same 5.6 W in powertop in idle at 20% brightness).

Here are the things that didn't work:

echo low > /sys/class/drm/card1/device/power_dpm_force_performance_level
Taking amdgpu firmware from git a few days ago, updating linux-firmware from 20250109.7673dffd to 20250210.5bc5868b.

I'll be happy to test other workarounds and/or patches if needed.

I did try amdgpu.dcdebugmask=0x10, but it didn't really made a differences for me. It was still laggy. Maybe because I didn't force the power profile.

I cannot switch to Xorg, and I don't want to do that anymore. So I'm really hoping if providing debug info can fix it. I did contact Lenovo, but of course they stated Linux was not supported (only specific models).

Essentially the same hardware here (Thinkpad T14 gen 5 AMD). For me the issue completely goes away when setting refresh rate to 60Hz.

Maybe because I didn't force the power profile.

Oh, just to make it clear: I don't have to do all of the 1, 2, 3 steps to make it work. Any one is enough to make it work, meaning that the kernel parameter alone seems to fix it for me, and I don't need to touch the power profile if I pass the kernel parameter. I'll keep an eye on it for some time, but I noticed the difference immediately.

I did contact Lenovo, but of course they stated Linux was not supported (only specific models).

Thank you for contacting Lenovo! Even though mine is not exactly the same model, a similar one is certified for Linux (but it probably has a 60 Hz screen).

I don't know if this is related: https://www.phoronix.com/news/Linux-6.14-rc3-Newer-AMD-PP

I'm now running Linux 6.13.1, which makes things a bit better, but I still notice lag, especially when you enable VRR and/or scaling. It also seems 6.14 fixes a lot of Realtek issues, which also seems to cause issues for some reason.

I don't know if 6.14 will be better, I'm really hoping it fixes most of the issues I'm having now. Unfortunately I cannot test it at the moment.

As there are multiple people saying this works and others saying it doesn't I suspect we have multiple issues. Those of you that it's not fixed; can you please see if the original bisect matches for you? If it doesn't; you should open your own issues.

Wrong frame timing/jerkiness with 120Hz display on 6.12 (bisected)

Before submitting your bug report:)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Designs

Child items 0

Activity

Admin message

Admin message

Wrong frame timing/jerkiness with 120Hz display on 6.12 (bisected)

Before submitting your bug report:)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Activity