see thread at https://forum.linuxcnc.org/forum/39-pncconf/30751-problems-with-prempt-rt-kernel-error-and-7i76e?limitstart=0
> Using PNCconf: I can’t use the test / tune functions for any axis motor or the spindle. I get the following error when trying to tune either axis stepper drive from within PNCconf:
>
> File “/usr/bin/pncconf”, Line 1630, in checkforrt
> eLif Hal.isrt and not hal.kernelversion == actual_kernel:
> AttributeError: ‘module” object has no attribute ‘kernel_version’
I did not test this for myself, but I think it’s an accurate bug report that will affect any uspace user.
评论 (5)
#2 – c-morley 于 2016-09-07
I will try to look at it this weekend
Chris
—
From: Jeff Epler notifications@github.com
Sent: September 6, 2016 4:07 PM
To: LinuxCNC/linuxcnc
Cc: c-morley; Mention
Subject: Re: [LinuxCNC/linuxcnc] Reportedly, pncconf does not work on preempt-rt because hal.kernel_version does not exist (#159)
@c-morleyhttps://github.com/c-morley can you take a look at this?
##
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/LinuxCNC/linuxcnc/issues/159#issuecomment-245001464, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHBrNTRn0qNnip4vcaVmbbTGgV8YofaBks5qnY-tgaJpZM4J1WQn.
#3 – c-morley 于 2016-09-20
I did not get time to look into this, but looking at the error message it seems that the python module linuxcnc, with preemptrt doesn’t have kernalversion as an attribute:
AttributeError: ‘module” object has no attribute ‘kernel_version’
I assume this might be because there is no hard requirement for kernel version?
Maybe we could just have it report the current kernel version so the test passes?
Chris M
#4 – jepler 于 2016-09-20
Yes, uspace realtime is not tied to one specific kernel, so that is why I coded it so that hal.kernelversion is not defined unless RTAPIKERNEL_VERSION is (see commit 2c5ed60 “let python know the required kernel version”):
#ifdef RTAPIKERNELVERSION
PyModuleAddStringConstant(m, "kernelversion", RTAPIKERNELVERSION);
#endif
In 2.7, uspace is realtime with “any RT-Preempt kernel”. In 2.8, this will depend on compile-time configuration details AND runtime installed packages besides the kernel. For instance, I could write something like this:
#ifdef RTAPIKERNELVERSION
PyModuleAddStringConstant(m, "kernelversion", RTAPIKERNELVERSION);
#else
if(rtapiisrealtime())
{
uname(&uts);
PyModuleAddStringConstant(m, "kernelversion", uts.release);
}
else
{
PyModuleAddStringConstant(m, "kernelversion",
"Any RT-Preempt kernel"
#ifdef USPACE_RTAI
" or any RTAI kernel with LXRT support"
#endif
#ifdef USPACE_XENOMAI
" or any Xenomai kernel with posix skin support"
);
}
#endif
pncconf and stepconf are the two in-tree users of hal.kernelversion so I am open to doing whatever makes more sense: changing those program so they don’t query hal.kernelversion except when rtapiiskernelspace(), or changing our promise so that hal.kernelversion is always defined to something, if we can define what that something_ should be.
#5 – c-morley 于 2016-09-21
I think we should make hal.kernal_version always defined to something.
If it makes sense in preempt to make it display the current kernel ( because for instance the current kernel will always work) then that seems fine.
Pncconf and stepconf only really want to know if using the HAL system is valid at the time of test invocation and give a hint to the user if not. With kernal RTAI the kernel had to be right or the system failed badly.
We could add a HALSYSTEMAVAILABLE test in the hal module that could test in whatever way is required (now or in the future) for what ever realtime system is currently being used.
This would seem to future proof the problem alot and leave the problem in one place.
Chris M
#1 – jepler 于 2016-09-06
@c-morley can you take a look at this?