From: jbarnes@sgi.com (Jesse Barnes)
To: Andrew de Quincey <adq_dvb@lidskialf.net>
Cc: andrew.grover@intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] deal with lack of acpi prt entries gracefully
Date: Thu, 11 Sep 2003 13:53:10 -0700 [thread overview]
Message-ID: <20030911205310.GA26569@sgi.com> (raw)
In-Reply-To: <200309112140.08967.adq_dvb@lidskialf.net>
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
next prev parent reply other threads:[~2003-09-11 20:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 20:13 [PATCH] deal with lack of acpi prt entries gracefully Jesse Barnes
2003-09-09 20:43 ` Andrew de Quincey
2003-09-09 21:17 ` Jesse Barnes
2003-09-09 21:38 ` Andrew de Quincey
2003-09-09 22:01 ` Jesse Barnes
2003-09-10 21:30 ` Andrew de Quincey
2003-09-10 21:38 ` Jesse Barnes
2003-09-11 20:40 ` Andrew de Quincey
2003-09-11 20:53 ` Jesse Barnes [this message]
2003-09-11 21:13 ` Andrew de Quincey
2003-09-11 21:20 ` Jesse Barnes
2003-09-11 22:00 ` Andrew de Quincey
2003-09-11 22:04 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2003-10-01 1:22 Brown, Len
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030911205310.GA26569@sgi.com \
--to=jbarnes@sgi.com \
--cc=adq_dvb@lidskialf.net \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox