Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

[dest...@gmail.com]

Hello dear Machinekit community,

we've successfully implemented a self built 3d printer with Machinekit. For stepper signal generation, we use the above mentioned cards. Up until yesterday, our config was working with the string

rt.loadrt('hm2_pci', config='num_encoders=1 num_stepgens=4 sserial_port_0="00xxxx"')

Yesterday I updated via apt-get upgrade to Machinekit version 0.1.1551530147.git6a143ec-1~stretch and now we get the following error on launch:

RuntimeError: rtapi_loadrt '('hm2_pci', 'config=num_encoders=1 num_stepgens=4 sserial_port_0="00xxxx"')' failed: Operation not permitted

Have you seen this error before?

Best regards

Dennis

[schoo...@gmail.com]

Please read
http://www.machinekit.io/docs/getting-help/

No-one can help you with this amount of information.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[dest...@gmail.com]

Sorry :-)

You are absolutely right. I'm running Debian stretch with Kernel

#1 SMP RPEEMPT RT Debian 4.9.144-3.1 (2019-02-19)

on an conventional PC.

1. It worked with Machinekit 0.1.1543327459.gite758f69-1~stretch. It doesn't work with 0.1.1551530147.git6a143ec-1~stretch.

I tried to launch it without hm2_pci config string, but it doesn't work.

2. I started it from the terminal window, with 'export DEBUG=5' (see attached log file), same problems.

3. Error text from bash is attached (output.log). Makes no sense for me.

4./5. I've search linuxcnc.log for clues. Problems start for me with the above mention permission denied error.

6. I've searched the forum again, and I found a similar problem. (https://groups.google.com/forum/#!searchin/machinekit/hm2_pci/machinekit/fahrSvm6b5c/vhK8S_NOEQAJ) with no solution yet as far as I can see. Please excuse for not answering in this topic, I simply didn't find it on my first search iteration.

7. I cannot see anything related on the issue tracker.

Thank you very much

Best regards

[Bas de Bruijn]

On 5 Mar 2019, at 12:20, dest...@gmail.com wrote:

Sorry :-)

You are absolutely right. I'm running Debian stretch with Kernel

#1 SMP RPEEMPT RT Debian 4.9.144-3.1 (2019-02-19)

on an conventional PC.

1. It worked with Machinekit 0.1.1543327459.gite758f69-1~stretch. It doesn't work with 0.1.1551530147.git6a143ec-1~stretch.

I tried to launch it without hm2_pci config string, but it doesn't work.

2. I started it from the terminal window, with 'export DEBUG=5' (see attached log file), same problems.

3. Error text from bash is attached (output.log). Makes no sense for me.

4./5. I've search linuxcnc.log for clues. Problems start for me with the above mention permission denied error.

Not sure how much i can help here.

Further on there’s this section:

8888:rt halg_xinitfv:90 HAL: initializing component 'hm2_pci' type=1 arg1=0 arg2=0/0x0

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt PCI_ID: 2718:5125 2718:5125

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: DeviceID: 2718 5125 2718 5125

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: Calling driver probe function

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: Enabling Device 0000:03:00.0

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Resource 0: 0xf7e00000 0xf7e0ffff 00000000

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Failed to parse "/sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/0000:03:00.0/resource"

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt hm2_pci: skipping AnyIO board at 0000:03:00.0, failed to enable PCI device

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Driver probe function failed!

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt hm2_pci: error registering PCI driver

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:

Did other things get updates too perhaps?

<output.log>

<linuxcnc.log>

[schoo...@gmail.com]

On 05/03/19 11:32, Bas de Bruijn wrote:

Not sure how much i can help here.

Further on there’s this section:

8888:rt halg_xinitfv:90 HAL: initializing component 'hm2_pci' type=1 arg1=0 arg2=0/0x0

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt PCI_ID: 2718:5125 2718:5125

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: DeviceID: 2718 5125 2718 5125

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: Calling driver probe function

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt RTAPI_PCI: Enabling Device 0000:03:00.0

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Resource 0: 0xf7e00000 0xf7e0ffff 00000000

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Failed to parse "/sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/0000:03:00.0/resource"

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt hm2_pci: skipping AnyIO board at 0000:03:00.0, failed to enable PCI device

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt Driver probe function failed!

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:8888:rt hm2_pci: error registering PCI driver

Mar  5 11:38:33 labor-linuxcnc-m2 msgd:0: hal_lib:

Did other things get updates too perhaps?

hm2_pci has not changed for 3 years and I cannot immediately see any other changes that might affect

First step is to reverse the process

apt remove machinekit*

Then download
http://deb.machinekit.io/debian/pool/main/m/machinekit/machinekit_0.1.1543327459.gite758f69-1~stretch_amd64.deb
http://deb.machinekit.io/debian/pool/main/m/machinekit/machinekit-rt-preempt-dbgsym_0.1.1543327459.gite758f69-1~stretch_amd64.deb

and install with
dpkg -i machinekit_0.1.1543327459.gite758f69-1~stretch_amd64.deb machinekit-rt-preempt-dbgsym_0.1.1543327459.gite758f69-1~stretch_amd64.deb

from wherever you downloaded them to

Then try again with DEBUG=5 set and attach the linuxcnc.log whatever the result.
(blank linuxcnc.log first)

On the face of it the error is failing to contact the board, not failing to load the driver and the error from the driver is resultant from that.


If you did not have this working immediately before ( the same day) you updated machinekit, I would check all cabling
and possibly remove the 6i25, clean the slot and board contacts with methylated spirits or similar, re-seat and try again.

[Dennis]

Thanks to you both!

I've done some further testing:

1) Mesa 6i25 in different PCI-E slot --> same result, not working

2) Different Mesa 6i25 from another working linuxcnc PC in original slot and second slot --> not working

3) Procedure from Schooner (downgrade to last working version) --> !working!

4) To countercheck I upgraded again to latest version of machinekit, the one that was not working --> not working

So to me something with the new version of machinekit is now working with my Mesa 6i25. It is not the card, not the PC and not the configuration.

Should I file an issue on the github tracker?

Best regards

Dennis

[schoo...@gmail.com]

No need for the github issue, we are looking at it!

The commit that was OK was quite old, it would be good to try and narrow down a bit to where the problem arose.
It will not have been very recently, since those were all ARM config changes.

If you are happy to do it, I can only suggest picking a package from a mid-point, say the first one in 2019 and installing that.
If it fails work back to say mid Dec 2018, if it succeeds work forward to end of Jan 2019 and so on.

In the absence of specific changes to hm2_pci, I suspect that another change, of which there were quite a few to
correct warnings etc, must have had an unforeseen effect elsewhere.

Anything you can do to isolate a commit or series of commits as causing this, would be very helpful

Tomorrow hopefully I can test on a 5i25/7i76 setup in the workshop, so having an idea where to look would speed things greatly

regards

[Dennis]

By geometric search I could narrow down the first 'problematic' package, I hope this is helpful to you:

the last working version is:

0.1.1543935482

the first non working version is:

0.1.1544363499

Thanks again for your help!

Best regards

Dennis

[Dennis]

Digging through github history in between 4th and 9th of December 2018 I found a commit (https://github.com/machinekit/machinekit/commit/e207745f52181562d22cacd636bc03721d2c2587) that modified the function pci_enable_device in rtapi_pci.c. This is the same function that throws the parse error in my linuxcnc.log. 

Maybe this is the problem...

[ce...@tuta.io]

Hmm, passing reference to pointer seems pretty odd and not something which was intended. What if you pass L1 and L2 as pointers and L3 as reference (compiled as RIP)?

Cern.

Dne úterý 5. března 2019 20:24:21 UTC+1 Dennis napsal(a):

[schoo...@gmail.com]

Thanks, I'll have a look later

[schoo...@gmail.com]

Well I can see the cause of all this, but the solution without generating a warning somewhere in the package builds is far from simple.
When this quite low level C was written, warnings were not as numerous as nowadays versions of gcc generate
and probably not top priority anyway so long as it worked.

I spent quite a long time trying various ways of removing warnings, but none were satisfactory for all usages of the variable,
across all architectures.

It essentially comes down to 32 bit and 64 bit differences in data type size.
If you then specify a format size in a printf operation, it will always generate a warning under one architecture or another.
Assigning with a (void*) cast, will do so too, hence the making of L1 and L2 void * probably

The idea of the `address of` reference &L1 was probably to prevent a warning regards printf format %p requiring void **,
but I would think it does not return what the function wants.

In any case I have reverted the commits and removed the -Werror CFLAG for now to enable packages to build.

Will take a while to filter through, not been able to test on my Mesa carded machine due to other issues,
hence reverted in its entirety.

Just using a package prior to these commits will keep you going for now.

Thanks for the report and your testing to quickly narrow it down.

regards

[Bas de Bruijn]

On 6 Mar 2019, at 12:30, "schoo...@gmail.com" <schoo...@gmail.com> wrote:

Well I can see the cause of all this, but the solution without generating a warning somewhere in the package builds is far from simple.
When this quite low level C was written, warnings were not as numerous as nowadays versions of gcc generate
and probably not top priority anyway so long as it worked.

I spent quite a long time trying various ways of removing warnings, but none were satisfactory for all usages of the variable,
across all architectures.

It essentially comes down to 32 bit and 64 bit differences in data type size.
If you then specify a format size in a printf operation, it will always generate a warning under one architecture or another.
Assigning with a (void*) cast, will do so too, hence the making of L1 and L2 void * probably

The idea of the `address of` reference &L1 was probably to prevent a warning regards printf format %p requiring void **,
but I would think it does not return what the function wants.

In any case I have reverted the commits and removed the -Werror CFLAG for now to enable packages to build.

Will take a while to filter through, not been able to test on my Mesa carded machine due to other issues,
hence reverted in its entirety.

If all has gone right, packages with the reverted offending commit should be built and in the apt repo.

[Charles Steinkuehler]

On 3/6/2019 5:30 AM, schoo...@gmail.com wrote:
>
> It essentially comes down to 32 bit and 64 bit differences in data type size.
> If you then specify a format size in a printf operation, it will always generate
> a warning under one architecture or another.
> Assigning with a (void*) cast, will do so too, hence the making of L1 and L2
> void * probably

I don't have time to test this in Machinekit, but I've solved these
sort of issues using the intptr_t data type (which changes size based
on the architecture), so something like:

unsigned intptr_t L1, L2;
unsigned long L3;

Another option (since intptr_t isn't guaranteed to be available and
I'm not 100% the pointer casts required for fscanf wouldn't throw a
warning) is to make a union and overlap a pointer with an integer
type, eg:

union foo {
unsigned long long foo_long;
void *foo_ptr;
}

...then use the appropriate type where needed.

--
Charles Steinkuehler
cha...@steinkuehler.net

[schoo...@gmail.com]

Yes, I read something very similar on stackoverflow Charles.
It is probably the way to go, certainly to test out.

As I didn't have the ability right now to test on real hardware,
I just reverted to be safe.

The warnings issue on Jessie and Stretch is as nothing to what is to come
in Buster with gcc 8.xx

There are some pretty intractable warnings due to the coding style in our
legacy code, where buffers are allocated to a defined length
and then a subsequent strncpy() or whatever is fixed to that same
defined length.

The later version of gcc will both warn of potential buffer overflow and of
potential data truncation, even if neither are possible in that instance.

Removing those, if ever deemed worth spending time on, will mean re-writing
a lot of code, possibly with some quite clunky stuff.

[John Morris]

Ugh, sorry for introducing this problem, and thanks for everyone's help figuring it out.

I think it's important to fix compiler warnings. When fixing these warnings, I found a couple of instances where the warnings actually pointed out real bugs. Warnings help me in my own development, and it's hard to see them in a haystack of other, unrelated warnings in the code (clean build log output was one of my motivations to fix the warnings in the first place). I bet there are other good reasons for fixing them. Am I alone on this one?

I'll fix this one properly so we can turn `-Werror` back on. I'll also take a look at Buster builds down the road when I actually start using it, if others think fixing warnings is worthwhile; if not, I won't fight the current.

John

________________________________________
From: machi...@googlegroups.com <machi...@googlegroups.com> on behalf of schoo...@gmail.com <schoo...@gmail.com>
Sent: Wednesday, March 6, 2019 10:32 PM
To: machi...@googlegroups.com
Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

[schoo...@gmail.com]

On 07/03/19 07:19, John Morris wrote:
> Ugh, sorry for introducing this problem, and thanks for everyone's help figuring it out.

One of those things John, if you don't do anything, you will never make
a mistake :)

>
> I think it's important to fix compiler warnings. When fixing these warnings, I found a couple of instances where the warnings actually pointed out real bugs. Warnings help me in my own development, and it's hard to see them in a haystack of other, unrelated warnings in the code (clean build log output was one of my motivations to fix the warnings in the first place). I bet there are other good reasons for fixing them. Am I alone on this one?

The fixes are good, allows for a much cleaner build. Also picks up on
sloppy coding style etc. where real problems can lurk.

>
> I'll fix this one properly so we can turn `-Werror` back on. I'll also take a look at Buster builds down the road when I actually start using it, if others think fixing warnings is worthwhile; if not, I won't fight the current.

Thanks, it will work perfectly well in the interim, don't worry until
you have the time.

Every increment of gcc seems to bring stricter standards adherence and
hence more warnings.

This has been beneficial in the past, where for instance we realised
that a maths library appeared to have been written in C by a python
programmer,
because a whole group of conditional operations were indented but not
within parenthesis, meaning only the first line was conditional and
every other
line was executed whatever the outcome of the conditional test.
That situation appeared to have existed in linuxcnc also, for many years.

I will wait for you to discover the wonders of gcc 8.xx for yourself and
see if you can live with them :D

[John Morris]

If I'd double-checked e207745, it would've been clear what was wrong: L3 should have stayed as ULL. D'oh!

Mick, I'd like to revert your commit 730837e, address all problems, and submit a PR. Of course e207745 caused the problem Dennis encountered, and I have a fix for it. However, it doesn't explain why it reverts b55b544 (or more likely I'm missing something). What's the problem there?

No, I'm not looking forward to silencing warnings in gcc 8. ;(

John

________________________________________
From: schoo...@gmail.com <schoo...@gmail.com>
Sent: Thursday, March 7, 2019 5:35 PM
To: John Morris; machi...@googlegroups.com

[schoo...@gmail.com]

On 08/03/19 09:28, John Morris wrote:
> If I'd double-checked e207745, it would've been clear what was wrong: L3 should have stayed as ULL. D'oh!
>
> Mick, I'd like to revert your commit 730837e, address all problems, and submit a PR. Of course e207745 caused the problem Dennis encountered, and I have a fix for it. However, it doesn't explain why it reverts b55b544 (or more likely I'm missing something). What's the problem there?

No specific problem, looked like that was the other bit of code which
threw a warning reading the same data
so I just reverted it back as was.

Since I had reverted to the old values in one, I expected it to error
looking for the new value in the other.

Was easier just to revert the associated commits, than find that whilst
it built (albeit with warnings)
haltalk could not make any sense of the data passed.

[John Morris]

Dennis, I think I have a fix in the below branch. If you could give it a test before I submit a PR, I'd be grateful.

https://github.com/zultron/machinekit/tree/pr-fix-hm2-pci

I'd also appreciate if you could paste the contents of your Mesa card's PCI resource file:

/sys/devices/pci0000:00/0000:00:1c.2/0000:02:00.0/0000:03:00.0/resource

Thanks again for doing all the legwork to track down this problem. It was easy to fix with that hard part done for me.

John

________________________________________
From: schoo...@gmail.com <schoo...@gmail.com>

Sent: Friday, March 8, 2019 7:23 PM
To: John Morris; machi...@googlegroups.com; dest...@gmail.com

[Dennis]

Hello John,

I can test it tomorrow...one question though, do I have to build it or are there .deb packages available? I've never built MK before :-)

Here is the content of the resource file:

0x00000000f7e00000 0x00000000f7e0ffff 0x0000000000040200

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

0x0000000000000000 0x0000000000000000 0x0000000000000000

Best regards

Dennis

[schoo...@gmail.com]

I have asked John to submit to the machinekit repo too (currently under machinekit-hal which is still semi experimental)

When he has done that, if you tell me what architecture and distro version (think it is amd64 Stretch?) I will build packages for you
and send them to you

[John Morris]

Hey guys,

PR against legacy MK repo at https://github.com/machinekit/machinekit/pull/1478

Thanks for the PCI resource file contents. I think the change should parse those contents correctly.

John

________________________________________
From: machi...@googlegroups.com <machi...@googlegroups.com> on behalf of schoo...@gmail.com <schoo...@gmail.com>

Sent: Monday, March 11, 2019 12:31 AM

To: machi...@googlegroups.com
Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version

From: schoo...@gmail.com<javascript:> <schoo...@gmail.com<javascript:>>

Sent: Friday, March 8, 2019 7:23 PM

To: John Morris; machi...@googlegroups.com<javascript:>; dest...@gmail.com<javascript:>

Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version


On 08/03/19 09:28, John Morris wrote:
> If I'd double-checked e207745, it would've been clear what was wrong: L3 should have stayed as ULL. D'oh!
>
> Mick, I'd like to revert your commit 730837e, address all problems, and submit a PR. Of course e207745 caused the problem Dennis encountered, and I have a fix for it. However, it doesn't explain why it reverts b55b544 (or more likely I'm missing something). What's the problem there?
No specific problem, looked like that was the other bit of code which
threw a warning reading the same data
so I just reverted it back as was.

Since I had reverted to the old values in one, I expected it to error
looking for the new value in the other.

Was easier just to revert the associated commits, than find that whilst
it built (albeit with warnings)
haltalk could not make any sense of the data passed.
>
> No, I'm not looking forward to silencing warnings in gcc 8. ;(
>
> John
>
> ________________________________________

> From: schoo...@gmail.com<javascript:> <schoo...@gmail.com<javascript:>>

> Sent: Thursday, March 7, 2019 5:35 PM

> To: John Morris; machi...@googlegroups.com<javascript:>

>> From: machi...@googlegroups.com<javascript:> <machi...@googlegroups.com<javascript:>> on behalf of schoo...@gmail.com<javascript:> <schoo...@gmail.com<javascript:>>

>> Sent: Wednesday, March 6, 2019 10:32 PM

>> To: machi...@googlegroups.com<javascript:>

>> Subject: Re: [Machinekit] Mesa 6i25 & 7i76 - Operation not permitted with new Machinekit Version
>>
>> Yes, I read something very similar on stackoverflow Charles.
>> It is probably the way to go, certainly to test out.
>>
>> As I didn't have the ability right now to test on real hardware,
>> I just reverted to be safe.
>>
>> The warnings issue on Jessie and Stretch is as nothing to what is to come
>> in Buster with gcc 8.xx
>>
>> There are some pretty intractable warnings due to the coding style in our
>> legacy code, where buffers are allocated to a defined length
>> and then a subsequent strncpy() or whatever is fixed to that same
>> defined length.
>>
>> The later version of gcc will both warn of potential buffer overflow and of
>> potential data truncation, even if neither are possible in that instance.
>>
>> Removing those, if ever deemed worth spending time on, will mean re-writing
>> a lot of code, possibly with some quite clunky stuff.
>>
>>
>> On 06/03/19 14:08, Charles Steinkuehler wrote:

>>> On 3/6/2019 5:30 AM, schoo...@gmail.com<javascript:> wrote:
>>>> It essentially comes down to 32 bit and 64 bit differences in data type size.
>>>> If you then specify a format size in a printf operation, it will always generate
>>>> a warning under one architecture or another.
>>>> Assigning with a (void*) cast, will do so too, hence the making of L1 and L2
>>>> void * probably
>>> I don't have time to test this in Machinekit, but I've solved these
>>> sort of issues using the intptr_t data type (which changes size based
>>> on the architecture), so something like:
>>>
>>> unsigned intptr_t L1, L2;
>>> unsigned long L3;
>>>
>>> Another option (since intptr_t isn't guaranteed to be available and
>>> I'm not 100% the pointer casts required for fscanf wouldn't throw a
>>> warning) is to make a union and overlap a pointer with an integer
>>> type, eg:
>>>
>>> union foo {
>>> unsigned long long foo_long;
>>> void *foo_ptr;
>>> }
>>>
>>> ...then use the appropriate type where needed.
>>>
>> --
>> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
>> ---
>> You received this message because you are subscribed to the Google Groups "Machinekit" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com<javascript:>.

>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com<mailto:machinekit+...@googlegroups.com>.

Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com<mailto:machinekit+...@googlegroups.com>.

[schoo...@gmail.com]

If you didn't get this ( I think gmail did not like the attachments )
contact me direct and I will upload them somewhere you can find.

On 10/03/19 17:14, schoo...@gmail.com wrote:
> Dennis
>
> Attached are Stretch amd64 packages for rt-preempt of Johns PR
> (if that is not what you need, let me know)
>
> Install by the same method I outlined to revert to the old packages
> that worked, at the beginning of this thread.
>
> regards