Re: RTAI 5.0.1 calibrate program: BUG: unable to handle kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
Vivian McPhail <[email protected]> Tue, 28 Nov 2017 15:09:52 +1300
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <CAGSp+B7eqDbTRL7VBfM6f7KSdjzrUC0c4-Ggr=xsf+4Pvznd6A@mail.gmail.com> |
Hi Paolo, Thank you for your helpful suggestions. > First of all I think that SMI_LOCK should just impede the disabling of the GBL_SMI_EN enable bit, i.e. the 0 one, while still allowing the manipulation of some of the other ones, possibly not all of them. So, for example, if you disable the special EOS bit, number 2, it will be re-enabled again automatically. I found that I had to disable some GPIO bits to disable SMI_EN bits. Now we find that GBL_SMI_EN is not always enabled. It seems random with respect to rebooting. > As an alternative you can try using the legacy setsmi and rstsmi support. To know how it works run, from within the RTAI installed "bin" directory: ./setsmi 0, ./rstsmi. Then look at their outcomes using dmesg. Once you are acquainted with their use setup the "mask" of a the SMI bits you want to clean, possibly using the smispv support to spot them. Then do: ./setsmi mask, recheckin it by using dmesg and smispv to see what happened, maybe repeating the game, after issuing rstsmi, with other bits, just to see how it works. We have managed to disable all the bits shown in `smispv` except `LEGACY_USB2` and `INTEL_USB2.` No matter what we do we cannot unset these bits. <quote> dmesg: ... [ 4687.106953] - CPU 0 (RETVAL 0), SMI COUNT 283266. [ 4687.106955] - CPU 1 (RETVAL 0), SMI COUNT 283266. [ 4687.106999] RTAI: Intel SMI chipset found (8086:a149), enabling SMI workaround. [ 4687.107024] Bits enabled: LEGACY_USB2, INTEL_USB2. [ 4687.107025] Original SMI configuration value 0xffff0000 has been cleared with mask = 0xffffff00 (saved mask setting 0xffff0000), new value 0xffff0000. [ 4687.107026] Bits enabled: LEGACY_USB2, INTEL_USB2. </quote> > BTW, if I remember it well you have the msr utility. If so you should help me, by verifying if the SMI counts reported by setsmi corresponds to what reported by msr. Notice also that you can check the SMI count alone by simply using ./smicnt, whenever you want. Yes, we have the `msr` utility. The SMI counts using `smicnt` are the same as using `msr.` > We are trying to provide a comprehensive SMI monitoring support and we'll be happy to have it checked by others. Great! > As a final point your SMI chipset should be in the smi-module.c list already, if not the new version should be able to find it anyway. Yes, our chipset is in `smi-module.c` now. I tried setting `#define CONFIG_RTAI_HW_SMI_INTEL_USB2 1` in `smi-module.c` but this did not seem to have any effect. Is this code just for the calibration program? > If you'll carry out any try along what suggested above, let us know. Many thanks, Vivian On 28 November 2017 at 10:57, Paolo Mantegazza <[email protected]> wrote: > We'll have a look at it. Meanwhile I would like to suggest another try. > First of all I think that SMI_LOCK should just impede the disabling of the > GBL_SMI_EN enable bit, i.e. the 0 one, while still allowing the > manipulation of some of the other ones, possibly not all of them. So, for > example, if you disable the special EOS bit, number 2, it will be > re-enabled again automatically. > As an alternative you can try using the legacy setsmi and rstsmi support. > To know how it works run, from within the RTAI installed "bin" directory: > ./setsmi 0, ./rstsmi. Then look at their outcomes using dmesg. > Once you are acquainted with their use setup the "mask" of a the SMI bits > you want to clean, possibly using the smispv support to spot them. Then do: > ./setsmi mask, recheckin it by using dmesg and smispv to see what happened, > maybe repeating the game, after issuing rstsmi, with other bits, just to > see how it works. > BTW, if I remember it well you have the msr utility. If so you should help > me, by verifying if the SMI counts reported by setsmi corresponds to what > reported by msr. Notice also that you can check the SMI count alone by > simply using ./smicnt, whenever you want. > We are trying to provide a comprehensive SMI monitoring support and we'll > be happy to have it checked by others. > As a final point your SMI chipset should be in the smi-module.c list > already, if not the new version should be able to find it anyway. > If you'll carry out any try along what suggested above, let us know. > > Thanks, Paolo. > > ________________________________________ > From: Vivian McPhail [[email protected]] > Sent: Monday, November 27, 2017 9:30 PM > To: Paolo Mantegazza > Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to handle > kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza) > > Hi Paolo, > > We have updated to rtai-5.1-test1 but still have problems with `smispv`. > > When we run `smispv` we cannot "apply" the changes to the various bits. > We believe this is because the SMI_LOCK bit has been set during boot-up. > The problem seems to be solved by this code for some chipsets: > > https://au.mathworks.com/matlabcentral/fileexchange/ > 18832-disabling-smis-on-intel-r--ich5-chipsets > > The SMI_LOCK bit can be reset by a "PCI reset." Is this something that > could be handled in the linux kernel boot procedure or does it have to be > set in BIOS? Unfortunately we have no experience with linux kernel and > less with BIOS. > > Cheers, > > Vivian > > <--------------------------------------> > > Some relevant information: > > We are using an intel i3-6100 CPU. This contains a Intel Corporation > Sunrise Point-H LPC Controller (8086:a149). > > By reading 100-series-chipset-datasheet-vol-2.pdf we find information on > SMI_LOCK > > SMI Lock (SMI_LOCK): When this bit is set, writes to the > GLB_SMI_EN bit will have no effect. Once the SMI_LOCK bit is set, > writes of '0' to SMI_LOCK bit will have no effect (i.e. once set, this > bit can only be cleared by PLTRST# assertion). > > This bit is part of the GEN_PMCON_A register > > General PM Configuration A (GEN_PMCON_A)—Offset A0h > Usage ACPI, Legacy. Available Desktop, Mobile. > Access Method > Default: A0000000h > Type: CFG Register > (Size: 32 bits) > Device: 31 > Function: 2 > > > Motherboard is SuperMicro X11SSA-F, based on intel C236 PCH chipset > > On 19 October 2017 at 22:02, Paolo Mantegazza <[email protected]< > mailto:[email protected]>> wrote: > Thanks for pointing out the segfault of the calibration helper. > The problem is just that there should not be such a helper anymore, > nonetheless it has been left in the distribution. > The reason is that the calibration is carried out as explained in the RTAI > config help lines, with due length in my opinion. Have a look at it, either > by reading the Kconfig file or under menuconfig. > Such a calibration is carried out, automatically, the very first time you > run rtai_sched and it does not find the file "rtai-installdir/calibration/latencies", > creates and uses it in subsequent runs. > If you want to tune it further your way just run the latency checkers in > the installed testsuite, then edit that file by hand. > > If rdmsr gives an increasing SMI count then there should be a problem for > sure. I'd like to add your troubling chipset to the smi-module.c list, but > you say that it did not work. Then before doing it I need to understand > what's wrong. > > To help me (and you as well, hopefully), you should try the other SMI > diagnostic tool found in RTAI, i.e. smispv. It is made within RTAI but is a > stand alone code you can run anyway, as described in README.SMISPV. > If you'll do I'd like to know the outcome and, once you succeeded with > smispv, try setsmi and see if it is ok or fails. > > My way to use it is to launch smispv, an interactive tool, execute a > latency test, wait for a high latency overrun, play with smispv till the > current latency remains acceptable, while the overall max stay high. Then > stop latency, rerun it and see that the latency is ok, cross check using > smispv again to reenable smi and witness the latency skyrocketing. Once > what must be done to set smi so to avoid troubles, verify that running > setsmi obtains the same result. Eventually, production work will begin by > using setsmi before insmodig rtai_hal.ko and the rest. > > Paolo. > > > > On 10/19/2017 04:01 AM, Samuel R wrote: > Hi Paolo, > > Let me resume a few things: > > - the tscdeadline option should work in RTAI; > > Yes, this is not related to our problem. Sorry for the confusion. > > - the calibration problem must not exist, if you downloaded RTAI from the > user contributions; > > The calibration program does work with the rtaicontrib version, although > there is a segmentation fault when it is called with the --help flag, i.e. > `./calibrate --help`. This is not really an issue since it appears that the > actual calibration works without problems. > > - as for the missing smi chipset send me an email with the missing one, > even if it will just confirm the one you mentioned already; I'll add it to > the list in the approaching 5.1; > > Intel Corporation Sunrise Point-H LPC Controller (8086:a149) > > - If you have an smi problem, before trying a fix, try to diagnose it > using the interactive graphic tool which come with RTAI; > - as a further help for possible smi problems download what found at " > 01.org/msr-tools<http://01.org/msr-tools>" and use rdmsr to see if there > are smi interrupts (there is a register counting them, if the count > increases then you have smi problems); > > Right now we do think that the problem is related to SMI. We have used the > `rdmsr 0x34` command and the SMI count increases by ~60 counts every second > (see video below). > > - last option, give me root access to it, so that I can see what happens > first hand; due to the time difference at Italy's antipode it can be > impracticable, as there must be someone to push the hard reset in case of > locks. > > This is probably not possible, since we are behind a university > firewall... However, I have created a short video to illustrate what I have > been trying with the smispv utility, and to show the rdmsr counts and > measured kernel latencies. At the end I also show that the rtai calibration > works. Hopefully this can adequately show what we are seeing from our side: > https://www.youtube.com/watch?v=zC73JI4puMI > > Sam > > > Paolo. > > > > On 10/18/2017 02:12 AM, Vivian McPhail wrote: > > Hi Paolo and list, > > My colleague, Sam, who has been helping me, has done the following: > > > To follow up on this: > > >>> Have you diagnosed SMI with the graphic tool found in RTAI? > >> > >> We have tried using the smispv utility, however it seems to have no > >> effect. > > > > Please be more specific. What did you try to do, what were you expecting, > > and what happened, exactly? > > While running the latency program we also run smispv, however attempting > to change the SMI bits appears to do nothing (the bitmask just goes back to > the original values when we try to set it). > > > For example, if you tried to disable some SMI bit, and after issuing the > > command the bit is still there, then it is likely that the SMI_LOCK is > set, > > preventing any change to the SMI bits. > > > > Check e.g. the intel's io-controller-hub-10-family-datasheet.pdf manual > > This SMI_LOCK bit sounds like it may be at least part of our problem. Our > hardware contains a Intel Corporation Sunrise Point-H LPC Controller > (8086:a149), and by reading 100-series-chipset-datasheet-vol-2.pdf we > find some information on SMI_LOCK in the GEN_PMCON_A register (offset > 0xA0). Is there an easy way to read the contents of this register so we can > check whether this bit is indeed set? > > >> When we try to use the setsmi utility found in > >> /usr/src/rtai-5.0.1/base/arch/x86/calibration, we see the following: > >> > >> insmod: ERROR: could not insert module /usr/realtime/modules/rtai_smi.ko: > Invalid parameters > >> setsmi: rmmod /usr/realtime/modules/rtai_smi.ko failed > > > > Have you an idea of what is the wrong parameter? > > The problem was that our controller was not defined in smi-module.c, so we > were getting the following error in dmesg: > [ 179.583365] RTAI: Intel chipset not found. > > I have edited smi-module.c as follows to include our device (0x8086, > 0xa149), which prevented this error. > > static struct pci_device_id hal_smi_pci_tbl[] = { > { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa149) }, > { 0, }, > }; > > However as with the smispv utility there is no noticeable change, either > to the latencies, or to the apparent bits set as read from the smispv > utility. Unfortunately I haven't had time to look further into the problem. > > Also, regarding Vivian's previous email, we did try adding > `lapic=notscdeadline` to the kernel parameters based on an idea another > colleague had, however this didn't improve our situation, so please ignore > this point. > > Sam > > On 18 October 2017 at 09:28, Vivian McPhail <[email protected]< > mailto:[email protected]>> wrote: > Hi, > > We have added `lapic=notscdeadline` to the kernel command line. > > When attempting to run the `calibrate --help` program we get: > > sc-qi4 /usr/realtime/calibration # ./calibrate --help > Segmentation fault (core dumped) > > sc-qi4 /usr/realtime/calibration # dmesg > ... > [ 3847.540947] calibrate[4426]: segfault at 0 ip 00007f1eb14e2ec6 sp > 00007ffc486cba90 error 4 in libc-2.23.so<http://libc-2.23.so > >[7f1eb14ac000+190000] > > setsmi now runs and enables SMI workaround but our latencies are still > high: > > RTAI Testsuite - KERNEL space latency test (output data in nanoseconds) > > *** latency verification tool with RTAI own real time kernel tasks *** > *** period = 100000 (ns), avrgtime = 1 (s) *** > > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > RTD| -1927| -1927| -1250| 150816| 150816| 58 > RTD| -1927| -1927| -1189| 172686| 172686| 93 > RTD| -1927| -1927| -1204| 146525| 172686| 122 > RTD| -1926| -1927| -1202| 149990| 172686| 154 > RTD| -1926| -1927| -1214| 150550| 172686| 184 > RTD| -1927| -1927| -1170| 151197| 172686| 220 > RTD| -1927| -1927| -1224| 148891| 172686| 245 > RTD| -1927| -1927| -1217| 149949| 172686| 275 > RTD| -1926| -1927| -1194| 150291| 172686| 309 > RTD| -1926| -1927| -1182| 144404| 172686| 334 > RTD| -1927| -1927| -1124| 153671| 172686| 366 > RTD| -1927| -1927| -1157| 151099| 172686| 395 > RTD| -1927| -1927| -1142| 157766| 172686| 428 > RTD| -1927| -1927| -1175| 154312| 172686| 456 > RTD| -1927| -1927| -1154| 150821| 172686| 486 > RTD| -1926| -1927| -1166| 149945| 172686| 516 > RTD| -1927| -1927| -1147| 174795| 174795| 547 > RTD| -1927| -1927| -1140| 189067| 189067| 580 > RTD| -1927| -1927| -1150| 150254| 189067| 614 > RTD| -1927| -1927| -1201| 162253| 189067| 646 > RTD| -1927| -1927| -1144| 157433| 189067| 681 > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > RTD| -1927| -1927| -1199| 147787| 189067| 708 > > Vivian > > On 6 October 2017 at 21:23, Paolo Mantegazza <[email protected]< > mailto:[email protected]>> wrote: > On 10/06/2017 03:32 AM, Vivian McPhail wrote: > > Hi list, > > > > Here is some more information: > > > > An i3-6xxx was the cpu that first lead to the calibration problem. > Which, in fact, was not a calibration problem but a memory protection that > did not exist on previous generations, i.e for about more than 10 years of > RTAI existence. > >In any case, once the problem was solved, through the contribution > release you mention, to my knowledge, the friendly user that helped me in > the fix has not signaled any latency problem. > >That said, can you tell us a few things more?. > > > We are using rtai-5.0.1 contributed version with linux kernel 4.4.43 > Linux sc-qi4 4.4.43-rtaicontrib-5.0.1 #23 SMP PREEMPT Fri Oct 6 12:26:42 > NZDT 2017 x86_64 Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz GenuineIntel > GNU/Linux > Motherboard SuperMicro MBD-X11SSA-F-0 > > >For example, what are the latency values you have, found with what test? > > > Using RTAI kernel latency test, found at /usr/realtime/testsuite/kern/latency/run. > We find similar results for userspace test > > RTAI Testsuite - KERNEL space latency test (output data in nanoseconds) > > *** latency verification tool with RTAI own real time kernel tasks *** > *** period = 100000 (ns), avrgtime = 1 (s) *** > > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > RTD| -2070| -2070| -1206| 151372| 151372| 64 > RTD| -2107| -2107| -1207| 150895| 151372| 94 > RTD| -2061| -2107| -1202| 151300| 151372| 127 > RTD| -2073| -2107| -1212| 166180| 166180| 157 > RTD| -2082| -2107| -1185| 153918| 166180| 189 > RTD| -2132| -2132| -1195| 151415| 166180| 221 > RTD| -2043| -2132| -1216| 149363| 166180| 251 > RTD| -2057| -2132| -1201| 151410| 166180| 283 > RTD| -2042| -2132| -1201| 153008| 166180| 315 > RTD| -2071| -2132| -1194| 157882| 166180| 346 > RTD| -2075| -2132| -1205| 152579| 166180| 379 > RTD| -2088| -2132| -1208| 153254| 166180| 409 > RTD| -2110| -2132| -1205| 151180| 166180| 441 > RTD| -2086| -2132| -1202| 150438| 166180| 473 > RTD| -2064| -2132| -1190| 151402| 166180| 507 > RTD| -2076| -2132| -1199| 150358| 166180| 538 > RTD| -2079| -2132| -1215| 159729| 166180| 568 > RTD| -2048| -2132| -1189| 154771| 166180| 602 > RTD| -2060| -2132| -1205| 150056| 166180| 633 > RTD| -2084| -2132| -1198| 150029| 166180| 666 > RTD| -2075| -2132| -1207| 150878| 166180| 698 > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > RTD| -2076| -2132| -1212| 151351| 166180| 725 > RTD| -2074| -2132| -1200| 156473| 166180| 755 > RTD| -2081| -2132| -1218| 155487| 166180| 784 > RTD| -2077| -2132| -1205| 150254| 166180| 816 > RTD| -2072| -2132| -1205| 146909| 166180| 848 > RTD| -2084| -2132| -1196| 149810| 166180| 882 > RTD| -2062| -2132| -1197| 149134| 166180| 915 > RTD| -2074| -2132| -1223| 148643| 166180| 943 > RTD| -2075| -2132| -1210| 150753| 166180| 976 > RTD| -2064| -2132| -1138| 176904| 176904| 1009 > RTD| -2055| -2132| -1165| 175403| 176904| 1036 > RTD| -2058| -2132| -1142| 156620| 176904| 1066 > RTD| -2061| -2132| -1155| 151707| 176904| 1095 > RTD| -2086| -2132| -1129| 149400| 176904| 1130 > RTD| -2174| -2174| -1135| 150516| 176904| 1164 > RTD| -2139| -2174| -1139| 154105| 176904| 1196 > RTD| -2073| -2174| -1161| 160744| 176904| 1222 > RTD| -2073| -2174| -1151| 150689| 176904| 1252 > RTD| -2179| -2179| -1153| 152630| 176904| 1283 > RTD| -2053| -2179| -1157| 149657| 176904| 1314 > RTD| -2080| -2179| -1143| 150982| 176904| 1346 > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns > RTD| -2070| -2179| -1029| 1246807| 1246807| 1391 > RTD| -2061| -2179| -1069| 948621| 1246807| 1431 > RTD| -2064| -2179| -1084| 650913| 1246807| 1469 > RTD| -2103| -2179| -1114| 359612| 1246807| 1502 > RTD| -2067| -2179| -1146| 161471| 1246807| 1535 > RTD| -2097| -2179| -1166| 150333| 1246807| 1566 > RTD| -2042| -2179| -1165| 151437| 1246807| 1597 > RTD| -2125| -2179| -1185| 148318| 1246807| 1626 > RTD| -2094| -2179| -1168| 150301| 1246807| 1656 > RTD| -2068| -2179| -1150| 150114| 1246807| 1689 > RTD| -2070| -2179| -1159| 150924| 1246807| 1720 > RTD| -2057| -2179| -1167| 156776| 1246807| 1751 > RTD| -2048| -2179| -1153| 155397| 1246807| 1783 > RTD| -2092| -2179| -1189| 150488| 1246807| 1812 > RTD| -2087| -2179| -1144| 150824| 1246807| 1846 > RTD| -2087| -2179| -1163| 151215| 1246807| 1877 > RTD| -2062| -2179| -1149| 151667| 1246807| 1909 > RTD| -2056| -2179| -1148| 155952| 1246807| 1943 > RTD| -2063| -2179| -1144| 150308| 1246807| 1977 > RTD| -2068| -2179| -1160| 157204| 1246807| 2009 > RTD| -2073| -2179| -1165| 151223| 1246807| 2039 > > > >Moreover are you sure they are due to SMI and not to other Linux config > params (see the suggestions below)? > > > We are not 100% sure on what the issue is, however we have used the > command `rdmsr 0x34`, which returns the count of SMI since boot, and we > observe that this register increases by ~60 counts every second (see, e.g. > https://xenomai.org/2014/06/dealing-with-x86-smi-troubles/) > > We believe that our issues are not related to kernel configuration, > however we are not experts in this domain so we may have made a mistake > somewhere... Here is our current kernel configuration. We have tried many > other possibilities, such as disabling legacy USB, and also video drivers > with no difference to the latency. Note that we have disabled almost all > bios options as well. > > Have you diagnosed SMI with the graphic tool found in RTAI? > > > We have tried using the smispv utility, however it seems to have no effect. > > Please be more specific. What did you try to do, what were you expecting, > and what happened, exactly? > > For example, if you tried to disable some SMI bit, and after issuing the > command the bit is still there, then it is likely that the SMI_LOCK is set, > preventing any change to the SMI bits. > > Check e.g. the intel's io-controller-hub-10-family-datasheet.pdf manual > > When we try to use the setsmi utility found in > /usr/src/rtai-5.0.1/base/arch/x86/calibration, we see the following: > > insmod: ERROR: could not insert module /usr/realtime/modules/rtai_smi.ko: > Invalid parameters > setsmi: rmmod /usr/realtime/modules/rtai_smi.ko failed > > Have you an idea of what is the wrong parameter? > > Paolo. > > Paolo, > > Thanks, > > > > Vivian > > > On 6 October 2017 at 11:21, Paolo Mantegazza <[email protected]< > mailto:[email protected]>> wrote: > An i3-6xxx was the cpu that first lead to the calibration problem. Which, > in fact, was not a calibration problem but a memory protection that did not > exist on previous generations, i.e for about more than 10 years of RTAI > existence. > In any case, once the problem was solved, through the contribution release > you mention, to my knowledge, the friendly user that helped me in the fix > has not signaled any latency problem. > That said, can you tell us a few things more?. For example, what are the > latency values you have, found with what test? Moreover are you sure they > are due to SMI and not to other Linux config params (see the suggestions > below)? Have you diagnosed SMI with the graphic tool found in RTAI? > > Paolo, > > REMARKS-SUGGESTIONS ABOUT CONFIGURING LINUX AND RTAI > > < LINUX kernel related > > - Under SMP set the number of CPUs equal to the real ones and have it > matched in RTAI, > no hyperthreading intended (see below) > - Some peripherals, e.g. video cards, may stall CPUs attempting to access > IO space. > Verify "what ifs" related to graphic acceleration, likely better if > disabled. > Consider also if X term usage is really needed. If possible avoid it, > especially > in production work. > - LINUX use of DMA can add latency, especially when it is supported in > burst mode. > - Cached memory disruption can add significant latencies, as experienced > in a > controller, after a far jump in the code and data, till the cache > becomes hot > again. > - Power management, see CONFIG_CPU_FREQ and CONFIG_CPU_IDLE below; on > portables > battery management too. > - Recent Intel SpeedStepping and Boosting. > - Disable AUDITSYSCALLS. > - Disable CPU_FREQ. > - Disable CPU_IDLE and INTEL_IDLE, or boot with "intel_idle.max_cstate=0". > If you > want to be sure to have a never sleeping CPU execute, at the lowest > priority, > your own, per cpu, idle task, i.e. just doing "while(1);". > - Disable APM and ACPI_Processor, but not everything related to power > management. > Take also into account that without ACPI enabled you might not see more > than > a single CPU. > - Do not enable IPIPE legacy support. As a safety measure against such a > choice, > RTAI build is inhibited at the making of rtai_hal.ko. > - Do not disable USB, but just any legacy support, possibly in the BIOS > also. Once > upon a time USB was a source of high RTAI latencies. Now that should > happen with > just legacy support enabled. > - Try to configure the CPU type to be as close as possible to the one you > have. > - If unsure on the CPU to choose, care of setting one featuring a Time > Stamp Clock > (TSC), which means no 486 and "false" i586, as generic INTEL i586 > compatibles > often do not have a TSC, while true INTEL ones do have it. > - If you are using a UniProcessor (UP) compile RTAI against a UP > configured kernel. > In fact RTAI compiled for SMP may not work when used on a UP machine. An > issue > to be fixed, sooner or later. In any case having everything UP for UP is > always > the more efficient solution. > - If it is of no interest to you, disable any kernel debug support. > Generally speaking, > most RTAI users are not expected to debug the kernel, so it is suggested > to always do > so for production work. In any case, even if there should be no trouble > in keeping it, > except for some overhead more and an increase of latency here and there, > it may happen > that tracing could affect RTAI parts having some commonality with the > kernel, e.g. > though trace points missing symbols. If that happens you should either > disable, at > least, the trace option in "Kernel hacking", or add the exporting of the > related > symbols, which appear missing at insmoding any RTAI module. > - If you witness a stack protector crash, disable stack protector support, > at the > bottom of the kernel config General Setup. There are 3 choices, "None" > will work > with RTAI for sure. It is possible that the "Regular" one could also be > OK, while > "Strong" will fail, always. > > > < RTAI related > > - Even if RTAI can work with hyperthreading enabled, such an option is > deprecated > as a possible cause of latency; in any case try and verify if it is > acceptable, > with your hardware and for your applications. > - Any initialization of the device drivers, or anything related to the > hardware, > may lead to high latencies, e.g., but not always. doing "startx &" while > a real > time application is running. Once it is started there should be no major > problems. > If the truoble persists and you really need X, concurrently with you > RTAI tasks, try > disabling hardware graphic acceleration. The best latencies usually > come with no > graphic application running. > - A sizable part of the latency you see in RTAI hard timed programs can > mature as > an interrupt latency, little can be done to avoid that. Recall that, for > shared pieces > of hardware, e.g APIC, LINUX is left with the capability of using a few > hard interrupts > disable/enable. Moreover the processing of LINUX interrupts, during hard > real time > RTAI activities, are delayed but must be pended to be processed later on > anyhow. > A thing which requires keeping interrupts disabled for a, hopefully > short, while. > - If SMI is enabled and latencies are high, often appearing periodic also, > use the > RTAI tools to monitor and, possibly, fix it. > > > ________________________________________ > From: Rtai [[email protected]<mailto:[email protected]>] on > behalf of Vivian McPhail [[email protected]<mailto: > [email protected]>] > Sent: Thursday, October 5, 2017 7:14 PM > To: [email protected]<mailto:[email protected]> > Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to handle > kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza) > > Hi List, > > With respect to the below problem. We have used the CONTRIB branch which > Paolo mentioned (I had thought he pointed to the same tarball as the > release). > > We are getting unacceptably high latencies with an i3 6100 7th generation > CPU and are wondering whether we should downgrade to a CPU that doesn't > have SMI. > > Has anyone else encountered latency issues like this? > > We can provide more information if required. > > Thanks, > > Vivian > > > Message: 1 > Date: Tue, 19 Sep 2017 17:42:43 +0200 > From: Paolo Mantegazza <[email protected]<mailto: > [email protected]><mailto:[email protected]<mailto:pa > [email protected]>>> > To: Rtai <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto: > [email protected]>>> > Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to > handle kernel paging request at 00007ffe78e450f0 > Message-ID: <[email protected]<mailto: > [email protected]><mailto:3acde249-5db1-d188- > [email protected]<mailto:3acde249-5db1-d188- > [email protected]>>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Ciao, > please, beware of trolls. They are amusing, at times, but often they do > not know what they are talking about. > > The problem of calibration faults has been solved by the end of > May-2017, thanks to a cooperation with Josef (A?falg). > The fix is > in"https://www.rtai.org/userfiles/downloads/RTAICONTRIB/rtai-5.0.1.tar.bz2 > ", > to be 5.1, when we'll get a new RTAI repository, hopefully soon. > > If you want to know more about it have a look at the following May-2017 > threads on the RTAI mailing list: > https://mail.rtai.org/pipermail/rtai/2017-May/027461.html > https://mail.rtai.org/pipermail/rtai/2017-May/027502.html > > Paolo > > On 09/19/2017 05:01 AM, Alec Ari wrote: > > I'm not sure why Paolo treats his RTAI 5.0.1 release like gold. It's got > tons of issues, everything from hard-locks, overruns, and extreme latency > spikes. Not sure where he got the idea that it's so brilliant and to always > grab the latest versions of his (ripped-off) code. RTAI 4.0.1 which I've > based my stable tree of off has absolutely no issues. > > > > Myself and many others (LinuxCNC) have been using this tree for the past > few years and it's fine: > > > > > > https://github.com/NTULINUX/RTAI > > > > Don't use the drop-legacy branch, it's not ready and I'm still ironing > out all the bugs that Paolo introduced into the scheduler and > self-calibration. The old calibration code worked so much better, literally > "just works." RTAI 5 is not ready for production and is not stable by any > means. I highly suggest avoiding anything above 5.0 until there's some more > confirmed cases of it working in upcoming releases. > > > > I've been doing kernel development for over a decade and this is not > user-error. > > _______________________________________________ > > Rtai mailing list > > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto: > [email protected]>> > > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://mail.rtai.org/pipermail/rtai/attachments/ > 20170919/5adf2dc1/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 19 Sep 2017 22:04:56 +0000 (UTC) > From: Alec Ari <[email protected]<mailto:[email protected]><mailto: > [email protected]<mailto:[email protected]>>> > To: Rtai <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto: > [email protected]>>> > Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to > handle kernel paging request at 00007ffe78e450f0 > Message-ID: <[email protected]<mailto: > [email protected]><mailto: > [email protected]<mailto:1337839588.5480447. > [email protected]>>> > Content-Type: text/plain; charset=UTF-8 > > I'm lost for words, Paolo actually replied to something I said. > > > So use the RTAI 5.0.1 tarball from the users repository instead of the one > in the releases, you say? The one with "ifdef CONFIG_RTAI_USE_STACK_ARGS" > scattered about? You do realize that CONFIG_RTAI_USE_STACK_ARGS is an > undefined config option that has no meaning, not in Kconfig or > configure.in<http://configure.in><http://configure.in> anywhere? > > > If you think I'm trolling, you should look at yourself. Stealing my code > and writing the sloppiest crap to almost purposely make it confusing. > > Like what the hell is this, seriously: > > { if (ipipe_notifier_enabled_p(current)) return ((int (*)(unsigned long, > void *))ipipe_root_domain->legacy.handlers[exception])(exception, regs); > } { > > I've said it before and I'll say it again; your work really belongs in the > obfuscated C code contest. This project would be dead without me and > ShabbyX, but you're too arrogant to give anyone else credit. Everything > that hasn't been done by myself or Shahbaz doesn't work. He left the > project and moved on to other things but I remember the countless hours we > spent into revamping the entire tree. You tell me who the troll is, or just > go hide off in your corner again like you always do. > > > Alec Ari > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Rtai mailing list > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto: > [email protected]>> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > ------------------------------ > > End of Rtai Digest, Vol 117, Issue 8 > ************************************ > > > > -- > Vivian McPhail > PhD Candidate > Department of Physics > University of Auckland > > > > -- > Vivian McPhail > PhD Candidate > Department of Physics > University of Auckland > > > > > -- > Vivian McPhail > PhD Candidate > Department of Physics > University of Auckland > > > > -- > Vivian McPhail > PhD Candidate > Department of Physics > University of Auckland > > > _______________________________________________ > Rtai mailing list > [email protected]<mailto:[email protected]> > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > > > > > -- > Vivian McPhail > PhD Candidate > Department of Physics > University of Auckland > -- Vivian McPhail PhD Candidate Department of Physics University of Auckland _______________________________________________ Rtai mailing list [email protected] https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai