From: James Cleverdon <jamesclv@us.ibm.com>
To: john stultz <johnstul@us.ibm.com>, lkml <linux-kernel@vger.kernel.org>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
Andrew Grover <andrew.grover@intel.com>
Subject: Re: [RFC][PATCH] linux-2.5.69_clear-smi-fix_A0
Date: Wed, 7 May 2003 07:54:08 -0700 [thread overview]
Message-ID: <200305070754.08881.jamesclv@us.ibm.com> (raw)
In-Reply-To: <1052258319.4503.7.camel@w-jstultz2.beaverton.ibm.com>
John,
That looks reasonable to me. The one possible catch would be for systems so
old they don't do SMI -- 386s and 486s, I imagine. If this code doesn't barf
on them when CONFIG_IO_APIC is turned on, then it should be fine (minus the
printk).
(I believe there was at least one such system, the Intel Xpress box. It
contained a 486 and seperate APIC chips.)
James
On Tuesday 06 May 2003 02:58 pm, john stultz wrote:
> All,
> I've been having problems with ACPI on a box here in our lab, it ends
> up that when we clear_IO_APIC() at boot time, we clear the SMI pin that
> is setup by the BIOS. This basically clobbers the SMI and we can then
> never make the transition into ACPI mode.
>
> I'm not sure if this is the right solution, but I figured I'd post it
> and take the flamage if I'm just being dumb. Basically in
> clear_IO_APIC_pin, I read the apic entry to make sure the delivery_mode
> isn't dest_SMI. If it is, we leave the apic entry alone and return.
>
> With this patch, the box boots and SMIs appear to function properly.
>
> Let me know if you have any thoughts or suggestions.
>
> thanks
> -john
>
>
> diff -Nru a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
> --- a/arch/i386/kernel/io_apic.c Tue May 6 14:46:58 2003
> +++ b/arch/i386/kernel/io_apic.c Tue May 6 14:46:58 2003
> @@ -219,6 +219,14 @@
> {
> struct IO_APIC_route_entry entry;
> unsigned long flags;
> +
> + /* Check delivery_mode to be sure we're not clearing an SMI pin */
> + *(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
> + *(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
> + if (entry.delivery_mode == dest_SMI){
> + printk(KERN_INFO "apic %i pin %i is an SMI pin!\n", apic, pin);
> + return;
> + }
>
> /*
> * Disable it in the IO-APIC irq-routing table:
--
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
next prev parent reply other threads:[~2003-05-07 14:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 21:58 [RFC][PATCH] linux-2.5.69_clear-smi-fix_A0 john stultz
2003-05-07 14:54 ` James Cleverdon [this message]
2003-05-07 14:24 ` Alan Cox
2003-05-07 19:34 ` Zwane Mwaikambo
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=200305070754.08881.jamesclv@us.ibm.com \
--to=jamesclv@us.ibm.com \
--cc=andrew.grover@intel.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.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;
as well as URLs for NNTP newsgroup(s).