Hi There
I have just hooked up my new via mainboard
(http://www.viaembedded.com/product/epia_ms_spec.jsp?motherboardId=281)
and installed the latest linux kernel on the system (2.6.8).
Unfortiunatly something is misbehaving with the timer/kernel interaction.
A snippet from dmesg:
agpgart: Detected VIA CLE266 chipset
agpgart: Maximum main memory to use for agp memory: 424M
agpgart: AGP aperture is 4M @ 0xe7000000
Losing some ticks... checking if CPU frequency changed.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
NET: Registered protocol family 17
Linux Kernel Card Services
options: [pci] [cardbus] [pm]
Losing some ticks... checking if CPU frequency changed.
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0340d60(lo)
IPv6 over IPv4 tunneling driver
Losing some ticks... checking if CPU frequency changed.
eth0: no IPv6 routers present
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: overridden by ACPI.
mtrr: 0xe0000000,0x1000000 overlaps existing 0xe0000000,0x800000
Losing some ticks... checking if CPU frequency changed.
padlock: Using VIA PadLock ACE for AES algorithm (multiblock).
Losing some ticks... checking if CPU frequency changed.
Losing some ticks... checking if CPU frequency changed.
Losing some ticks... checking if CPU frequency changed.
Losing some ticks... checking if CPU frequency changed.
.....
and then finally
Losing some ticks... checking if CPU frequency changed.
Losing some ticks... checking if CPU frequency changed.
Losing too many ticks!
TSC cannot be used as a timesource.
Possible reasons for this are:
You're running with Speedstep,
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.
Furthermore editors like jed and emacs takes forever to start. A "strace
emacs /somefile" shows that it hangs in a poll right after gettimeofday.
Any clues to what is wrong and how I go about fixing it?!
Regards Thomas, Denmark
> Losing some ticks... checking if CPU frequency changed.
> Losing some ticks... checking if CPU frequency changed.
> Losing too many ticks!
> TSC cannot be used as a timesource. Possible reasons for this are:
> You're running with Speedstep,
> You don't have DMA enabled for your hard disk (see hdparm),
> Incorrect TSC synchronization on an SMP system (see dmesg).
> Falling back to a sane timesource now.
>
>
> Furthermore editors like jed and emacs takes forever to start. A "strace
> emacs /somefile" shows that it hangs in a poll right after gettimeofday.
>
> Any clues to what is wrong and how I go about fixing it?!
>
> Regards Thomas, Denmark
>
I don't have a clue but the same problem on an amd64 system. I am
running a 64bit 2.6.9-rc1-mm4 kernel on my machine and if i add the boot
parameter report_lost_ticks it reports the same messages as your
machine. Since 2.6.7 there is this parameter, before the lost ticks
where reported all the time. I always thought that this is a 64bit
problem because i have heard from others which have this problem too.
Why are we loosing ticks? On my system it happens almost when an acpi
event occurs. I know that they aren't reported anymore but I don't like
the thing that my processor (or timesource) looses something.
Georg Schild
On Tue, Sep 14, 2004 at 11:53:16AM +0200, Georg Schild wrote:
> I don't have a clue but the same problem on an amd64 system. I am
Do you have a VIA chipset on this system?
Regards Thomas
Thomas S. Iversen wrote:
> Any clues to what is wrong and how I go about fixing it?!
Well, I made a kernel without acpi support and the problem went away.
Any clues to why that solved the problem?
Regards Thomas, Denmark
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas S. Iversen wrote:
| Thomas S. Iversen wrote:
|
|> Any clues to what is wrong and how I go about fixing it?!
|
|
| Well, I made a kernel without acpi support and the problem went away.
| Any clues to why that solved the problem?
Frequency scaling or anything alike? Have you tried using acpi pm timer?
This should prevent you from losing ticks.
Prakash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBSAQAxU2n/+9+t5gRAlw9AJ0ZXpDxhh+fhhmBrCIrplLFwNriSACgskqi
1xrE4nBXzzMoAjupSPecH48=
=ia4X
-----END PGP SIGNATURE-----
Prakash K. Cheemplavam wrote:
> | Well, I made a kernel without acpi support and the problem went away.
> | Any clues to why that solved the problem?
>
> Frequency scaling or anything alike? Have you tried using acpi pm timer?
> This should prevent you from losing ticks.
Yeah, I found the acpi pm timer (a new option) and the problem went away.
I haven't got any frequency scaling included, so it's simply ACPI calls
which
makes the system lose to many ticks :-(
Thomas
> Do you have a VIA chipset on this system?
Yes, it's a laptop with a k8t800 chipset. But I have some problems with
the soulution to disable ACPI though it's a laptop and diabling ACPI
would say no frequency scaling, no fan regulation etc. Does the PM_Timer
work on amd64 or isn't it just for x86? I think that i had heard about
that it wouldn't bring any effect on x86-64. We have discussed this
issue for a long while on the gentoo amd64 forums though it looks like
that just amd64 users have this problems.
Here a link but without any useful solution, we had the things with
disabling ACPI or enabling the PM-Timer already.
http://forums.gentoo.org/viewtopic.php?t=191716
As I know this problem started with kernels later than 2.6.5, don't know
the exact version, end ended with kernel 2.6.8 which only reports lost
ticks > 100 by default. But we still loose ticks and i don't like this
even if i don't see it anymore on dmesg.
Georg Schild