Date: Tue, 30 Nov 2010 00:01:52 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Giovanni Trematerra <giovanni.trematerra@gmail.com> Cc: Attilio Rao <attilio@freebsd.org>, David Rhodus <sdrhodus@gmail.com>, freebsd-current@freebsd.org Subject: Re: panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726 Message-ID: <4CF422D0.7050702@FreeBSD.org> In-Reply-To: <AANLkTikn0rkE4CncgD%2BSwg4GDYMAXhuKWDehR_sBAxnH@mail.gmail.com> References: <AANLkTimy-2oSgy8E2D-=WO41%2BdSem8MY=ZNCSSH3bBt%2B@mail.gmail.com> <201011291007.37044.jhb@freebsd.org> <4CF3E68C.4050300@FreeBSD.org> <AANLkTimAKS_PcnLb_8=zJq-mNd7B=wwoOYu_6LGYg3bk@mail.gmail.com> <AANLkTikn0rkE4CncgD%2BSwg4GDYMAXhuKWDehR_sBAxnH@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 hardclock_anycpu (kern_clock.c). Problem with many ticks at CPU startup should be fixed by r214987. > I haven't a patch only a dirty hack just to make sure we won't be > running for more than 5s solid, if we have a huge number of ticks in > input to sched_tick, which is something that ULE can still handle. > > Hope this helps. > > diff -r d16464301129 sys/kern/kern_clock.c > --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 > +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 > @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) > PROC_SUNLOCK(p); > } > thread_lock(td); > - sched_tick(cnt); > + sched_tick((cnt< (hz*10)/2) ? cnt : (hz*10)/2); > td->td_flags |= flags; > thread_unlock(td); > > -- > Giovanni Trematerra -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CF422D0.7050702>