Hi, I just write here a quick update of the bug to tell you the state of the process.
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 fine. 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 ???? :) Regards -- Emmanuel Who wouldn't be interested in everything we do?! -- Calvin & Hobbes (Bill Waterson)
