problem about the smispv.c
Tom <[email protected]> Fri, 20 Oct 2017 15:29:46 +0800 (CST)
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <[email protected]> |
hi list,
I got the contribution version tarball of rtai-5.0.1, and in smispv.c , line : 347
when run in virtualbox, it crashed. because there is no smi-enabled device. that is, find_smi_device returns 0.
so I think there should be a null pointer guard.
dev = find_smi_device(pacc);
if (!dev)
{
return;
}
smi_en_addr[0] = get_smi_en_addr(dev, 0);
smi_en_addr[1] = get_smi_en_addr(dev, 1);
tom@shanghai
At 2017-10-19 23:36:17, [email protected] wrote:
>Send Rtai mailing list submissions to
> [email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>or, via email, send a message with subject or body 'help' to
> [email protected]
>
>You can reach the person managing the list at
> [email protected]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Rtai digest..."
>
>
>Today's Topics:
>
> 1. Re: RTAI 5.0.1 calibrate program: BUG: unable to handle
> kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
> (Paolo Mantegazza)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 19 Oct 2017 11:02:39 +0200
>From: Paolo Mantegazza <[email protected]>
>To: Samuel R <[email protected]>
>Cc: Vivian McPhail <[email protected]>, "[email protected]"
> <[email protected]>
>Subject: Re: [Rtai] RTAI 5.0.1 calibrate program: BUG: unable to
> handle kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>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/
>>>> <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:[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:[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
>>>> <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/027461.html>
>>>> https://mail.rtai.org/pipermail/rtai/2017-May/027502.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
>>>> <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
>>>> <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
>>>> <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:[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
>>>> <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
>>>> <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
>> <https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai>
>>
>>
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://mail.rtai.org/pipermail/rtai/attachments/20171019/8d3460e2/attachment.html>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Rtai mailing list
>[email protected]
>https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
>------------------------------
>
>End of Rtai Digest, Vol 118, Issue 15
>*************************************
>
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai