DragonFly bugs List (threaded) for 2006-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: integer divide by zero panic in kern_synch.c
:hey,
:
:i recently got an integer divide by zero panic at:
:#19 0xc01a08a8 in updatepcpu (lp=3D0xc2bb4794, cpticks=3D0, ttlticks=3D0)
: at /usr/src/sys/kern/kern_synch.c:249
:249 acc =3D (cpticks << FSHIFT) / ttlticks;
:
:it's a 1.4-release box (though kernel is from january) which does=20
:nothing but pf/bridge
:
:kernel dump available upon request
:
:cheers
: simon
I would definitely like to see that dump. There is some fragileness
in that code path but I'm not exactly sure how it gets to that point.
lwp_cpbase and cpbase have to be integer multiples of
gd_schedclock.periodic, so the code path should result in a value of
at least 1 for nticks. But sometimes it doesn't.
...
} else if (lp->lwp_cpbase != cpbase) {
/*
* Adjust estcpu if we are in a different tick. Don't waste
* time if we are in the same tick.
*
* First calculate the number of ticks in the measurement
* interval.
*/
nticks = (cpbase - lp->lwp_cpbase) / gd->gd_schedclock.periodic;
updatepcpu(lp, lp->lwp_cpticks, nticks);
The two possibilities are (1) A field is overflowing or (2) on an SMP
system the cpus have different base offsets and a migrated process can
wind up with a non-integer-multiple.
It's easy to fix, just by adding some code to check for a non-zero nticks,
but I'd like to try to find the cause before I hack in that test.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]