DragonFlyBSD

: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