Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

Hello,

Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD 
Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank 
screen after boot until the display manager starts... if it does start 
at all. Using the nomodeset kernel parameter seems to be a workaround.

I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4 
("drivers/firmware: Move sysfb_init() from device_initcall to 
subsys_initcall_sync").

Any ideas?

Best regards,
Jaak Ristioja


git bisect start
# status: waiting for both good and bad commits
# good: [6995e2de6891c724bfeb2db33d7b87775f913ad1] Linux 6.4
git bisect good 6995e2de6891c724bfeb2db33d7b87775f913ad1
# status: waiting for bad commit, 1 good commit known
# bad: [2dde18cd1d8fac735875f2e4987f11817cc0bc2c] Linux 6.5
git bisect bad 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
# bad: [b775d6c5859affe00527cbe74263de05cfe6b9f9] Merge tag 'mips_6.5' 
of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
git bisect bad b775d6c5859affe00527cbe74263de05cfe6b9f9
# good: [3a8a670eeeaa40d87bd38a587438952741980c18] Merge tag 
'net-next-6.5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect good 3a8a670eeeaa40d87bd38a587438952741980c18
# bad: [188d3f80fc6d8451ab5e570becd6a7b2d3033023] drm/amdgpu: vcn_4_0 
set instance 0 init sched score to 1
git bisect bad 188d3f80fc6d8451ab5e570becd6a7b2d3033023
# good: [12fb1ad70d65edc3405884792d044fa79df7244f] drm/amdkfd: update 
process interrupt handling for debug events
git bisect good 12fb1ad70d65edc3405884792d044fa79df7244f
# bad: [9cc31938d4586f72eb8e0235ad9d9eb22496fcee] i915/perf: Drop the 
aging_tail logic in perf OA
git bisect bad 9cc31938d4586f72eb8e0235ad9d9eb22496fcee
# bad: [51d86ee5e07ccef85af04ee9850b0baa107999b6] drm/msm: Switch to 
fdinfo helper
git bisect bad 51d86ee5e07ccef85af04ee9850b0baa107999b6
# good: [bfdede3a58ea970333d77a05144a7bcec13cf515] drm/rockchip: cdn-dp: 
call drm_connector_update_edid_property() unconditionally
git bisect good bfdede3a58ea970333d77a05144a7bcec13cf515
# good: [123ee07ba5b7123e0ce0e0f9d64938026c16a2ce] drm: sun4i_tcon: use 
devm_clk_get_enabled in `sun4i_tcon_init_clocks`
git bisect good 123ee07ba5b7123e0ce0e0f9d64938026c16a2ce
# bad: [20d54e48d9c705091a025afff5839da2ea606f6b] fbdev: Rename 
fb_mem*() helpers
git bisect bad 20d54e48d9c705091a025afff5839da2ea606f6b
# bad: [728cb3f061e2b3a002fd76d91c2449b1497b6640] gpu: drm: bridge: No 
need to set device_driver owner
git bisect bad 728cb3f061e2b3a002fd76d91c2449b1497b6640
# bad: [0f1cb4d777281ca3360dbc8959befc488e0c327e] drm/ssd130x: Fix 
include guard name
git bisect bad 0f1cb4d777281ca3360dbc8959befc488e0c327e
# good: [0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630] dt-bindings: display: 
simple: Add BOE EV121WXM-N10-1850 panel
git bisect good 0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630
# bad: [60aebc9559492cea6a9625f514a8041717e3a2e4] drivers/firmware: Move 
sysfb_init() from device_initcall to subsys_initcall_sync
git bisect bad 60aebc9559492cea6a9625f514a8041717e3a2e4
# good: [8bb7c7bca5b70f3cd22d95b4d36029295c4274f6] drm/panel: 
panel-simple: Add BOE EV121WXM-N10-1850 panel support
git bisect good 8bb7c7bca5b70f3cd22d95b4d36029295c4274f6
# first bad commit: [60aebc9559492cea6a9625f514a8041717e3a2e4] 
drivers/firmware: Move sysfb_init() from device_initcall to 
subsys_initcall_sync

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Wed, Sep 13, 2023 at 03:02:26PM +0300, Jaak Ristioja wrote:
> Hello,
> 
> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank screen
> after boot until the display manager starts... if it does start at all.
> Using the nomodeset kernel parameter seems to be a workaround.
> 
> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> ("drivers/firmware: Move sysfb_init() from device_initcall to
> subsys_initcall_sync").
> 

Thanks for the regression report. I'm adding it to regzbot:

#regzbot ^introduced: 60aebc9559492c

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Linux regression tracking (Thorsten Leemhuis)]

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

Hi, Thorsten here, the Linux kernel's regression tracker.

On 13.09.23 14:02, Jaak Ristioja wrote:
> 
> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> screen after boot until the display manager starts... if it does start
> at all. Using the nomodeset kernel parameter seems to be a workaround.
> 
> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> ("drivers/firmware: Move sysfb_init() from device_initcall to
> subsys_initcall_sync").

Hmmm, no reaction since it was posted a while ago, unless I'm missing
something.

Huacai Chen, did you maybe miss this report? The problem is apparently
caused by a commit of yours (that Javier applied), you hence should look
into this.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

> git bisect start
> # status: waiting for both good and bad commits
> # good: [6995e2de6891c724bfeb2db33d7b87775f913ad1] Linux 6.4
> git bisect good 6995e2de6891c724bfeb2db33d7b87775f913ad1
> # status: waiting for bad commit, 1 good commit known
> # bad: [2dde18cd1d8fac735875f2e4987f11817cc0bc2c] Linux 6.5
> git bisect bad 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> # bad: [b775d6c5859affe00527cbe74263de05cfe6b9f9] Merge tag 'mips_6.5'
> of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
> git bisect bad b775d6c5859affe00527cbe74263de05cfe6b9f9
> # good: [3a8a670eeeaa40d87bd38a587438952741980c18] Merge tag
> 'net-next-6.5' of
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect good 3a8a670eeeaa40d87bd38a587438952741980c18
> # bad: [188d3f80fc6d8451ab5e570becd6a7b2d3033023] drm/amdgpu: vcn_4_0
> set instance 0 init sched score to 1
> git bisect bad 188d3f80fc6d8451ab5e570becd6a7b2d3033023
> # good: [12fb1ad70d65edc3405884792d044fa79df7244f] drm/amdkfd: update
> process interrupt handling for debug events
> git bisect good 12fb1ad70d65edc3405884792d044fa79df7244f
> # bad: [9cc31938d4586f72eb8e0235ad9d9eb22496fcee] i915/perf: Drop the
> aging_tail logic in perf OA
> git bisect bad 9cc31938d4586f72eb8e0235ad9d9eb22496fcee
> # bad: [51d86ee5e07ccef85af04ee9850b0baa107999b6] drm/msm: Switch to
> fdinfo helper
> git bisect bad 51d86ee5e07ccef85af04ee9850b0baa107999b6
> # good: [bfdede3a58ea970333d77a05144a7bcec13cf515] drm/rockchip: cdn-dp:
> call drm_connector_update_edid_property() unconditionally
> git bisect good bfdede3a58ea970333d77a05144a7bcec13cf515
> # good: [123ee07ba5b7123e0ce0e0f9d64938026c16a2ce] drm: sun4i_tcon: use
> devm_clk_get_enabled in `sun4i_tcon_init_clocks`
> git bisect good 123ee07ba5b7123e0ce0e0f9d64938026c16a2ce
> # bad: [20d54e48d9c705091a025afff5839da2ea606f6b] fbdev: Rename
> fb_mem*() helpers
> git bisect bad 20d54e48d9c705091a025afff5839da2ea606f6b
> # bad: [728cb3f061e2b3a002fd76d91c2449b1497b6640] gpu: drm: bridge: No
> need to set device_driver owner
> git bisect bad 728cb3f061e2b3a002fd76d91c2449b1497b6640
> # bad: [0f1cb4d777281ca3360dbc8959befc488e0c327e] drm/ssd130x: Fix
> include guard name
> git bisect bad 0f1cb4d777281ca3360dbc8959befc488e0c327e
> # good: [0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630] dt-bindings: display:
> simple: Add BOE EV121WXM-N10-1850 panel
> git bisect good 0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630
> # bad: [60aebc9559492cea6a9625f514a8041717e3a2e4] drivers/firmware: Move
> sysfb_init() from device_initcall to subsys_initcall_sync
> git bisect bad 60aebc9559492cea6a9625f514a8041717e3a2e4
> # good: [8bb7c7bca5b70f3cd22d95b4d36029295c4274f6] drm/panel:
> panel-simple: Add BOE EV121WXM-N10-1850 panel support
> git bisect good 8bb7c7bca5b70f3cd22d95b4d36029295c4274f6
> # first bad commit: [60aebc9559492cea6a9625f514a8041717e3a2e4]
> drivers/firmware: Move sysfb_init() from device_initcall to
> subsys_initcall_sync

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, all,

On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> [CCing the regression list, as it should be in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> On 13.09.23 14:02, Jaak Ristioja wrote:
> >
> > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > screen after boot until the display manager starts... if it does start
> > at all. Using the nomodeset kernel parameter seems to be a workaround.
> >
> > I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > ("drivers/firmware: Move sysfb_init() from device_initcall to
> > subsys_initcall_sync").
>
> Hmmm, no reaction since it was posted a while ago, unless I'm missing
> something.
>
> Huacai Chen, did you maybe miss this report? The problem is apparently
> caused by a commit of yours (that Javier applied), you hence should look
> into this.
I'm sorry but it looks very strange, could you please share your config file?

Huacai

>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> > git bisect start
> > # status: waiting for both good and bad commits
> > # good: [6995e2de6891c724bfeb2db33d7b87775f913ad1] Linux 6.4
> > git bisect good 6995e2de6891c724bfeb2db33d7b87775f913ad1
> > # status: waiting for bad commit, 1 good commit known
> > # bad: [2dde18cd1d8fac735875f2e4987f11817cc0bc2c] Linux 6.5
> > git bisect bad 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> > # bad: [b775d6c5859affe00527cbe74263de05cfe6b9f9] Merge tag 'mips_6.5'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
> > git bisect bad b775d6c5859affe00527cbe74263de05cfe6b9f9
> > # good: [3a8a670eeeaa40d87bd38a587438952741980c18] Merge tag
> > 'net-next-6.5' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> > git bisect good 3a8a670eeeaa40d87bd38a587438952741980c18
> > # bad: [188d3f80fc6d8451ab5e570becd6a7b2d3033023] drm/amdgpu: vcn_4_0
> > set instance 0 init sched score to 1
> > git bisect bad 188d3f80fc6d8451ab5e570becd6a7b2d3033023
> > # good: [12fb1ad70d65edc3405884792d044fa79df7244f] drm/amdkfd: update
> > process interrupt handling for debug events
> > git bisect good 12fb1ad70d65edc3405884792d044fa79df7244f
> > # bad: [9cc31938d4586f72eb8e0235ad9d9eb22496fcee] i915/perf: Drop the
> > aging_tail logic in perf OA
> > git bisect bad 9cc31938d4586f72eb8e0235ad9d9eb22496fcee
> > # bad: [51d86ee5e07ccef85af04ee9850b0baa107999b6] drm/msm: Switch to
> > fdinfo helper
> > git bisect bad 51d86ee5e07ccef85af04ee9850b0baa107999b6
> > # good: [bfdede3a58ea970333d77a05144a7bcec13cf515] drm/rockchip: cdn-dp:
> > call drm_connector_update_edid_property() unconditionally
> > git bisect good bfdede3a58ea970333d77a05144a7bcec13cf515
> > # good: [123ee07ba5b7123e0ce0e0f9d64938026c16a2ce] drm: sun4i_tcon: use
> > devm_clk_get_enabled in `sun4i_tcon_init_clocks`
> > git bisect good 123ee07ba5b7123e0ce0e0f9d64938026c16a2ce
> > # bad: [20d54e48d9c705091a025afff5839da2ea606f6b] fbdev: Rename
> > fb_mem*() helpers
> > git bisect bad 20d54e48d9c705091a025afff5839da2ea606f6b
> > # bad: [728cb3f061e2b3a002fd76d91c2449b1497b6640] gpu: drm: bridge: No
> > need to set device_driver owner
> > git bisect bad 728cb3f061e2b3a002fd76d91c2449b1497b6640
> > # bad: [0f1cb4d777281ca3360dbc8959befc488e0c327e] drm/ssd130x: Fix
> > include guard name
> > git bisect bad 0f1cb4d777281ca3360dbc8959befc488e0c327e
> > # good: [0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630] dt-bindings: display:
> > simple: Add BOE EV121WXM-N10-1850 panel
> > git bisect good 0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630
> > # bad: [60aebc9559492cea6a9625f514a8041717e3a2e4] drivers/firmware: Move
> > sysfb_init() from device_initcall to subsys_initcall_sync
> > git bisect bad 60aebc9559492cea6a9625f514a8041717e3a2e4
> > # good: [8bb7c7bca5b70f3cd22d95b4d36029295c4274f6] drm/panel:
> > panel-simple: Add BOE EV121WXM-N10-1850 panel support
> > git bisect good 8bb7c7bca5b70f3cd22d95b4d36029295c4274f6
> > # first bad commit: [60aebc9559492cea6a9625f514a8041717e3a2e4]
> > drivers/firmware: Move sysfb_init() from device_initcall to
> > subsys_initcall_sync

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, all,

On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> Hi, all,
>
> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
> >
> > [CCing the regression list, as it should be in the loop for regressions:
> > https://docs.kernel.org/admin-guide/reporting-regressions.html]
> >
> > Hi, Thorsten here, the Linux kernel's regression tracker.
> >
> > On 13.09.23 14:02, Jaak Ristioja wrote:
> > >
> > > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > screen after boot until the display manager starts... if it does start
> > > at all. Using the nomodeset kernel parameter seems to be a workaround.
> > >
> > > I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > subsys_initcall_sync").
> >
> > Hmmm, no reaction since it was posted a while ago, unless I'm missing
> > something.
> >
> > Huacai Chen, did you maybe miss this report? The problem is apparently
> > caused by a commit of yours (that Javier applied), you hence should look
> > into this.
> I'm sorry but it looks very strange, could you please share your config file?
As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
again. So I guess the reason:

When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
sysfb_init() from device_initcall to subsys_initcall_sync") there is
no platform device created for SIMPLEDRM at early stage, so it seems
also "no problem".

Huacai


>
> Huacai
>
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> >
> > > git bisect start
> > > # status: waiting for both good and bad commits
> > > # good: [6995e2de6891c724bfeb2db33d7b87775f913ad1] Linux 6.4
> > > git bisect good 6995e2de6891c724bfeb2db33d7b87775f913ad1
> > > # status: waiting for bad commit, 1 good commit known
> > > # bad: [2dde18cd1d8fac735875f2e4987f11817cc0bc2c] Linux 6.5
> > > git bisect bad 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> > > # bad: [b775d6c5859affe00527cbe74263de05cfe6b9f9] Merge tag 'mips_6.5'
> > > of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
> > > git bisect bad b775d6c5859affe00527cbe74263de05cfe6b9f9
> > > # good: [3a8a670eeeaa40d87bd38a587438952741980c18] Merge tag
> > > 'net-next-6.5' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> > > git bisect good 3a8a670eeeaa40d87bd38a587438952741980c18
> > > # bad: [188d3f80fc6d8451ab5e570becd6a7b2d3033023] drm/amdgpu: vcn_4_0
> > > set instance 0 init sched score to 1
> > > git bisect bad 188d3f80fc6d8451ab5e570becd6a7b2d3033023
> > > # good: [12fb1ad70d65edc3405884792d044fa79df7244f] drm/amdkfd: update
> > > process interrupt handling for debug events
> > > git bisect good 12fb1ad70d65edc3405884792d044fa79df7244f
> > > # bad: [9cc31938d4586f72eb8e0235ad9d9eb22496fcee] i915/perf: Drop the
> > > aging_tail logic in perf OA
> > > git bisect bad 9cc31938d4586f72eb8e0235ad9d9eb22496fcee
> > > # bad: [51d86ee5e07ccef85af04ee9850b0baa107999b6] drm/msm: Switch to
> > > fdinfo helper
> > > git bisect bad 51d86ee5e07ccef85af04ee9850b0baa107999b6
> > > # good: [bfdede3a58ea970333d77a05144a7bcec13cf515] drm/rockchip: cdn-dp:
> > > call drm_connector_update_edid_property() unconditionally
> > > git bisect good bfdede3a58ea970333d77a05144a7bcec13cf515
> > > # good: [123ee07ba5b7123e0ce0e0f9d64938026c16a2ce] drm: sun4i_tcon: use
> > > devm_clk_get_enabled in `sun4i_tcon_init_clocks`
> > > git bisect good 123ee07ba5b7123e0ce0e0f9d64938026c16a2ce
> > > # bad: [20d54e48d9c705091a025afff5839da2ea606f6b] fbdev: Rename
> > > fb_mem*() helpers
> > > git bisect bad 20d54e48d9c705091a025afff5839da2ea606f6b
> > > # bad: [728cb3f061e2b3a002fd76d91c2449b1497b6640] gpu: drm: bridge: No
> > > need to set device_driver owner
> > > git bisect bad 728cb3f061e2b3a002fd76d91c2449b1497b6640
> > > # bad: [0f1cb4d777281ca3360dbc8959befc488e0c327e] drm/ssd130x: Fix
> > > include guard name
> > > git bisect bad 0f1cb4d777281ca3360dbc8959befc488e0c327e
> > > # good: [0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630] dt-bindings: display:
> > > simple: Add BOE EV121WXM-N10-1850 panel
> > > git bisect good 0bd5bd65cd2e4d1335ea6c17cd2c8664decbc630
> > > # bad: [60aebc9559492cea6a9625f514a8041717e3a2e4] drivers/firmware: Move
> > > sysfb_init() from device_initcall to subsys_initcall_sync
> > > git bisect bad 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > # good: [8bb7c7bca5b70f3cd22d95b4d36029295c4274f6] drm/panel:
> > > panel-simple: Add BOE EV121WXM-N10-1850 panel support
> > > git bisect good 8bb7c7bca5b70f3cd22d95b4d36029295c4274f6
> > > # first bad commit: [60aebc9559492cea6a9625f514a8041717e3a2e4]
> > > drivers/firmware: Move sysfb_init() from device_initcall to
> > > subsys_initcall_sync

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> Hi, all,
> 
> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >
> > Hi, all,
> >
> > On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > Leemhuis) <regressions@leemhuis.info> wrote:
> > >
> > > [CCing the regression list, as it should be in the loop for regressions:
> > > https://docs.kernel.org/admin-guide/reporting-regressions.html]
> > >
> > > Hi, Thorsten here, the Linux kernel's regression tracker.
> > >
> > > On 13.09.23 14:02, Jaak Ristioja wrote:
> > > >
> > > > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > screen after boot until the display manager starts... if it does start
> > > > at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > >
> > > > I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > subsys_initcall_sync").
> > >
> > > Hmmm, no reaction since it was posted a while ago, unless I'm missing
> > > something.
> > >
> > > Huacai Chen, did you maybe miss this report? The problem is apparently
> > > caused by a commit of yours (that Javier applied), you hence should look
> > > into this.
> > I'm sorry but it looks very strange, could you please share your config file?
> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> again. So I guess the reason:

Did Jaak reply privately? It should have been disclosed in public
ML here instead.

> 
> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> no platform device created for SIMPLEDRM at early stage, so it seems
> also "no problem".

I don't understand above. You mean that after that commit the platform
device is also none, right?

Confused...

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > Hi, all,
> >
> > On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >
> > > Hi, all,
> > >
> > > On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > Leemhuis) <regressions@leemhuis.info> wrote:
> > > >
> > > > [CCing the regression list, as it should be in the loop for regressions:
> > > > https://docs.kernel.org/admin-guide/reporting-regressions.html]
> > > >
> > > > Hi, Thorsten here, the Linux kernel's regression tracker.
> > > >
> > > > On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > >
> > > > > Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > > Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > > screen after boot until the display manager starts... if it does start
> > > > > at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > >
> > > > > I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > > ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > > subsys_initcall_sync").
> > > >
> > > > Hmmm, no reaction since it was posted a while ago, unless I'm missing
> > > > something.
> > > >
> > > > Huacai Chen, did you maybe miss this report? The problem is apparently
> > > > caused by a commit of yours (that Javier applied), you hence should look
> > > > into this.
> > > I'm sorry but it looks very strange, could you please share your config file?
> > As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > again. So I guess the reason:
>
> Did Jaak reply privately? It should have been disclosed in public
> ML here instead.
Yes, he replied privately, and disabling DRM_SIMPLEDRM was suggested by me.

>
> >
> > When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > no platform device created for SIMPLEDRM at early stage, so it seems
> > also "no problem".
>
> I don't understand above. You mean that after that commit the platform
> device is also none, right?
No. The SIMPLEDRM driver needs a platform device to work, and that
commit makes the platform device created earlier. So, before that
commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
commit, SIMPLEDRM works, but the screen is blank.

Huacai
>
> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Linux regression tracking (Thorsten Leemhuis)]

On 09.10.23 10:54, Huacai Chen wrote:
> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>
>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>> screen after boot until the display manager starts... if it does start
>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>
>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>> subsys_initcall_sync").
>>>>>
>>>>> Hmmm, no reaction since it was posted a while ago, unless I'm missing
>>>>> something.
>>>>>
>>>>> Huacai Chen, did you maybe miss this report? The problem is apparently
>>>>> caused by a commit of yours (that Javier applied), you hence should look
>>>>> into this.
>>>> I'm sorry but it looks very strange, could you please share your config file?
>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>> again. So I guess the reason:
>>
>> Did Jaak reply privately? It should have been disclosed in public
>> ML here instead.
> Yes, he replied privately, and disabling DRM_SIMPLEDRM was suggested by me.

Well, this to me still looks a lot (please correct me if I'm wrong) like
regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
if I understood things correctly. Or is there a proper fix for this
already in the works and I just missed this? Or is there some good
reason why this won't/can't be fixed?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>> also "no problem".
>>
>> I don't understand above. You mean that after that commit the platform
>> device is also none, right?
> No. The SIMPLEDRM driver needs a platform device to work, and that
> commit makes the platform device created earlier. So, before that
> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> commit, SIMPLEDRM works, but the screen is blank.
> 
> Huacai
>>
>> Confused...
>>
>> --
>> An old man doll... just what I always wanted! - Clara
> 
> 

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 09.10.23 10:54, Huacai Chen wrote:
> > On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>
> >>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>> screen after boot until the display manager starts... if it does start
> >>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>
> >>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>> subsys_initcall_sync").
> >>>>>
> >>>>> Hmmm, no reaction since it was posted a while ago, unless I'm missing
> >>>>> something.
> >>>>>
> >>>>> Huacai Chen, did you maybe miss this report? The problem is apparently
> >>>>> caused by a commit of yours (that Javier applied), you hence should look
> >>>>> into this.
> >>>> I'm sorry but it looks very strange, could you please share your config file?
> >>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>> again. So I guess the reason:
> >>
> >> Did Jaak reply privately? It should have been disclosed in public
> >> ML here instead.
> > Yes, he replied privately, and disabling DRM_SIMPLEDRM was suggested by me.
>
> Well, this to me still looks a lot (please correct me if I'm wrong) like
> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> if I understood things correctly. Or is there a proper fix for this
> already in the works and I just missed this? Or is there some good
> reason why this won't/can't be fixed?
DRM_SIMPLEDRM was enabled but it didn't work at all because there was
no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
blank screen. Of course it is valuable to investigate further about
DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
I don't have a same machine.

Huacai
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke
>
> >>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>> also "no problem".
> >>
> >> I don't understand above. You mean that after that commit the platform
> >> device is also none, right?
> > No. The SIMPLEDRM driver needs a platform device to work, and that
> > commit makes the platform device created earlier. So, before that
> > commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > commit, SIMPLEDRM works, but the screen is blank.
> >
> > Huacai
> >>
> >> Confused...
> >>
> >> --
> >> An old man doll... just what I always wanted! - Clara
> >
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
> >
> > On 09.10.23 10:54, Huacai Chen wrote:
> > > On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > >> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > >>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > >>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > >>>>>>
> > >>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > >>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > >>>>>> screen after boot until the display manager starts... if it does start
> > >>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > >>>>>>
> > >>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > >>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > >>>>>> subsys_initcall_sync").
> > >>>>>
> > >>>>> Hmmm, no reaction since it was posted a while ago, unless I'm missing
> > >>>>> something.
> > >>>>>
> > >>>>> Huacai Chen, did you maybe miss this report? The problem is apparently
> > >>>>> caused by a commit of yours (that Javier applied), you hence should look
> > >>>>> into this.
> > >>>> I'm sorry but it looks very strange, could you please share your config file?
> > >>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > >>> again. So I guess the reason:
> > >>
> > >> Did Jaak reply privately? It should have been disclosed in public
> > >> ML here instead.
> > > Yes, he replied privately, and disabling DRM_SIMPLEDRM was suggested by me.
> >
> > Well, this to me still looks a lot (please correct me if I'm wrong) like
> > regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > if I understood things correctly. Or is there a proper fix for this
> > already in the works and I just missed this? Or is there some good
> > reason why this won't/can't be fixed?
> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> blank screen. Of course it is valuable to investigate further about
> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> I don't have a same machine.
> 
> Huacai

I am having the same issue on a Lenovo Thinkpad P70 (Intel Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).  Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank screen after boot and a rapidly flashing device-access-status indicator.

> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> >
> > #regzbot poke
> >
> > >>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > >>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > >>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > >>> no platform device created for SIMPLEDRM at early stage, so it seems
> > >>> also "no problem".
> > >>
> > >> I don't understand above. You mean that after that commit the platform
> > >> device is also none, right?
> > > No. The SIMPLEDRM driver needs a platform device to work, and that
> > > commit makes the platform device created earlier. So, before that
> > > commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > commit, SIMPLEDRM works, but the screen is blank.
> > >
> > > Huacai
> > >>
> > >> Confused...
> > >>
> > >> --
> > >> An old man doll... just what I always wanted! - Clara
> > >
> > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Thorsten Leemhuis]

Javier, Dave, Sima,

On 23.10.23 00:54, Evan Preston wrote:
> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>> Leemhuis) <regressions@leemhuis.info> wrote:
>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>
>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>
>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>> subsys_initcall_sync").
>>>>>>>>
>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>> again. So I guess the reason:
>>>
>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>> if I understood things correctly. Or is there a proper fix for this
>>> already in the works and I just missed this? Or is there some good
>>> reason why this won't/can't be fixed?
>>
>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>> blank screen. Of course it is valuable to investigate further about
>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>> I don't have a same machine.

Side note: Huacai, have you tried working with Jaak to get down to the
real problem? Evan, might you be able to help out here?

But I write this mail for a different reason:

> I am having the same issue on a Lenovo Thinkpad P70 (Intel 
> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> screen after boot and a rapidly flashing device-access-status
> indicator.

This additional report makes me wonder if we should revert the culprit
(60aebc9559492c ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
might lead to regressions for some users? But the patch description says
that this is not a common configuration, so can we maybe get away with that?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>> also "no problem".
>>>>> I don't understand above. You mean that after that commit the platform
>>>>> device is also none, right?
>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>> commit makes the platform device created earlier. So, before that
>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>
>>>> Huacai
>>>>>
>>>>> Confused...
>>>>>
>>>>> --
>>>>> An old man doll... just what I always wanted! - Clara
>>>>
>>>>
> 
> 

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Javier, Dave, Sima,
>
> On 23.10.23 00:54, Evan Preston wrote:
> > On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >> Leemhuis) <regressions@leemhuis.info> wrote:
> >>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>
> >>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>
> >>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>> subsys_initcall_sync").
> >>>>>>>>
> >>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>> again. So I guess the reason:
> >>>
> >>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>> if I understood things correctly. Or is there a proper fix for this
> >>> already in the works and I just missed this? Or is there some good
> >>> reason why this won't/can't be fixed?
> >>
> >> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >> blank screen. Of course it is valuable to investigate further about
> >> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >> I don't have a same machine.
>
> Side note: Huacai, have you tried working with Jaak to get down to the
> real problem? Evan, might you be able to help out here?
No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.

>
> But I write this mail for a different reason:
>
> > I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > screen after boot and a rapidly flashing device-access-status
> > indicator.
>
> This additional report makes me wonder if we should revert the culprit
> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> might lead to regressions for some users? But the patch description says
> that this is not a common configuration, so can we maybe get away with that?
From my point of view, this is not a regression, 60aebc9559492c
doesn't cause a problem, but exposes a problem. So we need to fix the
real problem (SIMPLEDRM has a blank screen on some conditions). This
needs Jaak or Evan's help.

Huacai
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> >>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>> also "no problem".
> >>>>> I don't understand above. You mean that after that commit the platform
> >>>>> device is also none, right?
> >>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>> commit makes the platform device created earlier. So, before that
> >>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>
> >>>> Huacai
> >>>>>
> >>>>> Confused...
> >>>>>
> >>>>> --
> >>>>> An old man doll... just what I always wanted! - Clara
> >>>>
> >>>>
> >
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Javier Martinez Canillas]

Huacai Chen <chenhuacai@kernel.org> writes:

Hello,

> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:

[...]

>>
>> This additional report makes me wonder if we should revert the culprit
>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>> might lead to regressions for some users? But the patch description says
>> that this is not a common configuration, so can we maybe get away with that?
> From my point of view, this is not a regression, 60aebc9559492c
> doesn't cause a problem, but exposes a problem. So we need to fix the
> real problem (SIMPLEDRM has a blank screen on some conditions). This
> needs Jaak or Evan's help.
>

I agree with this.

> Huacai

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Linux regression tracking (Thorsten Leemhuis)]

On 25.10.23 15:23, Huacai Chen wrote:
> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>>
>> Javier, Dave, Sima,
>>
>> On 23.10.23 00:54, Evan Preston wrote:
>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>
>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>
>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>
>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>> again. So I guess the reason:
>>>>>
>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>> already in the works and I just missed this? Or is there some good
>>>>> reason why this won't/can't be fixed?
>>>>
>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>> blank screen. Of course it is valuable to investigate further about
>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>> I don't have a same machine.
>>
>> Side note: Huacai, have you tried working with Jaak to get down to the
>> real problem? Evan, might you be able to help out here?
> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.

Yeah, understood, already suspected something like that, thx for confirming.

>> But I write this mail for a different reason:
>>
>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>> screen after boot and a rapidly flashing device-access-status
>>> indicator.
>>
>> This additional report makes me wonder if we should revert the culprit
>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>> might lead to regressions for some users? But the patch description says
>> that this is not a common configuration, so can we maybe get away with that?
>>From my point of view, this is not a regression, 60aebc9559492c
> doesn't cause a problem, but exposes a problem.

From my understanding of Linus stance in cases like this I think that
aspect doesn't matter. To for example quote
https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/

""
But it ended up exposing another problem, and as such caused a kernel
upgrade to fail for a user. So it got reverted.
"""

For other examples of his view see the bottom half of
https://docs.kernel.org/process/handling-regressions.html

We could bring Linus in to clarify if needed, but I for now didn't CC
him, as I hope we can solve this without him.

> So we need to fix the
> real problem (SIMPLEDRM has a blank screen on some conditions). This
> needs Jaak or Evan's help.

I'm all for solving the real problem, but if that is not possible within
a reasonable timeframe (which seems to be the case here) I assume Linus
in cases like this would want the culprit to be reverted. Unless of
cause that itself might cause a regression (which is possible, as the
commit made it into 6.5), then things become tricky.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>> also "no problem".
>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>> device is also none, right?
>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>> commit makes the platform device created earlier. So, before that
>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>
>>>>>> Huacai
>>>>>>>
>>>>>>> Confused...
>>>>>>>
>>>>>>> --
>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>
>>>>>>
>>>
>>>
> 
> 

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

On 25.10.23 16:23, Huacai Chen wrote:
> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>>
>> Javier, Dave, Sima,
>>
>> On 23.10.23 00:54, Evan Preston wrote:
>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>
>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>
>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>
>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>> again. So I guess the reason:
>>>>>
>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>> already in the works and I just missed this? Or is there some good
>>>>> reason why this won't/can't be fixed?
>>>>
>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>> blank screen. Of course it is valuable to investigate further about
>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>> I don't have a same machine.
>>
>> Side note: Huacai, have you tried working with Jaak to get down to the
>> real problem? Evan, might you be able to help out here?
> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> 

I'm sorry, what was it exactly you want me to do? Please be mindful that 
I'm not familiar with the internals of the Linux kernel and DRI, and it 
might sometimes take weeks before I have time to work and respond on this.

Jaak

>>
>> But I write this mail for a different reason:
>>
>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>> screen after boot and a rapidly flashing device-access-status
>>> indicator.
>>
>> This additional report makes me wonder if we should revert the culprit
>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>> might lead to regressions for some users? But the patch description says
>> that this is not a common configuration, so can we maybe get away with that?
>  From my point of view, this is not a regression, 60aebc9559492c
> doesn't cause a problem, but exposes a problem. So we need to fix the
> real problem (SIMPLEDRM has a blank screen on some conditions). This
> needs Jaak or Evan's help.
> 
> Huacai
>>
>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> --
>> Everything you wanna know about Linux kernel regression tracking:
>> https://linux-regtracking.leemhuis.info/about/#tldr
>> If I did something stupid, please tell me, as explained on that page.
>>
>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>> also "no problem".
>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>> device is also none, right?
>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>> commit makes the platform device created earlier. So, before that
>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>
>>>>>> Huacai
>>>>>>>
>>>>>>> Confused...
>>>>>>>
>>>>>>> --
>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>
>>>>>>
>>>
>>>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Jaak,

On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 25.10.23 16:23, Huacai Chen wrote:
> > On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > <regressions@leemhuis.info> wrote:
> >>
> >> Javier, Dave, Sima,
> >>
> >> On 23.10.23 00:54, Evan Preston wrote:
> >>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>
> >>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>
> >>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>> again. So I guess the reason:
> >>>>>
> >>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>> already in the works and I just missed this? Or is there some good
> >>>>> reason why this won't/can't be fixed?
> >>>>
> >>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>> blank screen. Of course it is valuable to investigate further about
> >>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>> I don't have a same machine.
> >>
> >> Side note: Huacai, have you tried working with Jaak to get down to the
> >> real problem? Evan, might you be able to help out here?
> > No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >
>
> I'm sorry, what was it exactly you want me to do? Please be mindful that
> I'm not familiar with the internals of the Linux kernel and DRI, and it
> might sometimes take weeks before I have time to work and respond on this.
It doesn't matter. I hope you can do some experiments to investigate
deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
whether there is also a blank screen. If no blank screen, that
probably means SIMPLEDRM has a bug, if still blank screen, that means
the firmware may pass wrong screen information.

Huacai

>
> Jaak
>
> >>
> >> But I write this mail for a different reason:
> >>
> >>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>> screen after boot and a rapidly flashing device-access-status
> >>> indicator.
> >>
> >> This additional report makes me wonder if we should revert the culprit
> >> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >> might lead to regressions for some users? But the patch description says
> >> that this is not a common configuration, so can we maybe get away with that?
> >  From my point of view, this is not a regression, 60aebc9559492c
> > doesn't cause a problem, but exposes a problem. So we need to fix the
> > real problem (SIMPLEDRM has a blank screen on some conditions). This
> > needs Jaak or Evan's help.
> >
> > Huacai
> >>
> >> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >> --
> >> Everything you wanna know about Linux kernel regression tracking:
> >> https://linux-regtracking.leemhuis.info/about/#tldr
> >> If I did something stupid, please tell me, as explained on that page.
> >>
> >>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>> also "no problem".
> >>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>> device is also none, right?
> >>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>> commit makes the platform device created earlier. So, before that
> >>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>
> >>>>>> Huacai
> >>>>>>>
> >>>>>>> Confused...
> >>>>>>>
> >>>>>>> --
> >>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>
> >>>>>>
> >>>
> >>>
>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

On 26.10.23 03:58, Huacai Chen wrote:
> Hi, Jaak,
> 
> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>
>> On 25.10.23 16:23, Huacai Chen wrote:
>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
>>> <regressions@leemhuis.info> wrote:
>>>>
>>>> Javier, Dave, Sima,
>>>>
>>>> On 23.10.23 00:54, Evan Preston wrote:
>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>>>
>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>>>> again. So I guess the reason:
>>>>>>>
>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>>>> already in the works and I just missed this? Or is there some good
>>>>>>> reason why this won't/can't be fixed?
>>>>>>
>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>>>> blank screen. Of course it is valuable to investigate further about
>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>>>> I don't have a same machine.
>>>>
>>>> Side note: Huacai, have you tried working with Jaak to get down to the
>>>> real problem? Evan, might you be able to help out here?
>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
>>>
>>
>> I'm sorry, what was it exactly you want me to do? Please be mindful that
>> I'm not familiar with the internals of the Linux kernel and DRI, and it
>> might sometimes take weeks before I have time to work and respond on this.
> It doesn't matter. I hope you can do some experiments to investigate
> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> whether there is also a blank screen. If no blank screen, that
> probably means SIMPLEDRM has a bug, if still blank screen, that means
> the firmware may pass wrong screen information.

Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and 
get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.

Jaak

> 
> Huacai
> 
>>
>> Jaak
>>
>>>>
>>>> But I write this mail for a different reason:
>>>>
>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>>>> screen after boot and a rapidly flashing device-access-status
>>>>> indicator.
>>>>
>>>> This additional report makes me wonder if we should revert the culprit
>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>>>> might lead to regressions for some users? But the patch description says
>>>> that this is not a common configuration, so can we maybe get away with that?
>>>   From my point of view, this is not a regression, 60aebc9559492c
>>> doesn't cause a problem, but exposes a problem. So we need to fix the
>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
>>> needs Jaak or Evan's help.
>>>
>>> Huacai
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>> --
>>>> Everything you wanna know about Linux kernel regression tracking:
>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>> If I did something stupid, please tell me, as explained on that page.
>>>>
>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>>>> also "no problem".
>>>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>>>> device is also none, right?
>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>>>> commit makes the platform device created earlier. So, before that
>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>>>
>>>>>>>> Huacai
>>>>>>>>>
>>>>>>>>> Confused...
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 26.10.23 03:58, Huacai Chen wrote:
> > Hi, Jaak,
> >
> > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>
> >> On 25.10.23 16:23, Huacai Chen wrote:
> >>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> >>> <regressions@leemhuis.info> wrote:
> >>>>
> >>>> Javier, Dave, Sima,
> >>>>
> >>>> On 23.10.23 00:54, Evan Preston wrote:
> >>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>>>
> >>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>>>> again. So I guess the reason:
> >>>>>>>
> >>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>>>> already in the works and I just missed this? Or is there some good
> >>>>>>> reason why this won't/can't be fixed?
> >>>>>>
> >>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>>>> blank screen. Of course it is valuable to investigate further about
> >>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>>>> I don't have a same machine.
> >>>>
> >>>> Side note: Huacai, have you tried working with Jaak to get down to the
> >>>> real problem? Evan, might you be able to help out here?
> >>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >>>
> >>
> >> I'm sorry, what was it exactly you want me to do? Please be mindful that
> >> I'm not familiar with the internals of the Linux kernel and DRI, and it
> >> might sometimes take weeks before I have time to work and respond on this.
> > It doesn't matter. I hope you can do some experiments to investigate
> > deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > whether there is also a blank screen. If no blank screen, that
> > probably means SIMPLEDRM has a bug, if still blank screen, that means
> > the firmware may pass wrong screen information.
>
> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
is that DRM_SIMPLEDRM has a bug. The next step is to enable
CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
some printk() in simpledrm_probe() and its sub-routines to see where
the driver fails. The output of these printk() can be seen by the
'dmesg' command after boot.

Huacai

>
> Jaak
>
> >
> > Huacai
> >
> >>
> >> Jaak
> >>
> >>>>
> >>>> But I write this mail for a different reason:
> >>>>
> >>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>>>> screen after boot and a rapidly flashing device-access-status
> >>>>> indicator.
> >>>>
> >>>> This additional report makes me wonder if we should revert the culprit
> >>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >>>> might lead to regressions for some users? But the patch description says
> >>>> that this is not a common configuration, so can we maybe get away with that?
> >>>   From my point of view, this is not a regression, 60aebc9559492c
> >>> doesn't cause a problem, but exposes a problem. So we need to fix the
> >>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> >>> needs Jaak or Evan's help.
> >>>
> >>> Huacai
> >>>>
> >>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>> --
> >>>> Everything you wanna know about Linux kernel regression tracking:
> >>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>> If I did something stupid, please tell me, as explained on that page.
> >>>>
> >>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>>>> also "no problem".
> >>>>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>>>> device is also none, right?
> >>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>>>> commit makes the platform device created earlier. So, before that
> >>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>>>
> >>>>>>>> Huacai
> >>>>>>>>>
> >>>>>>>>> Confused...
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>
>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Jaak and Evan,

On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >
> > On 26.10.23 03:58, Huacai Chen wrote:
> > > Hi, Jaak,
> > >
> > > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>
> > >> On 25.10.23 16:23, Huacai Chen wrote:
> > >>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > >>> <regressions@leemhuis.info> wrote:
> > >>>>
> > >>>> Javier, Dave, Sima,
> > >>>>
> > >>>> On 23.10.23 00:54, Evan Preston wrote:
> > >>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > >>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > >>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > >>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > >>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > >>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > >>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > >>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > >>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > >>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > >>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > >>>>>>>>>>>>> subsys_initcall_sync").
> > >>>>>>>>>>>>
> > >>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > >>>>>>>>>> again. So I guess the reason:
> > >>>>>>>
> > >>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > >>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > >>>>>>> if I understood things correctly. Or is there a proper fix for this
> > >>>>>>> already in the works and I just missed this? Or is there some good
> > >>>>>>> reason why this won't/can't be fixed?
> > >>>>>>
> > >>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > >>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > >>>>>> blank screen. Of course it is valuable to investigate further about
> > >>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > >>>>>> I don't have a same machine.
> > >>>>
> > >>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > >>>> real problem? Evan, might you be able to help out here?
> > >>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > >>>
> > >>
> > >> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > >> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > >> might sometimes take weeks before I have time to work and respond on this.
> > > It doesn't matter. I hope you can do some experiments to investigate
> > > deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > whether there is also a blank screen. If no blank screen, that
> > > probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > the firmware may pass wrong screen information.
> >
> > Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> some printk() in simpledrm_probe() and its sub-routines to see where
> the driver fails. The output of these printk() can be seen by the
> 'dmesg' command after boot.
I need your help. I tried with my laptop (ThinkPad E490, Intel Core
i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
please patch your 6.5.x kernel with this temporary patch [1], then
build a "bad kernel" with SIMPLEDRM enabled. And after booting your
machine with this "bad kernel", please give me the dmesg output. Thank
you very much.

[1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9


Huacai

>
> Huacai
>
> >
> > Jaak
> >
> > >
> > > Huacai
> > >
> > >>
> > >> Jaak
> > >>
> > >>>>
> > >>>> But I write this mail for a different reason:
> > >>>>
> > >>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > >>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > >>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > >>>>> screen after boot and a rapidly flashing device-access-status
> > >>>>> indicator.
> > >>>>
> > >>>> This additional report makes me wonder if we should revert the culprit
> > >>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > >>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > >>>> might lead to regressions for some users? But the patch description says
> > >>>> that this is not a common configuration, so can we maybe get away with that?
> > >>>   From my point of view, this is not a regression, 60aebc9559492c
> > >>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > >>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > >>> needs Jaak or Evan's help.
> > >>>
> > >>> Huacai
> > >>>>
> > >>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > >>>> --
> > >>>> Everything you wanna know about Linux kernel regression tracking:
> > >>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > >>>> If I did something stupid, please tell me, as explained on that page.
> > >>>>
> > >>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > >>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > >>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > >>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > >>>>>>>>>> also "no problem".
> > >>>>>>>>> I don't understand above. You mean that after that commit the platform
> > >>>>>>>>> device is also none, right?
> > >>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > >>>>>>>> commit makes the platform device created earlier. So, before that
> > >>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > >>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > >>>>>>>>
> > >>>>>>>> Huacai
> > >>>>>>>>>
> > >>>>>>>>> Confused...
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> An old man doll... just what I always wanted! - Clara
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>>>
> > >>
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

On 31.10.23 14:17, Huacai Chen wrote:
> Hi, Jaak and Evan,
> 
> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>>
>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>
>>> On 26.10.23 03:58, Huacai Chen wrote:
>>>> Hi, Jaak,
>>>>
>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>
>>>>> On 25.10.23 16:23, Huacai Chen wrote:
>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
>>>>>> <regressions@leemhuis.info> wrote:
>>>>>>>
>>>>>>> Javier, Dave, Sima,
>>>>>>>
>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>>>>>>> again. So I guess the reason:
>>>>>>>>>>
>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>>>>>>> already in the works and I just missed this? Or is there some good
>>>>>>>>>> reason why this won't/can't be fixed?
>>>>>>>>>
>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>>>>>>> blank screen. Of course it is valuable to investigate further about
>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>>>>>>> I don't have a same machine.
>>>>>>>
>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
>>>>>>> real problem? Evan, might you be able to help out here?
>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
>>>>>>
>>>>>
>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
>>>>> might sometimes take weeks before I have time to work and respond on this.
>>>> It doesn't matter. I hope you can do some experiments to investigate
>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
>>>> whether there is also a blank screen. If no blank screen, that
>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
>>>> the firmware may pass wrong screen information.
>>>
>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
>> some printk() in simpledrm_probe() and its sub-routines to see where
>> the driver fails. The output of these printk() can be seen by the
>> 'dmesg' command after boot.
> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> please patch your 6.5.x kernel with this temporary patch [1], then
> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> machine with this "bad kernel", please give me the dmesg output. Thank
> you very much.
> 
> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9

I'm unable to download it. Can you please send it by e-mail?

Jaak

> 
> 
> Huacai
> 
>>
>> Huacai
>>
>>>
>>> Jaak
>>>
>>>>
>>>> Huacai
>>>>
>>>>>
>>>>> Jaak
>>>>>
>>>>>>>
>>>>>>> But I write this mail for a different reason:
>>>>>>>
>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>>>>>>> screen after boot and a rapidly flashing device-access-status
>>>>>>>> indicator.
>>>>>>>
>>>>>>> This additional report makes me wonder if we should revert the culprit
>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>>>>>>> might lead to regressions for some users? But the patch description says
>>>>>>> that this is not a common configuration, so can we maybe get away with that?
>>>>>>    From my point of view, this is not a regression, 60aebc9559492c
>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
>>>>>> needs Jaak or Evan's help.
>>>>>>
>>>>>> Huacai
>>>>>>>
>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>>>>> --
>>>>>>> Everything you wanna know about Linux kernel regression tracking:
>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>>>>> If I did something stupid, please tell me, as explained on that page.
>>>>>>>
>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>>>>>>> also "no problem".
>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>>>>>>> device is also none, right?
>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>>>>>>> commit makes the platform device created earlier. So, before that
>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>>>>>>
>>>>>>>>>>> Huacai
>>>>>>>>>>>>
>>>>>>>>>>>> Confused...
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

[-- Attachment #1: Type: text/plain, Size: 7925 bytes --]

Hi, Jaak,

On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 31.10.23 14:17, Huacai Chen wrote:
> > Hi, Jaak and Evan,
> >
> > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>
> >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>
> >>> On 26.10.23 03:58, Huacai Chen wrote:
> >>>> Hi, Jaak,
> >>>>
> >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>
> >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> >>>>>> <regressions@leemhuis.info> wrote:
> >>>>>>>
> >>>>>>> Javier, Dave, Sima,
> >>>>>>>
> >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>>>>>>> again. So I guess the reason:
> >>>>>>>>>>
> >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>>>>>>> already in the works and I just missed this? Or is there some good
> >>>>>>>>>> reason why this won't/can't be fixed?
> >>>>>>>>>
> >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>>>>>>> I don't have a same machine.
> >>>>>>>
> >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> >>>>>>> real problem? Evan, might you be able to help out here?
> >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >>>>>>
> >>>>>
> >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> >>>>> might sometimes take weeks before I have time to work and respond on this.
> >>>> It doesn't matter. I hope you can do some experiments to investigate
> >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> >>>> whether there is also a blank screen. If no blank screen, that
> >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> >>>> the firmware may pass wrong screen information.
> >>>
> >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> >> some printk() in simpledrm_probe() and its sub-routines to see where
> >> the driver fails. The output of these printk() can be seen by the
> >> 'dmesg' command after boot.
> > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > please patch your 6.5.x kernel with this temporary patch [1], then
> > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > machine with this "bad kernel", please give me the dmesg output. Thank
> > you very much.
> >
> > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
>
> I'm unable to download it. Can you please send it by e-mail?
I'm sorry, please download from attachment.

Huacai

>
> Jaak
>
> >
> >
> > Huacai
> >
> >>
> >> Huacai
> >>
> >>>
> >>> Jaak
> >>>
> >>>>
> >>>> Huacai
> >>>>
> >>>>>
> >>>>> Jaak
> >>>>>
> >>>>>>>
> >>>>>>> But I write this mail for a different reason:
> >>>>>>>
> >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>>>>>>> screen after boot and a rapidly flashing device-access-status
> >>>>>>>> indicator.
> >>>>>>>
> >>>>>>> This additional report makes me wonder if we should revert the culprit
> >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >>>>>>> might lead to regressions for some users? But the patch description says
> >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> >>>>>> needs Jaak or Evan's help.
> >>>>>>
> >>>>>> Huacai
> >>>>>>>
> >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>>>>> --
> >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>>>>> If I did something stupid, please tell me, as explained on that page.
> >>>>>>>
> >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>>>>>>> also "no problem".
> >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>>>>>>> device is also none, right?
> >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>>>>>>
> >>>>>>>>>>> Huacai
> >>>>>>>>>>>>
> >>>>>>>>>>>> Confused...
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>
>

[-- Attachment #2: patch-6.5.9 --]
[-- Type: application/octet-stream, Size: 8471 bytes --]

diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 82fcfd29b..5f29ab2bc 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -83,25 +83,37 @@ static __init int sysfb_init(void)
 
 	sysfb_apply_efi_quirks();
 
+	printk("sysfb 1\n");
 	/* try to create a simple-framebuffer device */
 	compatible = sysfb_parse_mode(si, &mode);
 	if (compatible) {
+		printk("sysfb 2\n");
 		pd = sysfb_create_simplefb(si, &mode);
 		if (!IS_ERR(pd))
 			goto unlock_mutex;
 	}
 
 	/* if the FB is incompatible, create a legacy framebuffer device */
-	if (si->orig_video_isVGA == VIDEO_TYPE_EFI)
+	if (si->orig_video_isVGA == VIDEO_TYPE_EFI) {
 		name = "efi-framebuffer";
-	else if (si->orig_video_isVGA == VIDEO_TYPE_VLFB)
+		printk("sysfb 3a\n");
+	}
+	else if (si->orig_video_isVGA == VIDEO_TYPE_VLFB) {
 		name = "vesa-framebuffer";
-	else if (si->orig_video_isVGA == VIDEO_TYPE_VGAC)
+		printk("sysfb 3b\n");
+	}
+	else if (si->orig_video_isVGA == VIDEO_TYPE_VGAC) {
 		name = "vga-framebuffer";
-	else if (si->orig_video_isVGA == VIDEO_TYPE_EGAC)
+		printk("sysfb 3c\n");
+	}
+	else if (si->orig_video_isVGA == VIDEO_TYPE_EGAC) {
 		name = "ega-framebuffer";
-	else
+		printk("sysfb 3d\n");
+	}
+	else {
 		name = "platform-framebuffer";
+		printk("sysfb 3e\n");
+	}
 
 	pd = platform_device_alloc(name, 0);
 	if (!pd) {
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 79112b195..62fe2a6ea 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -637,6 +637,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 	size_t nformats;
 	int ret;
 
+	printk("T: create 1\n");
 	sdev = devm_drm_dev_alloc(&pdev->dev, drv, struct simpledrm_device, dev);
 	if (IS_ERR(sdev))
 		return ERR_CAST(sdev);
@@ -647,6 +648,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 	 * Hardware settings
 	 */
 
+	printk("T: create 2\n");
 	ret = simpledrm_device_init_clocks(sdev);
 	if (ret)
 		return ERR_PTR(ret);
@@ -655,31 +657,40 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 		return ERR_PTR(ret);
 
 	if (pd) {
+	printk("T: create 3a-1\n");
 		width = simplefb_get_width_pd(dev, pd);
 		if (width < 0)
 			return ERR_PTR(width);
+	printk("T: create 3a-2\n");
 		height = simplefb_get_height_pd(dev, pd);
 		if (height < 0)
 			return ERR_PTR(height);
+	printk("T: create 3a-3\n");
 		stride = simplefb_get_stride_pd(dev, pd);
 		if (stride < 0)
 			return ERR_PTR(stride);
+	printk("T: create 3a-4\n");
 		format = simplefb_get_format_pd(dev, pd);
 		if (IS_ERR(format))
 			return ERR_CAST(format);
 	} else if (of_node) {
+	printk("T: create 3b-1\n");
 		width = simplefb_get_width_of(dev, of_node);
 		if (width < 0)
 			return ERR_PTR(width);
+	printk("T: create 3b-2\n");
 		height = simplefb_get_height_of(dev, of_node);
 		if (height < 0)
 			return ERR_PTR(height);
+	printk("T: create 3b-3\n");
 		stride = simplefb_get_stride_of(dev, of_node);
 		if (stride < 0)
 			return ERR_PTR(stride);
+	printk("T: create 3b-4\n");
 		format = simplefb_get_format_of(dev, of_node);
 		if (IS_ERR(format))
 			return ERR_CAST(format);
+	printk("T: create 3b-5\n");
 		mem = simplefb_get_memory_of(dev, of_node);
 		if (IS_ERR(mem))
 			return ERR_CAST(mem);
@@ -690,15 +701,18 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 			of_node_put(panel_node);
 		}
 	} else {
+	printk("T: create 3c\n");
 		drm_err(dev, "no simplefb configuration found\n");
 		return ERR_PTR(-ENODEV);
 	}
+	printk("T: create 4\n");
 	if (!stride) {
 		stride = drm_format_info_min_pitch(format, 0, width);
 		if (drm_WARN_ON(dev, !stride))
 			return ERR_PTR(-EINVAL);
 	}
 
+	printk("T: create 5\n");
 	/*
 	 * Assume a monitor resolution of 96 dpi if physical dimensions
 	 * are not specified to get a somewhat reasonable screen size.
@@ -712,8 +726,8 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 	sdev->format = format;
 	sdev->pitch = stride;
 
-	drm_dbg(dev, "display mode={" DRM_MODE_FMT "}\n", DRM_MODE_ARG(&sdev->mode));
-	drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d byte\n",
+	drm_info(dev, "display mode={" DRM_MODE_FMT "}\n", DRM_MODE_ARG(&sdev->mode));
+	drm_info(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d byte\n",
 		&format->format, width, height, stride);
 
 	/*
@@ -723,33 +737,38 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 	if (mem) {
 		void *screen_base;
 
+	printk("T: create 6a-1\n");
 		ret = devm_aperture_acquire_from_firmware(dev, mem->start, resource_size(mem));
 		if (ret) {
 			drm_err(dev, "could not acquire memory range %pr: %d\n", mem, ret);
 			return ERR_PTR(ret);
 		}
 
-		drm_dbg(dev, "using system memory framebuffer at %pr\n", mem);
+		drm_info(dev, "using system memory framebuffer at %pr\n", mem);
 
+	printk("T: create 6a-2\n");
 		screen_base = devm_memremap(dev->dev, mem->start, resource_size(mem), MEMREMAP_WC);
 		if (IS_ERR(screen_base))
 			return screen_base;
 
+	printk("T: create 6a-3\n");
 		iosys_map_set_vaddr(&sdev->screen_base, screen_base);
 	} else {
 		void __iomem *screen_base;
 
+	printk("T: create 6b-1\n");
 		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 		if (!res)
 			return ERR_PTR(-EINVAL);
 
+	printk("T: create 6b-2\n");
 		ret = devm_aperture_acquire_from_firmware(dev, res->start, resource_size(res));
 		if (ret) {
 			drm_err(dev, "could not acquire memory range %pr: %d\n", res, ret);
 			return ERR_PTR(ret);
 		}
 
-		drm_dbg(dev, "using I/O memory framebuffer at %pr\n", res);
+		drm_info(dev, "using I/O memory framebuffer at %pr\n", res);
 
 		mem = devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
 					      drv->name);
@@ -763,10 +782,12 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 			mem = res;
 		}
 
+	printk("T: create 6b-3\n");
 		screen_base = devm_ioremap_wc(&pdev->dev, mem->start, resource_size(mem));
 		if (!screen_base)
 			return ERR_PTR(-ENOMEM);
 
+	printk("T: create 6b-4\n");
 		iosys_map_set_vaddr_iomem(&sdev->screen_base, screen_base);
 	}
 
@@ -774,6 +795,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 	 * Modesetting
 	 */
 
+	printk("T: create 7\n");
 	ret = drmm_mode_config_init(dev);
 	if (ret)
 		return ERR_PTR(ret);
@@ -790,6 +812,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 
 	/* Primary plane */
 
+	printk("T: create 8\n");
 	nformats = drm_fb_build_fourcc_list(dev, &format->format, 1,
 					    sdev->formats, ARRAY_SIZE(sdev->formats));
 
@@ -805,6 +828,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 
 	/* CRTC */
 
+	printk("T: create 9\n");
 	crtc = &sdev->crtc;
 	ret = drm_crtc_init_with_planes(dev, crtc, primary_plane, NULL,
 					&simpledrm_crtc_funcs, NULL);
@@ -814,6 +838,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 
 	/* Encoder */
 
+	printk("T: create 10\n");
 	encoder = &sdev->encoder;
 	ret = drm_encoder_init(dev, encoder, &simpledrm_encoder_funcs,
 			       DRM_MODE_ENCODER_NONE, NULL);
@@ -823,6 +848,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 
 	/* Connector */
 
+	printk("T: create 11\n");
 	connector = &sdev->connector;
 	ret = drm_connector_init(dev, connector, &simpledrm_connector_funcs,
 				 DRM_MODE_CONNECTOR_Unknown);
@@ -833,6 +859,7 @@ static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
 						       DRM_MODE_PANEL_ORIENTATION_UNKNOWN,
 						       width, height);
 
+	printk("T: create 12\n");
 	ret = drm_connector_attach_encoder(connector, encoder);
 	if (ret)
 		return ERR_PTR(ret);
@@ -870,20 +897,24 @@ static int simpledrm_probe(struct platform_device *pdev)
 	unsigned int color_mode;
 	int ret;
 
+	printk("T: probe 1\n");
 	sdev = simpledrm_device_create(&simpledrm_driver, pdev);
 	if (IS_ERR(sdev))
 		return PTR_ERR(sdev);
 	dev = &sdev->dev;
 
+	printk("T: probe 2\n");
 	ret = drm_dev_register(dev, 0);
 	if (ret)
 		return ret;
 
+	printk("T: probe 3\n");
 	color_mode = drm_format_info_bpp(sdev->format, 0);
 	if (color_mode == 16)
 		color_mode = sdev->format->depth; // can be 15 or 16
 
 	drm_fbdev_generic_setup(dev, color_mode);
+	printk("T: probe 4\n");
 
 	return 0;
 }

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

Hi Huacai,

On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> Hi, Jaak,
> 
> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >
> > On 31.10.23 14:17, Huacai Chen wrote:
> > > Hi, Jaak and Evan,
> > >
> > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>
> > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>>
> > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > >>>> Hi, Jaak,
> > >>>>
> > >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>>>>
> > >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > >>>>>> <regressions@leemhuis.info> wrote:
> > >>>>>>>
> > >>>>>>> Javier, Dave, Sima,
> > >>>>>>>
> > >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > >>>>>>>>>>>>>>>> subsys_initcall_sync").
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > >>>>>>>>>>>>> again. So I guess the reason:
> > >>>>>>>>>>
> > >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > >>>>>>>>>> already in the works and I just missed this? Or is there some good
> > >>>>>>>>>> reason why this won't/can't be fixed?
> > >>>>>>>>>
> > >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > >>>>>>>>> I don't have a same machine.
> > >>>>>>>
> > >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > >>>>>>> real problem? Evan, might you be able to help out here?
> > >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > >>>>>>
> > >>>>>
> > >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > >>>>> might sometimes take weeks before I have time to work and respond on this.
> > >>>> It doesn't matter. I hope you can do some experiments to investigate
> > >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > >>>> whether there is also a blank screen. If no blank screen, that
> > >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > >>>> the firmware may pass wrong screen information.
> > >>>
> > >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > >> some printk() in simpledrm_probe() and its sub-routines to see where
> > >> the driver fails. The output of these printk() can be seen by the
> > >> 'dmesg' command after boot.
> > > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > please patch your 6.5.x kernel with this temporary patch [1], then
> > > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > machine with this "bad kernel", please give me the dmesg output. Thank
> > > you very much.
> > >
> > > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> >
> > I'm unable to download it. Can you please send it by e-mail?
> I'm sorry, please download from attachment.

When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for 
me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch 
produces no dmesg output on my machine.

Evan

> 
> Huacai
> 
> >
> > Jaak
> >
> > >
> > >
> > > Huacai
> > >
> > >>
> > >> Huacai
> > >>
> > >>>
> > >>> Jaak
> > >>>
> > >>>>
> > >>>> Huacai
> > >>>>
> > >>>>>
> > >>>>> Jaak
> > >>>>>
> > >>>>>>>
> > >>>>>>> But I write this mail for a different reason:
> > >>>>>>>
> > >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > >>>>>>>> screen after boot and a rapidly flashing device-access-status
> > >>>>>>>> indicator.
> > >>>>>>>
> > >>>>>>> This additional report makes me wonder if we should revert the culprit
> > >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > >>>>>>> might lead to regressions for some users? But the patch description says
> > >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> > >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > >>>>>> needs Jaak or Evan's help.
> > >>>>>>
> > >>>>>> Huacai
> > >>>>>>>
> > >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > >>>>>>> --
> > >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > >>>>>>> If I did something stupid, please tell me, as explained on that page.
> > >>>>>>>
> > >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > >>>>>>>>>>>>> also "no problem".
> > >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > >>>>>>>>>>>> device is also none, right?
> > >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Huacai
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Confused...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Evan,

On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
>
> Hi Huacai,
>
> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > Hi, Jaak,
> >
> > On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >
> > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > Hi, Jaak and Evan,
> > > >
> > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>
> > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>
> > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > >>>> Hi, Jaak,
> > > >>>>
> > > >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>
> > > >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > >>>>>> <regressions@leemhuis.info> wrote:
> > > >>>>>>>
> > > >>>>>>> Javier, Dave, Sima,
> > > >>>>>>>
> > > >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > >>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > >>>>>>>>>>>>> again. So I guess the reason:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > >>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > >>>>>>>>>> reason why this won't/can't be fixed?
> > > >>>>>>>>>
> > > >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > >>>>>>>>> I don't have a same machine.
> > > >>>>>>>
> > > >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > >>>>>>> real problem? Evan, might you be able to help out here?
> > > >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > >>>>>>
> > > >>>>>
> > > >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > >>>>> might sometimes take weeks before I have time to work and respond on this.
> > > >>>> It doesn't matter. I hope you can do some experiments to investigate
> > > >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > >>>> whether there is also a blank screen. If no blank screen, that
> > > >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > >>>> the firmware may pass wrong screen information.
> > > >>>
> > > >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > >> some printk() in simpledrm_probe() and its sub-routines to see where
> > > >> the driver fails. The output of these printk() can be seen by the
> > > >> 'dmesg' command after boot.
> > > > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > please patch your 6.5.x kernel with this temporary patch [1], then
> > > > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > machine with this "bad kernel", please give me the dmesg output. Thank
> > > > you very much.
> > > >
> > > > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > >
> > > I'm unable to download it. Can you please send it by e-mail?
> > I'm sorry, please download from attachment.
>
> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> produces no dmesg output on my machine.
You copy-paste the patch? If you download it directly it can be
applied successfully, I think.

Huacai

>
> Evan
>
> >
> > Huacai
> >
> > >
> > > Jaak
> > >
> > > >
> > > >
> > > > Huacai
> > > >
> > > >>
> > > >> Huacai
> > > >>
> > > >>>
> > > >>> Jaak
> > > >>>
> > > >>>>
> > > >>>> Huacai
> > > >>>>
> > > >>>>>
> > > >>>>> Jaak
> > > >>>>>
> > > >>>>>>>
> > > >>>>>>> But I write this mail for a different reason:
> > > >>>>>>>
> > > >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > >>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > >>>>>>>> indicator.
> > > >>>>>>>
> > > >>>>>>> This additional report makes me wonder if we should revert the culprit
> > > >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > >>>>>>> might lead to regressions for some users? But the patch description says
> > > >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> > > >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > >>>>>> needs Jaak or Evan's help.
> > > >>>>>>
> > > >>>>>> Huacai
> > > >>>>>>>
> > > >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > >>>>>>> --
> > > >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > >>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > >>>>>>>
> > > >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > >>>>>>>>>>>>> also "no problem".
> > > >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > >>>>>>>>>>>> device is also none, right?
> > > >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Confused...
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> --
> > > >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>
> > > >>>
> > >
>
>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

Hi Huacai,

On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> Hi, Evan,
> 
> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> >
> > Hi Huacai,
> >
> > On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > Hi, Jaak,
> > >
> > > On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >
> > > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > > Hi, Jaak and Evan,
> > > > >
> > > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > >>
> > > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>>
> > > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > >>>> Hi, Jaak,
> > > > >>>>
> > > > >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>>>>
> > > > >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > > >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > >>>>>> <regressions@leemhuis.info> wrote:
> > > > >>>>>>>
> > > > >>>>>>> Javier, Dave, Sima,
> > > > >>>>>>>
> > > > >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > > >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > > >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > > >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > > >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > > >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > > >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > > >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > >>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > > >>>>>>>>>>>>> again. So I guess the reason:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > > >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > > >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > > >>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > > >>>>>>>>>> reason why this won't/can't be fixed?
> > > > >>>>>>>>>
> > > > >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > > >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > > >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > > >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > > >>>>>>>>> I don't have a same machine.
> > > > >>>>>>>
> > > > >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > > >>>>>>> real problem? Evan, might you be able to help out here?
> > > > >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > > >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > > >>>>> might sometimes take weeks before I have time to work and respond on this.
> > > > >>>> It doesn't matter. I hope you can do some experiments to investigate
> > > > >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > > >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > > >>>> whether there is also a blank screen. If no blank screen, that
> > > > >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > > >>>> the firmware may pass wrong screen information.
> > > > >>>
> > > > >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > > >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > > >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > > >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > > >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > > >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > > >> some printk() in simpledrm_probe() and its sub-routines to see where
> > > > >> the driver fails. The output of these printk() can be seen by the
> > > > >> 'dmesg' command after boot.
> > > > > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > > please patch your 6.5.x kernel with this temporary patch [1], then
> > > > > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > > machine with this "bad kernel", please give me the dmesg output. Thank
> > > > > you very much.
> > > > >
> > > > > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > >
> > > > I'm unable to download it. Can you please send it by e-mail?
> > > I'm sorry, please download from attachment.
> >
> > When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > produces no dmesg output on my machine.
> You copy-paste the patch? If you download it directly it can be
> applied successfully, I think.

The patch downloaded from your URL applies successfully.  However, I still 
see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all' 
shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.

Evan

> 
> Huacai
> 
> >
> > Evan
> >
> > >
> > > Huacai
> > >
> > > >
> > > > Jaak
> > > >
> > > > >
> > > > >
> > > > > Huacai
> > > > >
> > > > >>
> > > > >> Huacai
> > > > >>
> > > > >>>
> > > > >>> Jaak
> > > > >>>
> > > > >>>>
> > > > >>>> Huacai
> > > > >>>>
> > > > >>>>>
> > > > >>>>> Jaak
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>>> But I write this mail for a different reason:
> > > > >>>>>>>
> > > > >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > > >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > > >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > > >>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > > >>>>>>>> indicator.
> > > > >>>>>>>
> > > > >>>>>>> This additional report makes me wonder if we should revert the culprit
> > > > >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > > >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > > >>>>>>> might lead to regressions for some users? But the patch description says
> > > > >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > > >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> > > > >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > > >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > > >>>>>> needs Jaak or Evan's help.
> > > > >>>>>>
> > > > >>>>>> Huacai
> > > > >>>>>>>
> > > > >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > >>>>>>> --
> > > > >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > > >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > > >>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > > >>>>>>>
> > > > >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > > >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > > >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > > >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > > >>>>>>>>>>>>> also "no problem".
> > > > >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > > >>>>>>>>>>>> device is also none, right?
> > > > >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > > >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > > >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > > >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Huacai
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Confused...
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> --
> > > > >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>
> > > > >>>
> > > >
> >
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Evan,

On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
>
> Hi Huacai,
>
> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > Hi, Evan,
> >
> > On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > >
> > > Hi Huacai,
> > >
> > > On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > > Hi, Jaak,
> > > >
> > > > On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >
> > > > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > > > Hi, Jaak and Evan,
> > > > > >
> > > > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > >>
> > > > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>>
> > > > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > > >>>> Hi, Jaak,
> > > > > >>>>
> > > > > >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>>>>
> > > > > >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > > > >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > > >>>>>> <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>> Javier, Dave, Sima,
> > > > > >>>>>>>
> > > > > >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > > > >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > > >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > > > >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > > > >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > > > >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > > > >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > > > >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > > >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > > >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > > > >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > > >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > > >>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > > > >>>>>>>>>>>>> again. So I guess the reason:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > > > >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > > > >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > > > >>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > > > >>>>>>>>>> reason why this won't/can't be fixed?
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > > > >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > > > >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > > > >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > > > >>>>>>>>> I don't have a same machine.
> > > > > >>>>>>>
> > > > > >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > > > >>>>>>> real problem? Evan, might you be able to help out here?
> > > > > >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > > > >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > > > >>>>> might sometimes take weeks before I have time to work and respond on this.
> > > > > >>>> It doesn't matter. I hope you can do some experiments to investigate
> > > > > >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > > > >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > > > >>>> whether there is also a blank screen. If no blank screen, that
> > > > > >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > > > >>>> the firmware may pass wrong screen information.
> > > > > >>>
> > > > > >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > > > >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > > > >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > > > >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > > > >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > > > >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > > > >> some printk() in simpledrm_probe() and its sub-routines to see where
> > > > > >> the driver fails. The output of these printk() can be seen by the
> > > > > >> 'dmesg' command after boot.
> > > > > > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > > > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > > > please patch your 6.5.x kernel with this temporary patch [1], then
> > > > > > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > > > machine with this "bad kernel", please give me the dmesg output. Thank
> > > > > > you very much.
> > > > > >
> > > > > > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > > >
> > > > > I'm unable to download it. Can you please send it by e-mail?
> > > > I'm sorry, please download from attachment.
> > >
> > > When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > produces no dmesg output on my machine.
> > You copy-paste the patch? If you download it directly it can be
> > applied successfully, I think.
>
> The patch downloaded from your URL applies successfully.  However, I still
> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
Thank you for your testing. Since you cannot boot to GUI successfully
as Jaak, you may have some troubles with getting the dmesg output. But
you can try to use "systemd.unit=multi-user.target" boot parameters.
In this way you may boot to the login: prompt and then you can get
dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
to get the previous dmesg output with 6.4.12.

Hi, Jaak,

Have you tested? I think you can successfully get a dmesg output with my patch.

>
> Evan
>
> >
> > Huacai
> >
> > >
> > > Evan
> > >
> > > >
> > > > Huacai
> > > >
> > > > >
> > > > > Jaak
> > > > >
> > > > > >
> > > > > >
> > > > > > Huacai
> > > > > >
> > > > > >>
> > > > > >> Huacai
> > > > > >>
> > > > > >>>
> > > > > >>> Jaak
> > > > > >>>
> > > > > >>>>
> > > > > >>>> Huacai
> > > > > >>>>
> > > > > >>>>>
> > > > > >>>>> Jaak
> > > > > >>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> But I write this mail for a different reason:
> > > > > >>>>>>>
> > > > > >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > > > >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > > > >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > > > >>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > > > >>>>>>>> indicator.
> > > > > >>>>>>>
> > > > > >>>>>>> This additional report makes me wonder if we should revert the culprit
> > > > > >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > > > >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > > > >>>>>>> might lead to regressions for some users? But the patch description says
> > > > > >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > > > >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> > > > > >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > > > >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > > > >>>>>> needs Jaak or Evan's help.
> > > > > >>>>>>
> > > > > >>>>>> Huacai
> > > > > >>>>>>>
> > > > > >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > > >>>>>>> --
> > > > > >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > > > >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > > > >>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > > > >>>>>>>
> > > > > >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > > > >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > > > >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > > > >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > > > >>>>>>>>>>>>> also "no problem".
> > > > > >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > > > >>>>>>>>>>>> device is also none, right?
> > > > > >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > > > >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > > > >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > > > >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Huacai
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Confused...
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> --
> > > > > >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > >
> > >
> > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

On 05.11.23 14:40, Huacai Chen wrote:
> Hi, Evan,
> 
> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
>>
>> Hi Huacai,
>>
>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
>>> Hi, Evan,
>>>
>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
>>>>
>>>> Hi Huacai,
>>>>
>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
>>>>> Hi, Jaak,
>>>>>
>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>
>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
>>>>>>> Hi, Jaak and Evan,
>>>>>>>
>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>>>>
>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
>>>>>>>>>> Hi, Jaak,
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Javier, Dave, Sima,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>>>>>>>>>>>>> I don't have a same machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
>>>>>>>>>> the firmware may pass wrong screen information.
>>>>>>>>>
>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
>>>>>>>> the driver fails. The output of these printk() can be seen by the
>>>>>>>> 'dmesg' command after boot.
>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
>>>>>>> you very much.
>>>>>>>
>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
>>>>>>
>>>>>> I'm unable to download it. Can you please send it by e-mail?
>>>>> I'm sorry, please download from attachment.
>>>>
>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
>>>> produces no dmesg output on my machine.
>>> You copy-paste the patch? If you download it directly it can be
>>> applied successfully, I think.
>>
>> The patch downloaded from your URL applies successfully.  However, I still
>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> Thank you for your testing. Since you cannot boot to GUI successfully
> as Jaak, you may have some troubles with getting the dmesg output. But
> you can try to use "systemd.unit=multi-user.target" boot parameters.
> In this way you may boot to the login: prompt and then you can get
> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> to get the previous dmesg output with 6.4.12.
> 
> Hi, Jaak,
> 
> Have you tested? I think you can successfully get a dmesg output with my patch.

Yes, just tested it, here I think are the relevant parts from a dmesg 
produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:

...
[    2.909625] sysfb 1
[    2.909627] sysfb 2
...
[    2.951477] ACPI: bus type drm_connector registered
[    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    2.952105] resource: resource sanity check: requesting [mem 
0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB 
[mem 0xe0000000-0xe012bfff]
[    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
[    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
[    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware 
i915/kbl_dmc_ver1_04.bin (v1.4)
...
[    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on 
minor 0
[    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: 
no  post: no)
[    4.144414] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
[    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
[    4.144590] usbcore: registered new interface driver udl
[    4.144603] T: probe 1
[    4.144605] T: create 1
[    4.144610] T: create 2
[    4.144611] T: create 3a-1
[    4.144613] T: create 3a-2
[    4.144614] T: create 3a-3
[    4.144616] T: create 3a-4
[    4.144618] T: create 4
[    4.144619] T: create 5
[    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display 
mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
[    4.144628] simple-framebuffer simple-framebuffer.0: [drm] 
framebuffer format=XR24 little-endian (0x34325258), size=640x480, 
stride=2560 byte
[    4.144633] T: create 6b-1
[    4.144635] T: create 6b-2
[    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O 
memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
[    4.144643] T: create 6b-3
[    4.144660] T: create 6b-4
[    4.144662] T: create 7
[    4.144673] T: create 8
[    4.144676] T: create 9
[    4.144678] T: create 10
[    4.144681] T: create 11
[    4.144685] T: create 12
[    4.144689] T: probe 2
[    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for 
simple-framebuffer.0 on minor 2
[    4.144732] T: probe 3
[    4.145905] Console: switching to colour frame buffer device 80x30
[    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0: 
simpledrmdrmfb frame buffer device
[    4.150766] T: probe 4
[    4.151218] loop: module loaded
[    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
...
[   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer 
is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
...

The last message might be due to the display manager starting up.

Hope it helps.

J

> 
>>
>> Evan
>>
>>>
>>> Huacai
>>>
>>>>
>>>> Evan
>>>>
>>>>>
>>>>> Huacai
>>>>>
>>>>>>
>>>>>> Jaak
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Huacai
>>>>>>>
>>>>>>>>
>>>>>>>> Huacai
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jaak
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Huacai
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jaak
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> But I write this mail for a different reason:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
>>>>>>>>>>>>>> indicator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
>>>>>>>>>>>>     From my point of view, this is not a regression, 60aebc9559492c
>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
>>>>>>>>>>>> needs Jaak or Evan's help.
>>>>>>>>>>>>
>>>>>>>>>>>> Huacai
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>>>>>>>>>>>>> also "no problem".
>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>>>>>>>>>>>>> device is also none, right?
>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Huacai
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Confused...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

Hi Huacai,

On 2023-11-05 Sun 08:40pm, Huacai Chen wrote:
> Hi, Evan,
> 
> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> >
> > Hi Huacai,
> >
> > On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > Hi, Evan,
> > >
> > > On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > > >
> > > > Hi Huacai,
> > > >
> > > > On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > > > Hi, Jaak,
> > > > >
> > > > > On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >
> > > > > > On 31.10.23 14:17, Huacai Chen wrote:
> > > > > > > Hi, Jaak and Evan,
> > > > > > >
> > > > > > > On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > > >>
> > > > > > >> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > > >>>
> > > > > > >>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > > > >>>> Hi, Jaak,
> > > > > > >>>>
> > > > > > >>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > > >>>>>
> > > > > > >>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > > > > >>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > > > >>>>>> <regressions@leemhuis.info> wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>> Javier, Dave, Sima,
> > > > > > >>>>>>>
> > > > > > >>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > > > > >>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > > > >>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > > > > >>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > > >>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > > > > >>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > > > > >>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > > > > >>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > > >>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > > > > >>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > > >>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > > > >>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > > > >>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > > > > >>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > > > >>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > > > >>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > > > > >>>>>>>>>>>>> again. So I guess the reason:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > > > > >>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > > > > >>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > > > > >>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > > > > >>>>>>>>>> reason why this won't/can't be fixed?
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > > > > >>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > > > > >>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > > > > >>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > > > > >>>>>>>>> I don't have a same machine.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > > > > >>>>>>> real problem? Evan, might you be able to help out here?
> > > > > > >>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > > > > >>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > > > > >>>>> might sometimes take weeks before I have time to work and respond on this.
> > > > > > >>>> It doesn't matter. I hope you can do some experiments to investigate
> > > > > > >>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > > > > >>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > > > > >>>> whether there is also a blank screen. If no blank screen, that
> > > > > > >>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > > > > >>>> the firmware may pass wrong screen information.
> > > > > > >>>
> > > > > > >>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > > > > >>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > > > > >> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > > > > >> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > > > > >> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > > > > >> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > > > > >> some printk() in simpledrm_probe() and its sub-routines to see where
> > > > > > >> the driver fails. The output of these printk() can be seen by the
> > > > > > >> 'dmesg' command after boot.
> > > > > > > I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > > > > i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > > > > please patch your 6.5.x kernel with this temporary patch [1], then
> > > > > > > build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > > > > machine with this "bad kernel", please give me the dmesg output. Thank
> > > > > > > you very much.
> > > > > > >
> > > > > > > [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > > > >
> > > > > > I'm unable to download it. Can you please send it by e-mail?
> > > > > I'm sorry, please download from attachment.
> > > >
> > > > When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > > me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > > produces no dmesg output on my machine.
> > > You copy-paste the patch? If you download it directly it can be
> > > applied successfully, I think.
> >
> > The patch downloaded from your URL applies successfully.  However, I still
> > see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> Thank you for your testing. Since you cannot boot to GUI successfully
> as Jaak, you may have some troubles with getting the dmesg output. But
> you can try to use "systemd.unit=multi-user.target" boot parameters.
> In this way you may boot to the login: prompt and then you can get
> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> to get the previous dmesg output with 6.4.12.

I get a blank screen immediately after selecting a 6.5.x boot loader entry 
even using the 'systemd.unit=multi-user.target' boot parameter.  'jornalctl 
-k -b -1' from a successful 6.4.12 boot after a failed 6.5.x boot shows only 
the previous successful 6.4.12 boot's dmesg from two boots ago and nothing 
from the failed 6.5.x boot.  In case it's of any use my 6.4.12 dmesg is 
here: http://epreston.net/dmesg-6.4.12

Evan

> 
> Hi, Jaak,
> 
> Have you tested? I think you can successfully get a dmesg output with my patch.
> 
> >
> > Evan
> >
> > >
> > > Huacai
> > >
> > > >
> > > > Evan
> > > >
> > > > >
> > > > > Huacai
> > > > >
> > > > > >
> > > > > > Jaak
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Huacai
> > > > > > >
> > > > > > >>
> > > > > > >> Huacai
> > > > > > >>
> > > > > > >>>
> > > > > > >>> Jaak
> > > > > > >>>
> > > > > > >>>>
> > > > > > >>>> Huacai
> > > > > > >>>>
> > > > > > >>>>>
> > > > > > >>>>> Jaak
> > > > > > >>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> But I write this mail for a different reason:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > > > > >>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > > > > >>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > > > > >>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > > > > >>>>>>>> indicator.
> > > > > > >>>>>>>
> > > > > > >>>>>>> This additional report makes me wonder if we should revert the culprit
> > > > > > >>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > > > > >>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > > > > >>>>>>> might lead to regressions for some users? But the patch description says
> > > > > > >>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > > > > >>>>>>    From my point of view, this is not a regression, 60aebc9559492c
> > > > > > >>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > > > > >>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > > > > >>>>>> needs Jaak or Evan's help.
> > > > > > >>>>>>
> > > > > > >>>>>> Huacai
> > > > > > >>>>>>>
> > > > > > >>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > > > >>>>>>> --
> > > > > > >>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > > > > >>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > > > > >>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > > > > >>>>>>>
> > > > > > >>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > > > > >>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > > > > >>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > > > > >>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > > > > >>>>>>>>>>>>> also "no problem".
> > > > > > >>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > > > > >>>>>>>>>>>> device is also none, right?
> > > > > > >>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > > > > >>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > > > > >>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > > > > >>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Huacai
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Confused...
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> --
> > > > > > >>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>
> > > > > > >>>
> > > > > >
> > > >
> > > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Jaak and Evan,

On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 05.11.23 14:40, Huacai Chen wrote:
> > Hi, Evan,
> >
> > On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> >>
> >> Hi Huacai,
> >>
> >> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> >>> Hi, Evan,
> >>>
> >>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> >>>>
> >>>> Hi Huacai,
> >>>>
> >>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> >>>>> Hi, Jaak,
> >>>>>
> >>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>
> >>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> >>>>>>> Hi, Jaak and Evan,
> >>>>>>>
> >>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>
> >>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>
> >>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> >>>>>>>>>> Hi, Jaak,
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> >>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> >>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Javier, Dave, Sima,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> >>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> >>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> >>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>>>>>>>>>>>>> I don't have a same machine.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> >>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> >>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> >>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> >>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> >>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> >>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> >>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> >>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> >>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> >>>>>>>>>> the firmware may pass wrong screen information.
> >>>>>>>>>
> >>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> >>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> >>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> >>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> >>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> >>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> >>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> >>>>>>>> the driver fails. The output of these printk() can be seen by the
> >>>>>>>> 'dmesg' command after boot.
> >>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> >>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> >>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> >>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> >>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> >>>>>>> you very much.
> >>>>>>>
> >>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> >>>>>>
> >>>>>> I'm unable to download it. Can you please send it by e-mail?
> >>>>> I'm sorry, please download from attachment.
> >>>>
> >>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> >>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> >>>> produces no dmesg output on my machine.
> >>> You copy-paste the patch? If you download it directly it can be
> >>> applied successfully, I think.
> >>
> >> The patch downloaded from your URL applies successfully.  However, I still
> >> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> >> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > Thank you for your testing. Since you cannot boot to GUI successfully
> > as Jaak, you may have some troubles with getting the dmesg output. But
> > you can try to use "systemd.unit=multi-user.target" boot parameters.
> > In this way you may boot to the login: prompt and then you can get
> > dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > to get the previous dmesg output with 6.4.12.
> >
> > Hi, Jaak,
> >
> > Have you tested? I think you can successfully get a dmesg output with my patch.
>
> Yes, just tested it, here I think are the relevant parts from a dmesg
> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
>
> ...
> [    2.909625] sysfb 1
> [    2.909627] sysfb 2
> ...
> [    2.951477] ACPI: bus type drm_connector registered
> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> [    2.952105] resource: resource sanity check: requesting [mem
> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> [mem 0xe0000000-0xe012bfff]
> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> i915/kbl_dmc_ver1_04.bin (v1.4)
> ...
> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> minor 0
> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> no  post: no)
> [    4.144414] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> [    4.144590] usbcore: registered new interface driver udl
> [    4.144603] T: probe 1
> [    4.144605] T: create 1
> [    4.144610] T: create 2
> [    4.144611] T: create 3a-1
> [    4.144613] T: create 3a-2
> [    4.144614] T: create 3a-3
> [    4.144616] T: create 3a-4
> [    4.144618] T: create 4
> [    4.144619] T: create 5
> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> stride=2560 byte
> [    4.144633] T: create 6b-1
> [    4.144635] T: create 6b-2
> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> [    4.144643] T: create 6b-3
> [    4.144660] T: create 6b-4
> [    4.144662] T: create 7
> [    4.144673] T: create 8
> [    4.144676] T: create 9
> [    4.144678] T: create 10
> [    4.144681] T: create 11
> [    4.144685] T: create 12
> [    4.144689] T: probe 2
> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> simple-framebuffer.0 on minor 2
> [    4.144732] T: probe 3
> [    4.145905] Console: switching to colour frame buffer device 80x30
> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> simpledrmdrmfb frame buffer device
> [    4.150766] T: probe 4
> [    4.151218] loop: module loaded
> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> ...
> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> ...
>
> The last message might be due to the display manager starting up.
>
> Hope it helps.
Thank you for your testing. Jaak's problem seems related to the
initialization order, you can try to modify drivers/gpu/drm/Makefile,
move

obj-y                  += tiny/

to between these two lines

obj-$(CONFIG_DRM_SCHED) += scheduler/
obj-$(CONFIG_DRM_RADEON)+= radeon/

then build a new 6.5.x kernel to see whether your problem is resolved.

Evan's problem seems a little strange, could you please give me your
config files of both 6.4.12 and 6.5.x? And you can also try the above
method to see if anything changes.

Huacai

>
> J
>
> >
> >>
> >> Evan
> >>
> >>>
> >>> Huacai
> >>>
> >>>>
> >>>> Evan
> >>>>
> >>>>>
> >>>>> Huacai
> >>>>>
> >>>>>>
> >>>>>> Jaak
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Huacai
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Huacai
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Jaak
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Huacai
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Jaak
> >>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But I write this mail for a different reason:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> >>>>>>>>>>>>>> indicator.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> >>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> >>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> >>>>>>>>>>>>     From my point of view, this is not a regression, 60aebc9559492c
> >>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> >>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> >>>>>>>>>>>> needs Jaak or Evan's help.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> >>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>>>>>>>>>>>>> also "no problem".
> >>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>>>>>>>>>>>>> device is also none, right?
> >>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> >>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Confused...
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>
> >>>>
>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Jaak Ristioja]

On 06.11.23 04:15, Huacai Chen wrote:
> Hi, Jaak and Evan,
> 
> On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>
>> On 05.11.23 14:40, Huacai Chen wrote:
>>> Hi, Evan,
>>>
>>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
>>>>
>>>> Hi Huacai,
>>>>
>>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
>>>>> Hi, Evan,
>>>>>
>>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
>>>>>>
>>>>>> Hi Huacai,
>>>>>>
>>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
>>>>>>> Hi, Jaak,
>>>>>>>
>>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>>>
>>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
>>>>>>>>> Hi, Jaak and Evan,
>>>>>>>>>
>>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>>>
>>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
>>>>>>>>>>>> Hi, Jaak,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
>>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
>>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Javier, Dave, Sima,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
>>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
>>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
>>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
>>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
>>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
>>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
>>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
>>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
>>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
>>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
>>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
>>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
>>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
>>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
>>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
>>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
>>>>>>>>>>>>>>>>> I don't have a same machine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
>>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
>>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
>>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
>>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
>>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
>>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
>>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
>>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
>>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
>>>>>>>>>>>> the firmware may pass wrong screen information.
>>>>>>>>>>>
>>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
>>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
>>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
>>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
>>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
>>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
>>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
>>>>>>>>>> the driver fails. The output of these printk() can be seen by the
>>>>>>>>>> 'dmesg' command after boot.
>>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
>>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
>>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
>>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
>>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
>>>>>>>>> you very much.
>>>>>>>>>
>>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
>>>>>>>>
>>>>>>>> I'm unable to download it. Can you please send it by e-mail?
>>>>>>> I'm sorry, please download from attachment.
>>>>>>
>>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
>>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
>>>>>> produces no dmesg output on my machine.
>>>>> You copy-paste the patch? If you download it directly it can be
>>>>> applied successfully, I think.
>>>>
>>>> The patch downloaded from your URL applies successfully.  However, I still
>>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
>>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
>>> Thank you for your testing. Since you cannot boot to GUI successfully
>>> as Jaak, you may have some troubles with getting the dmesg output. But
>>> you can try to use "systemd.unit=multi-user.target" boot parameters.
>>> In this way you may boot to the login: prompt and then you can get
>>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
>>> to get the previous dmesg output with 6.4.12.
>>>
>>> Hi, Jaak,
>>>
>>> Have you tested? I think you can successfully get a dmesg output with my patch.
>>
>> Yes, just tested it, here I think are the relevant parts from a dmesg
>> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
>>
>> ...
>> [    2.909625] sysfb 1
>> [    2.909627] sysfb 2
>> ...
>> [    2.951477] ACPI: bus type drm_connector registered
>> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
>> [    2.952105] resource: resource sanity check: requesting [mem
>> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
>> [mem 0xe0000000-0xe012bfff]
>> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
>> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
>> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
>> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
>> i915/kbl_dmc_ver1_04.bin (v1.4)
>> ...
>> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
>> minor 0
>> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
>> no  post: no)
>> [    4.144414] input: Video Bus as
>> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
>> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
>> [    4.144590] usbcore: registered new interface driver udl
>> [    4.144603] T: probe 1
>> [    4.144605] T: create 1
>> [    4.144610] T: create 2
>> [    4.144611] T: create 3a-1
>> [    4.144613] T: create 3a-2
>> [    4.144614] T: create 3a-3
>> [    4.144616] T: create 3a-4
>> [    4.144618] T: create 4
>> [    4.144619] T: create 5
>> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
>> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
>> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
>> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
>> stride=2560 byte
>> [    4.144633] T: create 6b-1
>> [    4.144635] T: create 6b-2
>> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
>> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
>> [    4.144643] T: create 6b-3
>> [    4.144660] T: create 6b-4
>> [    4.144662] T: create 7
>> [    4.144673] T: create 8
>> [    4.144676] T: create 9
>> [    4.144678] T: create 10
>> [    4.144681] T: create 11
>> [    4.144685] T: create 12
>> [    4.144689] T: probe 2
>> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
>> simple-framebuffer.0 on minor 2
>> [    4.144732] T: probe 3
>> [    4.145905] Console: switching to colour frame buffer device 80x30
>> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
>> simpledrmdrmfb frame buffer device
>> [    4.150766] T: probe 4
>> [    4.151218] loop: module loaded
>> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
>> ...
>> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
>> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
>> ...
>>
>> The last message might be due to the display manager starting up.
>>
>> Hope it helps.
> Thank you for your testing. Jaak's problem seems related to the
> initialization order, you can try to modify drivers/gpu/drm/Makefile,
> move
> 
> obj-y                  += tiny/
> 
> to between these two lines
> 
> obj-$(CONFIG_DRM_SCHED) += scheduler/
> obj-$(CONFIG_DRM_RADEON)+= radeon/
> 
> then build a new 6.5.x kernel to see whether your problem is resolved.

Yes, this seems to have resolved it.

Jaak

> 
> Evan's problem seems a little strange, could you please give me your
> config files of both 6.4.12 and 6.5.x? And you can also try the above
> method to see if anything changes.
> 
> Huacai
> 
>>
>> J
>>
>>>
>>>>
>>>> Evan
>>>>
>>>>>
>>>>> Huacai
>>>>>
>>>>>>
>>>>>> Evan
>>>>>>
>>>>>>>
>>>>>>> Huacai
>>>>>>>
>>>>>>>>
>>>>>>>> Jaak
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Huacai
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Huacai
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jaak
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Huacai
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jaak
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But I write this mail for a different reason:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
>>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
>>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
>>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
>>>>>>>>>>>>>>>> indicator.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
>>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
>>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
>>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
>>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
>>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
>>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
>>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
>>>>>>>>>>>>>> needs Jaak or Evan's help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Huacai
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
>>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
>>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
>>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
>>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
>>>>>>>>>>>>>>>>>>>>> also "no problem".
>>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
>>>>>>>>>>>>>>>>>>>> device is also none, right?
>>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
>>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
>>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
>>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Huacai
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Confused...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 06.11.23 04:15, Huacai Chen wrote:
> > Hi, Jaak and Evan,
> >
> > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>
> >> On 05.11.23 14:40, Huacai Chen wrote:
> >>> Hi, Evan,
> >>>
> >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> >>>>
> >>>> Hi Huacai,
> >>>>
> >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> >>>>> Hi, Evan,
> >>>>>
> >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> >>>>>>
> >>>>>> Hi Huacai,
> >>>>>>
> >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> >>>>>>> Hi, Jaak,
> >>>>>>>
> >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>
> >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> >>>>>>>>> Hi, Jaak and Evan,
> >>>>>>>>>
> >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> >>>>>>>>>>>> Hi, Jaak,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Javier, Dave, Sima,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>>>>>>>>>>>>>>> I don't have a same machine.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> >>>>>>>>>>>> the firmware may pass wrong screen information.
> >>>>>>>>>>>
> >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> >>>>>>>>>> 'dmesg' command after boot.
> >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> >>>>>>>>> you very much.
> >>>>>>>>>
> >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> >>>>>>>>
> >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> >>>>>>> I'm sorry, please download from attachment.
> >>>>>>
> >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> >>>>>> produces no dmesg output on my machine.
> >>>>> You copy-paste the patch? If you download it directly it can be
> >>>>> applied successfully, I think.
> >>>>
> >>>> The patch downloaded from your URL applies successfully.  However, I still
> >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> >>> Thank you for your testing. Since you cannot boot to GUI successfully
> >>> as Jaak, you may have some troubles with getting the dmesg output. But
> >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> >>> In this way you may boot to the login: prompt and then you can get
> >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> >>> to get the previous dmesg output with 6.4.12.
> >>>
> >>> Hi, Jaak,
> >>>
> >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> >>
> >> Yes, just tested it, here I think are the relevant parts from a dmesg
> >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> >>
> >> ...
> >> [    2.909625] sysfb 1
> >> [    2.909627] sysfb 2
> >> ...
> >> [    2.951477] ACPI: bus type drm_connector registered
> >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> >> [    2.952105] resource: resource sanity check: requesting [mem
> >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> >> [mem 0xe0000000-0xe012bfff]
> >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> >> i915/kbl_dmc_ver1_04.bin (v1.4)
> >> ...
> >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> >> minor 0
> >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> >> no  post: no)
> >> [    4.144414] input: Video Bus as
> >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> >> [    4.144590] usbcore: registered new interface driver udl
> >> [    4.144603] T: probe 1
> >> [    4.144605] T: create 1
> >> [    4.144610] T: create 2
> >> [    4.144611] T: create 3a-1
> >> [    4.144613] T: create 3a-2
> >> [    4.144614] T: create 3a-3
> >> [    4.144616] T: create 3a-4
> >> [    4.144618] T: create 4
> >> [    4.144619] T: create 5
> >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> >> stride=2560 byte
> >> [    4.144633] T: create 6b-1
> >> [    4.144635] T: create 6b-2
> >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> >> [    4.144643] T: create 6b-3
> >> [    4.144660] T: create 6b-4
> >> [    4.144662] T: create 7
> >> [    4.144673] T: create 8
> >> [    4.144676] T: create 9
> >> [    4.144678] T: create 10
> >> [    4.144681] T: create 11
> >> [    4.144685] T: create 12
> >> [    4.144689] T: probe 2
> >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> >> simple-framebuffer.0 on minor 2
> >> [    4.144732] T: probe 3
> >> [    4.145905] Console: switching to colour frame buffer device 80x30
> >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> >> simpledrmdrmfb frame buffer device
> >> [    4.150766] T: probe 4
> >> [    4.151218] loop: module loaded
> >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> >> ...
> >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> >> ...
> >>
> >> The last message might be due to the display manager starting up.
> >>
> >> Hope it helps.
> > Thank you for your testing. Jaak's problem seems related to the
> > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > move
> >
> > obj-y                  += tiny/
> >
> > to between these two lines
> >
> > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > obj-$(CONFIG_DRM_RADEON)+= radeon/
> >
> > then build a new 6.5.x kernel to see whether your problem is resolved.
>
> Yes, this seems to have resolved it.
Hi, Jaak,

Thank you very much, and I hope this also solves Evan's problem.

Hi, Javier,

I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
Jaak's problem is due to the initialization order of drivers, and this
order depends on the Makefile.

FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
work.

So, when I move the "tiny" directory before i915, the problem is
solved. But the new problem is: is it acceptable to solve this problem
by adjusting Makefile?

Huacai

>
> Jaak
>
> >
> > Evan's problem seems a little strange, could you please give me your
> > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > method to see if anything changes.
> >
> > Huacai
> >
> >>
> >> J
> >>
> >>>
> >>>>
> >>>> Evan
> >>>>
> >>>>>
> >>>>> Huacai
> >>>>>
> >>>>>>
> >>>>>> Evan
> >>>>>>
> >>>>>>>
> >>>>>>> Huacai
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Jaak
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Huacai
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Huacai
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Jaak
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Huacai
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Jaak
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But I write this mail for a different reason:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> >>>>>>>>>>>>>>>> indicator.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> >>>>>>>>>>>>>> needs Jaak or Evan's help.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>>>>>>>>>>>>>>> also "no problem".
> >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>>>>>>>>>>>>>>> device is also none, right?
> >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Confused...
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>
>

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

Hi Huacai,

On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >
> > On 06.11.23 04:15, Huacai Chen wrote:
> > > Hi, Jaak and Evan,
> > >
> > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>
> > >> On 05.11.23 14:40, Huacai Chen wrote:
> > >>> Hi, Evan,
> > >>>
> > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> > >>>>
> > >>>> Hi Huacai,
> > >>>>
> > >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > >>>>> Hi, Evan,
> > >>>>>
> > >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > >>>>>>
> > >>>>>> Hi Huacai,
> > >>>>>>
> > >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > >>>>>>> Hi, Jaak,
> > >>>>>>>
> > >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>>>>>>>
> > >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> > >>>>>>>>> Hi, Jaak and Evan,
> > >>>>>>>>>
> > >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> > >>>>>>>>>>>> Hi, Jaak,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Javier, Dave, Sima,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> > >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > >>>>>>>>>>>>>>>>> I don't have a same machine.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> > >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> > >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> > >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> > >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > >>>>>>>>>>>> the firmware may pass wrong screen information.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> > >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> > >>>>>>>>>> 'dmesg' command after boot.
> > >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> > >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> > >>>>>>>>> you very much.
> > >>>>>>>>>
> > >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > >>>>>>>>
> > >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> > >>>>>>> I'm sorry, please download from attachment.
> > >>>>>>
> > >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > >>>>>> produces no dmesg output on my machine.
> > >>>>> You copy-paste the patch? If you download it directly it can be
> > >>>>> applied successfully, I think.
> > >>>>
> > >>>> The patch downloaded from your URL applies successfully.  However, I still
> > >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > >>> Thank you for your testing. Since you cannot boot to GUI successfully
> > >>> as Jaak, you may have some troubles with getting the dmesg output. But
> > >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> > >>> In this way you may boot to the login: prompt and then you can get
> > >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > >>> to get the previous dmesg output with 6.4.12.
> > >>>
> > >>> Hi, Jaak,
> > >>>
> > >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> > >>
> > >> Yes, just tested it, here I think are the relevant parts from a dmesg
> > >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> > >>
> > >> ...
> > >> [    2.909625] sysfb 1
> > >> [    2.909627] sysfb 2
> > >> ...
> > >> [    2.951477] ACPI: bus type drm_connector registered
> > >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> > >> [    2.952105] resource: resource sanity check: requesting [mem
> > >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> > >> [mem 0xe0000000-0xe012bfff]
> > >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> > >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> > >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> > >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> > >> i915/kbl_dmc_ver1_04.bin (v1.4)
> > >> ...
> > >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> > >> minor 0
> > >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> > >> no  post: no)
> > >> [    4.144414] input: Video Bus as
> > >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> > >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> > >> [    4.144590] usbcore: registered new interface driver udl
> > >> [    4.144603] T: probe 1
> > >> [    4.144605] T: create 1
> > >> [    4.144610] T: create 2
> > >> [    4.144611] T: create 3a-1
> > >> [    4.144613] T: create 3a-2
> > >> [    4.144614] T: create 3a-3
> > >> [    4.144616] T: create 3a-4
> > >> [    4.144618] T: create 4
> > >> [    4.144619] T: create 5
> > >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> > >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> > >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> > >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> > >> stride=2560 byte
> > >> [    4.144633] T: create 6b-1
> > >> [    4.144635] T: create 6b-2
> > >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> > >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> > >> [    4.144643] T: create 6b-3
> > >> [    4.144660] T: create 6b-4
> > >> [    4.144662] T: create 7
> > >> [    4.144673] T: create 8
> > >> [    4.144676] T: create 9
> > >> [    4.144678] T: create 10
> > >> [    4.144681] T: create 11
> > >> [    4.144685] T: create 12
> > >> [    4.144689] T: probe 2
> > >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> > >> simple-framebuffer.0 on minor 2
> > >> [    4.144732] T: probe 3
> > >> [    4.145905] Console: switching to colour frame buffer device 80x30
> > >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> > >> simpledrmdrmfb frame buffer device
> > >> [    4.150766] T: probe 4
> > >> [    4.151218] loop: module loaded
> > >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> > >> ...
> > >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> > >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> > >> ...
> > >>
> > >> The last message might be due to the display manager starting up.
> > >>
> > >> Hope it helps.
> > > Thank you for your testing. Jaak's problem seems related to the
> > > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > > move
> > >
> > > obj-y                  += tiny/
> > >
> > > to between these two lines
> > >
> > > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > >
> > > then build a new 6.5.x kernel to see whether your problem is resolved.
> >
> > Yes, this seems to have resolved it.
> Hi, Jaak,
> 
> Thank you very much, and I hope this also solves Evan's problem.

I still get a blank screen if I modify drivers/gpu/drm/Makefile to move the 
order of 'tiny'.

> 
> Hi, Javier,
> 
> I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
> Jaak's problem is due to the initialization order of drivers, and this
> order depends on the Makefile.
> 
> FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
> I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
> DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
> work.
> 
> So, when I move the "tiny" directory before i915, the problem is
> solved. But the new problem is: is it acceptable to solve this problem
> by adjusting Makefile?
> 
> Huacai
> 
> >
> > Jaak
> >
> > >
> > > Evan's problem seems a little strange, could you please give me your
> > > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > > method to see if anything changes.

I'll send you my config files.

> > >
> > > Huacai
> > >
> > >>
> > >> J
> > >>
> > >>>
> > >>>>
> > >>>> Evan
> > >>>>
> > >>>>>
> > >>>>> Huacai
> > >>>>>
> > >>>>>>
> > >>>>>> Evan
> > >>>>>>
> > >>>>>>>
> > >>>>>>> Huacai
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> Jaak
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Huacai
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Huacai
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Jaak
> > >>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Huacai
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Jaak
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> But I write this mail for a different reason:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> > >>>>>>>>>>>>>>>> indicator.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> > >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> > >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> > >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > >>>>>>>>>>>>>> needs Jaak or Evan's help.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Huacai
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > >>>>>>>>>>>>>>>>>>>>> also "no problem".
> > >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > >>>>>>>>>>>>>>>>>>>> device is also none, right?
> > >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Huacai
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Confused...
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>
> >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Evan,

On Tue, Nov 7, 2023 at 4:32 AM Evan Preston <x.arch@epreston.net> wrote:
>
> Hi Huacai,
>
> On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >
> > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > Hi, Jaak and Evan,
> > > >
> > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>
> > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > >>> Hi, Evan,
> > > >>>
> > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> > > >>>>
> > > >>>> Hi Huacai,
> > > >>>>
> > > >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > >>>>> Hi, Evan,
> > > >>>>>
> > > >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > > >>>>>>
> > > >>>>>> Hi Huacai,
> > > >>>>>>
> > > >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > >>>>>>> Hi, Jaak,
> > > >>>>>>>
> > > >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> > > >>>>>>>>> Hi, Jaak and Evan,
> > > >>>>>>>>>
> > > >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> > > >>>>>>>>>>>> Hi, Jaak,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Javier, Dave, Sima,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > >>>>>>>>>>>>>>>>> I don't have a same machine.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> > > >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> > > >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> > > >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> > > >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > >>>>>>>>>>>> the firmware may pass wrong screen information.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> > > >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> > > >>>>>>>>>> 'dmesg' command after boot.
> > > >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> > > >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> > > >>>>>>>>> you very much.
> > > >>>>>>>>>
> > > >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > >>>>>>>>
> > > >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> > > >>>>>>> I'm sorry, please download from attachment.
> > > >>>>>>
> > > >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > >>>>>> produces no dmesg output on my machine.
> > > >>>>> You copy-paste the patch? If you download it directly it can be
> > > >>>>> applied successfully, I think.
> > > >>>>
> > > >>>> The patch downloaded from your URL applies successfully.  However, I still
> > > >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > > >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > > >>> Thank you for your testing. Since you cannot boot to GUI successfully
> > > >>> as Jaak, you may have some troubles with getting the dmesg output. But
> > > >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> > > >>> In this way you may boot to the login: prompt and then you can get
> > > >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > > >>> to get the previous dmesg output with 6.4.12.
> > > >>>
> > > >>> Hi, Jaak,
> > > >>>
> > > >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> > > >>
> > > >> Yes, just tested it, here I think are the relevant parts from a dmesg
> > > >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> > > >>
> > > >> ...
> > > >> [    2.909625] sysfb 1
> > > >> [    2.909627] sysfb 2
> > > >> ...
> > > >> [    2.951477] ACPI: bus type drm_connector registered
> > > >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> > > >> [    2.952105] resource: resource sanity check: requesting [mem
> > > >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> > > >> [mem 0xe0000000-0xe012bfff]
> > > >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> > > >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> > > >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> > > >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> > > >> i915/kbl_dmc_ver1_04.bin (v1.4)
> > > >> ...
> > > >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> > > >> minor 0
> > > >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> > > >> no  post: no)
> > > >> [    4.144414] input: Video Bus as
> > > >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> > > >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> > > >> [    4.144590] usbcore: registered new interface driver udl
> > > >> [    4.144603] T: probe 1
> > > >> [    4.144605] T: create 1
> > > >> [    4.144610] T: create 2
> > > >> [    4.144611] T: create 3a-1
> > > >> [    4.144613] T: create 3a-2
> > > >> [    4.144614] T: create 3a-3
> > > >> [    4.144616] T: create 3a-4
> > > >> [    4.144618] T: create 4
> > > >> [    4.144619] T: create 5
> > > >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> > > >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> > > >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> > > >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> > > >> stride=2560 byte
> > > >> [    4.144633] T: create 6b-1
> > > >> [    4.144635] T: create 6b-2
> > > >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> > > >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> > > >> [    4.144643] T: create 6b-3
> > > >> [    4.144660] T: create 6b-4
> > > >> [    4.144662] T: create 7
> > > >> [    4.144673] T: create 8
> > > >> [    4.144676] T: create 9
> > > >> [    4.144678] T: create 10
> > > >> [    4.144681] T: create 11
> > > >> [    4.144685] T: create 12
> > > >> [    4.144689] T: probe 2
> > > >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> > > >> simple-framebuffer.0 on minor 2
> > > >> [    4.144732] T: probe 3
> > > >> [    4.145905] Console: switching to colour frame buffer device 80x30
> > > >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> > > >> simpledrmdrmfb frame buffer device
> > > >> [    4.150766] T: probe 4
> > > >> [    4.151218] loop: module loaded
> > > >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> > > >> ...
> > > >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> > > >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> > > >> ...
> > > >>
> > > >> The last message might be due to the display manager starting up.
> > > >>
> > > >> Hope it helps.
> > > > Thank you for your testing. Jaak's problem seems related to the
> > > > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > > > move
> > > >
> > > > obj-y                  += tiny/
> > > >
> > > > to between these two lines
> > > >
> > > > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > > >
> > > > then build a new 6.5.x kernel to see whether your problem is resolved.
> > >
> > > Yes, this seems to have resolved it.
> > Hi, Jaak,
> >
> > Thank you very much, and I hope this also solves Evan's problem.
>
> I still get a blank screen if I modify drivers/gpu/drm/Makefile to move the
> order of 'tiny'.
You probably encounter another problem which has no relationship with
60aebc9559492cea6a9625f514a804 ("drivers/firmware: Move sysfb_init()
from device_initcall to subsys_initcall_sync"). You can revert it to
test 6.5.x again.

Huacai

>
> >
> > Hi, Javier,
> >
> > I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
> > Jaak's problem is due to the initialization order of drivers, and this
> > order depends on the Makefile.
> >
> > FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> > so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
> > I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
> > DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
> > work.
> >
> > So, when I move the "tiny" directory before i915, the problem is
> > solved. But the new problem is: is it acceptable to solve this problem
> > by adjusting Makefile?
> >
> > Huacai
> >
> > >
> > > Jaak
> > >
> > > >
> > > > Evan's problem seems a little strange, could you please give me your
> > > > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > > > method to see if anything changes.
>
> I'll send you my config files.
>
> > > >
> > > > Huacai
> > > >
> > > >>
> > > >> J
> > > >>
> > > >>>
> > > >>>>
> > > >>>> Evan
> > > >>>>
> > > >>>>>
> > > >>>>> Huacai
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Evan
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> Huacai
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Jaak
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Huacai
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Huacai
> > > >>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Jaak
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Jaak
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> But I write this mail for a different reason:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > >>>>>>>>>>>>>>>> indicator.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> > > >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> > > >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> > > >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > >>>>>>>>>>>>>> needs Jaak or Evan's help.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > >>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > >>>>>>>>>>>>>>>>>>>>> also "no problem".
> > > >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > >>>>>>>>>>>>>>>>>>>> device is also none, right?
> > > >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Confused...
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>
> > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

Hi Huacai,

On 2023-11-07 Tue 09:49am, Huacai Chen wrote:
> Hi, Evan,
> 
> On Tue, Nov 7, 2023 at 4:32 AM Evan Preston <x.arch@epreston.net> wrote:
> >
> > Hi Huacai,
> >
> > On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >
> > > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > > Hi, Jaak and Evan,
> > > > >
> > > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>
> > > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > > >>> Hi, Evan,
> > > > >>>
> > > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> > > > >>>>
> > > > >>>> Hi Huacai,
> > > > >>>>
> > > > >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > > >>>>> Hi, Evan,
> > > > >>>>>
> > > > >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > > > >>>>>>
> > > > >>>>>> Hi Huacai,
> > > > >>>>>>
> > > > >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > > >>>>>>> Hi, Jaak,
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> > > > >>>>>>>>> Hi, Jaak and Evan,
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > >>>>>>>>>>>> Hi, Jaak,
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > > >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Javier, Dave, Sima,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > > >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > > >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > > >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > > >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > > >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > > >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > > >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > > >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > > >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > > >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > > >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > > >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > > >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > > >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > > >>>>>>>>>>>>>>>>> I don't have a same machine.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > > >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> > > > >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > > >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > > >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> > > > >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> > > > >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > > >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > > >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> > > > >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > > >>>>>>>>>>>> the firmware may pass wrong screen information.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > > >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > > >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > > >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > > >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > > >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > > >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> > > > >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> > > > >>>>>>>>>> 'dmesg' command after boot.
> > > > >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> > > > >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> > > > >>>>>>>>> you very much.
> > > > >>>>>>>>>
> > > > >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > > >>>>>>>>
> > > > >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> > > > >>>>>>> I'm sorry, please download from attachment.
> > > > >>>>>>
> > > > >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > > >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > > >>>>>> produces no dmesg output on my machine.
> > > > >>>>> You copy-paste the patch? If you download it directly it can be
> > > > >>>>> applied successfully, I think.
> > > > >>>>
> > > > >>>> The patch downloaded from your URL applies successfully.  However, I still
> > > > >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > > > >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > > > >>> Thank you for your testing. Since you cannot boot to GUI successfully
> > > > >>> as Jaak, you may have some troubles with getting the dmesg output. But
> > > > >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> > > > >>> In this way you may boot to the login: prompt and then you can get
> > > > >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > > > >>> to get the previous dmesg output with 6.4.12.
> > > > >>>
> > > > >>> Hi, Jaak,
> > > > >>>
> > > > >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> > > > >>
> > > > >> Yes, just tested it, here I think are the relevant parts from a dmesg
> > > > >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> > > > >>
> > > > >> ...
> > > > >> [    2.909625] sysfb 1
> > > > >> [    2.909627] sysfb 2
> > > > >> ...
> > > > >> [    2.951477] ACPI: bus type drm_connector registered
> > > > >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> > > > >> [    2.952105] resource: resource sanity check: requesting [mem
> > > > >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> > > > >> [mem 0xe0000000-0xe012bfff]
> > > > >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> > > > >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> > > > >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> > > > >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> > > > >> i915/kbl_dmc_ver1_04.bin (v1.4)
> > > > >> ...
> > > > >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> > > > >> minor 0
> > > > >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> > > > >> no  post: no)
> > > > >> [    4.144414] input: Video Bus as
> > > > >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> > > > >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> > > > >> [    4.144590] usbcore: registered new interface driver udl
> > > > >> [    4.144603] T: probe 1
> > > > >> [    4.144605] T: create 1
> > > > >> [    4.144610] T: create 2
> > > > >> [    4.144611] T: create 3a-1
> > > > >> [    4.144613] T: create 3a-2
> > > > >> [    4.144614] T: create 3a-3
> > > > >> [    4.144616] T: create 3a-4
> > > > >> [    4.144618] T: create 4
> > > > >> [    4.144619] T: create 5
> > > > >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> > > > >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> > > > >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> > > > >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> > > > >> stride=2560 byte
> > > > >> [    4.144633] T: create 6b-1
> > > > >> [    4.144635] T: create 6b-2
> > > > >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> > > > >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> > > > >> [    4.144643] T: create 6b-3
> > > > >> [    4.144660] T: create 6b-4
> > > > >> [    4.144662] T: create 7
> > > > >> [    4.144673] T: create 8
> > > > >> [    4.144676] T: create 9
> > > > >> [    4.144678] T: create 10
> > > > >> [    4.144681] T: create 11
> > > > >> [    4.144685] T: create 12
> > > > >> [    4.144689] T: probe 2
> > > > >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> > > > >> simple-framebuffer.0 on minor 2
> > > > >> [    4.144732] T: probe 3
> > > > >> [    4.145905] Console: switching to colour frame buffer device 80x30
> > > > >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> > > > >> simpledrmdrmfb frame buffer device
> > > > >> [    4.150766] T: probe 4
> > > > >> [    4.151218] loop: module loaded
> > > > >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> > > > >> ...
> > > > >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> > > > >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> > > > >> ...
> > > > >>
> > > > >> The last message might be due to the display manager starting up.
> > > > >>
> > > > >> Hope it helps.
> > > > > Thank you for your testing. Jaak's problem seems related to the
> > > > > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > > > > move
> > > > >
> > > > > obj-y                  += tiny/
> > > > >
> > > > > to between these two lines
> > > > >
> > > > > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > > > >
> > > > > then build a new 6.5.x kernel to see whether your problem is resolved.
> > > >
> > > > Yes, this seems to have resolved it.
> > > Hi, Jaak,
> > >
> > > Thank you very much, and I hope this also solves Evan's problem.
> >
> > I still get a blank screen if I modify drivers/gpu/drm/Makefile to move the
> > order of 'tiny'.
> You probably encounter another problem which has no relationship with
> 60aebc9559492cea6a9625f514a804 ("drivers/firmware: Move sysfb_init()
> from device_initcall to subsys_initcall_sync"). You can revert it to
> test 6.5.x again.

You are right.  I reverted "drivers/firmware: Move sysfb_init() from 
device_initcall to subsys_initcall_sync" on 6.5.9 and still get a blank 
screen immediately after boot loader entry selection.

Evan

> 
> Huacai
> 
> >
> > >
> > > Hi, Javier,
> > >
> > > I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
> > > Jaak's problem is due to the initialization order of drivers, and this
> > > order depends on the Makefile.
> > >
> > > FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> > > so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
> > > I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
> > > DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
> > > work.
> > >
> > > So, when I move the "tiny" directory before i915, the problem is
> > > solved. But the new problem is: is it acceptable to solve this problem
> > > by adjusting Makefile?
> > >
> > > Huacai
> > >
> > > >
> > > > Jaak
> > > >
> > > > >
> > > > > Evan's problem seems a little strange, could you please give me your
> > > > > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > > > > method to see if anything changes.
> >
> > I'll send you my config files.
> >
> > > > >
> > > > > Huacai
> > > > >
> > > > >>
> > > > >> J
> > > > >>
> > > > >>>
> > > > >>>>
> > > > >>>> Evan
> > > > >>>>
> > > > >>>>>
> > > > >>>>> Huacai
> > > > >>>>>
> > > > >>>>>>
> > > > >>>>>> Evan
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>> Huacai
> > > > >>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Jaak
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> Huacai
> > > > >>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Huacai
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Jaak
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Huacai
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Jaak
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> But I write this mail for a different reason:
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > > >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > > >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > > >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > > >>>>>>>>>>>>>>>> indicator.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> > > > >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > > >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > > >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> > > > >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > > >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> > > > >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > > >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > > >>>>>>>>>>>>>> needs Jaak or Evan's help.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Huacai
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > >>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > > >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > > >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > > >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > > >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > > >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > > >>>>>>>>>>>>>>>>>>>>> also "no problem".
> > > > >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > > >>>>>>>>>>>>>>>>>>>> device is also none, right?
> > > > >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > > >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Huacai
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Confused...
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>
> > > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Thorsten and Jaak,

On Tue, Nov 7, 2023 at 4:32 AM Evan Preston <x.arch@epreston.net> wrote:
>
> Hi Huacai,
>
> On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > >
> > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > Hi, Jaak and Evan,
> > > >
> > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>
> > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > >>> Hi, Evan,
> > > >>>
> > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> > > >>>>
> > > >>>> Hi Huacai,
> > > >>>>
> > > >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > >>>>> Hi, Evan,
> > > >>>>>
> > > >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > > >>>>>>
> > > >>>>>> Hi Huacai,
> > > >>>>>>
> > > >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > >>>>>>> Hi, Jaak,
> > > >>>>>>>
> > > >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> > > >>>>>>>>> Hi, Jaak and Evan,
> > > >>>>>>>>>
> > > >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> > > >>>>>>>>>>>> Hi, Jaak,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Javier, Dave, Sima,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > >>>>>>>>>>>>>>>>> I don't have a same machine.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> > > >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> > > >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> > > >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> > > >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > >>>>>>>>>>>> the firmware may pass wrong screen information.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> > > >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> > > >>>>>>>>>> 'dmesg' command after boot.
> > > >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> > > >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> > > >>>>>>>>> you very much.
> > > >>>>>>>>>
> > > >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > >>>>>>>>
> > > >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> > > >>>>>>> I'm sorry, please download from attachment.
> > > >>>>>>
> > > >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > >>>>>> produces no dmesg output on my machine.
> > > >>>>> You copy-paste the patch? If you download it directly it can be
> > > >>>>> applied successfully, I think.
> > > >>>>
> > > >>>> The patch downloaded from your URL applies successfully.  However, I still
> > > >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > > >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > > >>> Thank you for your testing. Since you cannot boot to GUI successfully
> > > >>> as Jaak, you may have some troubles with getting the dmesg output. But
> > > >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> > > >>> In this way you may boot to the login: prompt and then you can get
> > > >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > > >>> to get the previous dmesg output with 6.4.12.
> > > >>>
> > > >>> Hi, Jaak,
> > > >>>
> > > >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> > > >>
> > > >> Yes, just tested it, here I think are the relevant parts from a dmesg
> > > >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> > > >>
> > > >> ...
> > > >> [    2.909625] sysfb 1
> > > >> [    2.909627] sysfb 2
> > > >> ...
> > > >> [    2.951477] ACPI: bus type drm_connector registered
> > > >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> > > >> [    2.952105] resource: resource sanity check: requesting [mem
> > > >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> > > >> [mem 0xe0000000-0xe012bfff]
> > > >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> > > >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> > > >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> > > >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> > > >> i915/kbl_dmc_ver1_04.bin (v1.4)
> > > >> ...
> > > >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> > > >> minor 0
> > > >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> > > >> no  post: no)
> > > >> [    4.144414] input: Video Bus as
> > > >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> > > >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> > > >> [    4.144590] usbcore: registered new interface driver udl
> > > >> [    4.144603] T: probe 1
> > > >> [    4.144605] T: create 1
> > > >> [    4.144610] T: create 2
> > > >> [    4.144611] T: create 3a-1
> > > >> [    4.144613] T: create 3a-2
> > > >> [    4.144614] T: create 3a-3
> > > >> [    4.144616] T: create 3a-4
> > > >> [    4.144618] T: create 4
> > > >> [    4.144619] T: create 5
> > > >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> > > >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> > > >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> > > >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> > > >> stride=2560 byte
> > > >> [    4.144633] T: create 6b-1
> > > >> [    4.144635] T: create 6b-2
> > > >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> > > >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> > > >> [    4.144643] T: create 6b-3
> > > >> [    4.144660] T: create 6b-4
> > > >> [    4.144662] T: create 7
> > > >> [    4.144673] T: create 8
> > > >> [    4.144676] T: create 9
> > > >> [    4.144678] T: create 10
> > > >> [    4.144681] T: create 11
> > > >> [    4.144685] T: create 12
> > > >> [    4.144689] T: probe 2
> > > >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> > > >> simple-framebuffer.0 on minor 2
> > > >> [    4.144732] T: probe 3
> > > >> [    4.145905] Console: switching to colour frame buffer device 80x30
> > > >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> > > >> simpledrmdrmfb frame buffer device
> > > >> [    4.150766] T: probe 4
> > > >> [    4.151218] loop: module loaded
> > > >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> > > >> ...
> > > >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> > > >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> > > >> ...
> > > >>
> > > >> The last message might be due to the display manager starting up.
> > > >>
> > > >> Hope it helps.
> > > > Thank you for your testing. Jaak's problem seems related to the
> > > > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > > > move
> > > >
> > > > obj-y                  += tiny/
> > > >
> > > > to between these two lines
> > > >
> > > > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > > >
> > > > then build a new 6.5.x kernel to see whether your problem is resolved.
> > >
> > > Yes, this seems to have resolved it.
> > Hi, Jaak,
> >
> > Thank you very much, and I hope this also solves Evan's problem.
>
> I still get a blank screen if I modify drivers/gpu/drm/Makefile to move the
> order of 'tiny'.
>
> >
> > Hi, Javier,
> >
> > I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
> > Jaak's problem is due to the initialization order of drivers, and this
> > order depends on the Makefile.
> >
> > FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> > so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
> > I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
> > DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
> > work.
> >
> > So, when I move the "tiny" directory before i915, the problem is
> > solved. But the new problem is: is it acceptable to solve this problem
> > by adjusting Makefile?
> >
> > Huacai
I have propose a patch to fix this problem:
https://lore.kernel.org/dri-devel/20231108024613.2898921-1-chenhuacai@loongson.cn/T/#u

Huacai

> >
> > >
> > > Jaak
> > >
> > > >
> > > > Evan's problem seems a little strange, could you please give me your
> > > > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > > > method to see if anything changes.
>
> I'll send you my config files.
>
> > > >
> > > > Huacai
> > > >
> > > >>
> > > >> J
> > > >>
> > > >>>
> > > >>>>
> > > >>>> Evan
> > > >>>>
> > > >>>>>
> > > >>>>> Huacai
> > > >>>>>
> > > >>>>>>
> > > >>>>>> Evan
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>> Huacai
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Jaak
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> Huacai
> > > >>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Huacai
> > > >>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Jaak
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Jaak
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> But I write this mail for a different reason:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > >>>>>>>>>>>>>>>> indicator.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> > > >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> > > >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> > > >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > >>>>>>>>>>>>>> needs Jaak or Evan's help.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > >>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > >>>>>>>>>>>>>>>>>>>>> also "no problem".
> > > >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > >>>>>>>>>>>>>>>>>>>> device is also none, right?
> > > >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Huacai
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Confused...
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>
> > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Evan Preston]

On 2023-11-06 Mon 09:39pm, Evan Preston wrote:
> Hi Huacai,
> 
> On 2023-11-07 Tue 09:49am, Huacai Chen wrote:
> > Hi, Evan,
> > 
> > On Tue, Nov 7, 2023 at 4:32 AM Evan Preston <x.arch@epreston.net> wrote:
> > >
> > > Hi Huacai,
> > >
> > > On 2023-11-06 Mon 10:22pm, Huacai Chen wrote:
> > > > On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > >
> > > > > On 06.11.23 04:15, Huacai Chen wrote:
> > > > > > Hi, Jaak and Evan,
> > > > > >
> > > > > > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>
> > > > > >> On 05.11.23 14:40, Huacai Chen wrote:
> > > > > >>> Hi, Evan,
> > > > > >>>
> > > > > >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> > > > > >>>>
> > > > > >>>> Hi Huacai,
> > > > > >>>>
> > > > > >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> > > > > >>>>> Hi, Evan,
> > > > > >>>>>
> > > > > >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> > > > > >>>>>>
> > > > > >>>>>> Hi Huacai,
> > > > > >>>>>>
> > > > > >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> > > > > >>>>>>> Hi, Jaak,
> > > > > >>>>>>>
> > > > > >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> > > > > >>>>>>>>> Hi, Jaak and Evan,
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> > > > > >>>>>>>>>>>> Hi, Jaak,
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> > > > > >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> > > > > >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Javier, Dave, Sima,
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> > > > > >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> > > > > >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> > > > > >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> > > > > >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> > > > > >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> > > > > >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> > > > > >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> > > > > >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> > > > > >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> > > > > >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> > > > > >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> > > > > >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> > > > > >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> > > > > >>>>>>>>>>>>>>>>> I don't have a same machine.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> > > > > >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> > > > > >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> > > > > >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> > > > > >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> > > > > >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> > > > > >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> > > > > >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> > > > > >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> > > > > >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> > > > > >>>>>>>>>>>> the firmware may pass wrong screen information.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> > > > > >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> > > > > >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> > > > > >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> > > > > >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> > > > > >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> > > > > >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> > > > > >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> > > > > >>>>>>>>>> 'dmesg' command after boot.
> > > > > >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> > > > > >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> > > > > >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> > > > > >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> > > > > >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> > > > > >>>>>>>>> you very much.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> > > > > >>>>>>>>
> > > > > >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> > > > > >>>>>>> I'm sorry, please download from attachment.
> > > > > >>>>>>
> > > > > >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> > > > > >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> > > > > >>>>>> produces no dmesg output on my machine.
> > > > > >>>>> You copy-paste the patch? If you download it directly it can be
> > > > > >>>>> applied successfully, I think.
> > > > > >>>>
> > > > > >>>> The patch downloaded from your URL applies successfully.  However, I still
> > > > > >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> > > > > >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> > > > > >>> Thank you for your testing. Since you cannot boot to GUI successfully
> > > > > >>> as Jaak, you may have some troubles with getting the dmesg output. But
> > > > > >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> > > > > >>> In this way you may boot to the login: prompt and then you can get
> > > > > >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> > > > > >>> to get the previous dmesg output with 6.4.12.
> > > > > >>>
> > > > > >>> Hi, Jaak,
> > > > > >>>
> > > > > >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> > > > > >>
> > > > > >> Yes, just tested it, here I think are the relevant parts from a dmesg
> > > > > >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> > > > > >>
> > > > > >> ...
> > > > > >> [    2.909625] sysfb 1
> > > > > >> [    2.909627] sysfb 2
> > > > > >> ...
> > > > > >> [    2.951477] ACPI: bus type drm_connector registered
> > > > > >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> > > > > >> [    2.952105] resource: resource sanity check: requesting [mem
> > > > > >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> > > > > >> [mem 0xe0000000-0xe012bfff]
> > > > > >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> > > > > >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> > > > > >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> > > > > >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> > > > > >> i915/kbl_dmc_ver1_04.bin (v1.4)
> > > > > >> ...
> > > > > >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> > > > > >> minor 0
> > > > > >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> > > > > >> no  post: no)
> > > > > >> [    4.144414] input: Video Bus as
> > > > > >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> > > > > >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> > > > > >> [    4.144590] usbcore: registered new interface driver udl
> > > > > >> [    4.144603] T: probe 1
> > > > > >> [    4.144605] T: create 1
> > > > > >> [    4.144610] T: create 2
> > > > > >> [    4.144611] T: create 3a-1
> > > > > >> [    4.144613] T: create 3a-2
> > > > > >> [    4.144614] T: create 3a-3
> > > > > >> [    4.144616] T: create 3a-4
> > > > > >> [    4.144618] T: create 4
> > > > > >> [    4.144619] T: create 5
> > > > > >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> > > > > >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> > > > > >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> > > > > >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> > > > > >> stride=2560 byte
> > > > > >> [    4.144633] T: create 6b-1
> > > > > >> [    4.144635] T: create 6b-2
> > > > > >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> > > > > >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> > > > > >> [    4.144643] T: create 6b-3
> > > > > >> [    4.144660] T: create 6b-4
> > > > > >> [    4.144662] T: create 7
> > > > > >> [    4.144673] T: create 8
> > > > > >> [    4.144676] T: create 9
> > > > > >> [    4.144678] T: create 10
> > > > > >> [    4.144681] T: create 11
> > > > > >> [    4.144685] T: create 12
> > > > > >> [    4.144689] T: probe 2
> > > > > >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> > > > > >> simple-framebuffer.0 on minor 2
> > > > > >> [    4.144732] T: probe 3
> > > > > >> [    4.145905] Console: switching to colour frame buffer device 80x30
> > > > > >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> > > > > >> simpledrmdrmfb frame buffer device
> > > > > >> [    4.150766] T: probe 4
> > > > > >> [    4.151218] loop: module loaded
> > > > > >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> > > > > >> ...
> > > > > >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> > > > > >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> > > > > >> ...
> > > > > >>
> > > > > >> The last message might be due to the display manager starting up.
> > > > > >>
> > > > > >> Hope it helps.
> > > > > > Thank you for your testing. Jaak's problem seems related to the
> > > > > > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > > > > > move
> > > > > >
> > > > > > obj-y                  += tiny/
> > > > > >
> > > > > > to between these two lines
> > > > > >
> > > > > > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > > > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > > > > >
> > > > > > then build a new 6.5.x kernel to see whether your problem is resolved.
> > > > >
> > > > > Yes, this seems to have resolved it.
> > > > Hi, Jaak,
> > > >
> > > > Thank you very much, and I hope this also solves Evan's problem.
> > >
> > > I still get a blank screen if I modify drivers/gpu/drm/Makefile to move the
> > > order of 'tiny'.
> > You probably encounter another problem which has no relationship with
> > 60aebc9559492cea6a9625f514a804 ("drivers/firmware: Move sysfb_init()
> > from device_initcall to subsys_initcall_sync"). You can revert it to
> > test 6.5.x again.
> 
> You are right.  I reverted "drivers/firmware: Move sysfb_init() from 
> device_initcall to subsys_initcall_sync" on 6.5.9 and still get a blank 
> screen immediately after boot loader entry selection.
> 
> Evan
> 

Just to close the loop on my issue: after a BIOS update I can boot 6.5.x 
successfully.

Evan

> > 
> > Huacai
> > 
> > >
> > > >
> > > > Hi, Javier,
> > > >
> > > > I think I have mostly found the root cause. DRM_SIMPLEDRM has no bugs,
> > > > Jaak's problem is due to the initialization order of drivers, and this
> > > > order depends on the Makefile.
> > > >
> > > > FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> > > > so on), but DRM_SIMPLEDRM is after them. Thus, if Jaak uses FB_SIMPLE,
> > > > I915 will takeover FB_SIMPLE, then no problem; and if Jaak uses
> > > > DRM_SIMPLEDRM, DRM_SIMPLEDRM will try to takeover I915, but fails to
> > > > work.
> > > >
> > > > So, when I move the "tiny" directory before i915, the problem is
> > > > solved. But the new problem is: is it acceptable to solve this problem
> > > > by adjusting Makefile?
> > > >
> > > > Huacai
> > > >
> > > > >
> > > > > Jaak
> > > > >
> > > > > >
> > > > > > Evan's problem seems a little strange, could you please give me your
> > > > > > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > > > > > method to see if anything changes.
> > >
> > > I'll send you my config files.
> > >
> > > > > >
> > > > > > Huacai
> > > > > >
> > > > > >>
> > > > > >> J
> > > > > >>
> > > > > >>>
> > > > > >>>>
> > > > > >>>> Evan
> > > > > >>>>
> > > > > >>>>>
> > > > > >>>>> Huacai
> > > > > >>>>>
> > > > > >>>>>>
> > > > > >>>>>> Evan
> > > > > >>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> Huacai
> > > > > >>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Jaak
> > > > > >>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Huacai
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Huacai
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Jaak
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Huacai
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Jaak
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> But I write this mail for a different reason:
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> > > > > >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> > > > > >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> > > > > >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> > > > > >>>>>>>>>>>>>>>> indicator.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> > > > > >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > > > > >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> > > > > >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> > > > > >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> > > > > >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> > > > > >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> > > > > >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> > > > > >>>>>>>>>>>>>> needs Jaak or Evan's help.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Huacai
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > > >>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> > > > > >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> > > > > >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> > > > > >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> > > > > >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> > > > > >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> > > > > >>>>>>>>>>>>>>>>>>>>> also "no problem".
> > > > > >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> > > > > >>>>>>>>>>>>>>>>>>>> device is also none, right?
> > > > > >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> > > > > >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> > > > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> > > > > >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Huacai
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> Confused...
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>
> > > > >

Re: Blank screen on boot of Linux 6.5 and later on Lenovo ThinkPad L570

[Huacai Chen]

Hi, Jaak,

On Mon, Nov 6, 2023 at 9:49 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
>
> On 06.11.23 04:15, Huacai Chen wrote:
> > Hi, Jaak and Evan,
> >
> > On Mon, Nov 6, 2023 at 12:28 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>
> >> On 05.11.23 14:40, Huacai Chen wrote:
> >>> Hi, Evan,
> >>>
> >>> On Sat, Nov 4, 2023 at 10:50 AM Evan Preston <x.arch@epreston.net> wrote:
> >>>>
> >>>> Hi Huacai,
> >>>>
> >>>> On 2023-11-03 Fri 02:36pm, Huacai Chen wrote:
> >>>>> Hi, Evan,
> >>>>>
> >>>>> On Fri, Nov 3, 2023 at 1:54 PM Evan Preston <x.arch@epreston.net> wrote:
> >>>>>>
> >>>>>> Hi Huacai,
> >>>>>>
> >>>>>> On 2023-11-02 Thu 08:38pm, Huacai Chen wrote:
> >>>>>>> Hi, Jaak,
> >>>>>>>
> >>>>>>> On Wed, Nov 1, 2023 at 7:52 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>
> >>>>>>>> On 31.10.23 14:17, Huacai Chen wrote:
> >>>>>>>>> Hi, Jaak and Evan,
> >>>>>>>>>
> >>>>>>>>> On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 26.10.23 03:58, Huacai Chen wrote:
> >>>>>>>>>>>> Hi, Jaak,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja <jaak@ristioja.ee> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 25.10.23 16:23, Huacai Chen wrote:
> >>>>>>>>>>>>>> On Wed, Oct 25, 2023 at 6:08 PM Thorsten Leemhuis
> >>>>>>>>>>>>>> <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Javier, Dave, Sima,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 23.10.23 00:54, Evan Preston wrote:
> >>>>>>>>>>>>>>>> On 2023-10-20 Fri 05:48pm, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>> On Fri, Oct 20, 2023 at 5:35 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>>>> On 09.10.23 10:54, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at 4:45 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 09, 2023 at 09:27:02AM +0800, Huacai Chen wrote:
> >>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 10:31 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Tue, Sep 26, 2023 at 7:15 PM Linux regression tracking (Thorsten
> >>>>>>>>>>>>>>>>>>>>>> Leemhuis) <regressions@leemhuis.info> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 13.09.23 14:02, Jaak Ristioja wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Upgrading to Linux 6.5 on a Lenovo ThinkPad L570 (Integrated Intel HD
> >>>>>>>>>>>>>>>>>>>>>>>> Graphics 620 (rev 02), Intel(R) Core(TM) i7-7500U) results in a blank
> >>>>>>>>>>>>>>>>>>>>>>>> screen after boot until the display manager starts... if it does start
> >>>>>>>>>>>>>>>>>>>>>>>> at all. Using the nomodeset kernel parameter seems to be a workaround.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I've bisected this to commit 60aebc9559492cea6a9625f514a8041717e3a2e4
> >>>>>>>>>>>>>>>>>>>>>>>> ("drivers/firmware: Move sysfb_init() from device_initcall to
> >>>>>>>>>>>>>>>>>>>>>>>> subsys_initcall_sync").
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> As confirmed by Jaak, disabling DRM_SIMPLEDRM makes things work fine
> >>>>>>>>>>>>>>>>>>>>> again. So I guess the reason:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Well, this to me still looks a lot (please correct me if I'm wrong) like
> >>>>>>>>>>>>>>>>>> regression that should be fixed, as DRM_SIMPLEDRM was enabled beforehand
> >>>>>>>>>>>>>>>>>> if I understood things correctly. Or is there a proper fix for this
> >>>>>>>>>>>>>>>>>> already in the works and I just missed this? Or is there some good
> >>>>>>>>>>>>>>>>>> reason why this won't/can't be fixed?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM was enabled but it didn't work at all because there was
> >>>>>>>>>>>>>>>>> no corresponding platform device. Now DRM_SIMPLEDRM works but it has a
> >>>>>>>>>>>>>>>>> blank screen. Of course it is valuable to investigate further about
> >>>>>>>>>>>>>>>>> DRM_SIMPLEDRM on Jaak's machine, but that needs Jaak's effort because
> >>>>>>>>>>>>>>>>> I don't have a same machine.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Side note: Huacai, have you tried working with Jaak to get down to the
> >>>>>>>>>>>>>>> real problem? Evan, might you be able to help out here?
> >>>>>>>>>>>>>> No, Jaak has no response after he 'fixed' his problem by disabling SIMPLEDRM.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm sorry, what was it exactly you want me to do? Please be mindful that
> >>>>>>>>>>>>> I'm not familiar with the internals of the Linux kernel and DRI, and it
> >>>>>>>>>>>>> might sometimes take weeks before I have time to work and respond on this.
> >>>>>>>>>>>> It doesn't matter. I hope you can do some experiments to investigate
> >>>>>>>>>>>> deeper. The first experiment you can do is enabling SIMPLEFB (i.e.
> >>>>>>>>>>>> CONFIG_FB_SIMPLE) instead of SIMPLEDRM (CONFIG_DRM_SIMPLEDRM) to see
> >>>>>>>>>>>> whether there is also a blank screen. If no blank screen, that
> >>>>>>>>>>>> probably means SIMPLEDRM has a bug, if still blank screen, that means
> >>>>>>>>>>>> the firmware may pass wrong screen information.
> >>>>>>>>>>>
> >>>>>>>>>>> Testing with 6.5.9 I get a blank screen with CONFIG_DRM_SIMPLEDRM=y and
> >>>>>>>>>>> get no blank screen with CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM unset.
> >>>>>>>>>> CONFIG_FB_SIMPLE and  CONFIG_DRM_SIMPLEDRM use the same device created
> >>>>>>>>>> by sysfb_init(). Since FB_SIMPLE works fine, I think the real problem
> >>>>>>>>>> is that DRM_SIMPLEDRM has a bug. The next step is to enable
> >>>>>>>>>> CONFIG_DRM_SIMPLEDRM and trace its initialization. In detail, adding
> >>>>>>>>>> some printk() in simpledrm_probe() and its sub-routines to see where
> >>>>>>>>>> the driver fails. The output of these printk() can be seen by the
> >>>>>>>>>> 'dmesg' command after boot.
> >>>>>>>>> I need your help. I tried with my laptop (ThinkPad E490, Intel Core
> >>>>>>>>> i3-8145U, UHD Graphics 620) but I can't reproduce your problem. So
> >>>>>>>>> please patch your 6.5.x kernel with this temporary patch [1], then
> >>>>>>>>> build a "bad kernel" with SIMPLEDRM enabled. And after booting your
> >>>>>>>>> machine with this "bad kernel", please give me the dmesg output. Thank
> >>>>>>>>> you very much.
> >>>>>>>>>
> >>>>>>>>> [1] http://ddns.miaomiaomiao.top:9000/download/kernel/patch-6.5.9
> >>>>>>>>
> >>>>>>>> I'm unable to download it. Can you please send it by e-mail?
> >>>>>>> I'm sorry, please download from attachment.
> >>>>>>
> >>>>>> When applying this patch the first hunk (drivers/firmware/sysfb.c) fails for
> >>>>>> me with 6.5.9.  Attempting to load the 6.5.9 kernel without this patch
> >>>>>> produces no dmesg output on my machine.
> >>>>> You copy-paste the patch? If you download it directly it can be
> >>>>> applied successfully, I think.
> >>>>
> >>>> The patch downloaded from your URL applies successfully.  However, I still
> >>>> see no dmesg output using the patched 6.5.9 kernel.  'journalctl -k -b all'
> >>>> shows no dmesg output from any 6.5.x boots, only from 6.4.12 boots.
> >>> Thank you for your testing. Since you cannot boot to GUI successfully
> >>> as Jaak, you may have some troubles with getting the dmesg output. But
> >>> you can try to use "systemd.unit=multi-user.target" boot parameters.
> >>> In this way you may boot to the login: prompt and then you can get
> >>> dmesg output. Or if you still fail, you may use 'jornalctl -k -b -1'
> >>> to get the previous dmesg output with 6.4.12.
> >>>
> >>> Hi, Jaak,
> >>>
> >>> Have you tested? I think you can successfully get a dmesg output with my patch.
> >>
> >> Yes, just tested it, here I think are the relevant parts from a dmesg
> >> produced with CONFIG_DRM_SIMPLEDRM and the patch provided by Huacai:
> >>
> >> ...
> >> [    2.909625] sysfb 1
> >> [    2.909627] sysfb 2
> >> ...
> >> [    2.951477] ACPI: bus type drm_connector registered
> >> [    2.952096] i915 0000:00:02.0: [drm] VT-d active for gfx access
> >> [    2.952105] resource: resource sanity check: requesting [mem
> >> 0x00000000e0000000-0x00000000efffffff], which spans more than BOOTFB
> >> [mem 0xe0000000-0xe012bfff]
> >> [    2.952111] caller i915_ggtt_init_hw+0x88/0x120 mapping multiple BARs
> >> [    2.952138] i915 0000:00:02.0: [drm] Using Transparent Hugepages
> >> [    2.953204] Loading firmware: i915/kbl_dmc_ver1_04.bin
> >> [    2.953485] i915 0000:00:02.0: [drm] Finished loading DMC firmware
> >> i915/kbl_dmc_ver1_04.bin (v1.4)
> >> ...
> >> [    4.142075] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on
> >> minor 0
> >> [    4.144269] ACPI: video: Video Device [GFX0] (multi-head: yes  rom:
> >> no  post: no)
> >> [    4.144414] input: Video Bus as
> >> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
> >> [    4.144580] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 1
> >> [    4.144590] usbcore: registered new interface driver udl
> >> [    4.144603] T: probe 1
> >> [    4.144605] T: create 1
> >> [    4.144610] T: create 2
> >> [    4.144611] T: create 3a-1
> >> [    4.144613] T: create 3a-2
> >> [    4.144614] T: create 3a-3
> >> [    4.144616] T: create 3a-4
> >> [    4.144618] T: create 4
> >> [    4.144619] T: create 5
> >> [    4.144621] simple-framebuffer simple-framebuffer.0: [drm] display
> >> mode={"": 60 18432 640 640 640 640 480 480 480 480 0x40 0x0}
> >> [    4.144628] simple-framebuffer simple-framebuffer.0: [drm]
> >> framebuffer format=XR24 little-endian (0x34325258), size=640x480,
> >> stride=2560 byte
> >> [    4.144633] T: create 6b-1
> >> [    4.144635] T: create 6b-2
> >> [    4.144637] simple-framebuffer simple-framebuffer.0: [drm] using I/O
> >> memory framebuffer at [mem 0xe0000000-0xe012bfff flags 0x200]
> >> [    4.144643] T: create 6b-3
> >> [    4.144660] T: create 6b-4
> >> [    4.144662] T: create 7
> >> [    4.144673] T: create 8
> >> [    4.144676] T: create 9
> >> [    4.144678] T: create 10
> >> [    4.144681] T: create 11
> >> [    4.144685] T: create 12
> >> [    4.144689] T: probe 2
> >> [    4.144728] [drm] Initialized simpledrm 1.0.0 20200625 for
> >> simple-framebuffer.0 on minor 2
> >> [    4.144732] T: probe 3
> >> [    4.145905] Console: switching to colour frame buffer device 80x30
> >> [    4.150437] simple-framebuffer simple-framebuffer.0: [drm] fb0:
> >> simpledrmdrmfb frame buffer device
> >> [    4.150766] T: probe 4
> >> [    4.151218] loop: module loaded
> >> [    4.154434] i915 0000:00:02.0: [drm] fb1: i915drmfb frame buffer device
> >> ...
> >> [   44.630789] simple-framebuffer simple-framebuffer.0: swiotlb buffer
> >> is full (sz: 1310720 bytes), total 32768 (slots), used 0 (slots)
> >> ...
> >>
> >> The last message might be due to the display manager starting up.
> >>
> >> Hope it helps.
> > Thank you for your testing. Jaak's problem seems related to the
> > initialization order, you can try to modify drivers/gpu/drm/Makefile,
> > move
> >
> > obj-y                  += tiny/
> >
> > to between these two lines
> >
> > obj-$(CONFIG_DRM_SCHED) += scheduler/
> > obj-$(CONFIG_DRM_RADEON)+= radeon/
> >
> > then build a new 6.5.x kernel to see whether your problem is resolved.
>
> Yes, this seems to have resolved it.
Adjusting Makefile is unacceptable from the maintainer's view, but I
really don't want the original patch to be reverted.

So, could you please test with the below patch (keep the original
order in Makefile) and then give me the dmesg output?

diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index 561be8feca96..cc2e39fb98f5 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -350,21 +350,29 @@ int
aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
char *na
        resource_size_t base, size;
        int bar, ret = 0;

-       if (pdev == vga_default_device())
+       printk("DEBUG: remove 1\n");
+
+       if (pdev == vga_default_device()) {
+               printk("DEBUG: primary = true\n");
                primary = true;
+       }

-       if (primary)
+       if (primary) {
+               printk("DEBUG: disable sysfb\n");
                sysfb_disable();
+       }

        for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
                if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
                        continue;

+               printk("DEBUG: remove 2\n");
                base = pci_resource_start(pdev, bar);
                size = pci_resource_len(pdev, bar);
                aperture_detach_devices(base, size);
        }

+       printk("DEBUG: remove 3\n");
        /*
         * If this is the primary adapter, there could be a VGA device
         * that consumes the VGA framebuffer I/O range. Remove this

[1]  https://lore.kernel.org/lkml/170222766284.86103.11020060769330721008@leemhuis.info/T/#u

Huacai

>
> Jaak
>
> >
> > Evan's problem seems a little strange, could you please give me your
> > config files of both 6.4.12 and 6.5.x? And you can also try the above
> > method to see if anything changes.
> >
> > Huacai
> >
> >>
> >> J
> >>
> >>>
> >>>>
> >>>> Evan
> >>>>
> >>>>>
> >>>>> Huacai
> >>>>>
> >>>>>>
> >>>>>> Evan
> >>>>>>
> >>>>>>>
> >>>>>>> Huacai
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Jaak
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Huacai
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Huacai
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Jaak
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Huacai
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Jaak
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But I write this mail for a different reason:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am having the same issue on a Lenovo Thinkpad P70 (Intel
> >>>>>>>>>>>>>>>> Corporation HD Graphics 530 (rev 06), Intel(R) Core(TM) i7-6700HQ).
> >>>>>>>>>>>>>>>> Upgrading from Linux 6.4.12 to 6.5 and later results in only a blank
> >>>>>>>>>>>>>>>> screen after boot and a rapidly flashing device-access-status
> >>>>>>>>>>>>>>>> indicator.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This additional report makes me wonder if we should revert the culprit
> >>>>>>>>>>>>>>> (60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> >>>>>>>>>>>>>>> device_initcall to subsys_initcall_sync") [v6.5-rc1]). But I guess that
> >>>>>>>>>>>>>>> might lead to regressions for some users? But the patch description says
> >>>>>>>>>>>>>>> that this is not a common configuration, so can we maybe get away with that?
> >>>>>>>>>>>>>>      From my point of view, this is not a regression, 60aebc9559492c
> >>>>>>>>>>>>>> doesn't cause a problem, but exposes a problem. So we need to fix the
> >>>>>>>>>>>>>> real problem (SIMPLEDRM has a blank screen on some conditions). This
> >>>>>>>>>>>>>> needs Jaak or Evan's help.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Everything you wanna know about Linux kernel regression tracking:
> >>>>>>>>>>>>>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>>>>>>>>>>>>> If I did something stupid, please tell me, as explained on that page.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> When SIMPLEDRM takes over the framebuffer, the screen is blank (don't
> >>>>>>>>>>>>>>>>>>>>> know why). And before 60aebc9559492cea6a9625f ("drivers/firmware: Move
> >>>>>>>>>>>>>>>>>>>>> sysfb_init() from device_initcall to subsys_initcall_sync") there is
> >>>>>>>>>>>>>>>>>>>>> no platform device created for SIMPLEDRM at early stage, so it seems
> >>>>>>>>>>>>>>>>>>>>> also "no problem".
> >>>>>>>>>>>>>>>>>>>> I don't understand above. You mean that after that commit the platform
> >>>>>>>>>>>>>>>>>>>> device is also none, right?
> >>>>>>>>>>>>>>>>>>> No. The SIMPLEDRM driver needs a platform device to work, and that
> >>>>>>>>>>>>>>>>>>> commit makes the platform device created earlier. So, before that
> >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM doesn't work, but the screen isn't blank; after that
> >>>>>>>>>>>>>>>>>>> commit, SIMPLEDRM works, but the screen is blank.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Huacai
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Confused...
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> An old man doll... just what I always wanted! - Clara
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>
>