Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
tags 385147 + pending stop Hello Jamie On 2006-11-18 Jamie Thompson wrote: Have we had any movement on this? I've just disabled YaSSL assembler in MySQL 5.0.27-2. Please try this version when it is available (probably tomorrow morning) and report if I did the patch right and your problems are gone. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
Have we had any movement on this? My install is backing up slowly but surely under the weight of dependencies - I can't currently update Apache, php, mysql, or proftp properly. I got them all working again by installing older versions and forcing the installs with dpkg and then holding the packages, but of course now I can't use apt as as far as it's concerned, proftpd is broken and it won't let me install anything until that is resolvedironically, due to this cpuid issue, if I do let it resolve the problem, it, and indeed all the packages listed above, will stop working completely :) signature.asc Description: OpenPGP digital signature
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
Yavor Doganov wrote:
Well, I happen to know for a fact that the processor actually does have a
CPUID instruction, it's just disabled by default. It can be enabled quite
easily, which might be an avenue of enquiry for this problem.
I would be very grateful if you tell me how to do it. It will resolve
the issue at least for our Cyrix CPUs, but will remain for 486.
For me this bug is RC, because Debian is supposed to support CPUs =i486
for the i386 architecture.
I've attached a bit of hacked-together inline x86 assembly I wrote about
6 years ago to identify CPUs, which, as you would expect, enabled CPUID
on Cyrix CPUs to do it's job. It's not much use as-is, but should give
you the basic idea for enabling Cyrix's CPUID.
I did a bit of digging, and it seems this used to be handled correctly
by 2.4 kernels, but 2.6 seems to have broken it. People have suggested
patches, but nothing seems to have happenedas well, it doesn't work
on mine :)
SCPUInfoTempCPU;
//The Dreaded Assembler
__asm
{
inc TempCPU.Family ;//We have to have at least a
186
//Determine whether model came before or after the 286
xor ax, ax ;//Set AX to 0
pushax ;//and push onto stack
popf;//Pop flag register off of stack
pushf ;//Push back onto stack
pop ax ;//and pop off of AX
and ax, 0x0f000 ;//Do not clear the upper four bits
cmp ax, 0x0f000 ;//Are bits 12 - 15 all equal to 1?
je END ;//NO - It's a 186 or some other dinosaur
inc TempCPU.Family ;//YES - We have at least a 286
//Now work out if we have a 286 or above
mov ax, 0x07000 ;//Push 07000h
pushax ;//onto stack
popf;//Pop flag register off
pushf ;//and push back onto the stack
pop ax ;//Pop into AX register
//Are Bits 12-14 NOT all 0
and ax, 0x07000 ;//Mask all except bits 12-14
je END ;//NO -- Bits 12 - 14 are all 0 so a 286
inc TempCPU.Family ;//YES - We have at least a 386
//Now work out if we have a 386 or above
//Move the current EFLAGS into EAX
pushfd ;//Push the EFLAGS onto the stack
pop eax ;//Pop the EFLAGS into EAX
//Store our EFLAGS for later
mov ecx, eax;//Copy the value in EAX into ECX
//Toggle bit 18 (The Alignment Check flag) in the EFLAGS register
xor eax, 0x0004 ;
//Move the new EFLAGS from EAX to the EFLAGS register
pusheax ;//Push EAX onto the stack
popfd ;//Pop the EFLAGS into EFLAGS register
//Move the new EFLAGS back into EAX
pushfd ;//Push the EFLAGS onto the stack
pop eax ;//Pop the EFLAGS into EAX
//Compare our new EFLAGS with our original EFLAGS
xor eax, ecx;//XOR original new EFLAGS
jz END ;//Can't toggle the AC bit, so a 386
//Restore original EFlags
pushecx ;//Push ECX onto the stack
popfd ;//Pop old flags into the EFlags register
//Increment our counter
inc TempCPU.Family ;//We have at least a 486
//Now work out if we have the CPUID instuction availible
//CPUID test counter
mov ebx, 0 ;//Clear our counter
CPUIDTEST:
//We still have the original flags in ECX
mov eax, ecx;//Move the value in ECX into EAX
//Toggle bit 21 (The ID flag) in the EFLAGS register
xor eax, 0x0020 ;
//Move the new EFLAGS from EAX to the EFLAGS register
pusheax ;//Push EAX onto the stack
popfd ;//Pop the EFLAGS into EFLAGS register
//Move the new EFLAGS back into EAX
pushfd ;//Push the EFLAGS onto the stack
pop eax ;//Pop the EFLAGS into EAX
//Compare our new EFLAGS with our original EFLAGS
xor eax, ecx;//XOR original and new EFLAGS
jnz POSTCPUID ;//Can't toggle the AC bit, so a 486
cmp ebx, 1 ;//See if EBX = 1;
je END ;//YES- Failed to enable CPUID, so a 486
//But, Cyrix 6x86 processors can have the ID bit enabled
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
On Fri, Sep 01, 2006 at 01:16:11AM +0200, Christian Hammers wrote: On 2006-08-31 Steve Langasek wrote: On Thu, Aug 31, 2006 at 11:30:58PM +0200, Christian Hammers wrote: It was downgraded, I guess, to enable the propagation of the last mysql security uploads to testing. The problem affects only us, the second class citizens that have old machines. It was tagged wontfix because Christian Hammers (the mysql maintainer) believes that it won't be fixed by upstream. I tend to agree with him with regret. Yes, upstream won't disable assembler optimization as the problem only occurs only on very early i486 and clones like Cyrix, not even on most real i486. There are just too a few of you unlucky guys left :) AFAIK it's not required to disable the assembler -- it's only required to handle the illegal instruction? You volunteer to write the patch or know an assembler coder? ;-) I doubt that MySQL spends time for it. Neither, sorry. It's just my understanding that this illegal instruction can be trapped and handled. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
tags 383759 - unreproducible moreinfo thanks On Wed, Aug 30, 2006 at 03:06:28AM -0700, Steve Langasek wrote: reassign 385147 libmysqlclient15off forcemerge 383759 385147 Those two bugs are easily reproducible on CPU Pentium Classic. Anyway, I suspect the problem is actually bug #383759, which has for some reason been downgraded and tagged as 'wontfix'. It was downgraded, I guess, to enable the propagation of the last mysql security uploads to testing. The problem affects only us, the second class citizens that have old machines. It was tagged wontfix because Christian Hammers (the mysql maintainer) believes that it won't be fixed by upstream. I tend to agree with him with regret. Well, I happen to know for a fact that the processor actually does have a CPUID instruction, it's just disabled by default. It can be enabled quite easily, which might be an avenue of enquiry for this problem. I would be very grateful if you tell me how to do it. It will resolve the issue at least for our Cyrix CPUs, but will remain for 486. For me this bug is RC, because Debian is supposed to support CPUs =i486 for the i386 architecture. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
tags 383759 + confirmed tags 383759 - unreproducible stop Hi On 2006-08-31 Yavor Doganov wrote: Those two bugs are easily reproducible on CPU Pentium Classic. It was confirmed in the upstream discussion at http://bugs.mysql.com/bug.php?id=21765 It was downgraded, I guess, to enable the propagation of the last mysql security uploads to testing. The problem affects only us, the second class citizens that have old machines. It was tagged wontfix because Christian Hammers (the mysql maintainer) believes that it won't be fixed by upstream. I tend to agree with him with regret. Yes, upstream won't disable assembler optimization as the problem only occurs only on very early i486 and clones like Cyrix, not even on most real i486. There are just too a few of you unlucky guys left :) Well, I happen to know for a fact that the processor actually does have a CPUID instruction, it's just disabled by default. It can be enabled quite easily, which might be an avenue of enquiry for this problem. I would be very grateful if you tell me how to do it. It will resolve the issue at least for our Cyrix CPUs, but will remain for 486. If you want, you can try to find and enable the suggested TAOCRYPT_DISABLE_X86ASM option and rebuild the package yourself (tell me if it works) or just build without --with-yassl. For me this bug is RC, because Debian is supposed to support CPUs =i486 for the i386 architecture. So to latest information it does works on most i486 CPUs. Although it's just the SSL part of MySQL I have strong feelings against using inofficial compiler flags and rather leave it as maybe RC but +wontfix as 486 owners rarely run database servers ... Steve, what do you think? bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
Christian Hammers wrote: If you want, you can try to find and enable the suggested TAOCRYPT_DISABLE_X86ASM option and rebuild the package yourself (tell me if it works) or just build without --with-yassl. I will try this and will followup. But I cannot accept the latter as a general longterm solution; if I liked the idea of rebuilding/compiling I'd be using Gentoo :-) So to latest information it does works on most i486 CPUs. My 486 is down currently, but hopefully I'll fix it in a month or two and will report the outcome. Although it's just the SSL part of MySQL I have strong feelings against using inofficial compiler flags and rather leave it as maybe RC but +wontfix as 486 owners rarely run database servers ... But I'm not running a database server, just an elegant and fully efficient mail server, and it happens that exim4-daemon-heavy depends on libmysqlclient15off... I'm not saying that you should use unofficial flags, you're doing the right thing, it's just a bit frustrating that we're not important for upstream, not anymore :-( -- I had a very low opinion of TCL, basically because it wasn't Lisp. --RMS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
On 2006-08-31 Steve Langasek wrote: On Thu, Aug 31, 2006 at 11:30:58PM +0200, Christian Hammers wrote: It was downgraded, I guess, to enable the propagation of the last mysql security uploads to testing. The problem affects only us, the second class citizens that have old machines. It was tagged wontfix because Christian Hammers (the mysql maintainer) believes that it won't be fixed by upstream. I tend to agree with him with regret. Yes, upstream won't disable assembler optimization as the problem only occurs only on very early i486 and clones like Cyrix, not even on most real i486. There are just too a few of you unlucky guys left :) AFAIK it's not required to disable the assembler -- it's only required to handle the illegal instruction? You volunteer to write the patch or know an assembler coder? ;-) I doubt that MySQL spends time for it. For me this bug is RC, because Debian is supposed to support CPUs =i486 for the i386 architecture. So to latest information it does works on most i486 CPUs. Although it's just the SSL part of MySQL I have strong feelings against using inofficial compiler flags and rather leave it as maybe RC but +wontfix as 486 owners rarely run database servers ... Steve, what do you think? This is reported to break even the loading of php4-mysql on affected systems, which is definitely unrelated to running a database server; and the number of Cyrix systems affected is almost certainly much greater than the number of remaining early-486 systems affected. Let's leave it as RC. I try to disable the assembler and if in the meantime anybody writes a patch we take that. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
On Thu, Aug 31, 2006 at 11:30:58PM +0200, Christian Hammers wrote: It was downgraded, I guess, to enable the propagation of the last mysql security uploads to testing. The problem affects only us, the second class citizens that have old machines. It was tagged wontfix because Christian Hammers (the mysql maintainer) believes that it won't be fixed by upstream. I tend to agree with him with regret. Yes, upstream won't disable assembler optimization as the problem only occurs only on very early i486 and clones like Cyrix, not even on most real i486. There are just too a few of you unlucky guys left :) AFAIK it's not required to disable the assembler -- it's only required to handle the illegal instruction? For me this bug is RC, because Debian is supposed to support CPUs =i486 for the i386 architecture. So to latest information it does works on most i486 CPUs. Although it's just the SSL part of MySQL I have strong feelings against using inofficial compiler flags and rather leave it as maybe RC but +wontfix as 486 owners rarely run database servers ... Steve, what do you think? This is reported to break even the loading of php4-mysql on affected systems, which is definitely unrelated to running a database server; and the number of Cyrix systems affected is almost certainly much greater than the number of remaining early-486 systems affected. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
tags 385147 moreinfo unreproducible thanks On Tue, Aug 29, 2006 at 01:53:26PM +0100, Jamie Thompson wrote: When php4-mysql is enabled, php ceases to work and instead prints Illegal Instruction and terminates. If I disable the extension in php.ini, php works fine, abet without mysql functionality. I've tried reinstalling, to no avail. Mysql seems to be running fine going from it's cli client. That doesn't give me enough information to reproduce the problem. I've tried installing the broken version of libmysqlclient15off as suggested by Sean's comments, but running php4 doesn't give me any such errors. Anyway, I suspect the problem is actually bug #383759, which has for some reason been downgraded and tagged as 'wontfix'. Can you tell me what processor you have in the system you're running this on? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
reassign 385147 libmysqlclient15off forcemerge 383759 385147 thanks On Wed, Aug 30, 2006 at 09:18:08AM +0100, Jamie Robert Thompson wrote: Anyway, I suspect the problem is actually bug #383759, which has for some reason been downgraded and tagged as 'wontfix'. Can you tell me what processor you have in the system you're running this on? Oooh. You're good at this problem-solving lark. Yup, it's a Cyrix P166+. mrlinux:~# cat /proc/cpuinfo processor : 0 vendor_id : unknown cpu family : 4 model : 0 model name : 486 stepping: unknown fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : no cpuid level : -1 wp : yes flags : bogomips: 132.60 Ok, reassigning merging. Oh, one more thing, the problem seems to be ( according to the other bug reports ) that the CPU's lack of the CPUID instruction seems to be the problem. Well, I happen to know for a fact that the processor actually does have a CPUID instruction, it's just disabled by default. It can be enabled quite easily, which might be an avenue of enquiry for this problem. Hrm, how do you go about enabling it then? Is this something that should be referred to the kernel team? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
Package: php4-mysql Version: 4:4.4.2-1.1 Severity: normal When php4-mysql is enabled, php ceases to work and instead prints Illegal Instruction and terminates. If I disable the extension in php.ini, php works fine, abet without mysql functionality. I've tried reinstalling, to no avail. Mysql seems to be running fine going from it's cli client. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i486) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-486 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages php4-mysql depends on: ii debconf [debconf-2.0]1.5.3 Debian configuration management sy ii libapache2-mod-php4 [phpapi- 4:4.4.2-1.1 server-side, HTML-embedded scripti ii libc62.3.6-15GNU C Library: Shared libraries ii libmysqlclient15off 5.0.24-1mysql database client library ii php4-cli [phpapi-20050606] 4:4.4.2-1.1 command-line interpreter for the p ii php4-common 4:4.4.2-1.1 Common files for packages built fr php4-mysql recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385147: [php-maint] Bug#385147: When php4-mysql is enabled, php prints Illegal Instruction and terminates
hi jamie, On Tue, 2006-08-29 at 13:53 +0100, Jamie Thompson wrote: When php4-mysql is enabled, php ceases to work and instead prints Illegal Instruction and terminates. If I disable the extension in php.ini, php works fine, abet without mysql functionality. i'm fairly certain this is due to #384192, in which mysql accidentally changed their ABI without bumping the symbol versions, which can cause all kinds of problems. I've tried reinstalling, to no avail. Mysql seems to be running fine going from it's cli client. could you try downgrading to a version of libmysqlclient15off 5.0.24? if not you could try the latest version that hit unstable yesterday or the day before? i'm fairly certain the former will fix the problem, though if that's not possible i don't know that the latter will fix the problem without recompiling php4, which should happen as soon as the apache packaging team fixes an unrelated bug. sean signature.asc Description: This is a digitally signed message part
