Bug#234556: Possible Transmeta CMS bug
I just write here a quick update of the bug to tell you the state of the
First, it is still not solved but I think I have located it...
(still there is room for uncertainty).
After posting the description of the bug on the Linux Kernel
Mailing-list I've been contacted by a guy from Transmeta which kindly
will try to look for this bug and try to see if he can do something.
Thanks to the discussion I had with him, I think I got a deeper
understanding of what was going on.
As you should all know, the Transmeta Crusoe is using a CMS (Code
Morphing Software) to translate the x86 binaries into VLIW (Very Long
Instruction Words) instructions. For performance reasons, once the
translation of one binary is done it is kept into a cache in order to
not retranslate it too often.
Now you have to remember that we've noticed that once we enter in this
particular mode the Xserver was always failing even if we stop it and
run it again. But, when running a copy of the binary, it was working
According to the guy from Transmeta (which was working on the
development of the CMS for the Crusoe and the Efficeon), this technique
of copying binaries to work around the cache of the CMS seems to be an
usual technique used by the developers of the CMS.
Lets make now the hypothesis that from time to time the CMS is getting
crazy for some strange reasons and translate something wrong in the
binary of the Xserver.
Here we are !!! The combination of the CMS cache and the presence of a
bug in the CMS can perfectly explains the behaviour of the bug
(both the persistence once it occurs and that a copy of the exact same
file can work properly).
So my guess is that the bug is somewhere in the CMS... but I have no
tools to go that deep and Transmeta is a bit picky about this CMS, so
our only way to fix this bug is to make the people from Transmeta to fix
it... Time for lobbying ???? :)
Who wouldn't be interested in everything we do?!
-- Calvin & Hobbes (Bill Waterson)