Re: Unexpected switches to in-band

["Łukasz Majewski" <lukma@nabladev.com>]

Hi Giulio,

> Again, PocketBeagle 2 (TI AM6254). I get errors such as the below:
> 
> debian@BeagleBone:~$ sudo latmus -m -H20 -T 500s
> warming up on CPU0 (not isolated)...
> RTT|  00:00:01  (user, 1000 us period, priority 98, CPU0-noisol)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat
> best|--lat worst RTD|      4.957|     10.135|     22.647|       0|
>  0|      4.957|     22.647 RTD|      4.977|     10.107|     23.112|
>     0|     0|      4.957|     23.112 RTD|      0.948|     14.831|
> 52.911|       0|     0|      0.948|     52.911 RTD|      4.084|
> 9.548|     24.404|       0|     0|      0.724|    122.540 RTD|
> 4.195|     10.080|     50.350|       0|     0|      0.724|    122.540
> ---|-----------|-----------|-----------|--------|------|-----------------------
> RTS|   -982.336|     11.935|  12357.665|      22|     2|
> 00:02:36/00:08:20
> 
> *** WARNING: unexpected switches to in-band mode detected,
>               latency figures displayed are NOT reliable.
>               Please submit a bug report upstream.
> -- aborting
> 
> Possibly unrelated, it also happens that when I run our program,
> which runs with a period of 360us using 15% of CPU, it normally works
> OK, but occasionally I get _large_ underruns (like 3 to 5 ms). I
> haven't started debugging that yet, and I am not entirely sure it's
> EVL's fault, but I thought it may be worth mentioning it here.
> 
> This is on a kernel I put together: I applied the EVL commits that
> are at the tip of v6.12.y-evl-rebase on top of the TI
> v6.12.43-ti-arm64-r53 kernel plus the beagleboard patches. Here's a
> link, FYI
> https://github.com/giuliomoro/linux/tree/v6.12.43-ti-arm64-r53-bb-evl
> 
> I appreciate this may be a bit too far from mainline to ask for
> specific help, but I am wondering what the general approach to
> problem solution is here: what would make a the latmus thread
> unexpectedly switch to in-band?

I can report the same issue on:
https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commits/v6.6.69-evl1-rebase?ref_type=tags

With guidance (and huge help) from Phillipe I'm now ftracing the
evl core with latmus to check what can cause the issue.

In my case I do use two simple test programs to allocate C++ <vector> -
10 GiB of memory each.

It seems like latmus is trying at some point access some evicted from
cache memory page...

The reported switch to in-band (the execution path) seems to be correct
and expected. The real problem seems to be that at some point in time,
the raw_copy_from_user() (at linux-evl/drivers/evl/latmus.c):1126
causes the X86_PF_USER (user mode access) + X86_PF_INSTR (fault was an
instruction fetch) exceptions.

> 
> Thanks,
> Giulio
> 


-- 
Best regards,

Lukasz Majewski

--
Nabla Software Engineering GmbH
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschftsfhrer : Stefano Babic