#linuxcnc-devel Logs

Apr 26 2020

07:01 AM rene_dev_: Hazzy-m around?
07:06 AM andypugh: load_entry_point('Yapps2==2.2.1', 'console_scripts', 'yapps2')()
07:06 AM andypugh: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in load_entry_point
07:06 AM andypugh: return get_distribution(dist).load_entry_point(group, name)
07:06 AM andypugh: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2793, in load_entry_point
07:06 AM andypugh: return ep.load()
07:06 AM andypugh: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2411, in load
07:06 AM andypugh: return self.resolve()
07:06 AM andypugh: File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2417, in resolve
07:06 AM andypugh: module = __import__(self.module_name, fromlist=['__name__'], level=0)
07:06 AM andypugh: ImportError: bad magic number in 'yapps': b'\x03\xf3\r\n'
07:07 AM andypugh: I see Python3 in there, which is perhaps a surprise.
07:09 AM andypugh: Or maybe not, yapps2 is probably already converted.
07:18 AM andypugh: Seems to have been fixed by deleting all my .pyc files.
07:44 AM rene_dev_: andypugh I have news. you want the good or the bad news?
07:46 AM rene_dev_: make clean doesnt clean everything.
07:49 AM rmu|w: is that the good or the bad new
07:49 AM rmu|w: s
07:58 AM rene_dev_: neither...
07:59 AM rene_dev_: the problem is, gtk2 with python3 is a bit broken and unsupported
07:59 AM rene_dev_: so I started porting everything to gtk3
07:59 AM rene_dev_: and I hit a gtk bug, I already reported 2 years ago
08:00 AM rmu|w: good luck with that. :(
08:01 AM rmu|w: do you have a link to that bug=
08:01 AM rmu|w: ?
08:02 AM rene_dev_: https://gitlab.gnome.org/GNOME/gtk/issues/1270
08:02 AM rene_dev_: https://gitlab.gnome.org/GNOME/gtk/issues/64
08:02 AM rene_dev_: https://gitlab.gnome.org/GNOME/gtk/-/issues/49
08:02 AM rene_dev_: https://gitlab.freedesktop.org/mesa/mesa/issues/113
08:37 AM andypugh: It looks like the bugs got closed because you were not answering his questions?
08:46 AM rene_dev_: I stopped looking into it back then, as hazzy switched to qt5
08:46 AM rene_dev_: looks like it’s fixed in gtk4
08:46 AM rene_dev_: but gtk4 works entirely different
08:49 AM rene_dev_: But now I have ported gscreen to gtk3
09:00 AM rene_dev_: andypugh can you install gtk-3-examples
09:00 AM rene_dev_: and run gtk3-demo --run=glarea
09:00 AM rene_dev_: see if you have the problem
09:09 AM rmu|w: FWIW, it works on ubuntu 1804
09:22 AM andypugh: Doesn’t work through X-forwarding :-)
09:25 AM sync: it also works for me but there must be some underlying issue
09:25 AM sync: there is a workaround but it'll be very ugly
09:25 AM andypugh: It largely works on the native display, but I did see the X slider become a black box when I moved the window
09:28 AM andypugh: It’s very flaky on my Debian Stretch VM
09:32 AM rmu|w: it does not work as is on the raspberry pi 4, complains about unsupported shader. gl vs. gl es issue
09:34 AM sync: it should work on the rpi4
09:34 AM sync: but interestingly when I trace the api calls it seems to use a different pipeline in rene_dev_s vm
09:36 AM rene_dev_: andypugh rmu|w feel free to add this to the gtk issue :D you do need to move the window and move sliders to see the issue
09:54 AM rmu|w: the whole opengl business regarding which library gets loaded/used is a complete mess
10:27 AM andypugh: Linux contains many such messes. The deeper you dig the more precarious the whole thing seems
10:28 AM hazzy-m: rene_dev_: hello
10:29 AM rmu|w: andypugh: this opengl situation is not limited to linux
10:30 AM rene_dev_: hazzy-m Im back at the old gtkglarea issue :D
10:36 AM andypugh: seb_kuzminsky: Are you there?
10:37 AM andypugh: I am confused, I just made it through 1000 iterations of your test, but I don’t know what changed…
10:39 AM andypugh: … And now it just failed at 265. Bother!
10:39 AM andypugh: (I had actually changed something in RTAI, just not anything that seemed to be relevant)
10:39 AM hazzy-m: rene_dev_: uh oh, and I'm sure it's not gotten any easier to solve ...
10:40 AM hazzy-m: TurBoss was reminding me about that disaster last night actually
11:12 AM rmu|w: on the pi4, it depends on the opengl driver selected in raspi-config, with the "legacy", it says shader error. with the other driver, the demo starts, but window becomes black as soon as you move it or do something with the sliders.
11:42 AM skunkworks: I wonder how hard it would be for Eoffset to apply backlash comp...
12:24 PM seb_kuzminsky: andypugh: i'm popping my head in here for a little bit, what's up?
12:25 PM andypugh: I think we already went through it on email.
12:25 PM seb_kuzminsky: ok cool
12:26 PM andypugh: Well, except the latest is 2x rruns through to 1000, then the next died at 64.
12:26 PM andypugh: I am short of ideas on how to get to the bottom of this.
12:26 PM seb_kuzminsky: that's not unusual behavior for race condition/memory corruption type bugs
12:26 PM seb_kuzminsky: that's where i got to too, with rtai 5/linux 4.4/jessie :-(
12:27 PM andypugh: Do you understand what code this runs: https://github.com/NTULINUX/RTAI/blob/master/include/rtai_shm.h#L198
12:27 PM seb_kuzminsky: the next step for me back then (if i hadn't run out of energy) would have been to try to pare down the smallest linuxcnc test case to something that can build without linuxcnc/hal/rtapi, just pure C
12:28 PM seb_kuzminsky: ie something that can be shared with the RTAI upstream without forcing them to have to wade through thousands of lines of linuxcnc stuff, and learn our build system and everything
12:28 PM rene_dev_: andypugh did you try running scan-build?
12:28 PM andypugh: No. What is scan-build?
12:29 PM rene_dev_: https://clang-analyzer.llvm.org/
12:29 PM seb_kuzminsky: scan-build is cool
12:29 PM seb_kuzminsky: we use it in the buildbot
12:29 PM seb_kuzminsky: i don't know if it is capable of building/analyzing the whole kernel, or if i'd be able to make sense of its output if it did
12:31 PM andypugh: Well, initially just looking at RTAI would be a start
12:31 PM andypugh: But the RTAI code is very wierd, as the link above shows.
12:32 PM seb_kuzminsky: LXRT is one of the RTAI modes?
12:33 PM seb_kuzminsky: ah: "LXRT is a module that allows you to use all the services made available by RTAI and its schedulers in user space, both for soft and hard real time."
12:34 PM seb_kuzminsky: i believe we do not use that mode
12:36 PM andypugh: seb_kuzminsky: More the RTAI_PROTO macro.
12:36 PM andypugh: Because the C code in _rt_shm_alloc seems to run.
12:39 PM seb_kuzminsky: RTAI_PROTO is just a little silly: https://github.com/NTULINUX/RTAI/blob/master/include/rtai_types.h#L41
12:40 PM andypugh: Yes, I found it.
12:40 PM seb_kuzminsky: i guess it's a way to quickly try out different function prototypes for all the rtai functions at once
12:40 PM * seb_kuzminsky shrugs
12:41 PM andypugh: But I am unclear what happens when you combine a function prototype with code in it with a function with the same name elsewhere in the code
12:42 PM seb_kuzminsky: i don't understand your question
12:42 PM andypugh: That is a header file.
12:43 PM andypugh: But it contains code.
12:43 PM andypugh: There is a corresponding function too.
12:44 PM andypugh: https://github.com/NTULINUX/RTAI/blob/master/src/ipc/shm/shm.c#L53
12:44 PM cerna: seb_kuzminsky: I thought you do use the LXRT for the libuspace-rtai.so.
12:45 PM andypugh: The code in shm.c does get run.
12:45 PM seb_kuzminsky: that doesn't build & test regularly, so i don't know if it works or anything
12:46 PM andypugh: But I don’t understand if a call to _rt_shm_alloc calls the H then the C, of the C then the H, or one or the other depending.
12:47 PM seb_kuzminsky: https://github.com/NTULINUX/RTAI/blob/master/include/rtai_shm.h#L186
12:47 PM seb_kuzminsky: in kernel mode you get the _rt_shm_alloc() from the header file, i bet the one in the C file gets used by some sort of userspace library
12:48 PM andypugh: The one in the C file calls kmalloc
12:49 PM seb_kuzminsky: i misread it, it's the way you said, opposite of what i said
12:49 PM seb_kuzminsky: in kernel mode you get the C _rt_shm_alloc(), in userspace you get the one from the header file
12:50 PM andypugh: I guess that it has to be compiled-in to specific modules then? Each gets the required version?
12:51 PM seb_kuzminsky: right, each kernel C file that #includes rtai_shm.h gets its own static inline version of _rt_shm_alloc()
12:53 PM seb_kuzminsky: i guess the rtai devs decided that the extra icache pressure of inlining all that code is better than having to jump to a shared function? i'm not really up on performance issues on modern CPU architectures...
12:54 PM andypugh: I can’t help feeling that sorting this out is a job for an actual programmer.
12:54 PM andypugh: But I guess, I am learning from this.
12:56 PM seb_kuzminsky: if you can reduce the "crash rtai" code down to a simple C program that doesn't need linuxcnc to build, you might succeed in engaging the rtai development community
12:57 PM seb_kuzminsky: or if this is built from memfrob's code, he might be the person to ask for help
12:57 PM seb_kuzminsky: this seems like a job for an rtai expert
01:00 PM andypugh: Or we just give up
01:00 PM andypugh: Wheey is fine, really.
01:01 PM seb_kuzminsky: maybe we can keep supporting rtai on wheezy (32 and 64 bit) for the folks with old hardware, and support rt-preempt going forward
01:02 PM seb_kuzminsky: that would have the downside that we have to keep supporting old software on wheezy (linux 3.2, rtai 3.9, python 3.2, etc)
01:02 PM andypugh: I don’t think 64-bit is an option on Wheezy / RTAI?
01:03 PM seb_kuzminsky: that's right, it's not
01:03 PM andypugh: There are only x86 kernel patches.
01:03 PM seb_kuzminsky: but wheezy's rt-preempt supports both 32-bit and 64-bit
01:03 PM seb_kuzminsky: and of course, the 32-bit wheezy can install and run on 64-bit hardware
01:04 PM andypugh: I just feel naturally reluctant to discard the huge amount of work that Memfrob has done, and the significant amount that I have.
01:04 PM seb_kuzminsky: i feel your pain
01:04 PM seb_kuzminsky: i felt the same way when i abandoned my attempt at packaging rtai :-(
01:05 PM seb_kuzminsky: have you spoken with memfrob about this problem?
01:05 PM andypugh: (I have been using this RTAI kernel since November for all my testing and it has been fine. I only noticed a problem at all when I recently started running runtests routinely)
01:05 PM seb_kuzminsky: when i had lockup problems with rtai 5 i spoke with paolo and the rtai.org folks, they looked at it some (don't know how closely) but never came up with a fix
01:06 PM andypugh: Yes, no reply.
01:06 PM seb_kuzminsky: andypugh: yeah, stress tests are super valuable for that reason
01:06 PM seb_kuzminsky: it lets you compress a month of user testing into a night :-)
01:07 PM seb_kuzminsky: i wonder what the rtai.org folks are up to now, maybe i should dust off all my old git repos and build scripts and give their current code (rtai 5.2?) a try again
01:07 PM seb_kuzminsky: rtai.org claims to support 32-bit and 64-bit x86, plus arm
01:08 PM seb_kuzminsky: lol, their website boasts: "CVS (coming soon)"
01:09 PM andypugh: You can just clone the NTULINUX repo and use my kernel debs.
01:09 PM seb_kuzminsky: the point of this exercise would be to try a different version of the rtai code & kernel patch, and see if that has the same crashing problem, and if it does then engage with that developer community
01:10 PM andypugh: It’s all fairly straightforward, step-by-step recipe here: https://github.com/NTULINUX/RTAI/blob/master/README.INSTALL
01:11 PM seb_kuzminsky: that's good documentation!
01:11 PM andypugh: Ah, you mean automate the kernel build too?
01:11 PM seb_kuzminsky: yeah, the system that john morris and i made for building linux & rtai builds both from source into debs
01:14 PM seb_kuzminsky: this is possibly kind of old and out of date: https://github.com/SebKuzminsky/linux-rtai-build
01:16 PM rene_dev_: seb_kuzminsky nope, cant have anything python3 or gtk3 with wheezy, I tried yesterday.
01:17 PM rene_dev_: the only UI that works with python3 is axis, all other UIs require gtk3, which doesnt work because gtkglarea is broken. but its promising, maybe it does get fixed when I do a proper bug report.
01:18 PM rene_dev_: today I figured out what the actual problem is
01:31 PM andypugh: So, the choice to use Tcl was actually a good one?
01:32 PM seb_kuzminsky: keystick forever!
01:34 PM andypugh: We droped keystick, though.
01:34 PM andypugh: Perhaps it needs to be resurrected :-)
01:34 PM seb_kuzminsky: heh
01:40 PM andypugh: Back to work tomorrow. I was really expecting to have 2.8 out the door by now. But it doesn’t really feel any closer.
01:41 PM andypugh: And my 3 weeks of doing nothing else are at an end,
01:41 PM seb_kuzminsky: the rtai thing is a huge stumbling block for every single one of our releases
01:42 PM seb_kuzminsky: and this time you're also dealing with the python2 and gtk2 eol
01:42 PM Tom_L: would 5.2 be worth trying to build?
01:42 PM andypugh: Well, mainly I have been trying to get the builds clean and hack away at the github isues list.
01:42 PM seb_kuzminsky: Tom_L: it'd be an interesting data point, for sure
01:42 PM Tom_L: i just dl it
01:42 PM Tom_L: never built a rtai kernel before so...
01:43 PM andypugh: The Python 3 stuff is all aimed at Master.
01:43 PM Tom_L: buster is the target
01:43 PM Tom_L: andypugh, i'm counting on your instructions :)
01:43 PM andypugh: Yes, get buster and follow the steps in https://github.com/NTULINUX/RTAI/blob/master/README.INSTALL and you should get there.
01:44 PM Tom_L: yup, i've already got that open
01:44 PM andypugh: (Building Clang and friends, 17 % so far. I started when it was first suggested, over an hour ago)
01:45 PM andypugh: Of course, I forgot the -j4. Now it’s a question of whether it is faster to stop and add it, or let it finish.
01:46 PM Tom_L: use the rtai in your link or from rtai.org?
01:47 PM seb_kuzminsky: as long as you don't make clean, it'll be faster to stop it and restart it with -j4
01:47 PM seb_kuzminsky: Tom_L: for this experiment, use rtai 5.2 from rtai.org
01:47 PM andypugh: Definitely do a git clone of the NTULINUX one
01:47 PM Tom_L: i grabbed 5.2 from rtai.org
01:47 PM Tom_L: ok
01:47 PM andypugh: Hmm
01:47 PM andypugh: OK
01:47 PM Tom_L: ok guys. which?
01:47 PM Tom_L: :)
01:47 PM seb_kuzminsky: wait, what's the goal of this experiment?
01:47 PM andypugh: Yes, use rtai, make it an experiment
01:48 PM Tom_L: just to see if it's any better / worse
01:48 PM seb_kuzminsky: i thought it was to try the rtai.org version and see if that crashes too
01:48 PM andypugh: Good plan.
01:48 PM Tom_L: you may have to walk me thru the crash tests
01:48 PM Tom_L: after i build it
02:10 PM Tom_L: in kernel C++ support?
02:10 PM andypugh: No.
02:11 PM andypugh: Hmm. Or maybe I am wring there. Where is that question being asked?
02:11 PM Tom_L: i'm using the interactive build
02:13 PM andypugh: Kernel or RTAI?
02:13 PM andypugh: (I guess kernel?)
02:15 PM Tom_L: i think so yes
02:16 PM Tom_L: do you build rtai against a kernel tree?
02:16 PM Tom_L: it's asking for a /usr/src/linux source tree that isn't there
02:19 PM Tom_L: their build doc dates back to rtai 3
02:19 PM andypugh: Are you following the instructions?
02:19 PM andypugh: Ah, you are folowing the rtai instructions.
02:19 PM Tom_L: i don't think yours will apply to this without changes
02:19 PM andypugh: Some bits will
02:19 PM Tom_L: right
02:19 PM Tom_L: just gotta figure out which bits
02:20 PM andypugh: Like, the “ln -sf linux-X-X_X_ linux” instruction
02:21 PM andypugh: I suggest (intelligently) following Memfrob’s instructions, than look at the rtai.org ones if in doubt.
02:22 PM Tom_L: ok, i'll give it a go
02:57 PM rene_dev_: andypugh did you know that you can use a a to a usb cable for kernel debugging? https://www.kernel.org/doc/html/latest/driver-api/usb/usb3-debug-port.html
03:30 PM andypugh: rene_dev_: Interesting, though possibly of limited use here?
03:31 PM rene_dev_: if it crashes very useful
03:31 PM rene_dev_: does the scan-build come up with anything?
03:36 PM andypugh: The llvm build failed
03:36 PM andypugh: I am not sure why. : c++: fatal error: Killed signal terminated program cc1plus
03:46 PM Tom_L: i think this is a bit above my pay grade...
03:46 PM rmu|w: andypugh: llvm got killed while building linuxcnc?
03:48 PM andypugh: No, while building llvm
03:48 PM andypugh: Tom_L: How is it going?
03:49 PM rmu|w: andypugh: back in the day when building gcc, aborts like that usually pointed to bad hardware.
03:49 PM rmu|w: andypugh: there is https://apt.llvm.org/ that has prebuilt binary packages of llvm for buster
03:50 PM andypugh: That woul dhave been really helpful if their docs had pointed there.
03:50 PM rmu|w: hehe
03:51 PM rmu|w: duckduckgo has that as first result when searching for "llvm debian download"
03:52 PM andypugh: This page says “For other platforms, you must build Clang and LLVM manually. “
03:52 PM andypugh: https://clang-analyzer.llvm.org/installation#OtherPlatforms
03:53 PM rmu|w: i must admit i don't know if those builds include the analyzer
04:05 PM rmu|w: AFAIU scan-build is just a wrapper that injects command line arguments into compiler cmd line
04:07 PM rene_dev_: andypugh the clang from debian 10 builds fine, and all tests pass.
04:07 PM rene_dev_: cant you build the kernel and linuxcnc form buster? you dont actually need to run anything, its static analysis
04:07 PM andypugh: That’s your Pyton stuff?
04:08 PM andypugh: I don’t understand the second question,
04:11 PM rmu|w: andypugh: scan-build should be in the package clang-tools-10 as scan-build-10
04:12 PM rmu|w: rene_dev_: andypugh tried to build LLVM, and that failed
04:12 PM andypugh: Hmm, so why does the web page say that you _have_ to compile it from source?
04:12 PM rene_dev_: I was using clang 7
04:12 PM rene_dev_: from buster repo
04:13 PM rmu|w: andypugh: bit rot. another web page says "available in most linux distributions as package"
04:13 PM rmu|w: https://clang-analyzer.llvm.org/command-line.html
04:13 PM rmu|w: "Works on all major platforms (Windows, Linux, macOS) and is available as a package in many Linux distributions."
04:14 PM rene_dev_: yes, now Im pushing the changes that dont affect python2
04:14 PM rene_dev_: to make the diff smaller
04:15 PM andypugh: I was led astray by the actual web-site saying that you need to compile it from source.
04:16 PM rene_dev_: you dont
04:16 PM andypugh: Like, go to https://clang-analyzer.llvm.org and click on the obvious “Download” link, and it says you need to compile it.
04:17 PM rene_dev_: https://packages.debian.org/buster/clang-tools-7
04:17 PM rene_dev_: just run sudo apt install clang-tools
04:17 PM rene_dev_: ;D
04:17 PM andypugh: Yes, I have already installed it, now.
04:18 PM andypugh: (with the compile still at 29% after 4 hours…)
04:20 PM andypugh: Hmm, I am glad I didn’t wait for it to finish compiling.
04:20 PM andypugh: scan-build: No bugs found.
04:21 PM rene_dev_: what
04:21 PM rene_dev_: how did you run it?
04:23 PM andypugh: Wrongly, presumably
04:24 PM andypugh: scan-build ./configure … scan-build --keep-cc make
04:24 PM andypugh: But, of course, that was what the web page says, and that’s known to give bad advice.
04:26 PM andypugh: It’s not right. Even the compiler mentions that a variable might be being used undefined.
04:33 PM rmu|w: andypugh: just prefix your normal configure and make commands with scan-build
04:33 PM andypugh: Yes. I did. It didn’t work.
04:34 PM andypugh: https://stackoverflow.com/questions/38308269/scan-build-make-does-not-detect-any-bugs
04:35 PM rmu|w: i just tried with a recent checkout and clang-10 from apt.llvm.org, that reports 226 bugs
04:36 PM andypugh: In RTAI?
04:36 PM rmu|w: no, posix uspace
04:36 PM rmu|w: non-rt
04:36 PM andypugh: I mean, in the RTAI _application_
04:37 PM rene_dev_: rmu|w 226 sounds about right
04:37 PM rene_dev_: andypugh do normal configure, then run scan-build make
04:37 PM andypugh: Are we talking about the same thing?
04:37 PM rmu|w: probably not
04:37 PM andypugh: rene_dev_: Already did
04:37 PM rene_dev_: andypugh you are compiling linuxcnc, not the kernel?
04:37 PM rene_dev_: hmm, strange
04:38 PM andypugh: No, I am compiling _RTAI_
04:38 PM andypugh: Maybe you could try it?
04:38 PM rene_dev_: ah, uuh. Im not sure you can compile linux with llvm
04:39 PM andypugh: I am not trying to compile Linux. I am trying to compile RTAI. How many times do I need to repeat this?
04:40 PM rene_dev_: I thought rtai is a patch for the linux kernel
04:40 PM rene_dev_: ah, so you are compiling linuxcnc, with rtai as rt
04:41 PM andypugh: <gives up>
04:43 PM rmu|w: rene_dev_: rtai needs some kernel patch, but IIRC it provides some kind of posixy-interface to the real time stuff, and that code is separate from linux kernel code
04:43 PM rene_dev_: ah, I didnt know that
04:45 PM rmu|w: the kernel code is just some kind of interrupt interceptor
04:46 PM rmu|w: and some strangeness of the architecture stems from avoidind rt-linux patents. but my memory of that stuff is hazy, i only dealt with this stuff about 20 years ago...
04:49 PM rmu|w: https://en.wikipedia.org/wiki/Adaptive_Domain_Environment_for_Operating_Systems
04:50 PM andypugh: Feel free to try it, You should just be able to clone the NTULINUX git and compile the application without the kernel patch to text clang on it.
04:51 PM rmu|w: this one? https://github.com/NTULINUX/RTAI
04:51 PM andypugh: Yes
04:52 PM rmu|w: configure bombs out with "configure: error: IPIPE not enabled in /lib/modules/5.3.0-46-generic/build"
04:53 PM andypugh: Ah, well. maybe there is more to it than that.
04:53 PM andypugh: Did you run ./configure?
04:54 PM rmu|w: ./autogen.sh and then ./configure
04:54 PM andypugh: If you are really interested, there is a patched kernel package in www.linuxcnc.org
04:54 PM seb_kuzminsky: when i've built RTAI, i've used a process very similar to memleak's instructions
04:54 PM seb_kuzminsky: patch the linux source code with the rtai patch, configure, build, install, reboot
04:54 PM seb_kuzminsky: only *then* do i try to build the rtai package itself
04:55 PM andypugh: I tend to use the make menuconfig option. Though I do seem to need to change the install path every time.
04:55 PM andypugh: seb_kuzminsky: Yes, but I was homping that a static analyser might not need all that
04:56 PM rmu|w: i need to find a machine where i can test that, can't really reboot my regular dev machine
04:56 PM andypugh: A VM should work.
04:59 PM andypugh: This whole thing would be less tedious if the test machine wasn’t upstairs, could be configured to boot into the right kernel without me operating the grub screen and if the Wifi would connect automatically. But I spent a couple of hours today on those two things, and when even grub-customiser wasn’t able to make it boot the correct kernel I gave up.
05:00 PM rmu|w: lol.... the little things...
05:01 PM rmu|w: just delete all other kernels. but have some alternative method of booting ready
05:03 PM rmu|w: README.BIOS says to disable among other things virtualisation, hyperthreading, sleep states, iommu, secure boot and other things
05:06 PM seb_kuzminsky: andypugh: you can set GRUB_DEFAULT in /etc/default/grub
05:06 PM seb_kuzminsky: then update-grub
05:07 PM rmu|w: if this doesn't work, i also had the case where there was a second /boot partition somewhere on some harddisk, and the GRUB that got started decided to look at that partition, and not the one that got mounted on /boot
05:07 PM andypugh: seb_kuzminsky: Do you think I wouldn’t have foiund that in 2 hoirs of trying?
05:07 PM andypugh: It simply does not work on my system.
05:08 PM seb_kuzminsky: i should have known you would find that, sorry
05:08 PM seb_kuzminsky: it's weird that it doesn't work on your system, i used it the other night when i was testing your rtai kernel on bare metal
05:08 PM andypugh: I think that the problem is that it is multi-boot into 3 OS versions and the RTAI kernels are in the submenus
05:09 PM seb_kuzminsky: my machine is set up the same way
05:09 PM seb_kuzminsky: you can go into submenus with GRUB_DEFAULT
05:09 PM andypugh: But I have tried everything from 2>4 to 5>6 and nothing ever changes.
05:10 PM seb_kuzminsky: hang on a sec, i'll go look how i set mine up
05:10 PM andypugh: I have also tried doing it by menu item name, submenu>menu, using a GUI tool....
05:12 PM andypugh: And setting it to biit the last one used..
05:13 PM andypugh: Currently update-grub is admonishing me with:
05:13 PM andypugh: Warning: Please don't use old title `Debian GNU/Linux, with Linux 4.14.174-rtai-amd64' for GRUB_DEFAULT, use `Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 4.14.174-rtai-amd64' (for versions before 2.00) or `gnulinux-advanced-7dda1715-6cfd-492c-8ded-c36cb389fbf4>gnulinux-4.14.174-rtai-amd64-advanced-7dda1715-6cfd-492c-8ded-c36cb389fbf4' (for 2.00 or later)
05:13 PM andypugh: But that’s how grub-customiser set it up…
05:21 PM andypugh: So, I put in exactly what it said, and it stopped telling me off when I ran update-grub. Bit still boots 4.9.0-6
05:27 PM Tom_L: andypugh, i took a break for a while. im not sure i'm knowledgeable enough to pull this off
05:28 PM andypugh: I wasn’t in November, the first time I did it.
05:28 PM Tom_L: do i need the current installed kernel source for this? it keeps asking for the path to the kernel
05:29 PM rmu|w: andypugh: maybe you can get grub to remember your choice? GRUB_SAVEDEFAULT=true and GRUB_DEFAULT=saved in /etc/default/grub
05:29 PM rmu|w: https://askubuntu.com/questions/148662/how-to-get-grub2-to-remember-last-choice
05:29 PM Tom_L: it's asking about gtk stuff too and that becomes a version issue i think
05:29 PM Tom_L: that or xconfig
05:35 PM seb_kuzminsky: andypugh: my /etc/default/grub says:
05:35 PM seb_kuzminsky: GRUB_DEFAULT="1>4"
05:36 PM seb_kuzminsky: that machine boots automatically to the kernel i want
05:36 PM seb_kuzminsky: that's the 5th kernel from the submenu that is item 2 in the main menu
05:39 PM seb_kuzminsky: this is my main menu: http://highlab.com/~seb/linuxcnc/grub-main-menu.jpg
05:39 PM seb_kuzminsky: this is the submenu: http://highlab.com/~seb/linuxcnc/grub-submenu.jpg
05:40 PM seb_kuzminsky: and this is my GRUB_DEFAULT: http://highlab.com/~seb/linuxcnc/grub-default.jpg
05:41 PM seb_kuzminsky: since it's a bash script fragment, the quotes around the value are important, or the ">" will be interpreted as a shell redirect, which makes no sense there
05:42 PM seb_kuzminsky: you can see if it got relayed to grub correctly by looking for the line with "set default" in /boot/grub/grub.cfg
05:52 PM andypugh: grub.cfg has all sorts
05:53 PM andypugh: https://pastebin.ubuntu.com/p/Yfh4hgjkM3/
05:54 PM andypugh: seb_kuzminsky: But I would be interested to see if you can configure to boot an alternate Wheey kernel, as that is where my Buster is in the tree.
05:56 PM seb_kuzminsky: andypugh: line 19 is the one that matters, and it looks wrong
05:56 PM seb_kuzminsky: set default="gnulinux-advanced-7dda1715-6cfd-492c-8ded-c36cb389fbf4>gnulinux-4.14.174-rtai-amd64-advanced-7dda1715-6cfd-492c-8ded-c36cb389fbf4"
05:56 PM seb_kuzminsky: i'll go see if i can boot wheezy by default, hang on
05:56 PM andypugh: That is exactly what update-grub told me to put in after grub-customiser had had a go
05:57 PM seb_kuzminsky: i'm not familiar with that tool
05:57 PM andypugh: No, I only used it in desperation
06:07 PM seb_kuzminsky: yes, i changed to GRUB_DEFAULT="5>6" and it booted the 7th kernel from the wheezy partition
06:07 PM seb_kuzminsky: can you paste your /etc/default/grub?
06:10 PM seb_kuzminsky: are you trying to boot "Debian GNU/Linux, with Linux 4.19.114-rtai-amd64"?
06:20 PM Tom_L: do i need a copy of the current kernel tree to build rtai?
06:21 PM Tom_L: kernel 101 here
06:22 PM seb_kuzminsky: Tom_L: you need to install the kernel that you built using the rtai kernel patch, and you need to point the rtai code at that kernel when you build rtai
06:22 PM Tom_L: i haven't patched anything yet
06:25 PM Tom_L: trying to build 5.2 from rtai.org
06:26 PM seb_kuzminsky: did you look at the README? it says to build the kernel first
06:28 PM Tom_L: i'm not clear which kernel it's talking about
06:29 PM Tom_L: i have the 4.19 source also
06:29 PM seb_kuzminsky: rtai has two parts: an in-kernel part and a separate stand-alone part
06:29 PM Tom_L: ok
06:29 PM seb_kuzminsky: the in-kernel part you can think of as a fork of the linux kernel, but it's distributed as a patch against the upstream kernel code
06:30 PM Tom_L: the file i'm looking at said to start by 'make menuconfig'
06:30 PM Tom_L: and i get an error saying no path to kernel or such
06:30 PM seb_kuzminsky: the separate stand-alone part is the rtai kernel modules, that can only be loaded into a kernel with the in-kernel patch applied
06:31 PM seb_kuzminsky: i'm not sure what file you're looking at, but the best instructions i know of are here: https://github.com/NTULINUX/RTAI/blob/master/README.INSTALL
06:31 PM Tom_L: i had that open but was looking at the readme.install from rtai.org
06:32 PM Tom_L: i'll stumble around a while here..
06:32 PM Tom_L: how do i get the patches?
06:33 PM seb_kuzminsky: they're in the rtai tarball
06:33 PM seb_kuzminsky: somewhere
06:33 PM Tom_L: ok
06:33 PM Tom_L: so i should start with the kernel from kernel.org
06:33 PM Tom_L: and add the rtai patches
06:34 PM seb_kuzminsky: that's a perfectly reasonable thing to do
06:34 PM Tom_L: makes a bit more sense now
06:34 PM Tom_L: thanks
06:34 PM Tom_L: i thought i was building the kernel from rtai source only
06:34 PM Tom_L: shows what i know
06:34 PM seb_kuzminsky: i'm happy to help :-)
06:34 PM Tom_L: sorry to take your time too
06:34 PM seb_kuzminsky: yeah this stuff is pretty complicated, pretty low-level, and not at all set up to be welcoming to new people
06:35 PM seb_kuzminsky: bit like linuxcnc maybe :-)
06:35 PM Tom_L: i've built a couple kernels but never rtai
06:35 PM seb_kuzminsky: then you're halfway there already!
06:35 PM Tom_L: know nothing about tweaking them
06:36 PM Tom_L: so if i built preempt-rt from kernel source should i get a fresh copy for this?
06:37 PM seb_kuzminsky: so, i untarred rtai-5.2.tar.bz2 and looked in base/arch/x86/patches
06:37 PM seb_kuzminsky: there i see a bunch of patches for a bunch of specific kernel versions
06:38 PM seb_kuzminsky: i would pick one of those versions (probably start with the newest one), download that exact tarball from kernel.org, and go from there
06:38 PM Tom_L: ahh ok
06:38 PM Tom_L: see you knew where to look for em
06:40 PM seb_kuzminsky: not my first rodeo
06:48 PM Tom_L: i don't see an exact match
06:51 PM andypugh: You need to pick a kernel to suit a patch set
06:52 PM Tom_L: i figured that but unless i'm looking in the wrong place which i likely am, i don't see exact matches
06:52 PM andypugh: seb_kuzminsky: One approach that might be worth a try: I have been going through the options in the RTAI menuconfig (fancy!) and there are quite a few things in there that might be worth turning on and off to see if they help.
06:52 PM Tom_L: kernel org has 4.14.177 and rtai has 4.14.111
06:54 PM andypugh: https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.111.tar.gz
06:55 PM andypugh: Tom_L: ^
06:55 PM Tom_L: thanks
06:55 PM andypugh: All of them: https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/
06:55 PM Tom_L: i should mark that page :)
06:55 PM Tom_L: that's what i was looking for
06:57 PM andypugh: seb_kuzminsky: I have work in the morning, so need to stop now, but if you could find the time to look through the build options for RTAI looking for likely variations, then I can try them out. I have already tried turning off vmalloc (and, in fact turning off RTAI malloc. Which it seems we mustn’t use.)
06:59 PM seb_kuzminsky: i might look in to rtai some more tonight, but no promises
07:18 PM andypugh: I quick glance at the compile options would be nice, if you can find the time. Maybe jist looking through the Kconfig, it is actually quite well commented: https://github.com/NTULINUX/RTAI/blob/master/Kconfig
07:20 PM Tom_L: patching.... i hope
07:23 PM andypugh: That Kconfig actually mentions LinuxCNC specifically in several places.
07:24 PM Tom_L: andypugh, any specific things i might enable in the rtai patch?
07:24 PM andypugh: Kernel config time?
07:24 PM Tom_L: yes
07:25 PM andypugh: turn _off_ security->limit access to kernel log (or dmesg won’t work)
07:25 PM andypugh: Make sure your graphics card support is on.
07:27 PM andypugh: I think there is something else, but I have forgotten it.
07:27 PM andypugh: You probably want to put “rtai” in the box near the top of the list.
07:28 PM andypugh: And I need to sleep.
08:13 PM Tom_dev: arch/x86/entry/common.c:294:5: error: implicit declaration of function ‘ipipe_root_nr_syscalls’; did you mean ‘ipipe_handle_syscall’? [-Werror=implicit-function-declaration]
08:14 PM Tom_dev: https://mail.rtai.org/pipermail/rtai/2019-June/027998.html
08:18 PM Tom_dev: not sure where to go with that
11:27 PM Tom_dev: tried an older kernel 4.14.89 and still get similar ipipe errors