MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

Bug 410474 involves mysql not working on older 486s and some cyrix cpus
which do not have the cpuid instruction.  Any program that tries to use
libmysql (proftpd, php, etc) terminates with illegal instruction.

Upstream tried to fix it, but apparently failed to do so correctly,
although I suspect it does work on BSD if nothing else.

Since I run a 486, and deviced it was time to upgrade to Etch, to see if
there were any issues to report about it before the release happens, I
was rather surprised when proftpd suddenly didn't work.  Commenting out
the mysql module in proftpd's config made it work.  Then I noticed php
didn't work either, if it had mysql enabled, and I tracked down this bug
number.

I have now found a solution to the problem (which makes it solved not
just on BSD where setjmp saves signal context by default, which linux
does not), and added it to the bug.  Of course I don't know if the mysql
maintainer is actually around at the moment to notice and do something
with it.

So does it seem fair to raise the severity to flag mysql as release
critical for etch since it does affect any program that links in
libmysql running on any x86 without cpuid support?  I would hate to see
other people upgrade to Etch on older systems that were working find
just to end up with a bunch of programs no longer working.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Florian Weimer]

* Lennart Sorensen:

> So does it seem fair to raise the severity to flag mysql as release
> critical for etch since it does affect any program that links in
> libmysql running on any x86 without cpuid support?

Document it in the release notes, please.  It's not worth risking
stability for the majority of users for this kind of bug.

Anyway, is there any particular reason why upstream (or you) don't use
the Intel-recommended way for detection of CPUID support?  A library
twiddling with SIGILL isn't a terribly good idea.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 11:46:16PM +0200, Florian Weimer wrote:
> Document it in the release notes, please.  It's not worth risking
> stability for the majority of users for this kind of bug.
> 
> Anyway, is there any particular reason why upstream (or you) don't use
> the Intel-recommended way for detection of CPUID support?  A library
> twiddling with SIGILL isn't a terribly good idea.

I have no idea.  I just made the smallest change possible to make mysql
not break 486 machines.  The other option is to go back to what was done
for sarge as far as I can tell, which is use the C implementation rather
than the assembly one and loose the performance gains on newer CPUs.

And documenting in the release notes that 486s will break on upgrade
doesn't seem like a particularly good solution without a fixed package
being made.  Well if nothing else it can go into 4.0r1 I guess, or a
proposed update in the mean time.

Now if there is a recomended way to detect cpuid support, then it would
certainly make sense for the upstream to use that instead.  I find the
current method very icky. :)  setjmp, and a SIGILL handler just seems
wrong.  Where does one find the recomended method?

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Fri, Apr 06, 2007 at 12:12:58AM +0200, Sam Hocevar wrote:
>Here's a patch that uses the recommended method.

I will test that out on my 486 and see if that works.  It is certainly
much nicer, so assuming it works I vote for this one instead.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Sam Hocevar]

tag 410474 +patch
thanks

On Thu, Apr 05, 2007, Florian Weimer wrote:

> Document it in the release notes, please.  It's not worth risking
> stability for the majority of users for this kind of bug.
> 
> Anyway, is there any particular reason why upstream (or you) don't use
> the Intel-recommended way for detection of CPUID support?  A library
> twiddling with SIGILL isn't a terribly good idea.

   Here's a patch that uses the recommended method.

Cheers,
-- 
Sam.
--- ./extra/yassl/taocrypt/src/misc.cpp.orig	2007-04-06 00:02:10 +0200
+++ ./extra/yassl/taocrypt/src/misc.cpp	2007-04-06 00:04:49 +0200
@@ -192,27 +192,29 @@ bool HaveCpuId()
 }
 return true;
 #else
-typedef void (*SigHandler)(int);
+word32 eax, ebx;
 
-SigHandler oldHandler = signal(SIGILL, SigIllHandler);
-if (oldHandler == SIG_ERR)
-return false;
+__asm__ __volatile
+(
+"pushf\n\t"
+"pushf\n\t"
+"pop %0\n\t"
+"movl %0,%1\n\t"
+"xorl $0x20,%0\n\t"
+"push %0\n\t"
+"popf\n\t"
+"pushf\n\t"
+"pop %0\n\t"
+"popf"
+: "=r" (eax), "=r" (ebx)
+:
+: "cc"
+);
 
-bool result = true;
-if (setjmp(s_env))
-result = false;
-else 
-__asm__ __volatile
-(
-// save ebx in case -fPIC is being used
-"push %%ebx; mov $0, %%eax; cpuid; pop %%ebx"
-: 
-:
-: "%eax", "%ecx", "%edx" 
-);
+if (eax == ebx)
+return false;
 
-signal(SIGILL, oldHandler);
-return result;
+return true;
 #endif
 }
 

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Steve Langasek]

On Thu, Apr 05, 2007 at 06:24:04PM -0400, Lennart Sorensen wrote:
> On Thu, Apr 05, 2007 at 11:46:16PM +0200, Florian Weimer wrote:
> > Document it in the release notes, please.  It's not worth risking
> > stability for the majority of users for this kind of bug.

> > Anyway, is there any particular reason why upstream (or you) don't use
> > the Intel-recommended way for detection of CPUID support?  A library
> > twiddling with SIGILL isn't a terribly good idea.

> I have no idea.  I just made the smallest change possible to make mysql
> not break 486 machines.  The other option is to go back to what was done
> for sarge as far as I can tell, which is use the C implementation rather
> than the assembly one and loose the performance gains on newer CPUs.

> And documenting in the release notes that 486s will break on upgrade
> doesn't seem like a particularly good solution without a fixed package
> being made.  Well if nothing else it can go into 4.0r1 I guess, or a
> proposed update in the mean time.

Documenting it in the release notes isn't particularly *relevant* if a fixed
package is made, AFAICS.  The content for the r0 release notes is frozen
now anyway, to let translators catch up, so any mention of this in the
release notes would be included on CDs the same time as the fixed package,
more or less defeating the purpose.  We should probably consider an errata
document for the website, to document r0-specific issues that didn't make it
into the release notes, so that we don't have to choose between dropping
translations for not mentioning such errata and publishing
supposedly-complete translations that don't mention all the errata due to
time constraints.

Anyway, if this bug had been marked as RC at any point in the past months,
it certainly would have been fixed before now.  It's frustrating to see
people escalating bug severities at the very last minute, when the bug has
been known for a while and it's now too late to include a fix in r0 without
causing the release timeline to slip.  (This is not the only bug where this
has been the case; c.f. bug #399761.)  I do remember a bug thread months ago
about cpuid detection in mysql, but the fact that it wasn't listed as an RC
bug anymore means that it quickly fell off of *my* radar.

In practical terms, it seems to me that part of the fix here should really
be to declare that we don't officially support 486 CPUs anymore, since no
one who is using one was involved enough in the etch release to have
documented this bug as RC until three days before release. :P

-- 
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]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 03:42:28PM -0700, Steve Langasek wrote:
> Documenting it in the release notes isn't particularly *relevant* if a fixed
> package is made, AFAICS.  The content for the r0 release notes is frozen
> now anyway, to let translators catch up, so any mention of this in the
> release notes would be included on CDs the same time as the fixed package,
> more or less defeating the purpose.  We should probably consider an errata
> document for the website, to document r0-specific issues that didn't make it
> into the release notes, so that we don't have to choose between dropping
> translations for not mentioning such errata and publishing
> supposedly-complete translations that don't mention all the errata due to
> time constraints.
> 
> Anyway, if this bug had been marked as RC at any point in the past months,
> it certainly would have been fixed before now.  It's frustrating to see
> people escalating bug severities at the very last minute, when the bug has
> been known for a while and it's now too late to include a fix in r0 without
> causing the release timeline to slip.  (This is not the only bug where this
> has been the case; c.f. bug #399761.)  I do remember a bug thread months ago
> about cpuid detection in mysql, but the fact that it wasn't listed as an RC
> bug anymore means that it quickly fell off of *my* radar.

Well if I had known about it I would have suggested it should be RC.  I
should try to become a DD one of these days... :)

> In practical terms, it seems to me that part of the fix here should really
> be to declare that we don't officially support 486 CPUs anymore, since no
> one who is using one was involved enough in the etch release to have
> documented this bug as RC until three days before release. :P

My 486 actually does a useful job, and hence usually runs pure stable.
I figured I would upgrade it to see if anything broken, and boy did it
ever break.  It is a good old reliable machine and the only 486 I have.
I guess loosing proftpd and php isn't the worst things that can happen,
although I do like my ftp server to work, as well as my web server.  At
least I know have a fixed version installed so my machine works.

Maybe I am the only person left with a 486 doing useful work, but it has
run problem free for 15 years now and shows no signs of giving any.
Hopefully I will replace the 486 with a ppro in the next few months, in
which case the 486 will become available for me to just do tests on and
other experiments.

Is there any good reason 486s should not be supproted anymore?  I know
why 386s are not supported anymore.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 06:27:08PM -0400, Lennart Sorensen wrote:
> I will test that out on my 486 and see if that works.  It is certainly
> much nicer, so assuming it works I vote for this one instead.

It works perfectfly.  Given I see the linux kernel does the same thing,
I guess that isn't surprising at all.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 06:59:16PM -0400, Lennart Sorensen wrote:
> My 486 actually does a useful job, and hence usually runs pure stable.
> I figured I would upgrade it to see if anything broken, and boy did it
> ever break.  It is a good old reliable machine and the only 486 I have.
> I guess loosing proftpd and php isn't the worst things that can happen,
> although I do like my ftp server to work, as well as my web server.  At
> least I know have a fixed version installed so my machine works.
> 
> Maybe I am the only person left with a 486 doing useful work, but it has
> run problem free for 15 years now and shows no signs of giving any.
> Hopefully I will replace the 486 with a ppro in the next few months, in
> which case the 486 will become available for me to just do tests on and
> other experiments.

I guess I can add that given the mysql was the only real problem I
encountered upgrading, Etch looks to be in pretty darn good shape.  The
other minor problems was the netscape navigator 4.77 packages breaking
the x.org /usr/X11R6 upgrade.  I didn't realize they were still
installed.  I guess starting out with Debian 2.1, and upgrading over the
years you end up with a bit of garbage left installed.  I should check
for obsolete packages and clean them out more often.  Thanks to all the
great maintainers that have made it possible to never have to reinstall
in 8 years of service.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Steve Langasek]

On Thu, Apr 05, 2007 at 06:59:16PM -0400, Lennart Sorensen wrote:
> > In practical terms, it seems to me that part of the fix here should really
> > be to declare that we don't officially support 486 CPUs anymore, since no
> > one who is using one was involved enough in the etch release to have
> > documented this bug as RC until three days before release. :P

> My 486 actually does a useful job, and hence usually runs pure stable.
> I figured I would upgrade it to see if anything broken, and boy did it
> ever break.  It is a good old reliable machine and the only 486 I have.
> I guess loosing proftpd and php isn't the worst things that can happen,
> although I do like my ftp server to work, as well as my web server.  At
> least I know have a fixed version installed so my machine works.

> Maybe I am the only person left with a 486 doing useful work, but it has
> run problem free for 15 years now and shows no signs of giving any.
> Hopefully I will replace the 486 with a ppro in the next few months, in
> which case the 486 will become available for me to just do tests on and
> other experiments.

Well, on that subject c.f.
. :)

> Is there any good reason 486s should not be supproted anymore?  I know
> why 386s are not supported anymore.

Like I said, in practical terms, if a bug like this in a major server
package goes unnoticed until 3 days before the release, we are not actually
"supporting" 486.  We support the i386 architecture quite well, but it seems
only honest to admit that as a project, we don't care about 486 enough to
even get 486-specific problems marked as RC in time to do anything about
them for a release.

-- 
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]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Julien Cristau]

On Thu, Apr  5, 2007 at 19:08:03 -0400, Lennart Sorensen wrote:

> The other minor problems was the netscape navigator 4.77 packages
> breaking the x.org /usr/X11R6 upgrade.

Do you know the exact name of the old package that caused this problem?

Thanks,
Julien


signature.asc
Description: Digital signature

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Francesco P. Lovergine]

On Thu, Apr 05, 2007 at 04:10:19PM -0700, Steve Langasek wrote:
> Like I said, in practical terms, if a bug like this in a major server
> package goes unnoticed until 3 days before the release, we are not actually
> "supporting" 486.  We support the i386 architecture quite well, but it seems
> only honest to admit that as a project, we don't care about 486 enough to
> even get 486-specific problems marked as RC in time to do anything about
> them for a release.
> 

That could be fixed in R1, isn't it? I see no major problems on those
regards...

-- 
Francesco P. Lovergine


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Andreas Barth]

* Francesco P. Lovergine ([EMAIL PROTECTED]) [070406 12:33]:
> On Thu, Apr 05, 2007 at 04:10:19PM -0700, Steve Langasek wrote:
> > Like I said, in practical terms, if a bug like this in a major server
> > package goes unnoticed until 3 days before the release, we are not actually
> > "supporting" 486.  We support the i386 architecture quite well, but it seems
> > only honest to admit that as a project, we don't care about 486 enough to
> > even get 486-specific problems marked as RC in time to do anything about
> > them for a release.
> > 
> 
> That could be fixed in R1, isn't it? I see no major problems on those
> regards...

Well, we can fix it - but are you sure that's the only package with an
issue on 80486? I think we should put somewhere into Lenny that our code
should still run on 80486, but it might not be QAed enough for all
subarches (but we can discuss that later, don't need to reach a
consensus now).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Theodore Tso]

On Fri, Apr 06, 2007 at 12:36:18PM +0200, Andreas Barth wrote:
> * Francesco P. Lovergine ([EMAIL PROTECTED]) [070406 12:33]:
> > On Thu, Apr 05, 2007 at 04:10:19PM -0700, Steve Langasek wrote:
> > > Like I said, in practical terms, if a bug like this in a major server
> > > package goes unnoticed until 3 days before the release, we are not 
> > > actually
> > > "supporting" 486.  We support the i386 architecture quite well, but it 
> > > seems
> > > only honest to admit that as a project, we don't care about 486 enough to
> > > even get 486-specific problems marked as RC in time to do anything about
> > > them for a release.
> > 
> > That could be fixed in R1, isn't it? I see no major problems on those
> > regards...
> 
> Well, we can fix it - but are you sure that's the only package with an
> issue on 80486? I think we should put somewhere into Lenny that our code
> should still run on 80486, but it might not be QAed enough for all
> subarches (but we can discuss that later, don't need to reach a
> consensus now).

The fact that we can't say for sure is a good reason to say that we
don't "support" 486.  That is to say, we can't guarantee that it will
work, because we don't have enough people who are testing on that
platform.  

There is a difference between "we won't consciously break 486, and
we'll apply patches when they are called to our attention, but we
won't hold up an entire release for it", and "support".  For all that
people like to beat up on Red Hat and Fedora for their supposed "lack
of quality", this is a concept which Red Hat and other commercially
supported enterprise distributions understand.  If they can't test on
a platform, they don't call it supported.  (And they do get help from
major system vendors to do a lot of very serious regression testing
before they say that it is supported on a particular platform.)  

If we are going to claim that Debian is stable enterprise system for
servers, so stable in fact that we must use an obsolete version of
glibc compared to RHEL and SLES (even though we are releasing later
than RHEL and SLES), then it would be wise for us to use at _least_ as
stringent set of QA gaurantees as Red Hat and Novell.  And if that
means that we can't say that we "support" the 486, then so be it.

- Ted


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Fri, Apr 06, 2007 at 01:24:06AM +0200, Julien Cristau wrote:
> Do you know the exact name of the old package that caused this problem?

I believe they were:

communicator-smotif-477
navigator-smotif-477

Both from woody (3.0) non-free.

Certainly both include /usr/X11R6/bin in them.
--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Julien Cristau]

On Sat, Apr  7, 2007 at 13:31:00 -0400, Lennart Sorensen wrote:

> On Fri, Apr 06, 2007 at 01:24:06AM +0200, Julien Cristau wrote:
> > Do you know the exact name of the old package that caused this problem?
> 
> I believe they were:
> 
> communicator-smotif-477
> navigator-smotif-477
> 
> Both from woody (3.0) non-free.
> 
> Certainly both include /usr/X11R6/bin in them.

Thanks, I added those conflicts (along with a few others) in x11-common
1:7.1.0-18.  Unfortunately, it didn't make it to etch r0 :/

Cheers,
Julien


signature.asc
Description: Digital signature

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Sat, Apr 07, 2007 at 07:46:35PM +0200, Julien Cristau wrote:
> Thanks, I added those conflicts (along with a few others) in x11-common
> 1:7.1.0-18.  Unfortunately, it didn't make it to etch r0 :/

Sounds good.  I remember a while ago having a problem upgrading a newer
machine, and the package for opera had a similar issue.  I don't know if
opera fixed their .debs yet, but it isn't an official debian package
anyhow so I wouldn't worry about that one.

--
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]