From: ebiederm@xmission.com (Eric W. Biederman)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds@transmeta.com>,
Edward Spidre <beamz_owl@yahoo.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Possible PCI subsystem bug in 2.4
Date: 09 May 2001 09:45:10 -0600 [thread overview]
Message-ID: <m1g0eele61.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1010508174820.26399A-100000@delta.ds2.pg.gda.pl>
In-Reply-To: "Maciej W. Rozycki"'s message of "Tue, 8 May 2001 18:01:12 +0200 (MET DST)"
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> On 4 May 2001, Eric W. Biederman wrote:
>
> > The example that sticks out in my head is we rely on the MP table to
> > tell us if the local apic is in pic_mode or in virtual wire mode.
> > When all we really have to do is ask it.
>
> You can't. IMCR is write-only and may involve chipset-specific
> side-effects. Then even if IMCR exists, a system's firmware might have
> chosen the virtual wire mode for whatever reason (e.g. broken hardware).
Admittedly you can't detect directly detect IMCR state. But
triggering an interrupt on the bootstrap processor local apic, and
failing to receive it should be proof the IMCR is at work.
Alternatively if I'm wrong about the wiring disabling all interrupts
at the apic level and receiving one is a second proof that IMCR is at
work. Further I don't think a processor with an onboard apic, works
with an IMCR register.
What I was thinking of earlier is that you can detect an apic or
ioapic in virtual wire mode, which the current code and the intel MP
spec treats as the opposite possibility.
Eric
next prev parent reply other threads:[~2001-05-13 15:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010503140318.7583.qmail@web10704.mail.yahoo.com>
2001-05-03 17:08 ` Possible PCI subsystem bug in 2.4 Linus Torvalds
2001-05-03 17:51 ` Alan Cox
2001-05-03 18:12 ` Linus Torvalds
2001-05-03 18:22 ` Jeff Garzik
2001-05-03 18:31 ` Alan Cox
2001-05-04 15:41 ` Eric W. Biederman
2001-05-04 15:52 ` Alan Cox
2001-05-04 16:13 ` Eric W. Biederman
2001-05-04 17:04 ` Alan Cox
2001-05-05 5:41 ` Eric W. Biederman
2001-05-08 16:01 ` Maciej W. Rozycki
2001-05-09 15:45 ` Eric W. Biederman [this message]
2001-05-04 17:44 ` Linus Torvalds
2001-05-05 5:30 ` Eric W. Biederman
2001-05-05 7:17 ` Alan Cox
2001-05-04 11:34 ` Rogier Wolff
[not found] <20010503191655.67673.qmail@web10701.mail.yahoo.com>
2001-05-03 19:28 ` Linus Torvalds
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=m1g0eele61.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=beamz_owl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@ds2.pg.gda.pl \
--cc=torvalds@transmeta.com \
/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