upgrades WAIT A BIT AND… Another server issued the same behavior. 😥 Checking puppet logs: BMC Firmware updated. NOTE: should the update have been done oob, or not logged in our update system, we would not have found it as the source and just dropped the vendor Please use LVFS !
for the update BMC issued a scsi bus rescan every 1300s Should be fixed in new release… In fact no… and nothing in changelog Had to wait another month Business was… not happy. (Ask your local vendor for more detail) Continuing automated upgrades !
- 03/09: Case opened + sosreport - 03/10: log check: ntp, lots of “system clock wrong” - 03/11: same issue with live-cd, different kernel - 03/14: works OK with HPET but not TSC - 03/23: checking /proc/timer_list - 03/24: C test with gettimeofday() / rdtsc() : - 03/29: replaced motherboard, replaced CPU0 (usual time source) - 04/04: tried kernel testing - 04/12: tested CPUs swapping
by CPU0 anymore… due to realtime kernel we used (previous win) The main path is from: apic_timer()/hrtimer_interrupt() -> __hrtimer_run_queues() -> tick_sched_timer(): 1367 -> tick_sched_do_timer(): 141 -> tick_do_update_jiffies64(): 97 -> update_wall_time(): 2140 -> timekeeping_advance(TK_ADV_TICK): 2124 -> memcpy(). tick_sched_timer(): Calls ktime_get() to get current time. If cpu == tick_do_timer_cpu call tick_do_update_jiffies64() with new time. NOTE: tick_do_timer_cpu is not always the same. tick_do_update_jiffies64(): Will update jiffies and then call update_wall_time(void) which calls timekeeping_advance(). timekeeping_advance(): Updates the shadow_timekeeper. Write_seq_begin’s tk_core. Memcpy’s shadow_timekeeper to tk_core. Write_seq_end’s tk_core. NOTE: any read of tk_core values while write_seq_begin will loop till write_seq_end