On 29.11.2010 23:47, Giovanni Trematerra wrote:
I got it on QEMU and assumed that QEMU was not doing a proper job of
distributing run-time amongst cores (so VirtualBox???).
I figured out that sched_tick is being passed a huge number of ticks elapsed
for the cpu at startup, in my case, by hardcloc
>>>
>>>> -DR
>>>>
>>>> coke.fun dumped core - see /var/crash/vmcore.2
>>>>
>>>> Fri Nov 26 14:50:48 UTC 2010
>>>>
>>>> FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov
>>>>
d core - see /var/crash/vmcore.2
>>>
>>> Fri Nov 26 14:50:48 UTC 2010
>>>
>>> FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov
>>> 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC
>>> i386
>>>
>>>
:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC
i386
panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664
ftick 516947 ltick 517947 tick pri 2726
I ran the numbers and assuming a hz of 1000, this requires you to have a very
large value for ts_ticks (about (2726
gt; 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC
> i386
>
> panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664
> ftick 516947 ltick 517947 tick pri 2726
I ran the numbers and assuming a hz of 1000, this requires you to have a very
large value
