https://bugzilla.kernel.org/show_bug.cgi?id=217394
--- Comment #7 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
At least in your situation you can see that very clearly the interrupt source
override in the MADT is correct:
[ 0.003333] ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 1 low edge)
But your ACPI tables are incorrect (and hence the patch to the DSDT helps the
issue).
To me it seems this issue really boils down to the logic in the kernel of what
to trust when, and there doesn't seem to be a great answer.
Today it's something like this:
1) If it's extended IRQ syntax, trust the DSDT.
2) If it's legacy syntax (IRQ/IRQNoflags) mayyyybe double check what the MADT
and the DSDT have agree. This is needed for a number of older buggy machines.
"2" ended up causing problems for a number of Ryzen 6000 machines because they
didn't have an interrupt source override in place and without this the value
found in the MADT was wrong (Active high) but the value in the DSDT was right
(Active Low).
This is why we put in place a case to ignore all that and trust the DSDT on
Ryzen systems.
You're the exact opposite of this and so that's why this logic fell apart.
I think what we're missing is an indication of whether an interrupt source
override is actually being used or not. So it could work like this:
1) Extended IRQ syntax
-> Trust DSDT
2) Legacy Syntax
Does polarity and trigger match the IOAPIC configuration?
A) Yes
-> Done
B) No:
a) Interrupt Source Override
-> Trust ISR
b) DMI override?
-> Trust DMI override
c) Zen system?
-> Trust DSDT
d) Not Zen system
-> Trust IOAPIC configuration
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
