In article <47472dbca84.64566...@mail.owl.de>, Frank Wille <fr...@phoenix.owl.de> 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
