Arreglar el TSC cuando tu firmware está roto
Durante cuatro meses, en cada arranque, mi ThinkPad E595 entregó a Linux un núcleo de CPU tres segundos por detrás de los otros siete, y el kernel dejó el TSC por el HPET. Qué significa el aviso, por qué una máquina AMD Zen no tiene forma de repararlo desde dentro de Linux, qué dicen del firmware 40 arranques de journal, por qué tsc=reliable es la respuesta equivocada, y cómo tscsync mide y mueve los contadores en UEFI antes de que el kernel llegue a verlos, incluido el núcleo que marcó como BAD y que Linux aceptó igualmente. Actualizado para la BIOS 1.30: no arregla el desfase, y el watchdog de clocksource del kernel tiró el TSC en dos arranques incluso después de que tscsync sincronizara los núcleos. Con tsc=nowatchdog aguantó, y una comprobación de cinco minutos contra el reloj de tiempo real, código incluido, no encontró ningún warp ni deriva. Por último, qué hace esa caída en cualquier hipervisor KVM, sea Proxmox o no: el reloj maestro desaparece, los invitados pierden su lectura rápida del reloj, y en este portátil una lectura del reloj en un invitado salió siete veces más lenta.