Len Brown <lenb@xxxxxxxxxx> writes: >> It appears there are a few systems in the wild that use acpi >> interrupt source overrides to report a gsi > 16 is an isa irq. >> >> This breaks all kinds of assumptions I figure any BIOS doing that >> probably should be shot as that is very much not a conservative position. > > You might run into trouble here on the ES7000 -- though I don't know > if anybody is booting a modern kernel on one of those these days. > > IIR, ES7000 treated the bottom 16 as a special case. > When there was an irq shortage, I think they used overrides > to map higher PCI irqs into the empty spots below 16, > but I think to make room for them they may have mapped > some of the ISA irqs to high numbers. Fuzzy memory > on this at the moment... A couple of things. The ES7000 change is trivially safe because despite differences in how the numbers are computed I have made that transform that the es7000 does always apply. I also talked to Natalie about this. I can't be certain about this but from your description, from Natalies memories and from looking at the code. I believe the problem on the ES7000 is exactly what I am fixing in the code. Natalie has threatened to test this on an ES7000. The case of interest is this: Weird but valid platforms where GSI 0-15 are not ISA irqs. Some high numbered GSIs are ISA irqs and use interrupt source overrides to describe them. That is the case on the IBM platform that regressed a bit ago and Iranna D Ankad bisected a failure on. On that IBM platform GSI 0-15 (because the are not ISA irqs) are unusable today. Everything points to this problem I an fixing being the problem with early ES7000 machines, including the memory of their boot firmware developers complaint that they were in spec. Eric -- 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
