Advanced Search

Preemption ModelsThe various preemption models are kernel specific. In principle, user space programs are always preemptible.Preemption of a running task is performed by the scheduler. This action can be triggered by a kernel interaction like a system call or an asynchronous event like an interrupt. The scheduler saves the context of the preempted task and restores the context of the new task.The Linux kernel implements several preemption models. The desired model is selected at build time of the kernel. The “Fully Preemptible Kernel” preemption model must be selected to obtain Linux as an RTOS. For the sake of completeness a list and a short explanation of the existing Linux preemption models is given. The last two entries are available only with the PREEMPT_RT patch.

• No Forced Preemption (server) – the traditional Linux preemption model, geared towards throughput . System call returns and interrupts are the only preemption points.
• Voluntary Kernel Preemption (Desktop) – reduces the latency of the kernel by adding more “explicit preemption points” to the kernel code [. . . ] at the cost of slightly lower throughput . In addition to explicit preemption points, system call returns and interrupt returns are implicit preemption points.
• Preemptible Kernel (Low-Latency Desktop) – reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. An implicit preemption point is located after each preemption disable section.
• Preemptible Kernel (Basic RT) – resembles the “Preemptible Kernel (Low-Latency Desktop)” model. Besides the properties mentioned above, threaded interrupt handlers are forced (as when using the kernel command line parameter

  threadirqs

  ). This model is mainly used for testing and debugging of substitution mechanisms implemented by the PREEMPT_RT patch.
• Fully Preemptible Kernel (RT) – all kernel code is preemptible except for a few selected critical sections. Threaded interrupt handlers are forced. Furthermore several substitution mechanisms like sleeping spinlocks and rt_mutex are implemented to reduce preemption disabled sections. Additionally, large preemption disabled sections are substituted by separate locking constructs. This preemption model has to be selected in order to obtain real-time behavior.

The above was taken from here: wiki.linuxfoundation.org/realtime/docume...cs/preemption_models

I was wanting to know a little bit about the models. I would opine that the last model would be the one most appropriate for Linuxcnc.

 
Without those patches there is no choice for a fully-preemptible kernel. With the patch, however as shown above, you can. Kernel I'm working on is 6.1.69. The rpi-linux 6.1.y tree is currently at 6.1.93 but there are no patches for that kernel version. Even with the 6.1.69 kernel I had to add a supports rt patch.

Once I get 6.1.y working I'll investigate the 6.12.y branch.

These are the kernel versions supported by the 6.1.y branch, first number can be ignored, anything lower than 6.1.93 will need to be checked out via it's commit hash.
134:    Linux 6.1.93
14291:    Linux 6.1.92
16232:    Linux 6.1.91
23660:    Linux 6.1.90
27681:    Linux 6.1.89
27706:    Linux 6.1.88
32471:    Linux 6.1.87
35109:    Linux 6.1.86
37360:    Linux 6.1.85
42147:    Linux 6.1.84
50699:    Linux 6.1.83
62988:    Linux 6.1.82
64939:    Linux 6.1.81
71599:    Linux 6.1.80
77453:    Linux 6.1.79
84250:    Linux 6.1.78
86343:    Linux 6.1.77
92914:    Linux 6.1.76
99084:    Linux 6.1.75
110569:    Linux 6.1.74
113192:    Linux 6.1.73
113387:    Linux 6.1.72
118104:    Linux 6.1.71
120743:    Linux 6.1.70
124909:    Linux 6.1.69
128698:    Linux 6.1.68
134527:    Linux 6.1.67
134563:    Linux 6.1.66
138000:    Linux 6.1.65
140685:    Linux 6.1.64
152972:    Linux 6.1.63
163065:    Linux 6.1.62
164790:    Linux 6.1.62
166577:    Linux 6.1.61
169429:    Linux 6.1.60
175826:    Linux 6.1.59
179923:    Linux 6.1.58
180151:    Linux 6.1.57
184954:    Linux 6.1.56
195377:    Linux 6.1.55
200028:    Linux 6.1.54
207409:    Linux 6.1.53
223634:    Linux 6.1.52
224553:    Linux 6.1.51
225079:    Linux 6.1.50
229388:    Linux 6.1.49
229507:    Linux 6.1.48
229985:    Linux 6.1.47
235916:    Linux 6.1.46
240487:    Linux 6.1.45
244966:    Linux 6.1.44
245843:    Linux 6.1.43
252366:    Linux 6.1.42
259059:    Linux 6.1.41
259111:    Linux 6.1.40
266071:    Linux 6.1.39
283243:    Linux 6.1.38
283669:    Linux 6.1.37
284688:    Linux 6.1.36
289556:    Linux 6.1.35
294854:    Linux 6.1.34
298872:    Linux 6.1.33
305346:    Linux 6.1.32
306760:    Linux 6.1.31
310746:    Linux 6.1.30
319815:    Linux 6.1.29
326982:    Linux 6.1.28
344147:    Linux 6.1.27
345004:    Linux 6.1.26
348476:    Linux 6.1.25
352380:    Linux 6.1.24
357625:    Linux 6.1.23
363409:    Linux 6.1.22
370947:    Linux 6.1.21
377351:    Linux 6.1.20
395818:    Linux 6.1.19
395937:    Linux 6.1.18
401889:    Linux 6.1.17
401945:    Linux 6.1.16
426850:    Linux 6.1.15
428063:    Linux 6.1.14
429689:    Linux 6.1.13
433231:    Linux 6.1.12
436893:    Linux 6.1.11
443093:    Linux 6.1.10
452670:    Linux 6.1.8
458562:    Linux 6.1.7
463817:    Linux 6.1.6
464240:    Linux 6.1.5
469413:    Linux 6.1.4
475708:    Linux 6.1.3
479044:    Linux 6.1.2
509801:    Linux 6.1.1
513771:    Linux 6.1-rc8
518375:    Linux 6.1-rc7
527180:    Linux 6.1-rc6
535363:    Linux 6.1-rc5
545612:    Linux 6.1-rc4
554317:    Linux 6.1-rc3
565192:    Linux 6.1-rc2
576296:    Linux 6.1-rc1
871669:    Linux 6.1.

 

JT wrote:

Messing around with QLinearGradients and thinking of adding them to the Stylesheet Builder.

Is it worth it?

JT
 

A gradient would be good for something like a progressbar unless there's some other way to express zones.

Was messing with the qss builder a bit.....it definately needs an "open" function.

Also doesn't seem to be any way to apply the background colors. I assumed this would be part of "All" but it doesn't seem to work like that.

 

Like you assumed before I think those patches indeed didn't make it to the mainline kernel, but those are not needed to make a fully preemptible kernel.

The sysfs patch is only needed because LinuxCNC checks that indicator. Later I saw that the source of Raspberry also already has the arch_supports_rt in the kconfig.

It's stated that there is no need to apply RT patches, so why are there rt patches available up to 6.13 ?

From my findings the only way to select a "fully preemptible kernel" for arm is to apply the patches supplied by kernel.org. Which also include the sysfs patch.

Aaahhh thank you. I got a bit nervous after opening the firmware folder and seeing so many different versions. I will try as soon as I get to work Monday and report back.
Thanks again

Yeah, I wanted the S version, but they were out of stock, so I jumped on what was available. I’ve been trying to get ahold of a Mesa card for a while, but with the chip shortage everything was out of stock. I’ve seen people driving analog spindles with the PWM output from the 4th motor driver through a converter, it’s definitely doable. I’m just not too sure about the software side of things.

For Raspberry I think following this guide should help: github.com/by/RT-Kernel

Only after git clone, download this patch:
forum.linuxcnc.org/media/kunena/attachme...ernel-realtime.patch
Then enter the Linux folder and enter: git apply ../sys-kernel-realtime.patch
After make menuconfig make sure that these are also selected:
forum.linuxcnc.org/38-general-linuxcnc-q...6-12?start=10#315643

Thx Aciera, thx re the driver recommendation. Also I didn't know about the encoder delay kinda important, as I would like it to be accurate for longer machining runs I'll look into adding an external encoder as you suggest.

Thx Spumco,
You're right I could use the 10v but I don't think this will give good positioning accuracy, would be fine if I were using it in a lathe like situation.
I've found another servo driver which has step dir pulses, its their A series of servos (MR-J3-100A or MR-J4-100A),k the B series seems to be SSCNET series. I might try and chase down one of those.

I assume you posted some info on your 4th axis build so I'll do some reading up on the homing.

Hi.
Some time ago I took the photos of the PCB inside the wireless version of XHC WHB04B and then promptly forgot about them.
In hopes someone can make a good use of them in the future I'm gonna post them on the forum.
Unfortunately can't upload them all to the forum cause even at half the size they are to large, nor can I link them all in here so you'll have to follow the URL to view them on imgur. Sorry.

All the pictures at: imgur.com/a/xhc-whb04b-photos-of-pcbs-wNkBjyu

Cheers,
Bushman

Ahh, yes I see that now. There are a couple of procedures in tkfbox.tcl that overwrite the button text.
The only correct way I see to do it would be to roll your own dialog box.
There is an ugly workaround by running the below code in the user_live_update method of the user command file. You would restore bigfileopen.tcl back to the original.

It is really ugly...
 

I am attempting to connect a THCAD 10 to a Everlast supercut 50. It does not have any CNC connections. It is a HF machine and I was told I needed to connect to the DC plasma supply before the HF coil. I am looking for pictures or a wiring diagram for this machine. I can not find anything. 

Jdolecki wrote:

Motherboard won’t even post to bios.

Did you try resetting the BIOS?

Jdolecki wrote:

Cf card was empty.

Use a Linux PC, install Qphotorec ... or just download the Caine ISO and boot from USB, use QtPhotoRec to recover data from the CF

Thank you for the info