Hi all, I'm running 2.6.14-rt22 and just noticed something strange. I
have not installed it in all machines yet, but in some of them (same
hardware as others that seems to work fine) the TSC was selected as the
main clock for the kernel. Remember this is one of the Athlon X2
machines in which the TCS's drift...
dmesg shows this:
PM-Timer running at invalid rate: 2172% of normal - aborting.
and after that the tsc is selected as the timing source.
Time: tsc clocksource has been installed.
The strange thing is that this is the same hardware as on other
machines. I have to install this kernel on more machines, will report
then...
This is what's available after the boot:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies tsc pit
So I selected by hand:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
pit
On the machine that's not selecting tsc the options are:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies tsc pi
(and acpi_pm is selected, of course).
I think TSC's should never be selected on this hardware and it is known
not to work.
-- Fernando
On Fri, 2005-12-09 at 15:48 -0800, Fernando Lopez-Lezcano wrote:
> Hi all, I'm running 2.6.14-rt22 and just noticed something strange. I
> have not installed it in all machines yet, but in some of them (same
> hardware as others that seems to work fine) the TSC was selected as the
> main clock for the kernel. Remember this is one of the Athlon X2
> machines in which the TCS's drift...
>
> dmesg shows this:
> PM-Timer running at invalid rate: 2172% of normal - aborting.
>
> and after that the tsc is selected as the timing source.
> Time: tsc clocksource has been installed.
>
> The strange thing is that this is the same hardware as on other
> machines.
Aha! Yes but no. The BIOS makes a difference. The first BIOS that has
support for the X2 processors on this particular motherboard works fine
with regards to the acpi_pm clock source, subsequent ones make linux say
things like:
PM-Timer running at invalid rate: 2159% of normal - aborting.
and then tsc is selected as the clock source...
> I have to install this kernel on more machines, will report
> then...
>
> This is what's available after the boot:
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> jiffies tsc pit
>
> So I selected by hand:
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> pit
>
> On the machine that's not selecting tsc the options are:
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> acpi_pm jiffies tsc pi
> (and acpi_pm is selected, of course).
>
> I think TSC's should never be selected on this hardware and it is known
> not to work.
-- Fernando
On Fri, 2005-12-09 at 15:48 -0800, Fernando Lopez-Lezcano wrote:
> Hi all, I'm running 2.6.14-rt22 and just noticed something strange. I
> have not installed it in all machines yet, but in some of them (same
> hardware as others that seems to work fine) the TSC was selected as the
> main clock for the kernel. Remember this is one of the Athlon X2
> machines in which the TCS's drift...
>
> dmesg shows this:
> PM-Timer running at invalid rate: 2172% of normal - aborting.
Hm. That's odd. Either your PM-Timer isn't running at the right
frequency, or something is going wrong in the calibration. I'm
suspecting its the second. If you add a "return 0;" to the top of
verify_pmtmr_rate() in drivers/clocksource/acpi_pm.c does the acpi_pm
timer keep proper time?
thanks
-john
On Fri, 2005-12-09 at 17:21 -0800, Fernando Lopez-Lezcano wrote:
> On Fri, 2005-12-09 at 15:48 -0800, Fernando Lopez-Lezcano wrote:
> > Hi all, I'm running 2.6.14-rt22 and just noticed something strange. I
> > have not installed it in all machines yet, but in some of them (same
> > hardware as others that seems to work fine) the TSC was selected as the
> > main clock for the kernel. Remember this is one of the Athlon X2
> > machines in which the TCS's drift...
> >
> > dmesg shows this:
> > PM-Timer running at invalid rate: 2172% of normal - aborting.
> >
> > and after that the tsc is selected as the timing source.
> > Time: tsc clocksource has been installed.
> >
> > The strange thing is that this is the same hardware as on other
> > machines.
>
> Aha! Yes but no. The BIOS makes a difference. The first BIOS that has
> support for the X2 processors on this particular motherboard works fine
> with regards to the acpi_pm clock source, subsequent ones make linux say
> things like:
> PM-Timer running at invalid rate: 2159% of normal - aborting.
> and then tsc is selected as the clock source...
So you're saying the newer BIOS detects the PM timer as running too fast
or is it the older ones?
thanks
-john
On Fri, 9 Dec 2005, john stultz wrote:
> On Fri, 2005-12-09 at 17:21 -0800, Fernando Lopez-Lezcano wrote:
> > On Fri, 2005-12-09 at 15:48 -0800, Fernando Lopez-Lezcano wrote:
> > > Hi all, I'm running 2.6.14-rt22 and just noticed something strange. I
> > > have not installed it in all machines yet, but in some of them (same
> > > hardware as others that seems to work fine) the TSC was selected as the
> > > main clock for the kernel. Remember this is one of the Athlon X2
> > > machines in which the TCS's drift...
> > >
> > > dmesg shows this:
> > > PM-Timer running at invalid rate: 2172% of normal - aborting.
> > >
> > > and after that the tsc is selected as the timing source.
> > > Time: tsc clocksource has been installed.
> > >
> > > The strange thing is that this is the same hardware as on other
> > > machines.
> >
> > Aha! Yes but no. The BIOS makes a difference. The first BIOS that has
> > support for the X2 processors on this particular motherboard works fine
> > with regards to the acpi_pm clock source, subsequent ones make linux say
> > things like:
> > PM-Timer running at invalid rate: 2159% of normal - aborting.
> > and then tsc is selected as the clock source...
>
> So you're saying the newer BIOS detects the PM timer as running too fast
> or is it the older ones?
Yes, newer ones are apparently broken. This is a GA-K8NS Ultra-939
(NForce3), acpi_pm is recognized with BIOS F7, gives an error with F8 or
F9...
-- Fernando
On Fri, 2005-12-09 at 18:29 -0800, john stultz wrote:
> If you add a "return 0;" to the top of
> verify_pmtmr_rate() in drivers/clocksource/acpi_pm.c does the acpi_pm
> timer keep proper time?
Hey Fernando,
You replied to my other question, but I haven't heard anything back
about the one above. If you have time to test this, I'd really
appreciate it.
thanks again!
-john
On Tue, 2005-12-13 at 12:15 -0800, john stultz wrote:
> On Fri, 2005-12-09 at 18:29 -0800, john stultz wrote:
> > If you add a "return 0;" to the top of
> > verify_pmtmr_rate() in drivers/clocksource/acpi_pm.c does the acpi_pm
> > timer keep proper time?
>
> Hey Fernando,
> You replied to my other question, but I haven't heard anything back
> about the one above. If you have time to test this, I'd really
> appreciate it.
Sorry, I have not had time to test this yet...
I just downgraded one of the computers to BIOS F7 (from F9) and still
had the acpi_pm timer error on boot with 2.6.14-rt22. I'll have to
recheck things.
-- Fernando