Kernel 5.12: Gazelle (gaze15) boot slowed by "failed to write source OUI"

[thomas-zimmerman]

Customer (support case 62613) is running a 5.12 based kernel and getting a slower than normal boot caused by:

"<timestamp in seconds and millionths> failed to write OUI"

Messages that scroll on the screen for a couple seconds. Looks like the source is this patch that landed in 5.12: https://patchwork.kernel.org/project/intel-gfx/patch/[email protected]/ (customer found and reported the patch!)

[eliminmax]

I know this is old, but I can confirm that it's affecting my Gazelle (gaze15) as well, ~and has been since I got it in April '21.~ I am currently on Pop!_OS 21.10 with kernel 5.16.19-76051619-generic. Not a big deal, just a minor annoyance for me, but I figured I'd add this to the issue thread.

Edit: thinking about it, I'm not sure that this was an issue at first - I can't remember exactly when it started - it might have been after switching to the open firmware, or after switching from 20.04 to 21.04, or from 21.04 to 21.10. Sorry for any confusion I may have caused

[crawfxrd]

Firmware: 2022-05-16_3a5b422 Kernel: 5.17.5-76051705-generic

[    2.876451] fbcon: i915drmfb (fb0) is primary device
[    4.365377] i915 0000:00:02.0: [drm] *ERROR* Failed to write source OUI
[    4.553118] Console: switching to colour frame buffer device 240x67

Causes a 1.5s delay in kernel boot time.

[Vuwij]

Im getting a similar issue, but it only occurs when I close the lid and re-open it, it hangs here

[thefirethirteen]

Im getting a similar issue, but it only occurs when I close the lid and re-open it, it hangs here

Exact same message here, also when waking from suspend (or closing and re-opening the lid). Has anyone found any workaround beside a force shutdown or Alt+SysRq + REISUB (for a safer shutdown I believe)?

[topoipat]

I have the same issue, no idea how to fix...it causes me to lose unsaved work when I do a force restart

[jacobgkau]

This issue is about the log message showing up at boot and it slowing down the boot.

When you resume from suspend, the logs you're seeing are just the boot logs still in the buffer (the 5.498308 at the front means that log line occurred 5 seconds after the OS started booting). They're not likely to be relevant to the reason the system failed to resume.

Anyone getting failures to resume should reach out to support for troubleshooting, since that can be caused by hardware issues.