At the time the h1seiex and h1susex computers locked up, the last errors to be printed to the console were photographed and attached to the alog. The timestamps (running seconds since last reboot) shown are not consistent with time since last boot.
Looking at the boot logs on h1boot, here are the times of the last two boots of these computers (including this week's boots, all times are local)
| computer | boot 1 | boot 2 |
| h1seiex | 30 Sep 2016 06:45 | 27 Apr 2017 07:05 |
| h1susex | 30 Sep 2016 06:45 | 28 Apr 2017 06:56 |
A computer running since 9/30/2016 should have a running clock of about 18 million seconds. The times shown in the photographs are small. Since we know at which time the computers froze, we can extrapolate back to the apparent zero time (all times local)
| computer | system time on console [crash time] | t=0 datetime |
| h1seiex | 30096 seconds (08 hrs 21 mins) [06:15 Thu 4/27] | 21:53 Wed 4/26 |
| h1susex | 108493 seconds (01 day, 06 hrs, 08 min) [05:43 Fri 2/28] | 23:34 Wed 4/26 |
the "pseudo" boot time when the clock was zeroed are within two hours of each other Wednesday night.
As a sanity check, I have ran dmesg on h1iscex to show the logging of this morning's model restarts. This computer was last rebooted 01 Nov 2016 12:03 PST. Here is the dmesg output:
[15352542.295438] h1alsex: Synched 302425
Doing the math of how many seconds since 28 Apr 2017 07:16 PDT and 01 Nov 2016 12:03 PST gives 15,361,981 which is close to dmesg.