From: Philippe Gerum <rpm@xenomai.org>
To: Saul <xeno@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Non-deterministic behaviour in primary mode
Date: Fri, 31 Mar 2006 11:55:47 +0200 [thread overview]
Message-ID: <442CFCA3.4070704@domain.hid> (raw)
In-Reply-To: <1143790982.14016.257982746@domain.hid>
Saul wrote:
> Philippe Gerum wrote:
>
>>Mm, this really looks like some firmware/BIOS cyclic activity, that
>>would hit the busy loop more or less frequently, depending on the
>>internal timing of the outer loop. This reminds me that some recent
>>Intel chipset are known to prevent global SMI disabling actually, maybe
>>this is the case here, so our work-around would be basically useless.
>>Another usual suspect is NMI handling (which the Adeos layer does not
>>pipeline but rather delivers immediately), but I guess that you did not
>>activate the NMI watchdog anyway, so back to square #1, I guess.
>
>
> No, I never enabled the NMI watchdog.
>
> Yeah, that doesn't sound good for me. I just tried, for the first time,
> allowing SMI to remain enabled. Behaves exactly the same :( A failure
> to disable SMI would also explain why none of my peripherals were ever
> affected.
>
> I thought SMI was supposed to increase latencies, but I only see
> latencies < 60us at any load, unless I start video capture. Does the
> latency test absolutely rule out SMI as the cause?
Not really, e.g. if the video capture device is USB-attached, then SMI
could possibly remain in the picture.
Is there any way to
> check whether SMI is actually disabled?
>
Gilles will likely have more clue here, but I guess that reading back
the state of the GBL_SMI_EN_BIT from the SMI's MMIO space would
probably tell us if a previous request to disable SMI globally did
succeed or not. The code in question is in ksrc/arch/i386/smi.c.
Another option to cross-check that we might have an SMI issue would be
to find a box with an ICH4 chipset which is known to be reasonably
controllable by our SMI work-around, and try to do video capture using
it after Xenomai has globally disabled SMI sources.
> Thanks,
> Saul.
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
next prev parent reply other threads:[~2006-03-31 9:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-29 6:06 [Xenomai-help] Non-deterministic behaviour in primary mode Saul
2006-03-29 11:28 ` Jan Kiszka
2006-03-30 4:27 ` Saul
2006-03-29 12:27 ` Philippe Gerum
2006-03-30 4:47 ` Saul
2006-03-30 12:05 ` Gilles Chanteperdrix
2006-03-31 6:44 ` Saul
2006-03-30 21:00 ` Philippe Gerum
2006-03-31 7:43 ` Saul
2006-03-31 9:55 ` Philippe Gerum [this message]
2006-03-31 15:35 ` Gilles Chanteperdrix
2006-04-11 3:06 ` Saul
2006-04-11 12:08 ` Gilles Chanteperdrix
2006-04-12 0:56 ` Saul
2006-04-12 7:49 ` Jan Kiszka
2006-03-29 12:41 ` Philippe Gerum
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=442CFCA3.4070704@domain.hid \
--to=rpm@xenomai.org \
--cc=xeno@domain.hid \
--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.