Re: [PATCH] deal with lack of acpi prt entries gracefully

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Thursday 11 Sep 2003 9:53 pm, Jesse Barnes wrote:
> 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.

Which base architecture do you use? x86 and x86_64 ACPI now both support PIC 
based interrupt models.. as thats the only other option AFAIK (It tries 
IOAPIC first, then if that fails, it drops back to trying PIC mode).

> > 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.

Cool, well if it doesn't work, at least we know exactly what to fix.