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!
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.
-
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!
> 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
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!
>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 [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
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!
Sorry for such a stupid question, but I'm stumped (it doesn't take much).
modprobe reports that hotplug_path is unresolved when it processes
usbcore. CONFIG_HOTPLUG is defined, so it seems that hotplug_path is
defined and EXPORTed in kernel/kmod.c, so I'm unsure what the problem is.
Thanks, Ryan
On Wed, 4 Apr 2001, Ryan Mack wrote:
> Sorry for such a stupid question, but I'm stumped (it doesn't take much).
> modprobe reports that hotplug_path is unresolved when it processes
> usbcore. CONFIG_HOTPLUG is defined, so it seems that hotplug_path is
> defined and EXPORTed in kernel/kmod.c, so I'm unsure what the problem is.
I have noticed that sometimes when I change my .config doing a make dep,
make bzImage, make modules, is not enough. So, I back up my .config, run
make mrproper, copy the .config back, and then make dep, etc. The option
I know causes this is netfilter under 2.4.2.
> Thanks, Ryan
Hope this helps.
Bart.
--
WebSig: http://www.jukie.net/~bart/sig/