Created attachment 299209 [details] working config-5.14.10 Kernel 5.14.10 works great here: simple-framebuffer simple-framebuffer.0: framebuffer at 0xe1000000, 0x300000 bytes simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=1024x768x32, linelength=4096 simple-framebuffer simple-framebuffer.0: fb0: simplefb registered! However I cannot enable simplefb with any later kernels, i.e. 5.14.11 or 5.14.12 probably due to this change: --- a/linux-5.14.10/drivers/video/fbdev/Kconfig +++ b/linux-5.14.12/drivers/video/fbdev/Kconfig @@ -2191,8 +2191,9 @@ config FB_HYPERV This framebuffer driver supports Microsoft Hyper-V Synthetic Video. config FB_SIMPLE - bool "Simple framebuffer support" - depends on (FB = y) && !DRM_SIMPLEDRM + tristate "Simple framebuffer support" + depends on FB + depends on !DRM_SIMPLEDRM select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT Whenever I boot 5.14.11/5.14.12 the screen is completely black. Here's the difference between 5.14.10 and 5.14.12 configs: diff --git a/.config.old b/.config index 8ee12f9..79aba4d 100644 --- a/.config.old +++ b/.config @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/x86 5.14.10 Kernel Configuration +# Linux/x86 5.14.12 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)" CONFIG_CC_IS_GCC=y @@ -2924,7 +2924,7 @@ CONFIG_FB_EFI=y # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set -CONFIG_FB_SIMPLE=y +CONFIG_FB_SIMPLE=m # CONFIG_FB_SM712 is not set # end of Frame buffer Devices My 5.14.10 config has this: grep -i simple .config.old CONFIG_DRM_SIMPLEDRM=m CONFIG_FB_SIMPLE=y which works. Please advise.
If I enable it as a built-in kernel a ton of things change: diff --git a/.config.old b/.config index 79aba4d..fd0b9a4 100644 --- a/.config.old +++ b/.config @@ -2187,7 +2187,7 @@ CONFIG_I2C_MUX=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=y -CONFIG_I2C_ALGOBIT=m +CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support @@ -2800,10 +2800,11 @@ CONFIG_MEDIA_HIDE_ANCILLARY_SUBDRV=y CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=4 # CONFIG_VGA_SWITCHEROO is not set -CONFIG_DRM=m +CONFIG_DRM=y # CONFIG_DRM_DP_AUX_CHARDEV is not set +# CONFIG_DRM_DEBUG_MM is not set # CONFIG_DRM_DEBUG_SELFTEST is not set -CONFIG_DRM_KMS_HELPER=m +CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=300 # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set @@ -2856,7 +2857,7 @@ CONFIG_DRM_PANEL_BRIDGE=y # CONFIG_DRM_ETNAVIV is not set # CONFIG_DRM_CIRRUS_QEMU is not set # CONFIG_DRM_GM12U320 is not set -CONFIG_DRM_SIMPLEDRM=m +CONFIG_DRM_SIMPLEDRM=y # CONFIG_DRM_VBOXVIDEO is not set # CONFIG_DRM_GUD is not set # CONFIG_DRM_LEGACY is not set @@ -2873,11 +2874,11 @@ CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y -CONFIG_FB_SYS_FILLRECT=m -CONFIG_FB_SYS_COPYAREA=m -CONFIG_FB_SYS_IMAGEBLIT=m +CONFIG_FB_SYS_FILLRECT=y +CONFIG_FB_SYS_COPYAREA=y +CONFIG_FB_SYS_IMAGEBLIT=y # CONFIG_FB_FOREIGN_ENDIAN is not set -CONFIG_FB_SYS_FOPS=m +CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set @@ -2924,7 +2925,6 @@ CONFIG_FB_EFI=y # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set -CONFIG_FB_SIMPLE=m # CONFIG_FB_SM712 is not set # end of Frame buffer Devices And the compressed kernel gets bigger by around 200KB.
vmlinuz-5.14.10 4183968 bytes vmlinuz-5.14.12 4386688 bytes
I've reverted the patch that changes drivers/video/fbdev/Kconfig dependencies and now everything works as expected. With the patch: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22) fbcon: Taking over console Without the patch: simple-framebuffer simple-framebuffer.0: framebuffer at 0xe1000000, 0x300000 bytes simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=1024x768x32, linelength=4096 fbcon: Deferring console take-over simple-framebuffer simple-framebuffer.0: fb0: simplefb registered! The patch was introduced in Linux 5.14.12 actually, so 5.14.11 works. Please revert ec7cc3f74b4236860ce612656aa5be7936d1c594
(In reply to Artem S. Tashkinov from comment #0) > > My 5.14.10 config has this: > > grep -i simple .config.old > CONFIG_DRM_SIMPLEDRM=m > CONFIG_FB_SIMPLE=y > > which works. From what I can tell, this seems to be mostly a configuration error, as this configuration is not useful: if FB_SIMPLE is built-in, then loading DRM_SIMPLEDRM as a module will never bind to any devices. With my patch, the broken configuration is no longer possible, and you have to choose between one of the two drivers being built-in, or both as loadable modules, using a local configuration to decide which one to load on a given machine. If you just turn off CONFIG_DRM_SIMPLEDRM, you should get back to the previous behavior. That said, I see two additional bugs that have made your life harder: - Kconfig should probably not have allowed the FB_SIMPLE=y DRM_SIMPLEDRM=m configuration for a 'bool' driver before my patch either, I don't think that is intentional behavior. (In reply to Artem S. Tashkinov from comment #3) > With the patch: > simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to > setup generic emulation (ret=-22) - As far as I can tell, simpledrm is meant to be a drop-in replacement for fb-simple, so failing with -EINVAL here means something went unexpectedly wrong. The message comes from drm_fbdev_client_hotplug(), but I don't see where this gets an -EINVAL from, possibly this could be from do_register_con_driver().
(In reply to Arnd Bergmann from comment #4) > (In reply to Artem S. Tashkinov from comment #0) > > > > My 5.14.10 config has this: > > > > grep -i simple .config.old > > CONFIG_DRM_SIMPLEDRM=m > > CONFIG_FB_SIMPLE=y > > > > which works. > > > From what I can tell, this seems to be mostly a configuration > error, as this configuration is not useful: if FB_SIMPLE > is built-in, then loading DRM_SIMPLEDRM as a module will never > bind to any devices. > > With my patch, the broken configuration is no longer possible, > and you have to choose between one of the two drivers being > built-in, or both as loadable modules, using a local > configuration to decide which one to load on a given machine. > If you just turn off CONFIG_DRM_SIMPLEDRM, you should get back > to the previous behavior. > > That said, I see two additional bugs that have made your life harder: > > - Kconfig should probably not have allowed the FB_SIMPLE=y > DRM_SIMPLEDRM=m configuration for a 'bool' driver before > my patch either, I don't think that is intentional behavior. > > (In reply to Artem S. Tashkinov from comment #3) > > With the patch: > > simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to > > setup generic emulation (ret=-22) > > - As far as I can tell, simpledrm is meant to be a drop-in replacement > for fb-simple, so failing with -EINVAL here means something went > unexpectedly wrong. The message comes from drm_fbdev_client_hotplug(), > but I don't see where this gets an -EINVAL from, possibly this could > be from do_register_con_driver(). I've made this change to the config file: @@ -2808,7 +2808,6 @@ CONFIG_DRM_FBDEV_OVERALLOC=300 # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set # CONFIG_DRM_DP_CEC is not set -CONFIG_DRM_GEM_SHMEM_HELPER=y # # I2C encoder or helper chips @@ -2856,7 +2855,7 @@ # CONFIG_DRM_ETNAVIV is not set # CONFIG_DRM_CIRRUS_QEMU is not set # CONFIG_DRM_GM12U320 is not set -CONFIG_DRM_SIMPLEDRM=m +# CONFIG_DRM_SIMPLEDRM is not set # CONFIG_DRM_VBOXVIDEO is not set # CONFIG_DRM_GUD is not set # CONFIG_DRM_LEGACY is not set Now the system boots into the black screen.
What else can I do? Of course I can continue to revert the patch but that doesn't sound right.
Is there anything else I can do to resolve the issue?
Hey there. First off, thank you for all the work you do on the kernel. Like OP, the change of CONFIG_FB_SIMPLE from y to m unexpectedly broke LUKS / encryption unlocking on the systems of a multitude of Solus users during our update from 5.14.10 to 5.14.12, as you can see from [1], reports from [2] and [3]. In order to resolve the issue and enable these users to once again access their LUKS-based installs (those impacted appeared to be using NVIDIA-based hardware with nvidia-glx-driver 470.3.01), I needed to revert commit ec7cc3f74b4236860ce612656aa5be7936d1c594 and manually set CONFIG_FB_SIMPLE back to y from m [4]. This seemed to correctly force FB_SIMPLE, though whether or not this is abusing an issue with Kconfig or some other issue in the build system is another story. Throughout this, CONFIG_DRM_SIMPLEDRM has been set to m. What would be your recommendation moving forward that best ensures users across the widest breadth of hardware are able to continue using their encrypted-based systems? [1] https://dev.getsol.us/R3571:031a869e1f5154aa44ec5a7febb82dffe721ffcb [2] https://dev.getsol.us/T9962 [3] https://discuss.getsol.us/d/7529-cant-boot-after-latest-update/ [4] https://dev.getsol.us/R3571:a23d119ef77c863881852c8e80db509d46f83132
I think the important bit to work out is why it stops working with CONFIG_DRM_SIMPLEDRM=n/CONFIG_FB_SIMPLE=y, as this is the configuration that should be used here. Maybe in the test that Artem did, some other options got flipped as a side-effect? Joshua, could you test that configuration as well? The other thing that needs to be debugged is why CONFIG_DRM_SIMPLEDRM=y doesn't work as a replacement for CONFIG_FB_SIMPLE, but I suppose this may simply be designed to handle all hardware (yet). I have not looked at this myself.
After completely disabling CONFIG_DRM_SIMPLEDRM (# CONFIG_DRM_SIMPLEDRM is not set) now everything works. I'm not sure what it entails, I presume it's a sort of basic DRM driver for the hardware that has no native Linux drivers, so probably I won't be able to start Xorg without e.g. NVIDIA drivers but I've never used Xorg this way anyways.
(In reply to Artem S. Tashkinov from comment #10) > After completely disabling CONFIG_DRM_SIMPLEDRM (# CONFIG_DRM_SIMPLEDRM is > not set) now everything works. Ok, great! I think this is what you should be using in the future then. > I'm not sure what it entails, I presume it's a sort of basic DRM driver for > the hardware that has no native Linux drivers, so probably I won't be able > to start Xorg without e.g. NVIDIA drivers but I've never used Xorg this way > anyways. As far as I understand, DRM_SIMPLEDRM is meant as a drop-in replacement for FB_SIMPLE, and you should get roughly the same feature set with either one. If DRM_SIMPLEDRM=y works for you, then it's best to use that, otherwise consider reporting a bug to the simpledrm maintainers.
adding about this with this change DRM_SIMPLEDRM=y config see this topic for more https://forum.manjaro.org/t/testing-update-2021-11-13-kernel-gnome-41-1-xorg-server-21-1-lxqt-1-0-nvidia-470-86-plasma-5-23-3/90183/2 [code] nov. 13 14:41:47 mjro systemd[1]: Finished File System Check on /dev/disk/by-uuid/05923b1e-dbe7-4d73-9440-2c067e027f1a. nov. 13 14:41:47 mjro audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2duuid-05923b1e\x2ddbe7\x2d4d73\x2d9440\x2d2c067e027f1a comm="sy> nov. 13 14:41:47 mjro systemd[1]: Mounting /home... nov. 13 14:41:47 mjro systemd-udevd[416]: Using default interface naming scheme 'v249'. nov. 13 14:41:47 mjro kernel: BUG: unable to handle page fault for address: ffffaaa643b52000 nov. 13 14:41:47 mjro kernel: #PF: supervisor read access in kernel mode nov. 13 14:41:47 mjro kernel: #PF: error_code(0x0000) - not-present page nov. 13 14:41:47 mjro kernel: PGD 100000067 P4D 100000067 PUD 1001c0067 PMD 10f981067 PTE 0 nov. 13 14:41:47 mjro kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI nov. 13 14:41:47 mjro kernel: CPU: 8 PID: 233 Comm: kworker/8:2 Tainted: G OE 5.15.2-1-MANJARO #1 d68d158d4f98b4d55496e4b8ec4ea7ac9e330397 nov. 13 14:41:47 mjro kernel: Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570 AORUS PRO, BIOS F30 09/15/2020 nov. 13 14:41:47 mjro kernel: Workqueue: events drm_fb_helper_damage_work nov. 13 14:41:47 mjro kernel: RIP: 0010:memcpy_toio+0x23/0x50 nov. 13 14:41:47 mjro kernel: Code: c6 66 0f 1f 44 00 00 0f 1f 44 00 00 48 85 d2 74 28 40 f6 c7 01 75 33 48 83 fa 01 76 06 40 f6 c7 02 75 1f 48 89 d1 48 c1 e9 02 <f3> a5 f6 c2 02 74 02 66 a> nov. 13 14:41:47 mjro kernel: RSP: 0018:ffffaaa6409f7c70 EFLAGS: 00010212 nov. 13 14:41:47 mjro kernel: RAX: 0000000000002000 RBX: ffffaaa641868000 RCX: 0000000000000180 nov. 13 14:41:47 mjro kernel: RDX: 0000000000001e00 RSI: ffffaaa643b52000 RDI: ffffaaa641869800 nov. 13 14:41:47 mjro kernel: RBP: ffffaaa643b50800 R08: 0000000000060000 R09: 0000000034325258 nov. 13 14:41:47 mjro kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000001e00 nov. 13 14:41:47 mjro kernel: R13: ffff905cc0e42200 R14: 0000000000000405 R15: 0000000000000408 nov. 13 14:41:47 mjro kernel: FS: 0000000000000000(0000) GS:ffff905feec00000(0000) knlGS:0000000000000000 nov. 13 14:41:47 mjro kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 nov. 13 14:41:47 mjro kernel: CR2: ffffaaa643b52000 CR3: 0000000104708000 CR4: 0000000000350ee0 nov. 13 14:41:47 mjro kernel: Call Trace: nov. 13 14:41:47 mjro kernel: drm_fb_memcpy_dstclip+0x6f/0xa0 nov. 13 14:41:47 mjro kernel: drm_fb_blit_rect_dstclip+0xd0/0xf0 nov. 13 14:41:47 mjro kernel: simpledrm_simple_display_pipe_update+0xc5/0xe0 nov. 13 14:41:47 mjro kernel: drm_atomic_helper_commit_planes+0xc2/0x260 nov. 13 14:41:47 mjro kernel: drm_atomic_helper_commit_tail+0x42/0x80 nov. 13 14:41:47 mjro kernel: commit_tail+0xd8/0x130 nov. 13 14:41:47 mjro kernel: drm_atomic_helper_commit+0x11f/0x150 nov. 13 14:41:47 mjro kernel: drm_atomic_helper_dirtyfb+0x193/0x280 nov. 13 14:41:47 mjro kernel: drm_fb_helper_damage_work+0x1cf/0x310 nov. 13 14:41:47 mjro kernel: process_one_work+0x1e8/0x3c0 nov. 13 14:41:47 mjro kernel: worker_thread+0x50/0x3c0 nov. 13 14:41:47 mjro kernel: ? process_one_work+0x3c0/0x3c0 nov. 13 14:41:47 mjro kernel: kthread+0x132/0x160 nov. 13 14:41:47 mjro kernel: ? set_kthread_struct+0x50/0x50 nov. 13 14:41:47 mjro kernel: ret_from_fork+0x22/0x30 nov. 13 14:41:47 mjro kernel: Modules linked in: snd_intel_dspcfg(+) kvm(+) snd_intel_sdw_acpi vfat fat pcc_cpufreq(-) snd_hda_codec fjes(-) irqbypass snd_hda_core crct10dif_pclmul ghash_cl> nov. 13 14:41:47 mjro kernel: CR2: ffffaaa643b52000 nov. 13 14:41:47 mjro kernel: ---[ end trace 98f4b05f481c5976 ]--- nov. 13 14:41:47 mjro kernel: RIP: 0010:memcpy_toio+0x23/0x50 nov. 13 14:41:47 mjro kernel: Code: c6 66 0f 1f 44 00 00 0f 1f 44 00 00 48 85 d2 74 28 40 f6 c7 01 75 33 48 83 fa 01 76 06 40 f6 c7 02 75 1f 48 89 d1 48 c1 e9 02 <f3> a5 f6 c2 02 74 02 66 a> nov. 13 14:41:47 mjro kernel: RSP: 0018:ffffaaa6409f7c70 EFLAGS: 00010212 nov. 13 14:41:47 mjro kernel: RAX: 0000000000002000 RBX: ffffaaa641868000 RCX: 0000000000000180 nov. 13 14:41:47 mjro kernel: RDX: 0000000000001e00 RSI: ffffaaa643b52000 RDI: ffffaaa641869800 nov. 13 14:41:47 mjro kernel: RBP: ffffaaa643b50800 R08: 0000000000060000 R09: 0000000034325258 nov. 13 14:41:47 mjro kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000001e00 nov. 13 14:41:47 mjro kernel: R13: ffff905cc0e42200 R14: 0000000000000405 R15: 0000000000000408 nov. 13 14:41:47 mjro kernel: FS: 0000000000000000(0000) GS:ffff905feec00000(0000) knlGS:0000000000000000 nov. 13 14:41:47 mjro kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 nov. 13 14:41:47 mjro kernel: CR2: ffffaaa643b52000 CR3: 0000000104708000 CR4: 0000000000350ee0 [/code]
I'm sad later 5.14.x releases and 5.15 make the bzImage 200KB larger for seemingly no reasons (5.14.0 worked just fine) but I guess it's the way things need to be.