Re: Problems with a new Ryzen-based PC

On 12/21/2017 03:18 PM, Duane AW. Jeffery wrote:
>
> I am indeed not.  I’m running probably the RTAI 5.0-test2 package – 
> Its whatever RTAI was at when 4.1.18 was added to HAL patch support.  
> Generally speaking I get the system working and then don’t update 
> anything after that until forced to.
>
> Should I try RTAI 5.1-test1?  Is there a fix related to rt_lxrt_invoke 
> in 5.1-test1?
>
I expect so. Here is an explanation I gave to somebody else:

What I pointed out to the list is the problem of the argument passing from user to kernel space, where what has worked unchanged for almost 2 decades, not only on x86 archs, failed to run on recent Ix-6xxx INTEL. Here it is how it is explained in the configuration help:
config RTAI_USE_STACK_ARGS
         bool "Keep using RTAI way for user-kernel space on stack args exchange."
         default n
         help
         When it is sure that RTAI syscalls args, to be copied between user-kernel
         space, are on the stack, RTAI uses kernel space memcopy, instead of the
         various canonical copy from-to user. Such a scheme, quite simple and
         effective, has worked for almost two decades without any glitch.
         Unfortunately, recent CPUs, likely from Ix-6xxx onward, segfault with it,
         forcing RTAI to comply with the canonical way.
         The related trouble can be easily spotted at the very first rtai_sched.ko
         usage, i.e. when the very first latency calibration is carried out (see
         the related parameter helps), when the core dump summary, as read with dmesg,
         shows a segfault at lxrt_intercept_syscall.
         Nonetheless, such a way can still be a useful choice and may not cause any
         trouble with recent ATOMs and CELERONs.
         Thus, this parameter, defaulting to a safer no, lets the user have a choice
         anyhow.
The problem may have surfaced some time before but I did not had a hardware to verify it and remained unexplained to me till a user, after upgrading his hardware to an I5-6500 and seeing the failure of his RTAI application, which run unpaired for quite a bit of time, installed the disk of the running hardware onto the new one and saw it failed to work. Fortunately he was willing to help and we fixed the problem in a short time, As I said, I could not see it because I was using a not so new hardware release. Now I've one and I verified first hand that RTAI-5.1 works on it.


The failure was of the type you mentioned, albeit on an Intel cpu. Yours 
is AMD, but I dare hoping the problem could be the same.

Paolo.

> -Duane
>
> *From:*Rtai [mailto:[email protected]] *On Behalf Of *Paolo Mantegazza
> *Sent:* Tuesday, December 19, 2017 5:36 AM
> *To:* [email protected]
> *Subject:* Re: [Rtai] Problems with a new Ryzen-based PC
>
> May I bet that you are not using the latest rtai-5.1-test1? My bet is 
> based on the fact that it fail at rt_lxrt_invoke.
>
> Paolo.
>
> On 12/18/2017 09:13 PM, Duane AW. Jeffery wrote:
>
>     Hi all,
>
>     It’s been a while since I wrote to the list, but I’m back with a
>     new problem.  Once again the hardware we use has reached
>     end-of-life, and I’m left to try and get our RTAI system working
>     on some new modern hardware.
>
>     New system:
>
>     AMD Ryzen 3 1200
>
>     Gigabyte A320M-HD2
>
>     1TB WD Blue
>
>     MSI Radeon HD 6450
>
>     Installing our usual software (Linux 4.1.18, RTAI… 5? I think) on
>     it mostly works, except that our RT-enabled programs freeze the
>     system (mouse and keyboard unresponsive, display frozen) on
>     attempting to start them, and I notice during bootup where we
>     insmod the various RTAI modules that on insmod of rtai_sched, I
>     get a kernel bug:
>
>     BUG: unable to handle kernel paging request at 00007ffde855f1e0
>
>     Attached is a photo of the full kernel bug readout.
>
>     I tried recompiling the kernel, RTAI, and our software on the new
>     machine to no avail.   Manually running the latency tests in the
>     testsuite appears to work and give reasonable latencies.
>
>     Anybody have any idea where things are falling down?
>
>     -Duane Jeffery
>
>
>
>
>     _______________________________________________
>
>     Rtai mailing list
>
>     [email protected] <mailto:[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