[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