Messages in this thread | | | Date | Thu, 11 Sep 2003 13:53:10 -0700 | Subject | Re: [PATCH] deal with lack of acpi prt entries gracefully | From | (Jesse Barnes) |
| |
On Thu, Sep 11, 2003 at 09:40:08PM +0100, Andrew de Quincey wrote: > On Wednesday 10 Sep 2003 10:38 pm, Jesse Barnes wrote: > > On Wed, Sep 10, 2003 at 10:30:29PM +0100, Andrew de Quincey wrote: > > > So, exactly as your patch did, you just want it to drop back if there > > > were no PCI routing entries found by ACPI... sounds sensible enough. > > > > > > Can you confirm I have this right? > > > > Yep, that's it. The code should do that, but we get there before the > > list has been initialized, so we just hang. > > I'm not sure if this is automatically fixed or not yet. > > With the new patch: > > 1) If ACPI fails to parse a table, it disables ACPI, and so disables any > attempt to use ACPI for PRT routing.
That might work, though I'll be using the ACPI namespace to drive PCI discovery soon (hacking the PROM now). Maybe I should add some MADT and _PRT entries while I'm at it? The problem is that we don't support IOAPIC or IOSAPIC interrupt models/hw registers.
> 2) If ACPI is enabled, and enters the function you patched, code further in > checks if the routing tables have any entries. If not, it rejects the > attempt.
That would work I guess.
> From your patch, I get the impression (1) is what you were patching for.. am I > right? In that case, there shouldn't be a problem.
We also use ACPI tables SLIT and SRAT for memory/proximity detection, and fill in the proper FADT fields.
Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |