The Intel486 family of processors uses the test registers TR3, TR4 and TR5 to test the internal cache. When I was writing a test for the internal cache, I was paying attention to all of the code optimization techniques recommended by the Intel486 programmers reference manual. The optimization included aligning the destination of branch instructions to 16-byte boundaries.
So I wrote my test, and had it working. There was only one problem. For some inexplicable reason, occasionally the computer would go off into the weeds (that's a technical term for executing off into space somewhere you don't want it to execute). So like a good boy with $100,000 worth of equipment at my disposal, I hooked up the Intel486 to all of the equipment I could lend to bear on this situation. When the error occurred, I noticed that my code was jumping to a location that remarkably resembled the data I was writing to TR5. For example, if I was writing 55aa55aa to TR5, then my instruction stream was being diverted to 55aa55a0, or somewhere near there.
Now, I remembered that on the Intel386, TR4/TR5 was a read-only register which pointed to the next prefetch address. So I wasn't surprised that writing to TR5 was somehow connected to sending my code off into the weeds. So here is what was happening. When a code fetch was occurring, simultaneously with a write to TR5, then writing to TR5 would modify the prefetch address. This is not as common as you might think. The key to this bug, was simultaneously writing TR5, while a prefetch occurred. Therefore the code alignment was also a factor. Had the write to TR5 not been aligned on a 16-byte boundary, then it would have not been as probable to have a simultaneous write to TR5 during a prefetch. The essence of this bug, was that the internal prefetch queue pointer was being modified by the write to TR5. In essence, this condition unshadowed the prefetch queue pointer, and made it writeable.
I immediately reported this bug to Intel, along with a software work
around. And even though I had regular access to the Intel486 errata documents,
I never saw this bug listed in the errata. This omission was in spite of
my submission of source code which faithfully reproduced this bug. I have
no idea whether or not Intel ever fixed this bug, as it never was listed
in the Intel486 errata, and I had a sufficient work-around. I found another
bug in the Intel386 and Intel486 which had suffered the same fate --
it never showed up in the errata documents, even though it could be faithfully
reproduced with source code I had provided. And now that the Pentium errata
is public, I always look at it as though there are many bugs which are
never listed, even though their founders have reported them, and spent
many man-hours debugging them.