Issue #2951 has been updated by zhtw.
Checked on my real machine using 4.6 kernel with your patch. This specific test
passes now.
Bug #2951: clock_gettime always repots 0 sec, 0 nsec
http://bugs.dragonflybsd.org/issues/2951#change-12998
* Author: zhtw
Issue #2951 has been updated by swildner.
I've pushed a fix to master fixing these issues on real kernels.
See
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c1b9c0932e482bb6a37eb190a5b504b270d2166d
Why it doesn't work for the vkernel, I haven't had much time investigating.
Can you
Issue #2951 has been updated by zhtw.
Thanks!
It should definitely solve the problem with the nsec overflow. But turned out I
was very lucky with this test, because can't reproduce the overflow anymore.
But I still have this chezscheme test that fails.
In any case, I will be able to confirm
Issue #2951 has been updated by swildner.
Sorry, there was one more typo in the overflow fix, fixed in
https://leaf.dragonflybsd.org/~swildner/process_cputime4.diff
Bug #2951: clock_gettime always repots 0 sec, 0 nsec
Issue #2951 has been updated by swildner.
Yes, get_curthread_cputime() was wrongly adding so that tv_nsec could become >=
10.
Please check https://leaf.dragonflybsd.org/~swildner/process_cputime3.diff on a
real kernel. I've not yet looked at the vkernel issues.
This patch adds a fix
Issue #2951 has been updated by zhtw.
When I said million, I of course meant billion. But the example is correct
anyway.
I am also looking at the code, but my experience with kernel programming is
nearly non-existing.
Bug #2951: clock_gettime always
Issue #2951 has been updated by zhtw.
This is interesting. When you asked me to doublecheck if clock_gettime works
with CLOCK_THREAD_CPUTIME_ID (because you said it works for you), I actually
tested it on real kernel. So it does work on real kernel.
But now I'm proceeding with testing
Issue #2951 has been updated by zhtw.
Thank you. Just tried it. The result is still 0. But again, I'm testing in
under a vkernel.
Did you test it on a real kernel?
Is there anything I could do wrong here?
Bug #2951: clock_gettime always repots 0 sec,
Issue #2951 has been updated by zhtw.
I was able to run 4.4 vkernel with your patch (but with ru replaced with p_ru).
Unfortunately it did not help, I still see 0 nsec both in case of
CLOCK_PROCESS_CPUTIME_ID and CLOCK_PROF.
(Still can't run 4.6 vkernel.)
Issue #2951 has been updated by swildner.
CLOCK_THREAD_CPUTIME_ID isn't broken here, as far as I can see. Are you sure it
returns 0 for you?
CLOCK_PROF and CLOCK_VIRTUAL always return 0 here. Not sure what's the cause.
Please check this patch for CLOCK_PROCESS_CPUTIME_ID ->
Issue #2951 has been updated by zhtw.
I just noticed that in the header sys/time.h there is a whole lot of CLOCK_*
constants. Some of them are FreeBSD-specific, some Linux-specific. So
technically, but since (at least) CLOCK_PROF is mentioned in the man page, it
should work.
Btw, I checked
11 matches
Mail list logo
