SystemIO conflicts are not firmware bugs

SystemIO conflicts are not firmware bugs(codon.org.uk)

38 points by haeseong 9 days ago | 6 comments

eqvinox 7 days ago |

> the internet will tell you that PC firmware developers are incompetent³

> ³ I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion

If anything, isn't this evidence the vendor should've paid someone to write an ACPI driver for Linux? :-)

lmz 7 days ago | |

No. Unless the hardware had Linux stickers on it.

mitxela 7 days ago | |

Why should they? Would they sell more hardware if they did? And why Linux? Shouldn't they write an ACPI driver for Haiku first? Companies do what makes money, period. Activist companies have been almost completely wiped out by this stage of capitalism.

dataflow 7 days ago |

Two questions:

1. How does the kernel detect the conflict?

> you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime

2. How does the kernel prevent the firmware from running anything?

mitxela 7 days ago | |

ACPI firmware is not code that runs by itself. It is code that the kernel interprets. If the kernel doesn't interpret it, it won't run. SMM firmware runs by itself but also can't interact with ACPI locks anyway.

p_l 7 days ago | |

For (1) - ACPI is how the kernel knows what addresses maps where. And when a driver claims the same address space, it knows there's a conflict