So ich habe es jetzt mal auf hpet fest eingestellt weil es bei mir so unter eingetragen war als es mal ohne den tsc-Fehler gebootet hatte
[as@localhost ~]$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
[as@localhost ~]$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet
Taucht in dmesg auch schön auf, am Anfang natürlich
[ 0.000000] Command line: BOOT_IMAGE=linux root=UUID=832fc7e4-0c50-4bf0-8e5d-41981a18511c nokmsboot splash quiet hpet“
Und dann nur noch
[ 0.122578] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[ 0.122582] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[ 0.124014] Switching to clocksource hpet
Trotzdem wird beim acpi-check das tsc nochmal probiert, wenn auch als zu schlecht aussortiert
[ 10.080064] tsc: Marking TSC unstable due to TSC halts in idle
Das finde ich schon etwas befremdlich. Wozu überhaupt noch tsc checken wenn vorher eindeutig hpet als clocksource gewählt wurde?
Ich denke es ist irgendwie fest im acpi eingecoded weil
[ 10.078046] ACPI: Requesting acpi_cpufreq
[ 10.080046] Monitor-Mwait will be used to enter C-1 state
[ 10.080057] Monitor-Mwait will be used to enter C-2 state
[ 10.080064] tsc: Marking TSC unstable due to TSC halts in idle
[ 10.080073] ACPI: acpi_idle registered with cpuidle
[ 10.081211] Switching to clocksource hpet
Das acpi frägt also gar nicht nach ob es schon eine festgelegte clocksource gibt (nämlich die hier [ 0.124014] Switching to clocksource hpet ), sondern macht den ganzen Clocksourceprozess per default nochmal.
Für mich sieht das aus als hat da einer bei neuerem acpi-code gepennt (hehe, acpi <-> gepennt, schönes Wortspiel

). Andere würden sagen es ist ein bug.