Cache Errors From a Counter That Was Counting Clock Ticks

The first time IRIX reached a login on the emulated Origin 300, it arrived complaining. Every processor kept reporting a secondary-cache error:

WARNING: /hw/module/001c01/node/cpubus/0/a: INTR: Scache SBE, failing bit -1 CPU C3D1.AE10  SRAM  C8B7.T9

An SBE is a single-bit error, the kind error-correcting memory fixes on the fly and the kernel logs so an administrator can spot a cache going bad. On a real machine a steady stream of them is a reason to replace a processor module. On an emulator it is impossible, because there is no cache and nothing in it to flip. Thirty-four of them arrived in twenty-eight minutes.

Where a kernel learns about a corrected error

A corrected error does not have to raise an interrupt of its own. The R10000 family carries hardware performance counters, the same ones profilers use to count cache misses and branch mispredictions, and each is programmed by writing an event number into a small field of its control register. The published event table gives number 8 to correctable ECC errors on secondary-cache data. So a kernel can point a counter at event 8, let it overflow, and take the overflow as its notice that the cache has been correcting itself.

That is the path these warnings came down. And the model had a hole exactly there. Its R14000 control register kept the bits that enable counting in user, kernel and exception mode, and threw away the event number. A counter with no event number defaults to event zero, which is processor cycles. The kernel asked for “count cache corrections”, the model heard “count clock ticks”, and the counter overflowed at the rate a busy processor burns cycles. Every overflow read, correctly, as a report of a corrected cache error.

The fix, and why it does not count anything

The fix keeps the event number: the field is writable and reads back what was written. It does not make event 8 count, because the emulator has no cache and no ECC upsets to count. For event 8 that is the right answer in its own right, since a real machine with a healthy cache would also leave that counter where it was. For the rest of the thirty-two events, a counter that never moves is a stated limitation rather than hardware behaviour, and it is written down as one.

With it in place, the same installed disk boots on two processors and on four with no warning at all, and the firmware still reports ALL DIAGS PASSED.

The shape worth keeping

This is the cheapest kind of emulator shortcut: a control field nobody seems to read, dropped because nothing visibly broke. But a counter is only as honest as its selector. Drop the selector and the counter does not stop, it counts something else, and whoever reads it trusts the number. Here the reader was a kernel that took the number as a hardware fault report, so a missing five-bit field turned into a machine that believed its own cache was failing.