More about 2.4.3 timer problems
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.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More about 2.4.3 timer problems
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.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More about 2.4.3 timer problems
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, (c0 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.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Won't Power down (Was: More about 2.4.3 timer problems)
On Tue, 17 Apr 2001, Andrew Morton wrote: :viking wrote: :> :> Incidentally, Andrew, thanks for that patch. : :My brain is fading. Which patch was that? Gee! 8-) and you suggested it to me! It was the patch against 2.4.3-pre6 which corrected the system clock slowing down, due to the interrupts being disabled for too long in framebuffer mode. Well, it worked! I'm using it now, and as I mentioned in the past email, my only trouble now is the non-powering down of the machine. Ah well, again, thanks for monitoring.And here's a few lines to add to that patch too...your patch had neglected to turn on printk for all modules, and when I compiled my kernel, that was fine, but my modules couldn't see printk()! --- linux-2.4.3-pre6/kernel/Makefile Sun Apr 15 20:00:00 2001 +++ lk/kernel/Makefile Sun Apr 15 21:00:00 2001 @@ -12,1 +12,1 @@ - export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o + export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o printk.o 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.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
System clock loses time at approx 17 secs per two hours
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. (Tarballs -
wonderful things!)
However, I noticed that the kernel timer loses seconds over time with both the
2.4.2 and 2.4.3 kernels (seems to be at a steady rate...), and the rate of
loss is NOT related to the CMOS clock. I compared against a 2.2.18 kernel,
which lost about 1 second in 14 hours - about what I'd expect with my
machine).
Now, has anybody else noticed their 2.4.x kernel losing time? If so, and
anyone knows how I can fix it so it behaves like 2.2.18, I'd be grateful.
Can't say I like the April Fools release on "behalf" of Linus.
===
Some relevant data:
Linux version 2.4.3 ([EMAIL PROTECTED])
(gcc version 2.95.3 19991030 (prerelease)) #2 Sat Mar 31 09:52:39 NZST 2001
Software present (among others)
Gnu C 2.95.3 Gnu make 3.77
binutils 2.9.5.0.31 Linux C Library2.2.2
Dynamic linker (ldd) 2.2.2
Processor information (from /proc/cpuinfo) for a Cyrix-M II-300:
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : M II 3.5x Core/Bus Clock
stepping: 8
cpu MHz : 233.030
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr
bogomips: 465.30
Loaded driver and hardware information (/proc/ioports, /proc/iomem)
==Drivers==
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0220-022f : soundblaster
02f8-02ff : serial(auto)
0300-031f : eth0
0376-0376 : ide1
0388-038b : Yamaha OPL3
03c0-03df : vesafb
03f6-03f6 : ide0
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
4000-400f : Silicon Integrated Systems [SiS] 5513 [IDE]
4000-4007 : ide0
4008-400f : ide1
e000-e07f : Silicon Integrated Systems [SiS] 5597/5598 VGA
==memory info==
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-01cf : System RAM
0010-001e9c4f : Kernel code
001e9c50-002445d7 : Kernel data
0800-082f : vesafb
e100-e13f : Silicon Integrated Systems [SiS] 5597/5598 VGA
e140-e140 : Silicon Integrated Systems [SiS] 5597/5598 VGA
e141-e141 : Rockwell International HCF 56k V90 FaxModem
[7.5.] PCI information ('lspci -vvv' as root)
==PCI Information==
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 10)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR-
Region 1: I/O ports at
Region 2: I/O ports at
Region 3: I/O ports at
Region 4: I/O ports at 4000 [size=16]
00:0b.0 Serial controller: Rockwell International HCF 56k V90 FaxModem (rev 01)
(prog-if 00 [8250])
Subsystem: Aztech System Ltd MDP3858SP-A SVD Modem
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=32K]
--
/| _,.:*^*:., |\ 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.39in LOTR : Let others follow it who can!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
