DragonFly BSD
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

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 23 Apr 2006 08:58:46 -0700 (PDT)

: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
:   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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]