readme.smi

rtai-3.1-test3的源代码(Real-Time Application Interface )

From - Thu Apr 17 15:00:00 2003
Delivered-To: [e-mail]
Return-Path: <[e-mail]>
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 <[e-mail]>
To: Jason Perron <[e-mail]>,
      Paolo Mantegazza <[e-mail]>
Subject: Re:  README.SMI
Message-ID: <[e-mail]>
Reply-To: Vitor Angelo <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mailsrv-11827-1049795016-0001-2"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
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