Ed Sweetman <[email protected]> writes:
> why doesn't the startup of the kernel choose
> the pmtimer based on if it detects the system is a dual core proc with
> smp enabled?
The 64bit kernel does this. I believe John Stultz also implemented
it for 32bit, but it might not have hit mainline yet.
Sometimes people sabotate it though by not compiling in crucial
parts like ACPI - (no ACPI - no pmtimer)
> And if the pmtimer doesn't fix this sync issue, is
> there a fix out there? Currently with 2.6.16-rc1-mm5 the
> non-customized boot args to the kernel results in these messages.
pmtimer fixes the issue by not using the TSC at all. So if you
still have timer troubles when using the pmtimer then it's not the TSC to blame.
> Losing some ticks... checking if CPU frequency changed.
> warning: many lost ticks.
> Your time source seems to be instable or some driver is hogging interupts
> rip default_idle+0x2d/0x60
There are unfortunately many different chipset that could cause it.
There was an issue CPU found that could cause this, but it should only happen
on mobile athlon 64.
Sometimes there are timer routing problems on some Nvidia and ATI chipsets.
Assuming you're using 64bit then you can try apicmaintimer or apicpmtimer.
On 32bit you can try pci=noacpi noapic
-Andi
P.S.: I would recommend to approach the issue like visiting a doctor. If you
don't see the full picture don't blame a single piece like the TSC.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]