Comment 139 for bug 2034477

Revision history for this message
In , mario.limonciello (mario.limonciello-linux-kernel-bugs) wrote :

#54

1. I had a similar concern while adjusting v2. HOWEVER I think it's mitigated by the fact the DMI check ONLY runs in the failure path now. So even though it technically applies to all laptops from "82" family for Lenovo only ones with a problem will run it.

I would much rather we don't use a Zen heuristic because this has nothing to do with it being an AMD bug. It happens to be a BIOS bug on some Lenovo AMD systems.

I don't see this issue on Mendocino "reference hardware", nor on some other vendor's Mendocino hardware I've seen.

The only way we'll have a definitively correct list is if Mark (Lenovo) can provide it.

2. So you mean like the PIC malfunctions specifically on the quirked systems? Seems unlikely to me.

Another idea is that we can put the DMI check and writing to those registers somewhere else that runs "earlier" than probe_8259A() runs (earlier than device_initcall I guess). I'm not sure a good place for that though. Nothing in arch_initcall() stands out to me.

#56

OK thanks!

#59

I would say that this doesn't look fine. I see NVME IOMMU page faults on both suspend and resume, which means there is still "something" wrong. I *think* it's a different issue.

If it was just resume I would say it's similar to one that happened on a lot of other Lenovo systems which was another BIOS bug. By chance was your "time to resume" 10+ seconds?

Can you please try (separately) iommu=pt and amd_iommu=off?