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 #2952 has been updated by tuxillo.
Category changed from Kernel to vkernel
Status changed from New to Feedback
Assignee set to tuxillo
Hi,
Can you boot it with -v to see if we get a better idea where it might be
crashing?
Also, can you 'addr2line -f -e /var/vkernel/4.6/boot/kernel/kernel
Issue #2952 has been reported by zhtw.
Bug #2952: vkernel crashes during boot
http://bugs.dragonflybsd.org/issues/2952
* Author: zhtw
* Status: New
* Priority: Normal
* Assignee:
* Category: Kernel
* Target version:
Issue #2952 has been updated by tuxillo.
Hi,
If vkernel 4.6 hangs there you have to cherry-pick the commits I mentioned.
Let me know how it works for you.
Cheers,
Antonio Huete
Bug #2952: vkernel crashes during boot
Issue #2952 has been updated by zhtw.
Only now I noticed that I compiled it with CONFIGARGS=-p option.
After I removed the option, 4.4 vkernel started to work. 4.6 however now hangs:
a@kl:~$ sudo /var/vkernel/4.6/boot/kernel/kernel -m 2g -r /vhost/dev/root.img
-I auto:bridge0 -d -p
Issue #2952 has been updated by zhtw.
Booting with -v gives exactly the same output.
addr2line doesn't seem to recognize the line:
a@kl:/usr/src$ sudo addr2line -f -e /var/vkernel/4.6-p/boot/kernel/kernel
0x6ef9b9
.mcount
??:?
After cherry-picking the two commits it still doesn't work, but
Issue #2952 has been updated by zhtw.
Just to be clear, the summary:
When compiled with CONFIGARGS=-p, neither 4.4 nor 4.6 work -- both crash.
When compiled without this option, 4.4 works, but 4.6 hangs.
After cherry-picking:
Without CONFIGARGS=-p 4.6 works.
With it it still crashes.
Anyway,
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.
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 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.
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
13 matches
Mail list logo
