Pixelbook Go (ATLAS) 4K – i915 "CPU pipe A FIFO underrun", internal display unusable unless nomodeset

Pixelbook Go (ATLAS) 4K – i915 “CPU pipe A FIFO underrun”

I’m trying to get omarchy loaded onto my 2019 Google Pixelbook Go. When omarchy display didn’t work, I tried switching to arch - same issue.

Problem
Firmware/bootloader output is fine, but as soon as i915 loads the internal display
flashes several times and then shows a few faint horizontal lines (or stays black).
Booting with nomodeset works (simpledrm). Same behavior from the Omarchy ISO,
the Arch ISO, and the installed system.

System Details

  • Device: Google Pixelbook Go (ATLAS), i7-8500Y, 16GB, 4K panel
  • Firmware: Full ROM / UEFI – tested MrChromebox-2609.3 and 2606.1 (same result)
  • OS: Arch Linux, kernel 7.2.15-arch1-1 and linux-lts (same result)
  • Bootloader: Limine

Kernel log on every failed boot:
i915 0000:00:02.0: [drm] ERROR CPU pipe A FIFO underrun

From a drm.debug=0x1e log:

  • Firmware leaves eDP-1 at 1920x1080 with PCH pfit scaling to 3840x2160 (BIOS fb not reused)
  • i915 does a full modeset to native 3840x2160 @ 533300 kHz, 4 lanes @ 432000
    (1599900 / 1728000 link bandwidth)
  • FBC is enabled on plane 1A, then the FIFO underrun, then “Disabling FBC due to FIFO underrun”
  • SAGV is enabled after the plane update
  • No link-training errors

Kernel parameters tried (none but nomodeset helped):

  • nomodeset prevents the issue (but also prevents me from using omarchy/hyprland)
  • i915.enable_psr=0
  • i915.enable_psr=0 i915.enable_fbc=0 i915.enable_dc=0
  • …plus intel_idle.max_cstate=2, and intel_idle.max_cstate=1 alone
  • i915.fastboot=0 i915.enable_psr=0
  • video=eDP-1:1920x1080
  • video=eDP-1:1920x1080@60 i915.enable_fbc=0 i915.enable_psr=0 (black screen instead of
    flashing, but the underrun is still logged)

Full debug log (i915/drm lines): https://termbin.com/0i7me

Is this a known issue with the 4K ATLAS panel, and is there a firmware-side or
kernel-side fix or workaround? Happy to test builds or provide more logs.

if I had to guess, it’s an issue with the coreboot display init (libgfxinit) leaving the display in a state that the kernel driver doesn’t like. Flash the attached test build. grab a cbmem log after a clean boot. boot with kernel param drm.debug=0xe and run sudo dmesg | grep drm > drm.log

attach both logs here or post on pastebin (eg) and provide links

the test build is from top-of-tree, it’s possible the issue may be resolved already, but logs would be great regardless.

Did you mean to attach a test build? Thanks for your help.

sure did, whoops

coreboot_edk2-atlas-mrchromebox_20261112.zip (3.9 MB)