Re: [Xenomai-help] Smi workaround on ICH8M
2012/4/23 Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 04/23/2012 01:05 PM, Willy Lambert wrote: 2012/4/23 Philippe Gerum r...@xenomai.org: On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. Ok, thanks for answers. I did the test again , playing with usb and using the stress program to generate CPU load. The max latency for now is 15us in 4 mins. So I think it will be ok to keep SMI on for the time. Please let me know if this test is still stoo short. ^C---|---|---|---||--|- RTS| 0.604| 2.332| 15.161| 0| 0| 00:03:59/00:03:59 Do you know by chance where I can found infos about SMI sources ? I suppose it is not in the ICH8M docs, it would be in my board doc ? Or have I a soft way to do this check so that I don't have to spend time with my vendor which will obviously have hard time to answer that ? The list of potential SMI sources IS in the ICH8M docs. Whether these sources are used by your board essentially depends on the BIOS implementation (an SMI traps into BIOS code). So the theoretical answer to this question is to disassemble the the BIOS blob. ok, I think I won't do this for now as it's quite tricky, but I have the path in mind in case of problem. Thx for lighting up the way The practical answer is to run latency during a few hours, under stress using all the hardware which will be used in your target project (network card, disk I/Os, USB key I/Os, etc...). If an SMI is used but latencies remain acceptable with regard to your goals, no reason to bother. If you find unacceptable latencies, see the TROUBLESHOOTING guide, to see how to enable SMI workaround. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote:
Hi,
I have a message in dmesg about SMI workaround :
Xenomai: SMI-enabled chipset found, but SMI workaround disabled
(check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter
high interrupt latencies!
My kernel should be configured properly and following the In case of
high latencies of
http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did
some tests.
Latency test is here (if it is us it should be ok no ?):
RTT| 00:00:22 (periodic user-mode task, 100 us period, priority 99)
RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat
worst
RTD| 1.238| 1.365| 4.778| 0| 0| 0.605|
9.414
RTD| 1.238| 1.388| 5.292| 0| 0| 0.605|
9.414
RTD| 0.847| 1.365| 6.113| 0| 0| 0.605|
9.414
RTD| 1.238| 1.363| 4.676| 0| 0| 0.605|
9.414
RTD| 1.229| 1.365| 4.489| 0| 0| 0.605|
9.414
RTD| 1.237| 1.368| 4.194| 0| 0| 0.605|
9.414
RTD| 1.231| 1.386| 5.625| 0| 0| 0.605|
9.414
RTD| 0.681| 1.365| 6.020| 0| 0| 0.605|
9.414
RTD| 1.238| 1.365| 4.762| 0| 0| 0.605|
9.414
RTD| 1.165| 1.366| 6.987| 0| 0| 0.605|
9.414
RTD| 1.237| 1.364| 5.453| 0| 0| 0.605|
9.414
RTD| 1.093| 1.382| 5.567| 0| 0| 0.605|
9.414
RTD| 0.629| 1.365| 6.437| 0| 0| 0.605|
9.414
RTD| 1.236| 1.364| 4.584| 0| 0| 0.605|
9.414
RTD| 1.237| 1.366| 6.671| 0| 0| 0.605|
9.414
RTD| 1.238| 1.372| 4.436| 0| 0| 0.605|
9.414
RTD| 0.981| 1.384| 5.949| 0| 0| 0.605|
9.414
RTD| 0.626| 1.363| 5.844| 0| 0| 0.605|
9.414
RTD| 1.217| 1.364| 4.448| 0| 0| 0.605|
9.414
RTD| 1.237| 1.365| 4.451| 0| 0| 0.605|
9.414
RTD| 1.236| 1.368| 4.619| 0| 0| 0.605|
9.414
So I did a lspci -nn | grep LPC which gives :
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC
Interface Controller [8086:2815] (rev 04)
It is adviced to edit the ksrc/arch/x86/smi.c file. Is it still up to
date ? If yes could you help me to edit it ? I suppose it is this
section :
static struct pci_device_id rthal_smi_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_10)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801E_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_1)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_5)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_1)},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PCH_LPC_MIN+7)},
{0,},
};
I suppose I should add a line, with something from : pci_ids.h, but
it's not very clear to me which one to select.
If you see the messages, the ids for your chipset already are in the
table. If you want to enabled the SMI workaround, simply enable it in
the kernel configuration.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
2012/4/23 Philippe Gerum r...@xenomai.org: On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. Ok, thanks for answers. I did the test again , playing with usb and using the stress program to generate CPU load. The max latency for now is 15us in 4 mins. So I think it will be ok to keep SMI on for the time. Please let me know if this test is still stoo short. ^C---|---|---|---||--|- RTS| 0.604| 2.332| 15.161| 0| 0|00:03:59/00:03:59 Do you know by chance where I can found infos about SMI sources ? I suppose it is not in the ICH8M docs, it would be in my board doc ? Or have I a soft way to do this check so that I don't have to spend time with my vendor which will obviously have hard time to answer that ? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
2012/4/23 Willy Lambert lambert.wi...@gmail.com: 2012/4/23 Philippe Gerum r...@xenomai.org: On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. Ok, thanks for answers. I did the test again , playing with usb and using the stress program to generate CPU load. The max latency for now is 15us in 4 mins. So I think it will be ok to keep SMI on for the time. Please let me know if this test is still stoo short. ^C---|---|---|---||--|- RTS| 0.604| 2.332| 15.161| 0| 0| 00:03:59/00:03:59 Do you know by chance where I can found infos about SMI sources ? I suppose it is not in the ICH8M docs, it would be in my board doc ? Or have I a soft way to do this check so that I don't have to spend time with my vendor which will obviously have hard time to answer that ? Btw is there any way to test latencies without xenomai (or in secondary mode) to compare ? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 01:05 PM, Willy Lambert wrote: 2012/4/23 Philippe Gerum r...@xenomai.org: On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. Ok, thanks for answers. I did the test again , playing with usb and using the stress program to generate CPU load. The max latency for now is 15us in 4 mins. So I think it will be ok to keep SMI on for the time. Please let me know if this test is still stoo short. ^C---|---|---|---||--|- RTS| 0.604| 2.332| 15.161| 0| 0|00:03:59/00:03:59 Do you know by chance where I can found infos about SMI sources ? I suppose it is not in the ICH8M docs, it would be in my board doc ? Or have I a soft way to do this check so that I don't have to spend time with my vendor which will obviously have hard time to answer that ? The list of potential SMI sources IS in the ICH8M docs. Whether these sources are used by your board essentially depends on the BIOS implementation (an SMI traps into BIOS code). So the theoretical answer to this question is to disassemble the the BIOS blob. The practical answer is to run latency during a few hours, under stress using all the hardware which will be used in your target project (network card, disk I/Os, USB key I/Os, etc...). If an SMI is used but latencies remain acceptable with regard to your goals, no reason to bother. If you find unacceptable latencies, see the TROUBLESHOOTING guide, to see how to enable SMI workaround. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
