Re: RTAI 5.0.1 calibrate program: BUG: unable to handle kernel paging request at 00007ffe78e450f0 (Paolo Mantegazza)
Samuel R <[email protected]> Thu, 19 Oct 2017 15:01:17 +1300
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <CAH4NLT=8Vgb2-BNTwOyX=8-Qs0bd5tYL0e03rwNJi+QKkDUfJA@mail.gmail.com> |
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" 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]>
> 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[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]>
>> 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]
>>> > 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]] on behalf of Vivian McPhail [
>>>> [email protected]]
>>>> Sent: Thursday, October 5, 2017 7:14 PM
>>>> To: [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]>>
>>>> To: Rtai <[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]>>
>>>> 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]>
>>>> > 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/5a
>>>> df2dc1/attachment-0001.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Tue, 19 Sep 2017 22:04:56 +0000 (UTC)
>>>> From: Alec Ari <[email protected]<mailto:[email protected]>>
>>>> To: Rtai <[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]>>
>>>> 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> 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]>
>>>> 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]
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai