* [Xenomai] SMI handling on x86
@ 2013-03-13 19:43 Jeroen Van den Keybus
2013-03-13 21:40 ` Gilles Chanteperdrix
2013-04-09 21:04 ` Gilles Chanteperdrix
0 siblings, 2 replies; 6+ messages in thread
From: Jeroen Van den Keybus @ 2013-03-13 19:43 UTC (permalink / raw)
To: xenomai
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...
Jeroen.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] SMI handling on x86
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-04-09 21:04 ` Gilles Chanteperdrix
1 sibling, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-03-13 21:40 UTC (permalink / raw)
To: Jeroen Van den Keybus; +Cc: xenomai
On 03/13/2013 08:43 PM, Jeroen Van den Keybus wrote:
> Hi,
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
Do you have ACPI enabled in the kernel configuration?
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai] SMI handling on x86
2013-03-13 19:43 [Xenomai] SMI handling on x86 Jeroen Van den Keybus
2013-03-13 21:40 ` Gilles Chanteperdrix
@ 2013-04-09 21:04 ` Gilles Chanteperdrix
2013-04-17 11:44 ` Jeroen Van den Keybus
1 sibling, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-09 21:04 UTC (permalink / raw)
To: Jeroen Van den Keybus; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai] SMI handling on x86
2013-04-09 21:04 ` Gilles Chanteperdrix
@ 2013-04-17 11:44 ` Jeroen Van den Keybus
0 siblings, 0 replies; 6+ messages in thread
From: Jeroen Van den Keybus @ 2013-04-17 11:44 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
Gilles,
Thanks for responding. I had also checked what you describe. Unfortunately
it is the ACPI interrupt that causes the delay and is also responsible for
keeping the motherboard powered.
It's not the first time I hit the SMI induced latency problem, but it is
the first board that goes as far as to actually reset itself.
Jeroen.
2013/4/9 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 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.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-17 11:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2013-04-17 11:44 ` Jeroen Van den Keybus
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.