More about 2.4.3 timer problems

More about 2.4.3 timer problems

[Eric Gillespie]

First off, CC: back to me, as my machine can't handle an estimated 200
messages a day for me to sign up to the list 8-( - Anyway..

I updated my kernel to 2.4.3 when the patch was released. As I said earlier, I
noticed my timer losing a few seconds over the space of a couple of
hours.  Well, I have since found out that the amount of time lost is
proportional to the load on the machine: the heavier the load, the more time
lost.

I found this out while I was compiling a kernel, incidentally:

kernel-2.4.3 (and I am trying this without the TSC enabled, but it hasn't
made any difference that I've noticed), other details as before.
I really DON'T want to be running a cron job to re-read the CMOS
clock every minute or so - that's a patch, not a fix.


Output from "time make -j 3 bzImage"

VESA fb mode 1280x1024x16, clock lost 1m 35s in time
996.52 user 166.82 system 23:19.40 elapsed 83% CPU 
(0 avgtext+0 avgdata 0 maxresident)k 
0 inputs+0 outputs (471222 major+583276 minor) pagefaults 0swaps

Same command, fbmode 640x480x24, clock lost 19s in time
751.42 user 89.47 system 18:40.79 elapsed 75% CPU 
(0 avgtext+0 avgdata 0 maxresident)k
0inputs+0outputs (468926 major+578877 minor) pagefaults 0 swaps

Same command, normal (non-fb mode) lost no time off clock.
991.13 user 160.44 system 22:38.15 elapsed 84% CPU 
(0 avgtext+0 avgdata 0 maxresident)k 0 inputs+0 outputs 
(468051 major+577233 minor) pagefaults 0 swaps

Hope this helps out, and by the way, thank you to Mark Hahn & Gerhard Mack for
their suggestions.

-- 
 /|   _,.:*^*:.,   |\           Cheers from the Viking family, 
| |_/'  viking@ `\_| |            including Pippin, our cat
|    flying-brick    | $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/     5.39    in LOTR  : Let others follow it who can!

Re: More about 2.4.3 timer problems

[Andrew Morton]

Eric Gillespie wrote:
> 
>...
> VESA fb mode 1280x1024x16, clock lost 1m 35s in time
> ...
> Same command, normal (non-fb mode) lost no time off clock.

Is due to the 2.4.3 console drivers.  They block interrupts during
console output.  There's a fix in 2.4.2-ac<recent>.

There's also a patch against 2.4.3-pre6 at

	http://www.uow.edu.au/~andrewm/linux/console.html

If you'd care to test the 2.4.3-pre6 patch for a while, that'd
be useful.

-

Re: More about 2.4.3 timer problems

[viking]

Andrew Morton wrote:

> Eric Gillespie wrote:
> >
> >...
> > VESA fb mode 1280x1024x16, clock lost 1m 35s in time
> > ...
> > Same command, normal (non-fb mode) lost no time off clock.
>
> Is due to the 2.4.3 console drivers.  They block interrupts during
> console output.  There's a fix in 2.4.2-ac<recent>.
>
> There's also a patch against 2.4.3-pre6 at
>
>         http://www.uow.edu.au/~andrewm/linux/console.html
>
> If you'd care to test the 2.4.3-pre6 patch for a while, that'd
> be useful.
>

Cool - I'll do that - err, just one question - is a kernel-m.n-preX  a
precursor to kernel-m.n+1?
If that sentence didn't make sense, think back to algebra years.
Thanks again.

--
 /|   _,.:*^*:.,   |\           Cheers from the Viking family,
| |_/'  viking@ `\_| |            including Pippin, our cat
|    flying-brick    | $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/     5.39    in LOTR  : Let others follow it who can!

Re: More about 2.4.3 timer problems

[Alan Cox]

> I updated my kernel to 2.4.3 when the patch was released. As I said earlier, I
> noticed my timer losing a few seconds over the space of a couple of
> hours.  Well, I have since found out that the amount of time lost is
> proportional to the load on the machine: the heavier the load, the more time
> lost.
> 
> VESA fb mode 1280x1024x16, clock lost 1m 35s in time
> 996.52 user 166.82 system 23:19.40 elapsed 83% CPU 

The vesafb / clock sliding problem is fixed in the -ac releases.

Alan

Re: More about 2.4.3 timer problems

[Eric Gillespie]

Err, tried the patch you recommended me to apply to the 2.4.3 source code (not 
the 2.4.3-pre6), but everything else started complaining it couldn't see 
printk() any more.  Any advice?  Thanks...


-- 
 /|   _,.:*^*:.,   |\           Cheers from the Viking family, 
| |_/'  viking@ `\_| |            including Pippin, our cat
|    flying-brick    | $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/     5.39    in LOTR  : Let others follow it who can!

Re: More about 2.4.3 timer problems

[James Simmons]

>Err, tried the patch you recommended me to apply to the 2.4.3 source code
>(not the 2.4.3-pre6), but everything else started complaining it couldn't
>see printk() any more.  Any advice?  Thanks...

Can you tell us your hardware configuration and your kernel configuration.
What do you mean it couldn't see printk any more?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: More about 2.4.3 timer problems

[Eric Gillespie]

On Wed, 4 Apr 2001, James Simmons wrote:

:
:>Err, tried the patch you recommended me to apply to the 2.4.3 source code
:>(not the 2.4.3-pre6), but everything else started complaining it couldn't
:>see printk() any more.  Any advice?  Thanks...
:
:Can you tell us your hardware configuration and your kernel configuration.

This has been mentioned in an earlier message of mine, but basically, I have a
Cyrix M-II machine, 32 meg of ram, 3.4 gig HD, PCI and ISA buses, SiS chipset,
etc etc.

:What do you mean it couldn't see printk any more?

What I meant was that while kernel/printk.c got compiled to printk.o, none of
the modules compiled could then see the function printk(); when I did a depmod
-ae, the unresolved function (and the ONLY function) they all complained about
was printk, even though it appeared in the System.Map file, (c0xxxx T printk)
and, presumably, in the kernel image as well.

I noted that the patch touched printk.c, so wondered what the patch had
done... and I really didn't want to have to compile everything into my kernel
just to get it to work... it's almost like it was a question of scope...

The patch did work to eliminate the clock skew, aside from this printk
problem, but fortunately I was bright enough to have kept an older kernel
tarball around, so I could go back to unpatched version. 

Thanks for keeping in touch... me not being much of a programmer, I can't just
get my hands dirty and fix the patch problem, otherwise, I'd do it.  But
knowing my luck, I'd end up with a kernel that worked six times faster than
anything previously, but wind up destroying the hard disk and CMOS in two
minutes fifteen point three seconds.  And set my monitor on fire too...

-- 
 /|   _,.:*^*:.,   |\           Cheers from the Viking family, 
| |_/'  viking@ `\_| |            including Pippin, our cat
|    flying-brick    | $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/     5.39    in LOTR  : Let others follow it who can!