Re: Problems with a new Ryzen-based PC

Well, I tried the 5.1-test1, and it seems to fix that problem on rtai_sched insmod.

It created a new problem where my RTAI kernel module portion of my software #include's <rtai_posix.h>, which made it fail to compile on rt_ptimer_create not matching its prototype in rtai_tasklets.h.

I was able to compile my code without #include'ing <rtai_posix.h> to clear that error.

Now I'm having another issue that appeared before when I insmod my kernel module, which uses comedi calls.  It seems to still be rtai_sched that blows up.

Crash attached.

-Duane

From: Paolo Mantegazza [mailto:[email protected]]
Sent: Thursday, December 21, 2017 9:26 AM
To: Duane AW. Jeffery <[email protected]>; [email protected]
Subject: Re: [Rtai] 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]<mailto:[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