Bug#353494: Xserver SIGILL on processors without CPUID
Am Montag, den 24.12.2007, 23:28 +0100 schrieb Brice Goglin: Thank you very much for your input, I am going to forward all your analysis in the upstream bug and I hope someone will be here to confirm that you're right. I got around to test a patched xserver on my 6x86 machine. The X server works fine with this patch. Surely this has been discussed multiple times: The nice thing about debian stable is, that you can rely on all features and misfeatures in it, so if you hacked a workaround for a bug that suddenly stops working if the bug disappears, it will not stop working in debian stable. Of course this policy has its merits. But if a bug prevents the use of certain features completely, nothing can be broken by fixing this bug, so a fix might be appropriate for stable. Debian isn't doing it because of the philosophy of only adding security updates to stable. Is there some third-party repository that includes this kind of harmless bug fixes (I would call it something like stable-recommended-updates), do you have any pointers to a discussion on debian-devel about this subject? Regards, Michael Karcher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353494: Xserver SIGILL on processors without CPUID
On Tue, Dec 25, 2007 at 10:39:55 +0100, Michael Karcher wrote: But if a bug prevents the use of certain features completely, nothing can be broken by fixing this bug, so a fix might be appropriate for stable. Debian isn't doing it because of the philosophy of only adding security updates to stable. Some other important fixes can be included in stable, if the stable release managers agree. If you get an ack from [EMAIL PROTECTED] (need to send them the patch and explanation), I can prepare a fixed package and upload to proposed-updates. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353494: Xserver SIGILL on processors without CPUID
Package: xorg-server Tags: patch Hello, this bug is uncorrelated to Cyrix CPUs. It is caused by an bad expression in the MMX detection code. Apparently, gas changed the handling of local labels, so jnz 1 does not assemble to the same as jnz 1f, which it once did, IIRC. The documentation for gas does not mention local labels without an f or b suffix. The attached patch fixes the jump instructions in the inline assembly and thus this bug (except for the last submitted message). The patch has not yet been tested on the real hardware (first I have to recompile the xorg-server package which I might not get around to before christmas), but the obviously wrong x86 code in gdb's disassembly is gone. Regards, Michael Karcher --- xorg-server-1.1.1/fb/fbpict.c.orig 2007-12-24 10:37:26.0 +0100 +++ xorg-server-1.1.1/fb/fbpict.c 2007-12-24 10:37:50.0 +0100 @@ -1378,7 +1378,7 @@ pop %%eax\n mov $0x0, %%edx\n xor %%ecx, %%eax\n - jz 1\n + jz 1f\n mov $0x, %%eax\n push %%ebx\n @@ -1422,7 +1422,7 @@ cpuid\n xor %%edx, %%edx\n cmp $0x1, %%eax\n -jge 2\n +jge 2f\n mov $0x8001, %%eax\n cpuid\n 2:\n
Bug#353494: Xserver SIGILL on processors without CPUID
Michael Karcher wrote: Package: xorg-server Tags: patch Hello, this bug is uncorrelated to Cyrix CPUs. It is caused by an bad expression in the MMX detection code. Apparently, gas changed the handling of local labels, so jnz 1 does not assemble to the same as jnz 1f, which it once did, IIRC. The documentation for gas does not mention local labels without an f or b suffix. The attached patch fixes the jump instructions in the inline assembly and thus this bug Any idea why people would have seen the problem on Cyrix and not on other CPUs? (except for the last submitted message). Sad... The patch has not yet been tested on the real hardware (first I have to recompile the xorg-server package which I might not get around to before christmas), but the obviously wrong x86 code in gdb's disassembly is gone. This code has moved to the pixman library since Xserver 1.4. And it looks like the f suffix is there now. So if you are right, the bug should be fixed in unstable already. I'd like anybody to confirm this though. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353494: Xserver SIGILL on processors without CPUID
Michael Karcher wrote: The jump is only taken if CPUID is not present. The 6x68 CPUs are the last ones where CPUID is not present (not enabled by some Cyrix-special CPU configuration bit, in fact). Any Pentium has CPUID, the later Intel 486 (DX2 and upwards) has CPUID, any AMD processor since the 5x68 has cpuid, so the later processors k5 and k6 do have cpuid. Ok, it makes sense now. This code has moved to the pixman library since Xserver 1.4. And it looks like the f suffix is there now. So if you are right, the bug should be fixed in unstable already. Any chance of getting the fix in the next point release? Probably not, as it is not security related. Yes, that's very unlikely to happen unfortunately. Thank you very much for your input, I am going to forward all your analysis in the upstream bug and I hope someone will be here to confirm that you're right. Merry Christmas Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353494: Xserver SIGILL on processors without CPUID
Am Montag, den 24.12.2007, 15:58 +0100 schrieb Brice Goglin: this bug is uncorrelated to Cyrix CPUs. It is caused by an bad expression in the MMX detection code. Apparently, gas changed the handling of local labels, so jnz 1 does not assemble to the same as jnz 1f, which it once did, IIRC. The documentation for gas does not mention local labels without an f or b suffix. The attached patch fixes the jump instructions in the inline assembly and thus this bug Any idea why people would have seen the problem on Cyrix and not on other CPUs? The jump is only taken if CPUID is not present. The 6x68 CPUs are the last ones where CPUID is not present (not enabled by some Cyrix-special CPU configuration bit, in fact). Any Pentium has CPUID, the later Intel 486 (DX2 and upwards) has CPUID, any AMD processor since the 5x68 has cpuid, so the later processors k5 and k6 do have cpuid. The patch has not yet been tested on the real hardware (first I have to recompile the xorg-server package which I might not get around to before christmas), but the obviously wrong x86 code in gdb's disassembly is gone. This code has moved to the pixman library since Xserver 1.4. And it looks like the f suffix is there now. So if you are right, the bug should be fixed in unstable already. Any chance of getting the fix in the next point release? Probably not, as it is not security related. Regards, Michael Karcher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
