To fix SMI problems run "setsmi [hal_smi_masked_bits=<xxx>]", where
"hal_smi_masked_bits" should be used if SMI devices must be disabled
selectivily. Without it SMI is disabled completly. Note that using
"setsmi hal_smi_masked_bits=1" will disable SMI competely, it is in
fact the default action if nothing is said at insmod.

A list of a few specific bits:
#define INTEL_USB2_EN_BIT   (0x01 << 18) /* ICH4, ... */
#define LEGACY_USB2_EN_BIT  (0x01 << 17) /* ICH4, ... */
#define PERIODIC_EN_BIT     (0x01 << 14) /* called 1MIN_ in ICH0 */
#define TCO_EN_BIT          (0x01 << 13)
#define MCSMI_EN_BIT        (0x01 << 11)
#define SWSMI_TMR_EN_BIT    (0x01 << 6)
#define APMC_EN_BIT         (0x01 << 5)
#define SLP_EN_BIT          (0x01 << 4)
#define LEGACY_USB_EN_BIT   (0x01 << 3)
#define BIOS_EN_BIT         (0x01 << 2)

The default action of disabling SMI support completely will disable any 
device wanting to acces SMI. So assigning a specific "hal_smi_masked_bits" 
may be a more viable way of controlling SMI. Such a choice may however 
be not a trivial one, entailing some testing trials. In fact it is in view
of the need of easily fiddling with such a bit mask, without recompiling the
related support, that the alternative of setting it at RTAI configuration
has been dismissed.

To reset SMI to its previous state simply run: "rstsmi". 

Both scripts are located in $PREFIX/bin/ and they assume that directory
is in your $PATH.

------------------------------------------------------------------------------

REMARK!!!

All of what found in the explanation below should be in smi-module.c.

HISTORY and EXPLANATION of SMI INTERFERENCE with RTAI and RELATED TECH LINKs.

From - Thu Apr 17 15:00:00 2003
Delivered-To: mante@aero.polimi.it
Return-Path: <vitor@ead.eee.ufmg.br>
Received: from kom.mpipf-muenchen.mpg.de (kom.mpisoc.mpg.de [::ffff:192.129.1.23])
  by mailsrv.aero.polimi.it with esmtp; Tue, 08 Apr 2003 11:43:29 +0200
Received: from 10.1.1.2 by kom.mpipf-muenchen.mpg.de (InterScan E-Mail VirusWall NT); Tue, 08 Apr 2003 12:01:34 +0100 (GMT Daylight Time)
Received: from laboiss4.intra.mpipf-muenchen.mpg.de ([10.129.2.94] helo=vitor.smk.mpipf.de)
	by duch1.intra.mpipf-muenchen.mpg.de with smtp (Exim 4.05)
	id 192pwl-00046M-00; Tue, 08 Apr 2003 12:03:19 +0200
Received: by vitor.smk.mpipf.de (sSMTP sendmail emulation); Tue, 8 Apr 2003 06:59:47 -0300
Date: Tue, 8 Apr 2003 06:59:47 -0300
From: Vitor Angelo <vitor@ead.eee.ufmg.br>
To: Jason Perron <jaysnleep@hotmail.com>,
      Paolo Mantegazza <mantegazza@aero.polimi.it>
Subject: Re:  README.SMI
Message-ID: <20030408095947.GA24422@ead.eee.ufmg.br>
Reply-To: Vitor Angelo <vitor@ead.eee.ufmg.br>
References: <F35reImjVTML0SLFqE40000ebe8@hotmail.com> <3E918821.375F7268@aero.polimi.it>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mailsrv-11827-1049795016-0001-2"
Content-Disposition: inline
In-Reply-To: <3E918821.375F7268@aero.polimi.it>
User-Agent: Mutt/1.3.28i
Organization: Max-Planck-Institut
X-Operating-System: Debian GNU/Linux 3.0r1 - Woody - Kernel 2.4.20
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 1049795016.11837_0.mailsrv,S=6828

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_mailsrv-11827-1049795016-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mime-Autoconverted: from 8bit to 7bit by courier 0.39


Hi Jason and Paolo,

# 
# It is committed into the RTAI CVS as README.SMI.
# 

Initially I'd send the attached file, but I have some comments first.
I've resent the whole file (because of the ^M you mentioned Jason) but
just the two chipsets were added.

I'd like to suggest a different approach, and to know your opinions. The
TCO1_CNT is just one of the sources of SMIs and I had to "leave the
register alone" since the watchdog driver is been used. The GBL_SMI_EN
seems a really global configuration option, that will not avoid the SMI
events, just the interrupts. That's what bothers me...

I think that trying to avoid all possible sources of SMIs (caused by
Linux or BIOS), for all chipsets, would be a nightmare. Since I started
to use a ACPI enabled kernel (just the shutdown button feature) the
jitter problems stopped, _without_ disabling the GBL_SMI_EN bit!

My suggestion is (in a "if it doesn't work, go to the next" basis):

1) Disable all APM features at the BIOS, and, if possible, select
   configurations like "ventilation" to be fixed, and not handled by
   BIOS or ACPI OS.

2) Compile a kernel with ACPI enabled, keeping the PM settings at the
   BIOS fixed (not automatic) or handled by a ACPI OS where possible.

3) Disable the GBL_SMI_EN bit, and test if any device driver has stopped
   working properly. Check a possible system overheating in case it's
   not possible to keep the ventilation on all the time.

Maybe I'm just too paranoid about damaging the computer, but it's good
that the jitter problem seems to be gone without disabling the SMI. I'd
also like to add that both the watchdog driver and the ACPI kernel work
with the GBL_SMI_EN bit disabled "by hand".

I hope my english is not too bad and the information is more or less
clear. I'm looking forward to know your opinions.

Regards,

Vitor.

P.S. One last comment is that the specs for the 3 chipsets (ICH[234])
     look the same for the important bits in the SMI_EN register, so we
     could use the same code to disable the SMIs.



--=_mailsrv-11827-1049795016-0001-2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="README.SMI-new"

RTAI and SMI
============

When using RTAI with certain Intel-based motherboards, some people have 
experienced seemingly unexplainable latencies (many 100's of microseconds) 
that are unacceptable for the real-time performance they need.  In the past
it was believed that this problem was being caused by "buslocking" and that
the only way around it was to use different hardware.  

While buslocking my indeed be a problem in multiprocessor systems, if you
are using a single processor system the more likely culprit is System Management 
Interrupts (SMI) being generated by the power management hardware on the board.  
In a real time environment, SMIs are evil.  First off, they can last for 
hundreds of microseconds, which for many RT applications causes unacceptable 
jitter.  Second, they are the highest priority interrupt in the system (even 
higher than the NMI).  Third, you can't intercept the SMI because it doesn't 
have a vector in the CPU.  Instead, when the CPU gets an SMI it goes into a 
special mode and jumps to a hard-wired location in a special SMM address space 
(which is probably in BIOS ROM).  This is why RTAI can't help -- SMI interrupts 
are essentially "invisible" to it.

This problem has been most likely experienced by anybody trying to use RTAI
on a fairly modern (probably Pentium or higher) Intel based platform.  This
is unfortunate, because Intel motherboards and CPUs are cheap, fast and in
good supply, which makes them excellent candidates for low cost solutions
that we (and our bosses) all love and want.

The good news is that in many (maybe even all) cases, SMIs can be disabled
by twiddling a few bits in the system controller on the motherboard.  The
purpose of this document is to tell you how to do that based on what type
of controller you have.


Intel ® 82801DB I/O Controller Hub 4 (ICH4)
===========================================

Data Sheet URL: 

	http://www.intel.com/design/chipsets/datashts/29074401.pdf

Instructions:

	1. The GBL_SMI_EN bit in the SMI_EN register must be cleared.
	2. The TCO_TMR_HLT bit in the TCO1_CNT register must be set.

Suggestions contributed by Jason Perron <jaysnleep@hotmail.com>.


Intel ® 82801BA I/O Controller Hub 2 (ICH2)
===========================================

Data Sheet URL:

	http://www.intel.com/design/chipsets/datashts/29068702.pdf

Instructions:

	1. The GBL_SMI_EN bit in the SMI_EN register must be cleared.

Comments:

	The Linux watchdog "Intel i810 TCO timer" may be used with the
	SMIs disabled for these two chipsets.


Intel ® 82801CA I/O Controller Hub 3 (ICH3) - not tested yet
============================================================

Data Sheet URL:

	http://www.intel.com/design/chipsets/datashts/29073302.pdf

Comments:
	Exactly the same configuration for the 82801BA chipset. The same
	procedure should be valid.

Additions contributed by Vitor Angelo <vitor@ead.eee.ufmg.br>.

-----------------------------------------------------------------------


--=_mailsrv-11827-1049795016-0001-2--
