Re: PROBLEM:Illegal instruction when mount nfs file systems using

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Mikael Pettersson]

On Thu, 28 Jun 2001 20:42:09 +0100 (BST), Alan Cox wrote:

>> > Intel specifically state that you cannot use CMOV without checking
>> > for it. Its actually a gcc/binutils tool bug. The CPU is right.
>> 
>> How is that a gcc bug?  You tell the compiler to generate cmov, you run
>> it on a CPU that doesn't have it, you get what you deserve.  There's
>> really nothing the tools can do about that.
>
>I tell gcc to buld for the 'i686' architecture definition. It in fact builds
>for the i686 architecture assuming an optional feature.

Here I have to disagree with you Alan. When you pass "-march=i686" to
gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
"-march=i686" actually means "target an Intel P6 family chip, given
what we currently know about them". The gcc info pages don't talk
about CPUID family codes, they talk about specific chip families.

As for CMOV being optional, show me an Intel P6 without CMOV and I'll
volunteer to update gcc's docs to warn that "bastard CMOV-less P6 users
should not use the -march=i686 option".

Taking Alan's formal standpoint, there is _no_ compiler-usable difference
between family 4, 5, and 6 processors, since the changes are limited
to system-level code, or useless (gcc doesn't need UD2), or are conditional
on specific CPUID feature bits (which gcc cannot or should not test).
The only guaranteed and useful distinction is "386" and "486 or better",
since the 486 added BSWAP/CMPXCHG/XADD.
[IA-32 manual set, Volume 3, Section 17.7.1 in the revision I have.]

Furthermore, any interpretation of the CPUID family code _must_ be
conditionalised on the CPUID vendor field. The fact that Intel attaches
some semantics to "family 6" doesn't restrict other vendors, since Intel
also defines "vendor == Intel" while the other vendors obviously have
"vendor != Intel", a blatant deviation from the IA-32 manuals.

The real problem is that the kernel generates "uname -m" based only
on the CPUID family code, which is meaningless unless we also know
the vendor name. So "uname -m" ought to be "${FAMILY}86-${VENDOR}",
giving us "686-Intel", "686-AMD", "686-Centaur", and so on.

Unfortunately, changing the output of "uname -m" also breaks lots
of user-space configuration tools out there ... I'm not sure we want
to do that only because VIA&Centaur in their infinite wisdom
decided to build a "family 6" chip without a CMOV instruction.

/Mikael

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Alan Cox]

> Here I have to disagree with you Alan. When you pass "-march=i686" to
> gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> "-march=i686" actually means "target an Intel P6 family chip, given
> what we currently know about them". The gcc info pages don't talk

Which is fine. The Pentium Pro manual explicitly states that cmov may go
away. So it is not based on what we know about the CPU, its based on not
reading the documentation. 

It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
It happens to work because the error in reading the docs was never triggered
by intel removing cmov from a cpu as the reserved the right to do

Alan

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Bernd Schmidt]

On Fri, 29 Jun 2001, Alan Cox wrote:

> > Here I have to disagree with you Alan. When you pass "-march=i686" to
> > gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> > "-march=i686" actually means "target an Intel P6 family chip, given
> > what we currently know about them". The gcc info pages don't talk
> 
> Which is fine. The Pentium Pro manual explicitly states that cmov may go
> away. So it is not based on what we know about the CPU, its based on not
> reading the documentation. 
> 
> It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
> It happens to work because the error in reading the docs was never triggered
> by intel removing cmov from a cpu as the reserved the right to do

Pedantically you  may be right, but it's not a very useful interpretation of
the situation.  Would it make you happier if -march=i686 was documented as
generating cmov instructions?  IMO it's only a manual bug if at all.


Bernd

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Alan Cox]

> > It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
> > It happens to work because the error in reading the docs was never triggered
> > by intel removing cmov from a cpu as the reserved the right to do
> 
> Pedantically you  may be right, but it's not a very useful interpretation of
> the situation.  Would it make you happier if -march=i686 was documented as
> generating cmov instructions?  IMO it's only a manual bug if at all.

Its certainly too late to do anything about and I wouldnt suggest changing it
at all. It probably should be documented however.

Alan

RE: PROBLEM:Illegal instruction when mount nfs file systems using

[Frank Zhu (Shanghai)]

ok.
i just do another test.maybe meaningful.
1)no matter i select -march=i686 or -march=i386 the result are the same. 
2)the server 192.168.0.254 (netboot) ,client 192.168.0.3
there are /usr ,/usr/local/ ,/home, /lib, /bin ....... on the server
on the client
A: mount -t nfs netboot:/usr  /usr
    mount -t nfs netboot:/lib /lib
    mount -t nfs netboot:/bin /bin
    mount -t nfs netboot:/sbin /sbin
Illegal instruction (core dumped)

B:mount  -t nfs netboot:/usr /1
    mount -t nfs netboot:/lib /2
    mount -t nfs netboot:/bin /3
    mount -t nfs netboot:/sbin /4
    mount ...................
ok

it seems that mount on the  same mount point(/usr----/usr....) error occurs
but on the different mount point(/usr------/1......) seems ok
then i install a machine with (lower version distribution kernel
2.2.13)Bluepoint 1.0. there are no mount problems above.

  

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: 2001年6月29日 7:12
To: mikpe@csd.uu.se
Cc: alan@lxorguk.ukuu.org.uk; bernds@redhat.com; FrankZhu@viatech.com.cn;
linux-kernel@vger.kernel.org; mikpe@csd.uu.se
Subject: Re: PROBLEM:Illegal instruction when mount nfs file systems using


> Here I have to disagree with you Alan. When you pass "-march=i686" to
> gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> "-march=i686" actually means "target an Intel P6 family chip, given
> what we currently know about them". The gcc info pages don't talk

Which is fine. The Pentium Pro manual explicitly states that cmov may go
away. So it is not based on what we know about the CPU, its based on not
reading the documentation. 

It's a bug. -march=i6868 does not 'target an Intel P6 family chip, ...'
It happens to work because the error in reading the docs was never triggered
by intel removing cmov from a cpu as the reserved the right to do

Alan

Re: PROBLEM:Illegal instruction when mount nfs file systems using

[Alan Cox]

> > Intel specifically state that you cannot use CMOV without checking
> > for it. Its actually a gcc/binutils tool bug. The CPU is right.
> 
> How is that a gcc bug?  You tell the compiler to generate cmov, you run
> it on a CPU that doesn't have it, you get what you deserve.  There's
> really nothing the tools can do about that.

I tell gcc to buld for the 'i686' architecture definition. It in fact builds
for the i686 architecture assuming an optional feature. Intel's own PPro doc
is quite explicit that cmov could go away again in future chips.

So cmov should not have been in the 686 machine definition.

Alan