[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e1b220d-1737-468d-af0b-6050f8cdaf8b@oracle.com>
Date: Wed, 26 Feb 2025 16:01:18 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Takashi Iwai <tiwai@...e.de>, regressions@...ts.linux.dev,
linux-fsdevel@...r.kernel.org, stable@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Chrome and VSCode breakage with the commit
b9b588f22a0c
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
Powered by blists - more mailing lists