On Sat, 21 Jun 2008, Matthew Garrett wrote: > > Meanwhile we may consider implementing a workaround. I think one that > > does not hurt competent vendors would be preferable. The DSDT containing > > the rubbish described here is marked with an OEM ID: "HP " and OEM > > Table ID: "SB400". These keys could be used to remove IRQ0 information > > from the IRQ tables. Our code is prepared to handle such a case. > > Something easy to do for a seasoned ACPI fiddler, I suppose. ;) > > Something roughly like the following? Entirely untested, my 6125 is in a Maybe, though your code seems to match product IDs rather than the broken DSDT itself. I think the latter would be preferable as it would cover all the pieces of equipment using the broken piece of firmware rather than ones we have already tracked down. Perhaps the version could be included too, but that would only make sense if the breakage ever gets fixed -- the use of the through-8259A mode for the 8254 timer would allow this piece of equipment to benefit from the I/O APIC driven NMI watchdog. > box somewhere. My recollection is that skip_timer_override will disable > the IRQ 0->2 mapping, which I believe is what's broken here? Not exactly. The IRQ0->2 mapping is certainly wrong here, but so is the identity IRQ0->0 one. Which means it should not be recorded in mp_config_acpi_legacy_irqs() at all. I can cook this part if you'd rather not to, if you do the ACPI part. If you think there is no easy way to match the DSDT rather than the product ID -- we are trying to cope with outright breakage here after all, so any amount of effort is too much ;) -- I can update your proposal with what I have in mind. One point to note -- perhaps it would be better to avoid these #ifdef clauses -- even though it's a workaround, I think the amount of resources consumed does not justify the clutter introduced. Thanks for your submission. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
