Problem with VIA C3 chip and libcrypto
David Goodenough
( an ECS A900 ) which uses the VIA C3 chip. However I am not sure it is
a problem with libssl, so I thought I would ask here before entering bugs.
The latest libssl has processor specific versions of libcrypto, and the
one that ldd reports will be used is in /usr/lib/i686. But when this
one is used ssh and other such programs that use ssl fall over with an
illegal instruction fault. If I rename /usr/lib/i686 ssh works properly.
Now when I built the kernel (2.4.19) I specified that this was a VIA C3
and CONFIG_MCYRIXIII was set. However I noticed that when building the
kernel there were frequent references to march=586, note not 686.
/proc/cpuinfo reports:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 2
cpu MHz : 731.018
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips : 1458.17
I also notice that when I log on to a console (not X) that i686 is
mentioned in the banner.
Anyone got any ideas?
David
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Colin Watson
> I have found a problem with using the latest libssl package on a machine
> ( an ECS A900 ) which uses the VIA C3 chip. However I am not sure it is
> a problem with libssl, so I thought I would ask here before entering bugs.
See bug #164766. It seems cmov is being used in
/usr/lib/i686/libcrypto.so.0.9.6 despite the fact that it isn't
available on all i686 processors.
--
Colin Watson [cjwa...@flatline.org.uk]
Michael Karcher
> On Wed, Oct 30, 2002 at 11:25:55AM +0000, David Goodenough wrote:
> > I have found a problem with using the latest libssl package on a machine
> > ( an ECS A900 ) which uses the VIA C3 chip. However I am not sure it is
> > a problem with libssl, so I thought I would ask here before entering bugs.
> See bug #164766. It seems cmov is being used in
> /usr/lib/i686/libcrypto.so.0.9.6 despite the fact that it isn't
> available on all i686 processors.
Isn't the specification of the Intel Pentium Pro Processor(tm) defining
what a i686 processor is? If it's not that document, who defines the exact
meaning of i686?
So if the VIA C3 chip does not support the cmov instruction, the chip does
IMHO not implement the i686 instruction set, and should be treated as i586.
Or read it that way: It is a processor bug that CPUID reports "family 6"
on a processor lacking the cmov instruction. I don't like a kernel check
that downgrades the CPUID info on the VIA C3 either, but currently thats
the only way to go to make things right, I think.
Michael Karcher
Michael Karcher
> > So if the VIA C3 chip does not support the cmov instruction, the chip does
> > IMHO not implement the i686 instruction set, and should be treated as i586.
> According to Alan Cox this is actually a gcc bug. cmov is apparently an
> optional 686 instruction,
...because this is correct. Conditional moves are optional instructions,
just like MMX, 3D now!, SSE, fxsr, syscall or sysenter. So it is true that
gcc should *not* generate them for i686. On the other hand, using cmov
instructions could definitely improve performance in some applications
because they avoid mispredicted jumps. I don't know whether openssl can
take profit of these instructions, but It seems likely. Is there any way to
select libraries based on 'instruction set' instead of architecture, so
the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
and 3D now!', although they all are 'family: 6'.
This does *not* mean we should provide ssl libraries for all those different
processor subtypes, but it could be a good thing to provide for those
extensions, that result in a performance gain of more than 10%.
> and the problem would go away. I am not sure which level of gcc fixes
> the problem, I hope this does not require 3.2 as that opens a whole can
> of worms (which I know are being digested as I type).
Looking at the info pages of gcc 3.2 I don't see any option for enabling
or disabling the use of cmov, and strings on /usr/lib/gcc-lib/3.2.1/cc1
does not reveal any one either. So I fear, even gcc 3.2 still uses cmov.
I will test it.
> David
Michael
Ricardo Javier Cardenes Medina
> take profit of these instructions, but It seems likely. Is there any way to
> select libraries based on 'instruction set' instead of architecture, so
> the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
> the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
> and 3D now!', although they all are 'family: 6'.
See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
Oliver M. Bolzer
> On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > take profit of these instructions, but It seems likely. Is there any way to
> > select libraries based on 'instruction set' instead of architecture, so
> > the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
> > the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
> > and 3D now!', although they all are 'family: 6'.
>
> See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
>
> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
The problem with OpenSSL is, that it is hand-assembly. The author is using
the cmov instruction for an i686-optimized routine, though that instruction
is not guranteed to be available.
As another C3 user who has to keep libssl on hold for now, I'd suggest that
the i686-optimized version be replaced with a version that runs on all
i686-family processors.
Another option would be to do runtime detection and choose according to
that, but that would be without the current convenience that the linker
chooses the right lib. As long as the linker only decids on the general
processor type, the code for a specific processor type should match the
least common denominator.
--
Oliver M. Bolzer
oli...@gol.com
GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF
GOTO Masanori
Oliver M. Bolzer <oli...@gol.com> wrote:
> On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes Medina <rcar...@debian.org> wrote...
> > On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > > take profit of these instructions, but It seems likely. Is there any way to
> > > select libraries based on 'instruction set' instead of architecture, so
> > > the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
> > > the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
> > > and 3D now!', although they all are 'family: 6'.
> >
> > See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
> >
> > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> > pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
>
> The problem with OpenSSL is, that it is hand-assembly. The author is using
> the cmov instruction for an i686-optimized routine, though that instruction
> is not guranteed to be available.
I could not find which source cmov is used, could you tell me?
If it's the fact, openssl should be fixed in #164766.
> As another C3 user who has to keep libssl on hold for now, I'd suggest that
> the i686-optimized version be replaced with a version that runs on all
> i686-family processors.
> Another option would be to do runtime detection and choose according to
> that, but that would be without the current convenience that the linker
> chooses the right lib. As long as the linker only decids on the general
> processor type, the code for a specific processor type should match the
> least common denominator.
Yes. It's insane option that linker selects i586 library in only the
case of "flags: cmov" is detected on VIA C3. It means that linker
consider "C3 is i586". So, if kernel detects VIA C3, then it's natural
to be treated with i586 straightforwardly (thus /proc/cpuinfo prints
processor family: i586).
-- gotom
Christoph Martin
> At Mon, 4 Nov 2002 11:07:56 +0100,
> Oliver M. Bolzer <oli...@gol.com> wrote:
> > On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes Medina <rcar...@debian.org> wrote...
> > > On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > > > take profit of these instructions, but It seems likely. Is there any way to
> > > > select libraries based on 'instruction set' instead of architecture, so
> > > > the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
> > > > the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
> > > > and 3D now!', although they all are 'family: 6'.
> > >
> > > See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
> > >
> > > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> > > pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
> >
> > The problem with OpenSSL is, that it is hand-assembly. The author is using
> > the cmov instruction for an i686-optimized routine, though that instruction
> > is not guranteed to be available.
>
> I could not find which source cmov is used, could you tell me?
> If it's the fact, openssl should be fixed in #164766.
openssl does not use explicitly cmov. On all processors which are
detected as i686 by the linker a library is used which is optimized via
gcc and the -mcpu=i686 flag. This flag brings the cmov in I suspect.
> > As another C3 user who has to keep libssl on hold for now, I'd suggest that
> > the i686-optimized version be replaced with a version that runs on all
> > i686-family processors.
> > Another option would be to do runtime detection and choose according to
> > that, but that would be without the current convenience that the linker
> > chooses the right lib. As long as the linker only decids on the general
> > processor type, the code for a specific processor type should match the
> > least common denominator.
>
> Yes. It's insane option that linker selects i586 library in only the
> case of "flags: cmov" is detected on VIA C3. It means that linker
> consider "C3 is i586". So, if kernel detects VIA C3, then it's natural
> to be treated with i586 straightforwardly (thus /proc/cpuinfo prints
> processor family: i586).
This is what I said. The linker (glibc) should fix this.
Christoph
David Goodenough
Christoph
The linker can not fix this. The C3 is a legitimate 686, it just does not
have the OPTIONAL cmov instruction. The kernel therefore correctly shows
this as a 686, and the linker tries the i686 directory (I presume). The
linker has no way of knowing whether the code in the i686 directory uses
this optional instruction or not and loads it blindly, hence the problem.
I am told (by Alan Cox) that GCC originally uses cmov for 686, before it
was realised that it was optional. However looking through google I have
not been able to establish when gcc fixed it, and if this fix is present
in any 2.9x gcc or only in 3.x. Maybe the maintainer of gcc would know
and he may also be able to backfit this fix if it is not in 2.9x
David
Christoph Martin
> On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes Medina <rcar...@debian.org> wrote...
> > On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > > take profit of these instructions, but It seems likely. Is there any way to
> > > select libraries based on 'instruction set' instead of architecture, so
> > > the VIA C3 could get code 'without cmov', the PII 'with cmov and MMX',
> > > the PIII 'with cmov, MMX and SSE' and an Athlon processor 'with cmov, MMX
> > > and 3D now!', although they all are 'family: 6'.
> >
> > See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
> >
> > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
> > pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
>
> The problem with OpenSSL is, that it is hand-assembly. The author is using
> the cmov instruction for an i686-optimized routine, though that instruction
> is not guranteed to be available.
This is wrong. The cmov instruction is NOT used in the assembly
routines. Also there are only assembly routines for i586. The cmov
instruction comes in through the usage of the -mcpu=i686 flag of
gcc. cmov is optional in i686, so gcc should not use it.
Christoph
--
============================================================================
Christoph Martin, EDV der Verwaltung, Uni-Mainz, Germany
Internet-Mail: Christop...@Uni-Mainz.DE
Telefon: +49-6131-3926337
David Goodenough
> On Tue, Nov 05, 2002 at 02:17:40PM +0000, David Goodenough wrote:
> > On Tuesday 05 November 2002 13:04, Christoph Martin wrote:
> > > Am Die, 2002-11-05 um 01.34 schrieb GOTO Masanori:
> > > > At Mon, 4 Nov 2002 11:07:56 +0100,
> > > >
> > > > Oliver M. Bolzer <oli...@gol.com> wrote:
> > > > > Medina <rcar...@debian.org> wrote...
> > > > >
> > > > > > On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > > > > > > take profit of these instructions, but It seems likely. Is
> > > > > > > there any way to select libraries based on 'instruction set'
> > > > > > > instead of architecture, so the VIA C3 could get code 'without
> > > > > > > cmov', the PII 'with cmov and MMX', the PIII 'with cmov, MMX
> > > > > > > and SSE' and an Athlon processor 'with cmov, MMX and 3D now!',
> > > > > > > although they all are 'family: 6'.
> > > > > >
> > > > > > See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
> > > > > >
> > > > > > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
> > > > > > mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
> > > > >
> > > > > The problem with OpenSSL is, that it is hand-assembly. The author
> > > > > is using the cmov instruction for an i686-optimized routine, though
> > > > > that instruction is not guranteed to be available.
> > > >
>
> On the other hand:
> {"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW},
> GCC disagrees with you that the C3 is an i686.
Well we have a disagreement between the kernel (which when you specify
C3 actually compiles everything march=i586) which reports in /proc/cpuinfo
that family = 6, and gcc. From all I can find out cmove is an optional
instruction for the 686, and if cmove was not used the code would run on
a C3. So either this is a kernel problem, and the C3 should be reported
as a 586, or it is a gcc problem for generating the wrong code. Whoever
is wrong, the end result is that libssl will not work as shipped on any
machine with a C3 in it - someone needs to fix it.
I really do not care which package fixes it, as long as it gets fixed.
If we can get agreement on which package should fix it I am happy to see
if I can fix it, and I am quite prepared to test any fix, but I would
rather get agreement as to where the fix should be before I start, as at
the moment everyone is saying it is someone else's fault.
David
Daniel Jacobowitz
> On Tuesday 05 November 2002 13:04, Christoph Martin wrote:
>
> The linker can not fix this. The C3 is a legitimate 686, it just does not
> have the OPTIONAL cmov instruction. The kernel therefore correctly shows
> this as a 686, and the linker tries the i686 directory (I presume). The
> linker has no way of knowing whether the code in the i686 directory uses
> this optional instruction or not and loads it blindly, hence the problem.
>
> I am told (by Alan Cox) that GCC originally uses cmov for 686, before it
> was realised that it was optional. However looking through google I have
> not been able to establish when gcc fixed it, and if this fix is present
> in any 2.9x gcc or only in 3.x. Maybe the maintainer of gcc would know
> and he may also be able to backfit this fix if it is not in 2.9x
GCC 3.2 still uses CMOVE instructions on -march=i686.
On the other hand:
{"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW},
GCC disagrees with you that the C3 is an i686.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Oliver M. Bolzer
> "Oliver M. Bolzer" <oli...@gol.com> writes:
> > The problem with OpenSSL is, that it is hand-assembly. The author is using
> > the cmov instruction for an i686-optimized routine, though that instruction
> > is not guranteed to be available.
> This is wrong. The cmov instruction is NOT used in the assembly
> routines. Also there are only assembly routines for i586. The cmov
> instruction comes in through the usage of the -mcpu=i686 flag of
> gcc. cmov is optional in i686, so gcc should not use it.
OK, my error. I didn't check the sources myself (root for all evil) and
just assumed it was hand-written based on this thread.
Nevertheless, it IS a real problem. As the cmov instruction is OPTIONAL
for i686 but GCC uses it for 686, that is the cause of the problem. That
the kernel compiles itself as 585 if a C3 is specified is simply a
work-around. The correct solution is to fix GCC, but for now, can we
either not ship a i686-optimized libssl or just hardlink the
i585-version into the i686-directory ? We have lived with the i386
version long enough, using a slightly less optimized version for the
time being is MUCH better than simply breaking on C3 machines.
--
Oliver M. Bolzer
oli...@gol.com
GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF
Henrique de Moraes Holschuh
> Nevertheless, it IS a real problem. As the cmov instruction is OPTIONAL
> for i686 but GCC uses it for 686, that is the cause of the problem. That
> the kernel compiles itself as 585 if a C3 is specified is simply a
> work-around. The correct solution is to fix GCC, but for now, can we
> either not ship a i686-optimized libssl or just hardlink the
> i585-version into the i686-directory ? We have lived with the i386
> version long enough, using a slightly less optimized version for the
> time being is MUCH better than simply breaking on C3 machines.
That's no real fix. Any other binary compiled for i686 will break royally
on C3. The correct workaround is to downgrade it kernel-wise to a i586
until gcc is fixed, and all i686 stuff recompiled... or teach ld.so to think
that a C3 is a i586 for the time being.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Daniel Jacobowitz
> On Tue, 05 Nov 2002, Oliver M. Bolzer wrote:
> > Nevertheless, it IS a real problem. As the cmov instruction is OPTIONAL
> > for i686 but GCC uses it for 686, that is the cause of the problem. That
> > the kernel compiles itself as 585 if a C3 is specified is simply a
> > work-around. The correct solution is to fix GCC, but for now, can we
> > either not ship a i686-optimized libssl or just hardlink the
> > i585-version into the i686-directory ? We have lived with the i386
> > version long enough, using a slightly less optimized version for the
> > time being is MUCH better than simply breaking on C3 machines.
>
> That's no real fix. Any other binary compiled for i686 will break royally
> on C3. The correct workaround is to downgrade it kernel-wise to a i586
> until gcc is fixed, and all i686 stuff recompiled... or teach ld.so to think
> that a C3 is a i586 for the time being.
I note that Alan just moved the kernel from compiling using -march=i586
to -march=i486, in the absence of -march=c3.
GCC's policy seems to be to call the c3 a 486... perhaps the kernel is
the one which should change. The best place to pursue this
conversation is probably on the GCC list or on linux-kernel, however.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Michael Stone
>on C3. The correct workaround is to downgrade it kernel-wise to a i586
Yeah, that's easy for us to do, since a significant fraction of our
users compile their own kernels...
Mike Stone
Henrique de Moraes Holschuh
On Tue, 05 Nov 2002, Michael Stone wrote:
> On Tue, Nov 05, 2002 at 04:14:42PM -0200, Henrique de Moraes Holschuh wrote:
> >That's no real fix. Any other binary compiled for i686 will break royally
> >on C3. The correct workaround is to downgrade it kernel-wise to a i586
>
> Yeah, that's easy for us to do, since a significant fraction of our
> users compile their own kernels...
And get screwed over the issue anyway... well, a workaround for the whole
trouble would be for ld.so to refuse to RUN i686 binaries and libs in a C3
:)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh