The -gcp bisect is still ongoing, but we've met with some of the Google folks regarding the second part of the issue. The second part of the issue has been picked up by them, as the FBIOPUT_VSCREENINFO ioctl seems to have regressed in modern xserver-xorg-core packages, but we're still awaiting feedback on next steps/timelines as it's upstream of us.
Both of these will need to be resolved for the virt disp to fully work. If Google does outpace this LP's work and we're able to backport the changes, the scope of this LP could be worked around by using -generic in the interim. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gcp in Ubuntu. https://bugs.launchpad.net/bugs/2036273 Title: 5.15+ GCE Instances are unable to create fb0 with virt mon attached Status in linux-gcp package in Ubuntu: New Bug description: This is a public facing LP issue to address the content in Canonical's SF#00366439. Summary: Post 18.04 ( or 20.04 prior to moving to 5.15 ), efifb fails to stand up fb0. It is assigned, but fb0 is never created, nor are there any errors that I noted. Here is an example from a focal using linux-gcp --- 5.15.0-1041-gcp #49~20.04.1-Ubuntu SMP kyler_hornor@kyler-focal:~$ sudo dmesg | grep efifb [ 0.925827] pci 0000:00:05.0: BAR 0: assigned to efifb --- If you then install the generic HWE kernel and reboot, you can see that fb0 is successfully summoned: --- 5.15.0-83-generic #92~20.04.1-Ubuntu SMP kyler_hornor@kyler-focal:~$ sudo dmesg | grep efifb [ 2.128815] pci 0000:00:05.0: BAR 0: assigned to efifb [ 3.021819] efifb: probing for efifb [ 3.022511] efifb: framebuffer at 0xc0000000, using 6076k, total 6075k [ 3.023925] efifb: mode is 1920x1080x24, linelength=5760, pages=1 [ 3.025382] efifb: scrolling: redraw [ 3.026347] efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0 --- and finally, using linux-gcp-lts on 20.04, it does work (as it's 5.4): --- 5.4.0-1112-gcp #121-Ubuntu SMP kyler_hornor@kyler-focal:~$ sudo dmesg | grep efifb [ 0.834541] pci 0000:00:05.0: BAR 0: assigned to efifb [ 1.057258] efifb: probing for efifb [ 1.058182] efifb: framebuffer at 0xc0000000, using 6076k, total 6075k [ 1.059210] efifb: mode is 1920x1080x24, linelength=5760, pages=1 [ 1.060203] efifb: scrolling: redraw [ 1.060722] efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0 --- So some linux-gcp backport or config seems to be breaking this. Supplementary to this, the framebuffer can not be leveraged by X and throws a fatal error around the time shadow is loaded. This part is replicable on -generic, as well as on debian using gdm3/X, so this is likely an upstream problem. I tried disabling shadow with an X conf, but as it uses 24bppp, it forces it. For the scope of this LP, we need to figure out the -gcp specific breakage. I've reached out to google to see if we can get some contacts on the virt mon team to push the other aspect forward. Replication: Launch any ubuntu 20.04+ GCE instance with the "Display Device" option enabled. Expected Behavior: We should see the above output in dmesg and also observe /dev/fb0 being created. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/2036273/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
