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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.