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
[email protected]
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
