5.15+ GCE Instances are unable to create fb0 with virt mon attached

Bug #2036273 reported by Kyler Hornor
22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-gcp (Ubuntu)
New
Undecided
Unassigned

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.

Revision history for this message
Jawed Abbasi (jabbasi) wrote :

Hi Kyler

Will you be able to let me know your few availability slots so that I can schedule/coordinate a call?

Revision history for this message
Pete Moore (petemoore) wrote :

Hi guys
Is there an update here?
Many thanks!

Revision history for this message
Kyler Hornor (kylerhornor) wrote :

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.

Revision history for this message
Pete Moore (petemoore) wrote :

Many thanks Kyler.

Jawed, could you provide an update from Google's side? Thank you.

Revision history for this message
Jawed Abbasi (jabbasi) wrote :

Hi Pete

I provided an update on out internal case, hope that was helpful.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.