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