>I should point out that I'm using an ancient version of HiJack v200

Whew! Had me pulling my hair out for a few minutes there.

Yes, that would be the jiffies bug in v200.
Not in the latest versions.

The jiffies bug worked like this:

The clock interrupt handler gets invoked, signalling another "jiffie" (1/100sec) has passed. The code then begins to reset the "match register" for the next 1/100sec jiffie interval, but gets interrupted midway through by some other hardware interrupt.

If that second interrupt takes more than about .9/100sec to complete, then the original timer interrupt routine will mess up the reset when it eventually gets to run again.

The result is that the "match register" is already behind the actual counter, and will not match until the 32-bit counter wraps around (at 3.6MHz), which takes about 00:19:53 in elapsed time.

This probably won't happen so long as the second interrupt is handled very quickly. Things like ethernet and USB activity take longer to handle than other interrupts, and are more likely to trigger the bug.

And, yes, just having Hijack installed will increase the likelihood as well, since Hijack does most of it's processing during the button and display interrupt handling, lengthening those routines.

Finding the bug was hard, the fix was simple: mask ALL interrupts in the critical section of code which resets the match register in the timer interrupt handler.

Cheers.