Bug 476609

Created attachment 327061 [details]
dmesg from 2.6.27.7-134.fc10 with 'acpi_pm_good clocksource=jiffies' parameters

Description of problem:

After an upgrade of an "Acer TravelMate 230" laptop a machine became unusable.  A    user-space was not starting, beginining with udev, without hitting on a keyboard for every step.  Even when booted into level 3 with a default boot it was possible to loose about 40 clock minutes during one hour.  With added acpi_pm_good (AFAICT acpi_pm should be good) and hpet=force the situation
improved somewhat.  It was still necessary to coax a kernel from a keyboard through a boot sequence but time looked a bit more stable - for a while.
Without any good reason a machine may loose big chunks of it, in order
of tens of minutes, without any aparent reason.

Also after some relatively short time some commands would stop responding. For example after 'ls' was typed it may never return and attempts to kill it will not work although there will be nothing unusual in a process table, if you can get 'ps' still to work; 'ls' will likely be in "S" or "Ss" state and that is about it.  The same 'ls' may still work if used from a network login although a situation will be deteriorating and after a while nothing will work but a power switch. /sys/devices/system/clocksource/clocksource0/available_clocksource shows  'tsc acpi_pm jiffies' and also 'hpet' if 'hpet=force' is used.

After some experiments it turned out that F10 kernels can be used only if 'clocksource=jiffies' is added to boot parameters.  I have also 'acpi_pm_good' there and I do not know if skipping it would have bad effects.  In any case - in this setup wall-clock behaves normally and there are no bad effects as described above.

An upgrade itself took well over 12 hours and did not really finish (but it was impossible to examine what really happened) even if it displayed "Reboot".  yum-complete-transaction later had around 500 steps on its list.  As I understand that now this was courtesy of a kernel used by anaconda.

Attached is dmesg from 2.6.27.7-134.fc10 in a "good" configuration. It does
not seem to be much of a difference when booting "bad" although I found
then lines like:

Marking TSC unstable due to TSC halts in idle
Clocksource tsc unstable (delta = 107801214414 ns)

and 

intel8x0_measure_ac97_clock: measured 85204 usecs

while for a "good" configuration that last line will be

intel8x0_measure_ac97_clock: measured 51000 usecs

If 'hpet=force' is used then line like those will show up too:

hpet clockevent registered
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz

only attempts to use that also came to naught.

/proc/cpuinfo shows all the time:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Mobile Intel(R) Celeron(R) CPU 2.00GHz
stepping        : 7
cpu MHz         : 1999.755
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid xtpr
bogomips        : 3999.51
clflush size    : 64
power management:

even when user-space starts to "die" (but 'cat' still works).

I do not know if this is a more extreme manifestation of bug 476051 or this is another issue.

Version-Release number of selected component (if applicable):
kernel-2.6.27.5-117.fc10.i686
kernel-2.6.27.7-134.fc10.i686

How reproducible:
always on that particular hardware

Additional info:
The laptop in question did not need any "clock magic" to run just fine
with all kernels from F8 distro.

I have seen F10 running on another, really different, i686 class SMP machine and there nothing like the above happens.  Only tsc is used there as a default
clocksource, "available" reports the same 'tsc acpi_pm jiffies', and tsc related items in dmesg look like this:

TSC: PIT calibration confirmed by PMTIMER.
TSC: using PMTIMER calibration value
checking TSC synchronization [CPU#0 -> CPU#1]: passed.

Only that the first two "TSC" lines show exactly like that for all F10 kernels
on a stricken laptop regardless of used options.