system freezes

[Xen]

Ralf Mardorf schreef op 09-11-2017 19:12:
> On Thu, 09 Nov 2017 13:52:50 +0100, Nils Kassube wrote:
>> I can't imagine that switching the clock source from tsc to hpet could
>> cause a hang - probably those issues aren't related.
> 
> I would keep it in mind, but ignore it at the moment.
> Clearing CMOS is for free as in beer, so it was wise to do it.
> If it shouldn't solve the issue I would take a look at smartctl, since
> it's for free as in beer. Running memtest is for free as in beer.
> Disconnecting and then connecting the SATA cables again is for free as
> in beer. Unplugging the RAM bars and mounting perhaps not all of them
> again, is for free as in beer. Replacing the battery is inexpensive.

So I fell asleep late last night with the computer on.

The monitor went into standby through KDE.

When I come back initially the system doesn't respond. Takes about 10-20 
seconds.

That's odd. More odd is that the clock, that was current when I went to 
sleep, is now 4 exact hours behind.



I also have my keyboard connected though a KVM switch.

I wanted to send a message to dmesg so I could compare the time stamp on 
the previous ones, so I reset my keyboard.

Initially I couldn't use my keyboard but this can be a temporary glitch. 
I pressed the reset hotkey again and this time I could use my keyboard 
again but

* a "jiffies" message about the CPU entered the console I was in (but 
not dmesg)

* it appears the latest dmesg messages congruent with my earlier pastes, 
--- was actually from the current moment where I returned to the PC.







So this event here:

nov 10 02:52:09 xen-linux kernel: nouveau 0000:03:00.0: DRM: EVO timeout
nov 10 02:52:21 xen-linux systemd[1]: Started Getty on tty2.
nov 10 02:52:24 xen-linux login[23722]: pam_unix(login:session): session 
opened for user xen by LOGIN(uid=0)
nov 10 02:52:25 xen-linux systemd[1]: Started Session 11 of user xen.
nov 10 02:52:25 xen-linux systemd-logind[1367]: New session 11 of user 
xen.
nov 10 02:55:05 xen-linux kernel: usb 1-4.4.1: USB disconnect, device 
number 13
nov 10 02:56:18 xen-linux rtkit-daemon[2296]: The canary thread is 
apparently starving. Taking action.
nov 10 02:56:18 xen-linux rtkit-daemon[2296]: Demoting known real-time 
threads.
nov 10 02:56:18 xen-linux rtkit-daemon[2296]: Successfully demoted 
thread 24501 of process 2295 (n/a).
nov 10 02:56:18 xen-linux rtkit-daemon[2296]: Demoted 1 threads.
nov 10 02:56:18 xen-linux kernel: INFO: rcu_sched self-detected stall on 
CPU
nov 10 02:56:18 xen-linux kernel: INFO: rcu_sched self-detected stall on 
CPU
nov 10 02:56:18 xen-linux kernel: INFO: rcu_sched self-detected stall on 
CPU
nov 10 02:56:18 xen-linux kernel:         1-...: (1 GPs behind) 
idle=a7f/1/0 softirq=702465/702466 fqs=0
nov 10 02:56:18 xen-linux kernel:         2-...: (1 ticks this GP) 
idle=e67/2/0 softirq=724166/724166 fqs=0


Is me opening a TTY, the question is if there was actually anything 
between 02:52:09

And 02:52:21 in terms of an entire night.

Because the preceding

nov 10 02:42:11 xen-linux smartd[1291]: Device: /dev/sdb [SAT], SMART 
Usage Attribute: 194 Temperature_Celsius changed from 116 to 115
nov 10 02:52:09 xen-linux kernel: perf: interrupt took too long (3395 > 
2500), lowering kernel.perf_event_max_sample_rate to 58750
nov 10 02:52:09 xen-linux kernel: NMI watchdog: Watchdog detected hard 
LOCKUP on cpu 2


May very well have "stopped" the clock.

So what I think is that the clock stopped running between 02:52:09 and 
02:52:21 OR it stopped between the last SMART message and 02:52:09.

The nouveau message is congruent however with the time I would have come 
back to the pc.

But it's clear not just the clock stopped running: the entire system has 
been in a frozen state.

For 4 hours.

Either that or the clock runs *really* slow but I didn't notice that 
while using the PC.