Bug 214723

Summary: Cannot enable simplefb due to "fbdev: simplefb: fix Kconfig dependencies"
Product: Drivers Reporter: Artem S. Tashkinov (aros)
Component: Video(Other)Assignee: drivers_video-other
Status: RESOLVED CODE_FIX    
Severity: blocking CC: arnd, daniel, joshua, mike, stephane.coin
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 5.14.12, 5.15-rc5 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: working config-5.14.10

Description Artem S. Tashkinov 2021-10-14 20:28:28 UTC
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.
Comment 1 Artem S. Tashkinov 2021-10-14 20:38:20 UTC
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.
Comment 2 Artem S. Tashkinov 2021-10-14 20:41:46 UTC
vmlinuz-5.14.10 4183968 bytes
vmlinuz-5.14.12 4386688 bytes
Comment 3 Artem S. Tashkinov 2021-10-14 21:24:16 UTC
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
Comment 4 Arnd Bergmann 2021-10-15 08:28:50 UTC
(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().
Comment 5 Artem S. Tashkinov 2021-10-16 08:57:30 UTC
(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.
Comment 6 Artem S. Tashkinov 2021-10-18 14:36:05 UTC
What else can I do?

Of course I can continue to revert the patch but that doesn't sound right.
Comment 7 Artem S. Tashkinov 2021-10-20 17:20:04 UTC
Is there anything else I can do to resolve the issue?
Comment 8 Joshua Strobl 2021-10-21 15:38:59 UTC
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
Comment 9 Arnd Bergmann 2021-10-22 09:54:16 UTC
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.
Comment 10 Artem S. Tashkinov 2021-10-22 11:56:34 UTC
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.
Comment 11 Arnd Bergmann 2021-10-22 12:43:45 UTC
(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.
Comment 12 stephane.coin@free.fr 2021-11-13 17:33:05 UTC
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]
Comment 13 Artem S. Tashkinov 2021-12-30 20:15:58 UTC
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.