On 2/26/25 3:42 PM, Eric Biggers wrote: > On Wed, Feb 26, 2025 at 09:11:04AM -0500, Chuck Lever wrote: >> On 2/26/25 3:38 AM, Takashi Iwai wrote: >>> On Sun, 23 Feb 2025 16:18:41 +0100, >>> Chuck Lever wrote: >>>> >>>> On 2/23/25 3:53 AM, Takashi Iwai wrote: >>>>> [ resent due to a wrong address for regression reporting, sorry! ] >>>>> >>>>> Hi, >>>>> >>>>> we received a bug report showing the regression on 6.13.1 kernel >>>>> against 6.13.0. The symptom is that Chrome and VSCode stopped working >>>>> with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker >>>>> https://bugzilla.suse.com/show_bug.cgi?id=1236943 >>>>> >>>>> Quoting from there: >>>>> """ >>>>> I use the latest TW on Gnome with a 4K display and 150% >>>>> scaling. Everything has been working fine, but recently both Chrome >>>>> and VSCode (installed from official non-openSUSE channels) stopped >>>>> working with Scaling. >>>>> .... >>>>> I am using VSCode with: >>>>> `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. >>>>> """ >>>>> >>>>> Surprisingly, the bisection pointed to the backport of the commit >>>>> b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list >>>>> to iterate simple_offset directories"). >>>>> >>>>> Indeed, the revert of this patch on the latest 6.13.4 was confirmed to >>>>> fix the issue. Also, the reporter verified that the latest 6.14-rc >>>>> release is still affected, too. >>>>> >>>>> For now I have no concrete idea how the patch could break the behavior >>>>> of a graphical application like the above. Let us know if you need >>>>> something for debugging. (Or at easiest, join to the bugzilla entry >>>>> and ask there; or open another bug report at whatever you like.) >>>>> >>>>> BTW, I'll be traveling tomorrow, so my reply will be delayed. >>>>> >>>>> >>>>> thanks, >>>>> >>>>> Takashi >>>>> >>>>> #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 >>>>> #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943 >>>> >>>> We received a similar report a few days ago, and are likewise puzzled at >>>> the commit result. Please report this issue to the Chrome development >>>> team and have them come up with a simple reproducer that I can try in my >>>> own lab. I'm sure they can quickly get to the bottom of the application >>>> stack to identify the misbehaving interaction between OS and app. >>> >>> Do you know where to report to? >> >> You'll need to drive this, since you currently have a working >> reproducer. You can report the issue here: >> >> https://support.google.com/chrome/answer/95315?hl=en&co=GENIE.Platform%3DDesktop >> >> > > FYI this was already reported on the Chrome issue tracker 2 weeks ago: > https://issuetracker.google.com/issues/396434686 That appears to be as a response to the first report to us. Thanks for finding this. I notice that this report indicates the problem is with a developer build of Chrome, not a GA build. If /dev/dri is a tmpfs file system, then it would indeed be affected by b9b588f22a0c. No indication yet of how. -- Chuck Lever
