All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] APIC physical broadcast for i82489DX
Date: Thu, 7 Oct 2004 15:45:53 -0700	[thread overview]
Message-ID: <20041007224553.GY9106@holomorphy.com> (raw)
In-Reply-To: <Pine.LNX.4.58L.0410072244570.27899@blysk.ds.pg.gda.pl>

On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> This is the same as version <= 0xf || version >= 0x14; I'm rather

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  I suppose defining a macro called something like APIC_XAPIC(x) to (x >= 
> 0x14) might actually have some sense, although unlike with the i82489DX, 
> there is no promise for this to be always true.

There is a presumption there that higher APIC revisions will be
backward-compatible and will have comparable version numbers, yes.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> suspicious, as the docs have long since been purged, making this

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  AFAIK i82489DX documents were never available online and I suppose they
> might have never existed in a PDF form.  You could have ordered hardcopies
> in mid 90's.

Which probably either predated or coincided with my earliest use of
computers.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> hopeless for anyone without archives (or a good memory) dating back to
>> that time to check. All that's really needed is citing the version that
>> comes out of the version register and checking other APIC
>> implementations to verify they don't have versions tripping this check,

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  The APIC_INTEGRATED() macro reflects the range reserved for the i82489DX.  
> Both "Multiprocessor Specification" and "IA-32 Intel Architecture Software
> Developer's Manual, Vol.3" which are available online specify it clearly
> and explicitly.  AFAIK, there is no integrated APIC implementation that
> would violate it (unlike with I/O APICs), so what's the problem?  If a 
> buggy chip appears, we can revisit this assumption.

Only documentation; this is probably as good as it gets, so I'm happy
with this level of explanation, for instance, saying what the revision
numbers are.


On Thu, 7 Oct 2004, William Lee Irwin III wrote:
>> the latter of which is feasible for those relying on still-extant
>> documentation. Better yet would be dredging up the docs... So, what is
>> the range of the version numbers reported by i82489DX's?

On Thu, Oct 07, 2004 at 11:12:55PM +0100, Maciej W. Rozycki wrote:
>  The i82489DX datasheet documents 0x01 for the chip and the
> implementations I've encountered so far agree.

Since it's not available online this will have to do. I seem to have
turned up some vague evidence they were made into PDF's ca. 1993, but
don't really expect that to mean anything.


-- wli

  reply	other threads:[~2004-10-07 23:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200410071609.i97G9reQ003072@hera.kernel.org>
2004-10-07 18:32 ` [PATCH] APIC physical broadcast for i82489DX William Lee Irwin III
2004-10-07 22:12   ` Maciej W. Rozycki
2004-10-07 22:45     ` William Lee Irwin III [this message]
2004-10-07  1:28 Maciej W. Rozycki

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=20041007224553.GY9106@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.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.