Stuck Jiffies: fix #2

(second try.. lost the attachment first time around)

Okay, I have attached the second half of the "stuck jiffies" patch. This part isn't strictly needed for fixing the lockups, but does fix related bugs in time keeping.

This code has also been part of the Hijack kernels for some time now.

Cheers

What does 'stuck jiffies' mean?

What does 'stuck jiffies' mean?

If you don't know, don't worry about it. This patch is only for those modifying the source code of the kernel.

>What does 'stuck jiffies' mean?

You don't need to know this, but a "jiffie" is the basic unit of time-keeping and scheduling in the Linux Kernel. On the RioCar/Empeg, one jiffie == 1/100 second.

The recent v2 beta software releases have been suffering from a number of malfunctions due to a bug in the RioCar/Empeg Linux kernel, where the hardware timer that generates "jiffies" is reset. This bug results in the jiffie timer not being reset correctly, requiring it to count all the way up to 0xffffffff and then wrap around again, a complete 32-bit cycle at 3.6Mhz, before the next "jiffie" is triggered.

Since this locks up many parts of the machine for the 19-20 minutes it takes, the condition has been referred to as "stuck jiffies". The recent Hijack replacement kernels include fixes for this bug, as do upcoming releases (someday) from the manufacturer.

Cheers

And as an aside for everyone, the same bug has been there for a long time, even in the 1.02/1.03 player releases. But for stuck jiffies to actually happen, other system interrupts have to do a lot of processing (more than a jiffie's worth).

The Hijack kernels perform more processing per interrupt than the "stock" kernels, causing the condition to arise more often than it otherwise might have. The ethernet and USB drivers (in the kernel) are also relatively slow at times, triggering the condition.

Cheers

human nature is very curious by default U know ;-)
...and maybe one day I'll deal with it.