Re: [EXTERNAL] Re: Channel Access performance with RTEMS on MVME5500

[Joel Sherrill via Tech-talk <tech-talk at aps.anl.gov>]

Assuming I looked at the right NIC driver, the one used by the beatnik boards doesn't do much for MII status changes. See .mve_ack_link_change. That's not necessarily bad but if the detection/reaction code for the cable being unplugged isn't right, it could explain it.

And FWIW, we consciously kept the legacy network stack around. We knew there were some older boards that didn't have the RAM for libBSD and we recognized that even having capable hardware doesn't mean anyone will port a driver to libBSD. We could have abandoned it but we didn't. It was a conscious effort to not force stack/driver updates for the hardware the EPICS community was using. The legacy stack still being around is a feature of RTEMS being open source -- not a bug. 

--joel

On Thu, Mar 20, 2025 at 8:39 AM Kasemir, Kay via Tech-talk <tech-talk at aps.anl.gov> wrote:

> EPICS Mutexes in an interrupt context … crashes

 

No idea about RTEMS in particular, but you can generally not _take_ a mutex in an interrupt context.

You may be able to _give_ a mutex to wake a thread that’s waiting on that mutex, but details will depend on the OS.

You can use epicsEvent from within an interrupt service routine to signal a thread that it should start doing some work.

 

If the interrupt context currently uses mutexes, it might be best to rewrite it to use epicsEvent and maybe move work out of the interrupt service routine into a thread that’s woken by the event.

 

 

On 2025-03-20, 9:32 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

Hello Alex,

the ‘USE_POSIX_THREAD_PRIORITY_SCHEDULING = NO’' is an EPICS thing.

I don't know exactly what this does as I have never used it with RTEMS.

I think that cancels out the whole point of a priority-based system ;-)

 

All your jobs have a very low priority 253 (in RTEMS) and priority 2 in Posix.

 

Based on my gut feeling, I would recommend setting back to USE_POSIX_THREAD_PRIORITY_SCHEDULING=YES and then

in rtems_init for POSIX_Init() to set the priority high. You can use the code element I sent to you in the last tech-talk-reply.

Then all the interrupt handlers will also get a high priority and I assume that the crashes will also go away.

 

Would you like to try that?

 

Good luck,

Heinz

 

 

 

> On 20. Mar 2025, at 12:50, Wells, Alex (DLSLtd,RAL,LSCI) <alex.wells at diamond.ac.uk> wrote:

>

> Hi Heinz,

>

> Thank you for the information. There's definitely something fishy going on with the thread priorities somewhere; it seems that everything is being started with the same priority.

>

> I will also note that we are building RTEMS with "USE_POSIX_THREAD_PRIORITY_SCHEDULING = NO". This appears to be required, as we use EPICS Mutexes in an interrupt context, and if we leave this set to "YES" we see a crashes. Could this be related to the oddities below?