All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Morris <john@zultron.com>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Xenomai <xenomai@xenomai.org>
Subject: Re: [Xenomai] SMI workarounds in one-size-fits-all kernel packages (Was: Re: Kernel OOPS during regression tests)
Date: Sun, 13 Jan 2013 23:33:15 -0600	[thread overview]
Message-ID: <50F3989B.7050808@zultron.com> (raw)
In-Reply-To: <50F30EEA.8090803@xenomai.org>

On 01/13/2013 01:45 PM, Gilles Chanteperdrix wrote:
> On 01/13/2013 08:36 PM, John Morris wrote:
>> On 01/13/2013 07:53 AM, Gilles Chanteperdrix wrote:
>>> On 01/13/2013 05:40 AM, John Morris wrote:
>>>> On 01/12/2013 01:03 PM, Gilles Chanteperdrix wrote:
>>>>> It seems a really bad idea to enable the SMI workaround by default.
>>>>
>>>> Thanks!  Despite feeling uncomfortable contradicting the documentation,
>>>> I was encouraged to turn this on by someone more authoritative than me.
>>>> It does seem like a separate package with it turned on is warranted for
>>>> those who have problems and have been fairly warned about the risk.
>>>
>>> I guess we should turn the compile-time option into a kernel parameter.
>>> So, the smi workaround would be disabled by default, and only enabled
>>> when passing a kerne command-line option.
>>
>> That would be ideal!
> 
> We will try to issue a fix for the 2.6.2 release first, this improvement
> will be part of the next release.

A boot-time option would definitely solve the one-kernel-fits-all need.
 In my ideal fantasy world, a run-time option, perhaps in /proc/xenomai,
would potentially make this dummy-proof, since someone could write a
utility to tweak settings in a running system, maybe even a smart
utility that could help detect dangerous conditions.

I did find Jan's userland utility 'smictrl' [1] that uses libpci to
provide a simple way to query and set SMI controls on a running system.
 If it has all the functionality of Xenomai's SMI workaround, maybe we
could toss that into the packages, write a wiki page and say 'good
enough for now'.  (I tried it on an old Dell PC and my old Thinkpad,
both with ICH5 chipset, and while it could manipulate some bits, the
ones that might have mattered couldn't be reset.  I assumed they were
locked down by the BIOS, not by any shortcoming of the utility.)

	John

[1]  http://git.kiszka.org/?p=smictrl.git


      reply	other threads:[~2013-01-14  5:33 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-12 17:26 [Xenomai] Kernel OOPS during regression tests John Morris
2013-01-12 17:31 ` Gilles Chanteperdrix
2013-01-13  4:36   ` John Morris
2013-01-13 12:16     ` Gilles Chanteperdrix
2013-01-13 19:14       ` [Xenomai] 3.5.7 "I-pipe: could not find timer" (Was: Re: Kernel OOPS during regression tests) John Morris
2013-01-13 19:41         ` Gilles Chanteperdrix
2013-01-14  4:47           ` [Xenomai] 3.5.7 posix/mprotect failure; "I-pipe: could not find timer" fixed! John Morris
2013-01-14 11:57             ` Gilles Chanteperdrix
2013-01-14 12:00               ` Jan Kiszka
2013-01-14 13:36                 ` Jan Kiszka
2013-01-14 20:52                   ` John Morris
2013-01-14 22:54                     ` Gilles Chanteperdrix
2013-01-15  7:16                       ` [Xenomai] 3.5.7 posix/mprotect fixed; (Was: posix/mprotect failure) John Morris
2013-01-15  7:31                         ` Gilles Chanteperdrix
2013-01-18  3:56                           ` John Morris
2013-01-18  4:31                             ` Gilles Chanteperdrix
2013-01-14 19:50             ` [Xenomai] 3.5.7 posix/mprotect failure; "I-pipe: could not find timer" fixed! Gilles Chanteperdrix
2013-01-14 20:56               ` John Morris
2013-01-14 22:57                 ` Gilles Chanteperdrix
2013-01-14 12:00           ` [Xenomai] 3.5.7 "I-pipe: could not find timer" (Was: Re: Kernel OOPS during regression tests) Jan Kiszka
2013-01-14 18:50             ` Gilles Chanteperdrix
2013-01-14 19:13               ` Jan Kiszka
2013-01-14 19:15                 ` Gilles Chanteperdrix
2013-01-14 19:37                   ` Jan Kiszka
2013-01-14 20:39                     ` Gilles Chanteperdrix
2013-01-15 11:35                       ` Jan Kiszka
2013-01-15 12:06                         ` Gilles Chanteperdrix
2013-01-15 12:09                           ` Philippe Gerum
2013-01-15 12:21                             ` Jan Kiszka
2013-01-15 13:44                               ` Philippe Gerum
2013-01-15 13:48                                 ` Jan Kiszka
2013-01-15 13:58                                   ` Philippe Gerum
2013-01-15 14:10                                     ` Jan Kiszka
2013-01-15 19:39                                     ` Gilles Chanteperdrix
2013-01-16  8:02                                       ` Jan Kiszka
2013-01-16  8:44                                         ` Jan Kiszka
2013-01-16  9:41                                           ` Philippe Gerum
2013-01-16  9:48                                             ` Jan Kiszka
2013-01-16 10:37                                               ` Philippe Gerum
2013-01-16 12:03                                                 ` Gilles Chanteperdrix
2013-01-16 12:18                                                   ` Jan Kiszka
2013-01-15 13:59                                   ` Jan Kiszka
2013-01-12 19:02 ` [Xenomai] Kernel OOPS during regression tests Gilles Chanteperdrix
2013-01-13  6:50   ` John Morris
2013-01-13 11:23     ` Jan Kiszka
2013-01-13 12:18       ` Gilles Chanteperdrix
2013-01-13 19:34         ` [Xenomai] 3.5.3 posix/mprotect fail "sigdebug_handler triggered" (Was: Re: Kernel OOPS during regression tests) John Morris
2013-01-13 19:42           ` Gilles Chanteperdrix
2013-01-12 19:03 ` [Xenomai] Kernel OOPS during regression tests Gilles Chanteperdrix
2013-01-13  4:40   ` John Morris
2013-01-13 13:53     ` Gilles Chanteperdrix
2013-01-13 19:36       ` [Xenomai] SMI workarounds in one-size-fits-all kernel packages (Was: Re: Kernel OOPS during regression tests) John Morris
2013-01-13 19:45         ` Gilles Chanteperdrix
2013-01-14  5:33           ` John Morris [this message]

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=50F3989B.7050808@zultron.com \
    --to=john@zultron.com \
    --cc=gilles.chanteperdrix@xenomai.org \
    --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.