Skip to content
HUBrisOrigami development library
Color Schemes
Color Scheme Browser
Desktop SchemesBase · gamma 1.7
Monitor gamma
Chrome type · pointer

/usr/lib/X11/schemes · x_eoe_6530m

IRIS InSight: Origami Development Library
NavigatorOrigami Bring-Up Notes
Engineering Notespage 11 of 27

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.

Development Library / Engineering Notes / A Transposed Doubleword, and the Golden That Passed Itpage 11 of 27