Engineering Notes
A Transposed Doubleword, and the Golden That Passed It
A doubleword served through a 32-bit device slot came back with its halves transposed, panicking IRIX at kernel init, and the window's register test had baked its golden from the transposed order so it passed against the bug.
The Bridge presents each PCI device through a window, and the window has to serve a doubleword, eight bytes, to devices that read and write in eight-byte units. Getting that right on a big-endian machine took two goes, and the second bug was hidden by the test that should have caught it.
Two halves in the wrong order
The window served a 32-bit device by splitting an eight-byte access into two four-byte cycles, one
at the lower offset and one at the higher. On a big-endian device the word at the lower offset is
the high half of the doubleword. The reassembly put it in the low half instead, word0 | (word1 << 32) where it should have been (word0 << 32) | word1, so the two halves came back transposed.
Most accesses never noticed, because most values are not pointers and a transposed halfword pair
often still lands somewhere harmless. IRIX did notice. Early in kernel init it reads a 64-bit pointer
through a 32-bit slot, and the transposed address it got back, 0xc0000fc0 returned as
0xc0000fc000000000, faulted the moment it was dereferenced, a deterministic panic right after the
firmware’s field-replaceable-unit analysis. The write path split the value the same way and carried
the mirror of the bug.
The reason it survived a passing test
The window has a register-level test with a golden expectation, and it passed. It passed because the commit that introduced the transpose wrote the golden from the transposed output: the test asserted the wrong order as correct, so it agreed with the bug rather than catching it. A golden baked from the code it is meant to check tests nothing, and this is the exact shape of that. The fix corrects the golden to the natural doubleword and adds a cross-path check that writes through the split path and reads back through the whole-doubleword path, so the two orderings have to agree rather than each being free to be wrong in the same way.
Why the doubleword had to be served whole at all
The split existed for the 32-bit devices that want it, but one device on this machine does not. The Neterion Xframe acts on a whole doubleword in a single access for its diagnostic magic, its reset key and its MAC-configuration key: hand it two partial cycles and the full-value effect never fires. Serving it means letting an eight-byte access reach the handler whole, which is done by raising the window’s implementation width to eight so the memory core stops splitting the access on the model’s behalf, and then branching on the slot’s device-size bit: a 64-bit device gets its doubleword in one cycle, a 32-bit device the two corrected cycles. The half-order rule lives in the handler now, next to the split that depends on it.