Hi,
I notice a regression report on bugzilla [1]. Quoting from it:
> [email protected] 2023-05-14 09:55:38 UTC
>
> Since a Kernel update a few weeks ago, my laptop freezes when resuming from hibernation. It seems to handle the resume process normally but at the moment I should see Gnome login screen, I either get a black screen with just a white underscore instead, or nothing displayed at all (no backlight). I can't do anything at that point and I have to hard reboot.
>
> Steps to reproduce:
> - hibernate
> - resume
> - wait until the resuming process should finish: black screen instead of e.g. Gnome's login screen
>
> journalctl gives nothing between the beginning of the resume and the crash, as if it never happened.
>
> I have a Dell XPS 15 (9550) with Arch Linux. The issue happens on linux (since v6.2.0 I think) but linux-lts (currently v6.1.28) is fine.
>
> A bisect on linux-git gave commit da6d9c8ecd00 as the cause of the problem.
See bugzilla for the full thread.
Julien: I asked you to also provide dmesg log as I don't know
what exactly happened, but you mentioned the culprit was
da6d9c8ecd00e2 ("wifi: brcmfmac: add firmware vendor info in driver info"),
which implies that the crash involves your wifi device. From my experience
though, GDM crashes are usually caused by xwayland.
Anyway, I'm adding this to regzbot:
#regzbot introduced: da6d9c8ecd00e2 https://bugzilla.kernel.org/show_bug.cgi?id=217442
#regzbot title: brcmfmac firmware vendor info addition triggers GDM crash on resuming from hibernation
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217442
--
An old man doll... just what I always wanted! - Clara
Hi,
On 5/15/23 04:21, Bagas Sanjaya wrote:
> Hi,
>
> I notice a regression report on bugzilla [1]. Quoting from it:
>
>> [email protected] 2023-05-14 09:55:38 UTC
>>
>> Since a Kernel update a few weeks ago, my laptop freezes when resuming from hibernation. It seems to handle the resume process normally but at the moment I should see Gnome login screen, I either get a black screen with just a white underscore instead, or nothing displayed at all (no backlight). I can't do anything at that point and I have to hard reboot.
>>
>> Steps to reproduce:
>> - hibernate
>> - resume
>> - wait until the resuming process should finish: black screen instead of e.g. Gnome's login screen
>>
>> journalctl gives nothing between the beginning of the resume and the crash, as if it never happened.
>>
>> I have a Dell XPS 15 (9550) with Arch Linux. The issue happens on linux (since v6.2.0 I think) but linux-lts (currently v6.1.28) is fine.
>>
>> A bisect on linux-git gave commit da6d9c8ecd00 as the cause of the problem.
>
> See bugzilla for the full thread.
>
> Julien: I asked you to also provide dmesg log as I don't know
> what exactly happened, but you mentioned the culprit was
> da6d9c8ecd00e2 ("wifi: brcmfmac: add firmware vendor info in driver info"),
> which implies that the crash involves your wifi device. From my experience
> though, GDM crashes are usually caused by xwayland.
>
> Anyway, I'm adding this to regzbot:
>
> #regzbot introduced: da6d9c8ecd00e2 https://bugzilla.kernel.org/show_bug.cgi?id=217442
> #regzbot title: brcmfmac firmware vendor info addition triggers GDM crash on resuming from hibernation
da6d9c8ecd00e2 is known to cause a NULL pointer deref on resume,
which is likely what is happening here. This is fixed by:
https://lore.kernel.org/regressions/[email protected]/
This patch is ready for merging and is waiting for the wireless-maintainer
to merge it and send it to Linus.
Regards,
Hans
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217442
>
On 5/15/23 15:56, Hans de Goede wrote:
> Hi,
>
> On 5/15/23 04:21, Bagas Sanjaya wrote:
>> Hi,
>>
>> I notice a regression report on bugzilla [1]. Quoting from it:
>>
>>> [email protected] 2023-05-14 09:55:38 UTC
>>>
>>> Since a Kernel update a few weeks ago, my laptop freezes when resuming from hibernation. It seems to handle the resume process normally but at the moment I should see Gnome login screen, I either get a black screen with just a white underscore instead, or nothing displayed at all (no backlight). I can't do anything at that point and I have to hard reboot.
>>>
>>> Steps to reproduce:
>>> - hibernate
>>> - resume
>>> - wait until the resuming process should finish: black screen instead of e.g. Gnome's login screen
>>>
>>> journalctl gives nothing between the beginning of the resume and the crash, as if it never happened.
>>>
>>> I have a Dell XPS 15 (9550) with Arch Linux. The issue happens on linux (since v6.2.0 I think) but linux-lts (currently v6.1.28) is fine.
>>>
>>> A bisect on linux-git gave commit da6d9c8ecd00 as the cause of the problem.
>>
>> See bugzilla for the full thread.
>>
>> Julien: I asked you to also provide dmesg log as I don't know
>> what exactly happened, but you mentioned the culprit was
>> da6d9c8ecd00e2 ("wifi: brcmfmac: add firmware vendor info in driver info"),
>> which implies that the crash involves your wifi device. From my experience
>> though, GDM crashes are usually caused by xwayland.
>>
>> Anyway, I'm adding this to regzbot:
>>
>> #regzbot introduced: da6d9c8ecd00e2 https://bugzilla.kernel.org/show_bug.cgi?id=217442
>> #regzbot title: brcmfmac firmware vendor info addition triggers GDM crash on resuming from hibernation
>
> da6d9c8ecd00e2 is known to cause a NULL pointer deref on resume,
> which is likely what is happening here. This is fixed by:
>
> https://lore.kernel.org/regressions/[email protected]/
>
> This patch is ready for merging and is waiting for the wireless-maintainer
> to merge it and send it to Linus.
>
OK, thanks for the fixup!
#regzbot fix: wifi: brcmfmac: Check for probe() id argument being NULL
--
An old man doll... just what I always wanted! - Clara
On 15.05.23 15:09, Bagas Sanjaya wrote:
> On 5/15/23 15:56, Hans de Goede wrote:
>> On 5/15/23 04:21, Bagas Sanjaya wrote:
>>> I notice a regression report on bugzilla [1]. Quoting from it:
> [...]
>>>> A bisect on linux-git gave commit da6d9c8ecd00 as the cause of the problem.
>>
>> da6d9c8ecd00e2 is known to cause a NULL pointer deref on resume,
Bagas, fwiw, to prevent situations like these I usually search on lore
for a shorted variant of the commit-id[1] before telling regzbot about
it. In quite a lot of cases I find something useful that might mean that
tracking is not worth it.
Ciao, Thorsten
e.g. [1] https://lore.kernel.org/all/?q=da6d9c8*