Ctrl+Alt+F1 does not switch out of the X Windows desktop to the console

[davidplowman]

Describe the bug

Normally pressing Ctrl+Alt+F1 switches out of the X Windows desktop to fullscreen console, and Ctrl+Alt+F7 returns again.

I've been observing somewhat random behaviour, with the behaviour changing on reboot:

1. Sometimes it just doesn't work at all, and the screen looks unchanged (showing the X desktop) but with the cursor missing. Ctrl+Alt+F7 however returns the cursor and everything is OK again. When this happens there is a kernel crash in dmesg.

2. At other times it does switch to the console, and back again, but then Ctrl+Alt+F1 won't work again until the mouse has been wiggled. Though if you never touched the mouse at all then it continues to work. Nothing in dmesg in this case.

I'm finding this easiest to reproduce on a Pi 3, though I'm sure I've seen it on a Pi 4 as well. I believe this to be the offending commit. The previous commit seems repeatedly and reliably to work correctly, but when "rpi-updating" to this one the bad behaviour is observed.

There's a suggestion that this patch #4971 is related.

Steps to reproduce the behaviour

As above. I've flashed a brand new SD card, inserted it into my Pi 3, let it run through its updates and all is fine. I've installed nothing extra.

Then execute sudo rpi-update eaac3e5367944f2caf6eda88f81282633a3d7128, reboot and then the bug occurs. As explained, the behaviour tends to change rather randomly with each reboot.

Device (s)

Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B

System

pi@raspberrypi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2022-04-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 226b479f8d32919c9fe36dd5b4c20c02682f8180, stage4
pi@raspberrypi:~ $ vcgencmd version
Mar 24 2022 13:20:54 
Copyright (c) 2012 Broadcom
version e5a963efa66a1974127860b42e913d2374139ff5 (clean) (release) (start)
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.15.33-v7+ #1540 SMP Mon Apr 11 13:11:56 BST 2022 armv7l GNU/Linux
pi@raspberrypi:~ $ cat /boot/.firmware_revision 
eaac3e5367944f2caf6eda88f81282633a3d7128

Logs

No response

Additional context

No response

[davidplowman]

@popcornmix FYI

[popcornmix]

@mripard any thoughts.

I'm tempted to revert #4971
As well possibly causing this issue, it causes a performance regression when using opengl with
kms on Arch or fkms on RPiOS (#4988)

Ill try to reproduce this, and confirm a reversion does fix it.

[mripard]

Yeah, I agree that we should revert it.

I've reported both issues upstream and will try to look into it after the IGT fixes I'm working on

[popcornmix]

Reverting PR didn't fix it. I think it's from upstream bump to 5.15.33. Let me see if I can narrow it down further.

[popcornmix]

Reverting upstream "fbdev: Hot-unplug firmware fb devices on forced removal" (which also needs a revert of "fbdev: Fix unregistering of framebuffers without device") seems to fix this issue.

[popcornmix]

@davidplowman this should be fixed in rpi-update kernel.

[martinezjavier]

I've posted https://lists.freedesktop.org/archives/dri-devel/2022-May/353699.html which I believe should solve this issue as well.

[popcornmix]

@martinezjavier tested your patch (without the reverts) and it also fixes the issue.
When it's accepted upstream/reaches stable I'll replace reverts with your upstream fix.

[martinezjavier]

@popcornmix great, thanks for testing!

[martinezjavier]

@popcornmix could I ask you to test another patch series? The previous patch shared wasn't really correct and just papered over the issue. The latest attempt is: https://lists.freedesktop.org/archives/dri-devel/2022-May/354285.html

Only patch 2/2 should be enough for you if you are using simplefb, but there's also a fix for efifb and a patch to fbdev core to prevent the use-after-free even if the fbdev driver is buggy.

[martinezjavier]

I was able to reproduce the issue and confirm the fix on a rpi4 with:

$ cat < /dev/fb0 &
$ echo simple-framebuffer.0 > /sys/bus/platform/drivers/simple-framebuffer/unbind
$ kill %1

[martinezjavier]

FYI the fixes landed in mainline and will be in v5.18-rc7.

[popcornmix]

@martinezjavier thanks - I'll drop reverts on next update.