I915 [drm] *ERROR* Atomic update failure on pipe A

I noticed this i915 error last night and I applied a KMS fix I was given by someone on the Arch forum for an xorg error which was to add MODULES=(i915)
to /etc/mkinitcpio.conf
and run sudo mkinitcpio -P

From what I understand kernel mode setting is getting the kernel to load the graphic driver module in this case i915 early rather than having xorg load the module later. Anyway I thought it fixed the issue as the error didn’t show up when I ran sudo journalctl -b

This morning I saw the error again when I ran sudo journalctl -p err -e


Nov 04 06:55:48 Blackstone kernel: i801_smbus 0000:00:1f.4: Transaction timeout

Nov 04 06:55:48 Blackstone kernel: i801_smbus 0000:00:1f.4: Failed terminating the transaction

Nov 04 06:55:48 Blackstone kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!

Nov 04 06:56:09 Blackstone pulseaudio[1231]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.service not found.

Nov 04 06:56:25 Blackstone kernel: i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=73 end=74) time 154 us, min 2146, max 2159, scanline start 2145, end 2165

I found this fix

So I added i915.enable_psr=0 to my kernel parameters and ran sudo grub-mkconfig -o /boot/grub/grub.cfg

After editing the kernel parameters sudo journalctl -p err -e


Nov 04 07:38:42 Blackstone kernel: i801_smbus 0000:00:1f.4: Transaction timeout

Nov 04 07:38:42 Blackstone kernel: i801_smbus 0000:00:1f.4: Failed terminating the transaction

Nov 04 07:38:42 Blackstone kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!

Nov 04 07:38:51 Blackstone pulseaudio[1208]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.service not found.

sudo journalctl -b Is clean too.

It seems to be gone, but I thought it was fixed yesterday as the issue went away but then came back.

  1. Is it okay to leave KMS configured the way I’ve done it?

  2. If leaving KMS isn’t okay do I disable it by adding nomodeset to my kernel parameters or by editing /etc/default/grub and deleting MODULES=(i915) and
    running sudo mkinitcpio -P

  3. Is my understanding of KMS correct?`

  4. How do I know if it is fixed, do I just keep checking the logs over a period of time and assume it is fixed if I don’t see the error again for a while?

[SOLVED] I couldn’t edit my above post, I think because I had deleted it.

Anyway I think I found the fix which is in the original link I pasted.

what I did was:

add i915.enable_guc=2 to the kernel parameters

and edited /etc/mkinitcpio.conf with MODULES=(i915) then ran sudo mkinitcpio -P

3 Likes

The same error came back again so I went back to the same searches and the wiki and I noticed if the initramfs already includes i915 module then GuC/HuC have to be enabled differently.

wiki says:

For those processors it is necessary to add i915.enable_guc=2 to the kernel parameters to enable both GuC and HuC firmware loading. Alternatively, if the initramfs already includes the i915 module (see Kernel mode setting#Early KMS start), you can set these options through a file in /etc/modprobe.d/, e.g.:

/etc/modprobe.d/i915.conf

options i915 enable_guc=2

So I did that and ran sudo mkinitcpio -P rebooted and ran sudo -E cat /sys/kernel/debug/dri/0/i915_huc_load_status and also sudo -E cat /sys/kernel/debug/dri/0/i915_guc_load_status

both GuC and HuC are now running. I thought I had enabled them before, hopefully this does the trick.

1 Like