---------------------------------------- Update (Aug 1st): After recent kernel and system updates the workaround in my last update quit being viable for me as the issue started returning after about 15 minutes. I read somewhere that changing from fixed to VRR on one or all of your displays might help, only one of my displays supports VRR so I tried that and noticed it immediately stopped the 3003/gbm error flood and flickering and lasted about 17 hours before recurring. When it did, I simply toggled it back off and got another 10 hours or so of error/flicker free uptime. So I then worked with ChatGPT and Google AI to create a script to automate the toggling of VRR for my one monitor that supports it. After several trials and failures I finally got a script that automates this for me and provides a workaround I don't have to manage, I simply let it run in a terminal and check the output to see how many times it has had to execute, I'm currently at 2 days of uptime and the script has executed 6 times sporadically, keeping the canvas stable and flicker free. To bypass modern GNOME 50 D-Bus sandbox restrictions and resolve the MetaDrmBufferGbm leak without dropping the desktop session, you can force a full hardware graphics pipeline modeset by simultaneously re- asserting your entire multi-monitor coordinate matrix.Below is an automated Bash script that monitors journalctl for the gbm_surface_lock_front_buffer failed flood strings. Once triggered, it uses gdctl to instantly toggle between an equivalent VRR and Fixed refresh rate canvas matrix layout. This forces a clean hardware flush and releases the stale color buffers seamlessly without any visual panel blinks or interface stutter. Adjust the gdctl screen strings to match your unique hardware topology. ---------------------------------------- ```bash #!/bin/bash START_TIME=$(date +"%b %d %H:%M:%S") echo "$START_TIME 🚀 Auto-Purge Service started. Monitoring for pesky Mutter 50 buffer floods..." TOGGLE_STATE=0 COUNT=0 THRESHOLD=3 # We stream live into a reading descriptor exec 3< <(journalctl -b -f -n 0 | grep --line-buffered "gbm_surface_lock_front_buffer failed") while read -r line <&3 do ((COUNT++)) if [ $COUNT -ge $THRESHOLD ]; then LOG_TIME=$(date +"%b %d %H:%M:%S") echo "$LOG_TIME 🚨 Buffer leak flood detected ($COUNT errors)! Curses!!! Triggering REAL hardware pipeline reset..." if [ $TOGGLE_STATE -eq 0 ]; then gdctl set --logical-monitor --monitor HDMI-2 --mode "1920x1080@60.000" --scale 1.0 --x 1920 --y 1080 --logical-monitor --monitor HDMI-1 --mode "3840x2160@60.000" --scale 2.0 --x 916 --y 0 --logical-monitor --monitor DP-1 --mode "3840x2160@59.997" --scale 2.0 --x 0 --y 1080 --primary > /dev/null 2>&1 TOGGLE_STATE=1 echo "$LOG_TIME 🔄 gdctl: Entire layout flipped to FIXED mode -> Buffers Purged!" else gdctl set --logical-monitor --monitor HDMI-2 --mode "1920x1080@60.000" --scale 1.0 --x 1920 --y 1080 --logical-monitor --monitor HDMI-1 --mode "3840x2160@60.000" --scale 2.0 --x 916 --y 0 --logical-monitor --monitor DP-1 --mode "3840x2160@59.997+vrr" --scale 2.0 --x 0 --y 1080 --primary > /dev/null 2>&1 TOGGLE_STATE=0 echo "$LOG_TIME 🔄 gdctl: Entire layout flipped to VRR mode -> Buffers Purged!" fi echo "$LOG_TIME ⏳ Entering a 30 second Cool Breeze Mode..." sleep 30 # GHOST PURGE: Read and immediately throw away any backlog lines left over from the flood while read -t 0.1 -r ghost_line <&3; do : # Doing nothing dumps the line directly into the trash bin done COUNT=0 RESUME_TIME=$(date +"%b %d %H:%M:%S") echo "$RESUME_TIME 🟢 Cool Breeze Mode finished. Resuming fresh active monitoring..." fi done ``` ---------------------------------------- Use code with caution. ---------------------------------------- If one of the displays does not support VRR the same result might be achieved by simply changing one display between 60.000 Hz and 59.940 Hz but I haven't tried that as the script above is working great for my situation. If this quits working for me after additional kernel/system updates or if this is no longer needed I will update this thread, but for now this works great for me. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2156644 Title: GNOME Panel & Activities Overview workspace thumbnails flickering issue Status in linux package in Ubuntu: New Bug description: GNOME Activities Overview workspace thumbnails begin flickering after several hours of uptime on Ubuntu 26.04 LTS with GNOME Shell 50.1 running on Wayland and Intel Alder Lake-N integrated graphics (i915 driver). System: Ubuntu 26.04 (upgraded from 24.04) GNOME Shell 50.1 / Mutter 50.1 Wayland session (no Xorg session available) Intel Alder Lake-N UHD Graphics (i915 driver) Three displays (all 1920×1080 @ 60Hz) Symptoms: After several hours of uptime, GNOME Activities Overview becomes visually corrupted. Specifically, workspace thumbnails flicker immediately upon entering Overview (Super key or hot corner). The flickering is limited to Overview workspace thumbnails and GNOME top bar. Normal desktop, application windows remain stable and unaffected. Exiting Overview immediately returns the desktop to normal. Logging out and back in resolves the issue temporarily, but it returns in minutes, rebooting it returns after several hours. No GPU resets, hangs, or DRM errors appear in journalctl. I’ve tried: Kernel parameter: intel_idle.max_cstate=1 Appears to delay or partially change the symptoms, but the issue still occurs. Kernel parameter: i915.enable_dc=0 Initially seemed to reduce symptoms, but the issue still returned. Adding i915.enable_psr=0 i915.enable_fbc=0 to GRUB also did not solve the issue. Tested different kernels (including older kernel) No change in long-term behavior. Disabled a couple of third-party GNOME extensions (still using default Ubuntu extensions). Observations: The issue does not affect application rendering or the desktop outside of Activities Overview. It appears only after extended uptime (hours), not immediately after login. The issue is reproducible across reboots and kernel versions. No relevant errors in journalctl related to i915, DRM, or GPU resets. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-15-generic 7.0.0-15.15 ProcVersionSignature: Ubuntu 7.0.0-15.15-generic 7.0.0 Uname: Linux 7.0.0-15-generic x86_64 ApportVersion: 2.34.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Jun 12 19:46:59 2026 InstallationDate: Installed on 2023-10-25 (962 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: GMKtec NucBox G2 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-15-generic root=UUID=4f8f8593-25f0-4c7b-8445-d8bc2891550a ro quiet splash i915.enable_psr=0 i915.enable_fbc=0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: Upgraded to resolute on 2026-06-09 (3 days ago) dmi.bios.date: 06/08/2023 dmi.bios.release: 5.27 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 5.27 dmi.board.asset.tag: Default string dmi.board.name: GMKtec dmi.board.vendor: GMKtec dmi.board.version: Default string dmi.chassis.asset.tag: Default string dmi.chassis.type: 0 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr5.27:bd06/08/2023:br5.27:svnGMKtec:pnNucBoxG2:pvrDefaultstring:rvnGMKtec:rnGMKtec:rvrDefaultstring:cvnDefaultstring:ct0:cvrDefaultstring:skuG2:pfaMINI: dmi.product.family: MINI dmi.product.name: NucBox G2 dmi.product.sku: G2 dmi.product.version: Default string dmi.sys.vendor: GMKtec To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2156644/+subscriptions
Комментариев нет:
Отправить комментарий