From: Arndt S. <ab...@sr...> - 2002-05-07 17:05:12
|
Hi Paul, first of all, thank you very much for your ongoing efforts! On Tue, May 07, 2002 at 09:37:45AM -0700, Diefenbaugh, Paul S wrote: > Arndt, All: > > Ya, we're trying to get to the bottom of this whole PCI IRQ routing mess. > The issue is that we haven't found a single process that works well on all > systems. Things are getting pretty complex as we need to support PCI IRQ > Link-, IOAPIC-, and IOSAPIC-based, as well as the potential for a mix of > Link and IO[S]APIC. On top of this we're trying to balance IRQ usage w/out > clobbering ISA-based devices. The curse of the PC platform -- when you think you just got right with the systems and devices that you have, someone comes with yet another (broken or not) system that fails. Too bad it's me this time :-] > The ACPI specification isn't clear on exactly how PCI IRQ Link devices > should be initialized or used. I get the feeling that OEMs have implemented > solutions that happen to work on a certain OS's implementation. Our > challenge is in reverse-engineering a compatible process. True. > Andy and I are working with Dominik to figure this out but we need more > information. I'm looking for a root-cause analysis: understanding of an > ailing system's chipset and ASL, plus output of the chipset's PCI IRQ > routing configuration registers and identification of what bits are wrong or > missing. A summary of which systems are having trouble would also be useful > (e.g. make/model, chipset, etc.). I am also working closely with Dominik, testing his patches; I just built 2.4.18 + acpi20020503 plus Dominik's newest pciirq16pre1, and this combination works again -- with the old PCI IRQ code, though, which he made selectable by means of a .config option. But this approach is OK for me; if we cannot find a way that works for all machines right now, it's better to make both ways available until the problem is fully solved. If you want to build a database with working and non-working systems, please say how you want information to be submitted. I'll be glad to contribute. > Note that the systems we have in-house don't have these issues... I am sure you are saying the truth. Best regards, Arndt -- Arndt Schoenewald <ab...@sr...>, Dortmund, Germany |