Yes that kernel option works.
Though this is probably not an ideal situation. I was wondering if anyone had tried to use the Linux Clear Kernel as it has not updated to 6.4.1
Seems as though a patch was submitted upstream.
https://lore.kernel.org/regressions/20230710133836.4367-2-mail@eworm.de/
Incidentally the fix appears to be to force polling when running on Framework board.
2 Likes
They are matching DMI_PRODUCT_VERSION to A6, whereas on my 12th-gen it’s A8 (per the output of dmidecode), so I fear this patch would be insufficient…
Anyone in the loop to notify the devs?
Edit: Ooh I don’t know anymore, in a previous mail of this kernel thread, they have a patch with A4 instead… and say it’s for 12th-gen… weird…
I guess I am missing pieces of information to understand.
The only certainty is that on my machine it’s neither A4 nor A6, it’s A8, for whatever reason…
Edit 2: I added a comment on the Bugzilla page.
Merged two threads dealing with the same issue together. This seems to affect all distros, not just Ubuntu.
1 Like
I guess it depends what each of understands by “not an ideal situation”, but FWIW the workaround flag is doing the exact same thing that the proposed patches are:
- Before kernel 6.4, the test for working TPM interrupts didn’t run correctly and the kernel would always fall back to polling mode and log
[Firmware Bug]: TPM interrupt not working, polling instead. - In 6.4 the test was fixed to run , but there seems to be a regression where it reports a false-positive and the Framework TPM gets into a bad state when using interrupts.
- Applying the command line option forces the TPM to disable interrupts and go back to polling mode.
- The proposed patches add Framework models to the list of devices with known broken TPM interrupts, so the kernel will automatically select polling mode.
It’s possible that at some point whatever causes the “interrupt storm” on these laptops will be fixed and interrupts can be restored. But for now there’s not really any downside to explicitly disabling TPM interrupts on the command line, versus rolling back to an older kernel that disables TPM interrupts in a different way, or waiting for the next kernel which will disable TPM interrupts in a third way.
2 Likes
Confirmed this fixed my boot hang at “ima: Allocated hash …” with TPM enabled in BIOS.
Thanks much.
1 Like
Confirmed here too.
Still the bug needs to be solved as this workaround would need some digging for newcomers.
Maybe we should link this discussion into the wiki of the various distributions starting with Arch (as is notoriously appreciated distros-wide.).
I can confirm I had this issue on the gentoo distibution kernel (gentoo-kernel-bin) 6.4.3, and adding the tpm_tis.interrupts=0 resolved the issue. I’ve also noted it in the Gentoo wiki here: Framework Laptop - Gentoo Wiki
2 Likes
This looks to be fixed in the latest Linux kernel release 6.4.4:
“tpm/tpm_tis: Disable interrupts for Framework Laptop Intel 13th gen
tpm/tpm_tis: Disable interrupts for Framework Laptop Intel 12th gen”
The kernel parameter “tpm_tis.interrupts=0” won’t be needed after upgrading to that kernel.
1 Like
After upgrading to kernel 6.4.4 from the Arch testing repositories, and removing the “tpm_tis.interrupts=0” kernel parameter, I can confirm that I didn’t experience this issue on the Framework Laptop Intel 12th gen i5-1240p model.
4 Likes
Appreciate all the helpful details. Can we get a summary of each distro and release affected? I want to see if this affects Arch only or other distros as well. Please reply with:
Kernel:
Distro:
Release (rolling releases like Arch just respond with Arch again):
Kernel: 6.4.0 - 6.4.3
Distro: Arch
Release: Arch
1 Like
Kernel: 6.4.4
Distro: arch
Release (rolling releases like Arch just respond with Arch again): arch
I can confirm kernel 6.4.4 fixes the issue
1 Like
Kernel: 6.4.2
Distro: Gentoo
I found success with this solution. Disabling the IMA kernel option and rebuilding solved the problem (.config diff).
1 Like
Kernel: 6.4.4-200.fc38.x86_64
Distro: Fedora
Release: 38 (KDE Plasma)
I can’t boot the above kernel without the tpm_tis.interrupts=0 argument even though it’s 6.4.4.
I have a Framework Laptop 13 12th gen i7-1260p on BIOS 3.0.4.
2 Likes
Kernel: 6.4.4.-200.fc38x86_64
Distro: Fedora
Release: 38 (Workstation)
Had to tadd the tpm_tls.interrupts=0 argument to get it to boot. This was not broken previously. This is with a 12th gen I7-1260p with BIOS 3.06.
2 Likes
The fixing patches for framework laptop got cherry picked for Arch 6.4.4.
The patches for Framework laptop are part of the official kernel 6.4.5:
- Patch for Framework 13th gen
- Patch for Framework 12th gen
- And there is also another fix in 6.4.5 which fixes the issue for any other device which is not explicitly blacklisted.
3 Likes
Confirming fedora 38 6.4.4 is broken and that adding tpm_tis.interrupts=0 to the kernel args via grubby fixed it
1 Like
My FWL 13 with the Intel Core i5-1240p just got the 6.4.4 update on Fedora (KDE spin) and won’t boot that kernel. I could temporarily disable TPM but my system dual-boots with Windows 11 which I use for college so I’d rather only do it as a last resort. Hopefully it gets fixed in a later kernel release. Thankfully GRUB makes it easy to boot into earlier kernels.