From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jeroen Van den Keybus <jeroen.vandenkeybus@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] SMI handling on x86
Date: Tue, 09 Apr 2013 23:04:46 +0200 [thread overview]
Message-ID: <5164826E.2000808@xenomai.org> (raw)
In-Reply-To: <CAPRPZsBh=5TkR93kiQR8yg0ABfJZtwJ_piBQKAOznEWMppgCyw@mail.gmail.com>
On 03/13/2013 08:43 PM, Jeroen Van den Keybus wrote:
> Hi,
>
>
> We have configured Linux 3.5.7 / Xenomai 2.6.2.1 on an MSI-7514 mainboard
> with a Core 2 Duo CPU.
>
> This configuration suffers from excessive worst-case latencies during the
> 'latency' test (on average: 2.6 µs, worst-case around 1900 µs, around 10
> overruns per second). I believe these overruns are due to the CPUs entering
> SM mode (SMI). As soon as the ACPI BIOS SMI is disabled (when
> xeno_nucleus/native are loaded as a module), the computer shuts down in 5
> secs. or so. Presumably some power supply watchdog on the mainboard isn't
> triggered.
>
> - Has someone also observed this behaviour and maybe solved it in some way ?
> - I looked around in the Intel manuals and I don't think it's possible to
> have only 1 CPU handle these SMIs. Is that correct ? If it were possible,
> we could run RT tasks on the other one, obviously, but currently latency
> shows overruns on both CPUs.
> - Would it somehow be possible/sensible to leave the SMI disabled and
> generically call the SMI handler directly from within (a task in) the OS ?
> There's probably going to be issues, the least of which would be proper
> handling of the RSM instruction outside SM mode. But still...
Hi,
I see this post has not received an answer after a long time. What can
be done for sure is only disabling some sources of SMI, the SMI
workaround module tries to do that, but probably has not a knob for
every possible SMI source. So, what you should do is get the datasheet
for the precise Intel ICH you own, and try and find all the SMI sources.
Then try and find which one causes the latency issues, with the hope
that it is not also the one needed to avoid the reboot.
Regards.
--
Gilles.
next prev parent reply other threads:[~2013-04-09 21:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 19:43 [Xenomai] SMI handling on x86 Jeroen Van den Keybus
2013-03-13 21:40 ` Gilles Chanteperdrix
[not found] ` <CAPRPZsDDi_LfwiMdbfZro5h6cU69ONNNvG7XtSDdKE0M3bjwpw@mail.gmail.com>
2013-03-13 21:59 ` Jeroen Van den Keybus
2013-03-13 22:19 ` Jeroen Van den Keybus
2013-04-09 21:04 ` Gilles Chanteperdrix [this message]
2013-04-17 11:44 ` Jeroen Van den Keybus
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=5164826E.2000808@xenomai.org \
--to=gilles.chanteperdrix@xenomai.org \
--cc=jeroen.vandenkeybus@gmail.com \
--cc=xenomai@xenomai.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.