[nSLUG] Between rock and hard place with acpi & mondo?

Robert Ashley rb.ashley at gmail.com
Mon Dec 10 21:10:50 AST 2007


Gerald and I put Mandriva 2008 on my box last Friday. (Thanks Gerald!) We
installed off a live DVD. First, we got no further than the first splash
screen and it hung there until we added acpi=off to the boot script (after
hitting F2 options).  Everything is now cool and working fine except with
shutdown. All files get unmounted, including hda but the fan keeps running.
So I have to hit the power button to turn it off, big deal.

I tried fiddling with the acpi options through the KDE controls, but this
resulted in a defiantly unbootable box. I re-installed Mandriva a few
times--a big time sucker!--but got no further with the acpi thing.

So, I reasoned if I had mondo-rescue I could easily keep experimenting with
acpi, safe in the thought I'd have a complete image of my setup to save me
from having to re-install.

The mondo download and DVD burn went with no hitches.  Then I booted from
the DVD and it launched, no prob. But then it hung, the last two lines of
the script reading:

...
*Clocksource tsc unstable (delta = -298819065969 ns)
Time: hpet clocksource has been installed*

Then it hangs.  Googling the above text leads me to think that the tsc (time
stamp counter) issue is directly associated with an acpi issue. Hence, the
"rock-and-hard-place" cliche. I need acpi to make the rescue and I need
rescue to ease the fix experimentation.

My first goal is: Obtaining a reliable backup image of my hard drive (by
whatever means), so I can freely experiment with the acpi fix...OR...a
reliable acpi fix so my mondo will work.

I'd like to solve the acpi issue but apart from the trivial inconvenience of
having to fully power down with the final push of a button, I'm quite
satisfied with Mandriva setup.

Any ideas muchly welcomed!!

Kernel in use is 2.6.22.12
AMD AM2 Sempron 3400
Asus M2A-VM 690G AM2

Bob

P.S. Here's a few refs I found:

*TSC*=Time Stamp Counter.
Processors<http://www.linuxquestions.org/questions/fedora-35/clocksource-tsc-unstable-568932/#>have
dynamically changed clock speed (ofc to save power). The TSC is
supposed to tick at the CPU rate (unless it's a constant_tsc, see
/proc/cpuinfo flags, so on frequency change, this ought to happen. The
kernel will automatically switch to something else.
***********

> One of the 2.6.21 regressions was Guilherme's problem seeing *his box
> lock up when the system detected an unstable TSC and dropped back to
> using the HPET*.
>
> In digging deeper, we found the HPET is not actually incrementing on
> this system. And in fact, the reason why this issue just cropped up was
> because of Thomas's clocksource watchdog code was comparing the TSC to
> the HPET (which wasn't moving) and thought the TSC was broken.
because I know that VT8237 has HPET built in. But I don't see any lines
starting with "hpet: enabled" or something similar. But I don't know
what to search for. I didn't have contact with HPET earlier.
It is very similar and Your problem with ondemand is starting right
after
> May  3 19:17:22 cn kernel: *Clocksource tsc unstable* (delta = -136422685
> ns)
I don't see such message as long as "performance" governor is used.

Anyway adding "hpet=disable" at boot should confirm for sure that it
isn't it. And I think that John already ruled this out by
clocksource=acpi_pm.

*************
Most likely you have cpu frequency scaling on and there might be a
problem at point the govener switches over.

Check you have installed another clock source like acpi_pm
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

If so you can try turning off cpu frequency scaling in the kernel (or set to
performance) which 'should' elimanate the unstable msg and speed up boot.
Temperature/power is not an issue who cares anyways.

OR/AND

You can try adding the below to your kernel command line (stick it on the
same line as your kernel in /boot/grub/menu.lst). This won't get rid of the
unstable line but it will force the kernel to use a more stable clocksource
so there should be no trouble switching over anymore (if indeed there is
trouble to begin with).

clocksource=acpi_pm

************************
Is "*Clocksource tsc unstable"* kernel msg a problem or not ? | KernelTrap
kerneltrap.org/node/8306Note created December 10, 2007
12/10/07
I had the same problem. Mplayer, and xine video didn't work (except when
using the RTC timesource). I added "notsc" on the kernel commandline and
everything has worked beautifully for me after that.

***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20071210/a754c704/attachment.html>


More information about the nSLUG mailing list