(ret == 0);
}
Let us know whether you see any problem in handling this race in kernel.
Regards,
Arul
On Thu, Sep 5, 2019 at 9:04 PM Thomas Gleixner wrote:
>
> Arul,
>
> On Thu, 5 Sep 2019, Arul Jeniston wrote:
> > When we adjust the date setting using date command we
return EXIT_SUCCESS;
}
3. Observed the following read failure logs within few minutes.
root@sonic:~/test/exp2# ./timerfdtest
read returned 0 nooftimeo:1392
Regards,
Arul
On Tue, Aug 20, 2019 at 3:12 PM Arul Jeniston wrote:
>
> Hi Tglx,
>
> > Can you please boot something
Hi Tglx,
> Can you please boot something more recent - at least 4.19 LTS - on that
> machine and let it run for a couple of days to check whether there are 'TSC
> ADJUST' related entries in dmesg?
Sure. Would check and update.
Regards,
Arul
hi Tglx
Agreed. Please find the dmesg output below. We see the problem on
[1456773.366951].
Let us know if you find anything suspicious.
[0.00] Linux version 4.9.0-8-amd64
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
6.3.0-18+deb9u1) ) #1 SMP Debian
hi Tglx,
> But for the above scenario:
>
> ktime_get()
> do {
> seq = read_seqcount_begin(_core.seq);
> base = tk->tkr_mono.base;
> nsecs = timekeeping_get_ns(>tkr_mono);
>
> } while (read_seqcount_retry(_core.seq, seq));
>
> So if
hi Tglx,
...
> > > Is the timer expiry and the timerfd_read() on the same CPU or on different
> > > ones?
> >
We have 1+ units running in production. We see this problem ~20
switches in a span of one year time.
The problem is not seen more than once in the same unit. The
occurrence is random
Hi tgls,
> BIOS is the more likely candidate.
We would check BIOS and update.
> We expect TSC not to go backwards. If it does it's broken and not usable as
> a clocksource for the kernel. The problem is that this is not necessarily
> easy to detect.
We used relative timer with
Adding few more data points...
On Fri, Aug 16, 2019 at 10:25 PM Arul Jeniston wrote:
>
> Hi tglx,
>
> Thank you for your comments.
> Please find my commend in-lined
>
> On Fri, Aug 16, 2019 at 4:15 PM Thomas Gleixner wrote:
> >
> > Arul,
> >
>
Hi tglx,
Thank you for your comments.
Please find my commend in-lined
On Fri, Aug 16, 2019 at 4:15 PM Thomas Gleixner wrote:
>
> Arul,
>
> On Fri, 16 Aug 2019, Arul Jeniston wrote:
>
> > Subject: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
> &g
'hrtimer_forward_now()' returns zero due to bigger backward time drift.
This causes timerfd_read to return 0. As per man page, read on timerfd
is not expected to return 0.
This problem is well explained in https://lkml.org/lkml/2019/7/31/442
. This patch fixes this problem.
Signed-off-by: Arul
From: ARUL JENISTON MC
---
fs/timerfd.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index 6a6fc8aa1de7..f5094e070e9a 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -284,8 +284,16 @@ static ssize_t timerfd_read(struct file *file
Hi Team,
We have a query on the implementation linux timer implementation.
We have been running our application on linux kernel 4.9.168 (debian -
stretch) version. We use intel Rangeley 4 cpu system which has tsc
timer. Our application is an multi-threaded program which creates a
monotonic
12 matches
Mail list logo
