tech-kern archive

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

Re: thousands of callout_cpu0



In article <47472dbca84.6456660b%mail.owl.de@localhost>,
Frank Wille  <frank%phoenix.owl.de@localhost> wrote:
>Hi!
>
>While debugging a different problem I checked the callout list with ddb(4)
>on my Amiga and saw this:
>
>db> callout
>hardclock_ticks now: 825
>    ticks  wheel                  arg  func
>      -26 -1/-256                   0  pffasttimo
>  4529516 -1/-256              4520a0  callout_cpu0
>  4529521 -1/-256              4520a8  callout_cpu0
>  4529526 -1/-256              4520b0  callout_cpu0
>  4529531 -1/-256              4520b8  callout_cpu0
>  4529536 -1/-256              4520c0  callout_cpu0
>  4529541 -1/-256              4520c8  callout_cpu0
>  4529546 -1/-256              4520d0  callout_cpu0
>  4529551 -1/-256              4520d8  callout_cpu0
>  4529556 -1/-256              4520e0  callout_cpu0
>  4529561 -1/-256              4520e8  callout_cpu0
>  4529566 -1/-256              4520f0  callout_cpu0
>  4529571 -1/-256              4520f8  callout_cpu0
>  4529577 -1/-256              452100  callout_cpu0
>  4529582 -1/-256              452108  callout_cpu0
>  4529587 -1/-256              452110  callout_cpu0
>...
>  4534507 -1/-256              454088  callout_cpu0
>791670873 -1/-256              454090  callout_cpu0
>2002868682  -1/-256           2f300000  ?
>
>There must be more than a thousand of callout_cpu0 entries with a ticks
>value that looks like a pointer (4529516 == 0x451d6c), after only a few
>seconds of booting into single user.
>
>
>The problem exists since at least 7.99.4 (7.0 is ok). I saw it on several
>architectures, like i386, ppc and m68k.
>
>Any idea what happened here?

I changed the ddb callout code so that it is usable from crash(8). 
Is that the change that broke it? Can you revert kern_timeout.c and
see if that fixes it?

christos



Home | Main Index | Thread Index | Old Index