[LTP] [PATCH V3] syscalls/timer_settime01: Make sure the timer fires

Cyril Hrubis chrubis@suse.cz
Fri Jul 24 15:29:13 CEST 2020


Hi!
> >> When tesing timer_settime01 on 3.10.0-1136.el7.x86_64, this case fails
> >> whether we use any type clock.
> >>
> >> timer_settime01.c:174: PASS: timer_settime(CLOCK_BOOTTIME) passed
> >> timer_settime01.c:164: FAIL: timer_gettime(CLOCK_BOOTTIME_ALARM) reported
> >> bad values (0: 678013000): SUCCESS (0)
> >> timer_settime01.c:174: PASS: timer_settime(CLOCK_BOOTTIME_ALARM) passed
> >> timer_settime01.c:164: FAIL: timer_gettime(CLOCK_REALTIME_ALARM) reported
> >> bad values (0: 358240000): SUCCESS (0)
> >> timer_settime01.c:174: PASS: timer_settime(CLOCK_REALTIME_ALARM) passed
> >> timer_settime01.c:174: PASS: timer_settime(CLOCK_TAI) passed
> > 
> > Can you share the complete test log? I am not sure if only the _ALARM
> > cocks are failing or all. You are getting values in the order of
> > 300-700 ms, while the max value can't be greater than 50 ms. So seems
> > like a kernel issue to me. Over that, both _ALARM type clocks weren't
> > supported before 3.11 and looks like your kernel version is 3.10.
> Yes, only _ALARM fails. I  only find a kernel patch (commit 
> 11ffa9d6065f344  timerfd: Add alarm timers) introduced alarm clock types 
> for timefd in kernel 3.11 and  a kernel patch (commit 9a7adcf5c6dea63d 
> timers: Posix interface for alarm-timers)  in kernel 3.1. It seems my 
> kernel version has supported this two alarm clock, but not sure why this 
> case fails.

This is on RHEL kernel that has backported the _ALARM support right? So
this may as well be case of badly bacported patch...

-- 
Cyril Hrubis
chrubis@suse.cz


More information about the ltp mailing list