From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
mingo@elte.hu, hpa@zytor.com, tglx@linutronix.de,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] x86: apic - unify lapic_resume
Date: Mon, 18 Aug 2008 18:39:43 +0400 [thread overview]
Message-ID: <20080818143943.GA7237@lenovo> (raw)
In-Reply-To: <Pine.LNX.4.55.0808181506230.29123@cliff.in.clinika.pl>
[Maciej W. Rozycki - Mon, Aug 18, 2008 at 03:19:05PM +0100]
| On Sun, 17 Aug 2008, Cyrill Gorcunov wrote:
|
| > it seems this limit is not APIC related since iirc 82489DX allows
| > to address 2^14 bits, x2APIC - more then 128 entities too. So I suspect
| > it somehow cpu bitmap related. Am I wrong (I didn't _check_ the code)?
|
| For the record: the 82489DX supports an 8-bit physical unit ID so 256
| distinct values are supported. Of these I gather 255 is taken for the
| broadcast ID in the physical destination mode, but that is nowhere
| explicitly confirmed in the 82489DX docs (it can be implied from protocol
| description though). While the ID is indeed 8-bit in the 82489DX, for
| systems where future compatibility was a concern Intel recommended the use
| of IDs from 0 through to 14 only in anticipation of the future integrated
| APIC with the physical mode addressing capability limited to 4 bits only
| (and 15 taken for the broadcast ID).
|
| Full 32 bits are available with the 82489DX for the logical destination
| mode and only the flat (no cluster) mode is supported.
|
| Maciej
|
Thanks, Maciej! The doc says to use 0-14 so I misinterpreted it as
bits :(. I've to be more carefull next time. Thanks!
- Cyrill -
next prev parent reply other threads:[~2008-08-18 14:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-16 19:21 one more apic merging preliminary series Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 1/6] x86: apic - unify clear_local_APIC Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 2/6] x86: apic - unify lapic_resume Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 3/6] x86: apic - unify lapic_suspend Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 4/6] x86: apic - rearrange functions and comments Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 5/6] x86: apic - unify lapic_is_integrated Cyrill Gorcunov
2008-08-16 19:21 ` [PATCH 6/6] x86: apic - unify xapic_icr_read Cyrill Gorcunov
2008-08-16 19:52 ` [PATCH 2/6] x86: apic - unify lapic_resume Maciej W. Rozycki
2008-08-16 20:00 ` Arjan van de Ven
2008-08-16 20:12 ` Cyrill Gorcunov
2008-08-18 14:19 ` Maciej W. Rozycki
2008-08-18 14:39 ` Cyrill Gorcunov [this message]
2008-08-16 20:25 ` Maciej W. Rozycki
2008-08-16 20:05 ` Cyrill Gorcunov
2008-08-17 12:45 ` one more apic merging preliminary series Ingo Molnar
2008-08-17 13:12 ` Cyrill Gorcunov
2008-08-18 20:37 ` Suresh Siddha
2008-08-19 0:21 ` Ingo Molnar
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=20080818143943.GA7237@lenovo \
--to=gorcunov@gmail.com \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).