[Xenomai] SMI handling on x86

[Xenomai] SMI handling on x86

[Jeroen Van den Keybus]

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.

Re: [Xenomai] SMI handling on x86

[Gilles Chanteperdrix]

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.

Re: [Xenomai] SMI handling on x86

[Jeroen Van den Keybus]

I don't have the .config at hand, but I believe so, yes. I did disable
processor ACPI though.



2013/3/13 Jeroen Van den Keybus <jeroen.vandenkeybus@gmail.com>

> I don't have the .config at hand, but I believe so, yes. I did disable
> processor ACPIm though.
>
> Jeroen.
>
>

Re: [Xenomai] SMI handling on x86

[Jeroen Van den Keybus]

Ok, I managed to get hold of the .config. I only retained those entries
that seemed obviously relevant to ACPI.


# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_EC_DEBUGFS=m
# CONFIG_ACPI_PROC_EVENT is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_PROCESSOR is not set
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_BGRT is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set

CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m

CONFIG_PNPACPI=y

CONFIG_ATA_ACPI=y

# CONFIG_PATA_ACPI is not set

# ACPI drivers
#
CONFIG_I2C_SCMI=m

# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

# CONFIG_THINKPAD_ACPI is not set
CONFIG_ACPI_WMI=m
# CONFIG_ACPI_CMPC is not set


2013/3/13 Jeroen Van den Keybus <jeroen.vandenkeybus@gmail.com>

> I don't have the .config at hand, but I believe so, yes. I did disable
> processor ACPI though.
>
>
>
>
> 2013/3/13 Jeroen Van den Keybus <jeroen.vandenkeybus@gmail.com>
>
>> I don't have the .config at hand, but I believe so, yes. I did disable
>> processor ACPIm though.
>>
>> Jeroen.
>>
>>
>

Re: [Xenomai] SMI handling on x86

[Gilles Chanteperdrix]

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.

Re: [Xenomai] SMI handling on x86

[Jeroen Van den Keybus]

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.
>
>