Re: Common Millisecond Counter Issue
If my guess is correct, this is a combination of two problems. The first is using code like:
timeout = current_time + delta;
while ( current_time < timeout ) yield();
time_snap = current_time;
while ((current_time - time_snap) < delta) yield();
and the other is inadvertent use of signed arithmetic in there somewhere, which makes it worse.
When I started messing with Linux device drivers, I noticed the first problem in the timer code. In a Roadrunner moment, as I was asking my boss if this could still be the case, a Win95 machine next to his desk crashed in a suspiciously similar way. (the 16-bit Windows manifestation had a different deadly duration because 16bit, and roughly 18Hz) When I were a lad, the danger of the first sort of code was drilled into us. Apparently the Windows _and_ Linux folks didn't take that class, or slept through it. Now they work for Boeing.
BTW: Last time I looked, the Linux timer code had grown a dense mat of "hair" around that code, rather than fixing the underlying cause. I suspect the reason for the first implementation was the desire to save stack space (need to store both time_snap and delta), combined with ignorance of the problem.
The reason for not actually fixing it seems to be "But we've always done it this way". I haven't checked in the last six years, but would be delighted to hear they finally bit the bullet.
The usual bandaid for this sort of thing these days is just make all the time variables bigger. I can imagine Lister facing a shutdown of this sort and wondering why the coders of Holly didn't anticipate 64-bit wrap.