On Fri, 6 Nov 2026 at 10:16, Dave Hansen <[email protected]> wrote: > > On 10/15/26 09:10, Rodrigo Vivi wrote: > >> BTW, "xe.force_probe=!*" on the command-line also gets the output back > >> to normal. > > the force probe proves that we can still probe safely, but apparently > > on my first attempt I missed the fact that pcim_enable_device will > > touch the device and register a pci_disable_device that might > > clear stuff and mess with the VGA fb... > > > > Perhaps if we move just one step over: > > > > https://github.com/rodrigovivi/linux/ > > commit/616cd8c1b4d4414cd1f7ad56fa5d8abd36d7968d > > So I gave this exact commit a go. It still seems to have the same basic > problems. I put the missing "ptl_guc_70.bin" file in place, but it just > moved over to needing the "huc" and went back to the no console > behavior. I added the "huc" and the "gsc", which seems to make the > driver happier, but the screen has garbage. Looks like I may be missing > one of those MEI drivers. > > But, still, the driver seems to be rather aggressive about killing the > console even before it is working itself: > > > [ 0.672748] xe 0000:00:02.0: vgaarb: deactivate vga console > > [ 0.673227] xe 0000:00:02.0: [drm] Running in SR-IOV PF mode > > [ 0.676750] xe 0000:00:02.0: [drm] Tile0: GT0: Using GuC firmware from > > xe/ptl_guc_70.bin version 70.72.1 > > [ 0.914206] xe 0000:00:02.0: [drm] Tile0: GT0: ccs1 fused off > > [ 0.914213] xe 0000:00:02.0: [drm] Tile0: GT0: ccs2 fused off > > [ 0.914214] xe 0000:00:02.0: [drm] Tile0: GT0: ccs3 fused off > > [ 0.935645] xe 0000:00:02.0: [drm] Tile0: GT1: Using GuC firmware from > > xe/ptl_guc_70.bin version 70.72.1 > > [ 0.937939] xe 0000:00:02.0: [drm] Tile0: GT1: Using HuC firmware from > > xe/ptl_huc.bin version 10.3.3 > > [ 0.938382] xe 0000:00:02.0: [drm] Tile0: GT1: Using GSC firmware from > > xe/ptl_gsc_1.bin version 105.0.2.1397 > > [ 0.938855] xe 0000:00:02.0: [drm] Tile0: GT1: can't init GSC proxy due > > to missing mei component > > [ 0.959120] xe 0000:00:02.0: [drm] Tile0: GT1: vcs1 fused off > > [ 0.959139] xe 0000:00:02.0: [drm] Tile0: GT1: vcs2 fused off > > [ 0.959150] xe 0000:00:02.0: [drm] Tile0: GT1: vcs3 fused off > > [ 0.959159] xe 0000:00:02.0: [drm] Tile0: GT1: vcs4 fused off > > [ 0.959168] xe 0000:00:02.0: [drm] Tile0: GT1: vcs5 fused off > > [ 0.959177] xe 0000:00:02.0: [drm] Tile0: GT1: vcs6 fused off > > [ 0.959186] xe 0000:00:02.0: [drm] Tile0: GT1: vcs7 fused off > > [ 0.959195] xe 0000:00:02.0: [drm] Tile0: GT1: vecs1 fused off > > [ 0.959205] xe 0000:00:02.0: [drm] Tile0: GT1: vecs2 fused off > > [ 0.959214] xe 0000:00:02.0: [drm] Tile0: GT1: vecs3 fused off > > [ 1.024100] [drm] Initialized xe 1.1.0 for 0000:00:02.0 on minor 0 > > BTW, I am building the "xe" driver in. It's causing all kinds of fun > problems, like needing to manually add xe firmware to my initrd. > > Maybe the: > > config DRM_XE_DISPLAY > bool "Enable display support" > depends on DRM_XE && DRM_XE=m && HAS_IOPORT > > DRM_XE=m dependency is biting me. Is it stealing the console before it > knows it can actually display something?
It's chicken and egg, you can't init the GPU properly until you steal the console, you can't unsteal the console once you fail to init the GPU properly. Restoring text or efifb is quite difficult depending on how far into init you get before you have to. You unfortunately don't have a kick off efifb now option. Though we could probably do better, it's hard to validate. Dave.
