aarch64 and kqueue timer events

Matthew Grooms <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
Hi all,

I'm seeing some strange behavior with kqueue timers on my aarch64 host. 
Here is a simple test program that I've compiled on both amd64 and 
aarch64. It just sets up a simple kqueue timer with a loop that waits 
for the event to fire every 3 seconds ...

#include <err.h>
#include <time.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/event.h>

int main( int argc, char *argv[] )
{
     int kq = kqueue();
     if( kq < 0 )
         err( 1, "failed to obtain kqueue handle" );

     struct kevent ke;
     EV_SET( &ke, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 3000, 0 );
     if( kevent( kq, &ke, 1, NULL, 0, NULL ) < 0 )
         err( 1, "failed to add kevent timer filter" );

     printf( "started at %i\n", (int)time(NULL) );

     while( true )
     {
         int r = kevent( kq, NULL, 0, &ke, 1, NULL );
         if( r < 0 )
             err( 1, "failed to read kevent list" );

         printf( "timer fired %i times at %i\n", r, (int)time(NULL) );
     }

     return 0;
}

When I compile and run the code on an amd64 host, everything works as 
expected. The event timer expires once every 3 seconds ...

mgrooms@amd64:~/devel$ cc test.cpp -o test && ./test
started at 1627175311
timer fired 1 times at 1627175314
timer fired 1 times at 1627175317
timer fired 1 times at 1627175320

However, when I compile and run the same code on an aarch64 host ( rpi4b 
), something very different happens. The event timer expires after 3 
seconds the first time. But each subsequent expiration is for exactly 
twice the defined interval, 6 seconds ...

mgrooms@aarch64:~/devel$ cc test.cpp -o test && ./test
started at 1625789207
timer fired 1 times at 1625789210
timer fired 1 times at 1625789216
timer fired 1 times at 1625789222

Any idea what's going on here? Seems like a bug in somewhere on the arm 
side.

Thanks in advance,

-Matthew
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.