Floating point broken between 2.4.0-ac4 and -ac5?

Floating point broken between 2.4.0-ac4 and -ac5?

[junio]

A Duron box running 2.4.0-ac5 (and -ac6) shows NaN in many
places (such as df output showing usage "nan%").  Right now I
reverted back to 2.4.0-ac4 which does not show the problem.
The kernel was compiled with CONFIG_MK7 and without
MATH_EMULATION, if that makes any difference.
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Floating point broken between 2.4.0-ac4 and -ac5?

[Alan Cox]

> A Duron box running 2.4.0-ac5 (and -ac6) shows NaN in many
> places (such as df output showing usage "nan%").  Right now I
> reverted back to 2.4.0-ac4 which does not show the problem.
> The kernel was compiled with CONFIG_MK7 and without
> MATH_EMULATION, if that makes any difference.

If you boot with the nofxsr option does that fix the problem ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Udo A. Steinberg]

Hi all,

As I just found out, Linux 2.4.1-pre1 breaks several things on
my system that worked perfectly in 2.4.0-final and the entire
2.4.0-ac tree.

XFree 4.2.0 now fails to detect monitor timings and therefore
removes all modelines and bails out. The relevant diff of the
X logfile follows. Note the "nan" bits.

< (II) NV(0): Gamma: 1.80
---
> (II) NV(0): Gamma: nan
385,386c385,386
< (II) NV(0): redX: 0.625 redY: 0.340   greenX: 0.285 greenY: 0.600
< (II) NV(0): blueX: 0.150 blueY: 0.065   whiteX: 0.283 whiteY: 0.298
---
> (II) NV(0): redX: 0.625 redY: nan   greenX: 0.285 greenY: 0.600
> (II) NV(0): blueX: 0.150 blueY: nan   whiteX: 0.283 whiteY: 0.298
424c424
< (II) NV(0): Clock range:  12.00 to 350.00 MHz
---
> (II) NV(0): Clock range:    nan to    nan MHz


Moreover, with 2.4.1-pre1 the "w" command behaves in mysterious ways:

Normal output is something like:

USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     tty1     -                 2:23pm  4:41   0.03s  0.03s  -bash  

With 2.4.1-pre1 things look like:

USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
root     tty1     -                 2:21pm   ?     0.2147483648s  0.01s  w

I'm not sure I need it so precise :-)

Since the 2.4.1-pre1 patch is rather small, it shouldn't be too hard
to hunt down the part that causes these oddities.

Regards,
Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Ingo Oeser]

On Wed, Jan 10, 2001 at 02:31:03PM +0100, Udo A. Steinberg wrote:
> As I just found out, Linux 2.4.1-pre1 breaks several things on
> my system that worked perfectly in 2.4.0-final and the entire
> 2.4.0-ac tree.
> 
> XFree 4.2.0 now fails to detect monitor timings and therefore
> removes all modelines and bails out. The relevant diff of the
> X logfile follows. Note the "nan" bits.
> 
[logs]
> Since the 2.4.1-pre1 patch is rather small, it shouldn't be too hard
> to hunt down the part that causes these oddities.

The only thing that looks responsible for this is the FXSR stuff,
that changed.

Like to try again backing this out?

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Udo A. Steinberg]

Hi,

Ingo Oeser wrote:
> 
> The only thing that looks responsible for this is the FXSR stuff,
> that changed.
> 
> Like to try again backing this out?

Just to make sure it wasn't a gcc thing, I've recompiled the original
setup with egcs-1.1.2 (previously had used 2.95.2) and that did not
fix a thing.

Next backed out the entire XMM and FXSR related stuff and now everything
is fine again. The CPU in question is an AMD Thunderbird (see cpuinfo
below). A friend with a similar setup but a Pentium-3 CPU doesn't seem
to see the problem (couldn't verify myself).

/proc/cpuinfo:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 807.211
cache size      : 256 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 vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1608.90 


Who wrote that new FXSR stuff? Maybe they have an idea of what's going on.

Regards,
Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Jonathan Hudson]

In article <3A5C96BB.96B19DB@hell.wh8.tu-dresden.de>,
	"Udo A. Steinberg" <sorisor@Hell.WH8.TU-Dresden.De> writes:
UAS> 
UAS> Next backed out the entire XMM and FXSR related stuff and now everything
UAS> is fine again. The CPU in question is an AMD Thunderbird (see cpuinfo
UAS> below). A friend with a similar setup but a Pentium-3 CPU doesn't seem
UAS> to see the problem (couldn't verify myself).
UAS> 

Yes. Broke horribly on my Duron 800. Time set to Dec 22 1932, X
completely confused. Anything to do the the network very
slow. Rebooted back into 2.4.0 and normality (including correct time).

Definitly an AMD issue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

In article <3A5C96BB.96B19DB@Hell.WH8.TU-Dresden.De>,
Udo A. Steinberg <sorisor@Hell.WH8.TU-Dresden.De> wrote:
>
>Next backed out the entire XMM and FXSR related stuff and now everything
>is fine again. The CPU in question is an AMD Thunderbird (see cpuinfo
>below). A friend with a similar setup but a Pentium-3 CPU doesn't seem
>to see the problem (couldn't verify myself).

Mind trying it with the "HAVE_FXSR" and "HAVE_XMM" macros in 

	linux/include/asm-i386/processor.h

fixed? They _should_ be just

	#define HAVE_FXSR	(cpu_has_fxsr)
	#define HAVE_XMM	(cpu_has_xmm)

instead of testing random bits in CR4 that have different meaning on
different CPU's. 

I'm surprised actually - the same CR4 tests are in newer 2.2.x kernels,
I think. (And in 2.2.x kernels, the above "cpu_has_xxx" do _not_ work
unless FP exception testing etc has been fixed in the 2.2.x tree)

Andrea?

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Alan Cox]

> 	#define HAVE_FXSR	(cpu_has_fxsr)
> 	#define HAVE_XMM	(cpu_has_xmm)
> 
> I'm surprised actually - the same CR4 tests are in newer 2.2.x kernels,
> I think. (And in 2.2.x kernels, the above "cpu_has_xxx" do _not_ work

Nope. 2.2 doesnt have XMM/FXSR support. There are add on patches for it but
I don't plan to merge them

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Udo A. Steinberg]

Linus Torvalds wrote:
> 
> Mind trying it with the "HAVE_FXSR" and "HAVE_XMM" macros in
> 
>         linux/include/asm-i386/processor.h
> 
> fixed? They _should_ be just
> 
>         #define HAVE_FXSR       (cpu_has_fxsr)
>         #define HAVE_XMM        (cpu_has_xmm)

That doesn't help either.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andi Kleen]

On Thu, Jan 11, 2001 at 11:05:55AM +0100, Udo A. Steinberg wrote:
> Linus Torvalds wrote:
> > 
> > Mind trying it with the "HAVE_FXSR" and "HAVE_XMM" macros in
> > 
> >         linux/include/asm-i386/processor.h
> > 
> > fixed? They _should_ be just
> > 
> >         #define HAVE_FXSR       (cpu_has_fxsr)
> >         #define HAVE_XMM        (cpu_has_xmm)
> 
> That doesn't help either.

Did you have CONFIG_X86_FXSR or CONFIG_X86_RUNTIME_FXSR enabled when it
worked? 

If not it probably means that the XServer is testing OSFXSR and the branch
that handles it doesn't work.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Udo A. Steinberg]

Andi Kleen wrote:
> 
> Did you have CONFIG_X86_FXSR or CONFIG_X86_RUNTIME_FXSR enabled when it
> worked?
> 
> If not it probably means that the XServer is testing OSFXSR and the branch
> that handles it doesn't work.

--- linux-2.4.0/.config Thu Jan 11 11:22:11 2001
+++ linux-2.4.1/.config Thu Jan 11 11:24:56 2001
@@ -27,7 +27,7 @@
 # CONFIG_M586TSC is not set
 # CONFIG_M586MMX is not set
 # CONFIG_M686 is not set
-# CONFIG_M686FXSR is not set
+# CONFIG_MPENTIUMIII is not set
 # CONFIG_MPENTIUM4 is not set
 # CONFIG_MK6 is not set
 CONFIG_MK7=y

The only difference between the two .config files is shown above.
2.4.0 works, 2.4.1 doesn't. And it's not just the X server acting funny.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 11:31:21AM +0100, Udo A. Steinberg wrote:
>  CONFIG_MK7=y

I'm looking into it.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 06:36:05PM +0100, Andrea Arcangeli wrote:
> On Thu, Jan 11, 2001 at 11:31:21AM +0100, Udo A. Steinberg wrote:
> >  CONFIG_MK7=y
> 
> I'm looking into it.

The fxsr fixes from 2.4.1-pre1 allows athlon to correctly use FXSR too (when
nofxsr isn't passed to the kernel of course).

So then this 3dnow breaks here:

void *_mmx_memcpy(void *to, const void *from, size_t len)
{
	void *p=to;
	int i= len >> 6;	/* len/64 */

	if (!(current->flags & PF_USEDFPU))
		clts();
	else
	{
		__asm__ __volatile__ ( " fnsave %0; fwait\n"::"m"(current->thread.i387));
		current->flags &= ~PF_USEDFPU;
	}

The 3dnow is hardcoding the usage of old fnsave, whereas it should be using the
i387 operations in first place as all other parts of the kernel.

Then athlon will be able use both the faster fxsr and the 3dnow code
at the same time (whereas in 2.4.0 it wasn't wrongly using fxsr).

I also noticed this minor leftover:

--- ./arch/i386/kernel/i386_ksyms.c.~1~	Thu Dec 14 22:33:59 2000
+++ ./arch/i386/kernel/i386_ksyms.c	Thu Jan 11 17:15:21 2001
@@ -116,6 +116,7 @@
 EXPORT_SYMBOL(mmx_clear_page);
 EXPORT_SYMBOL(mmx_copy_page);
 #endif
+EXPORT_SYMBOL(mmu_cr4_features);
 
 #ifdef CONFIG_SMP
 EXPORT_SYMBOL(cpu_data);


Until I fix the 3dnow code to use the i387.c library please workaround
this way:

--- ./arch/i386/config.in.~1~	Thu Jan 11 17:52:05 2001
+++ ./arch/i386/config.in	Thu Jan 11 18:38:29 2001
@@ -109,7 +109,7 @@
    define_int  CONFIG_X86_L1_CACHE_SHIFT 6
    define_bool CONFIG_X86_TSC y
    define_bool CONFIG_X86_GOOD_APIC y
-   define_bool CONFIG_X86_USE_3DNOW y
+#   define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
 fi


FXSR on athlon works like a charm in the aa 2.2.x patchkit because in 2.2.x
there are no special string operations that uses 3dnow.

Sorry for having missed that.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 06:46:45PM +0100, Andrea Arcangeli wrote:
> Until I fix the 3dnow code to use the i387.c library please workaround
> this way:
> 
> --- ./arch/i386/config.in.~1~	Thu Jan 11 17:52:05 2001
> +++ ./arch/i386/config.in	Thu Jan 11 18:38:29 2001
> @@ -109,7 +109,7 @@
>     define_int  CONFIG_X86_L1_CACHE_SHIFT 6
>     define_bool CONFIG_X86_TSC y
>     define_bool CONFIG_X86_GOOD_APIC y
> -   define_bool CONFIG_X86_USE_3DNOW y
> +#   define_bool CONFIG_X86_USE_3DNOW y
>     define_bool CONFIG_X86_PGE y
>     define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
>  fi

Ah no, I even better, just pass `nofxsr` to the 2.4.1-pre2 kernel. (no
need to recompile)

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 06:48:21PM +0100, Andrea Arcangeli wrote:
> Ah no, I even better, just pass `nofxsr` to the 2.4.1-pre2 kernel. (no
> need to recompile)

Ok here the right fix against 2.4.1-pre2 so now you can use 3dnow and fxsr
at the same time (and nofxsr can still dynamically disable fxsr and xmm):

diff -urN -X /home/andrea/bin/dontdiff 2.4.1-pre2/arch/i386/kernel/i386_ksyms.c 2.4.1-pre2-fxsr/arch/i386/kernel/i386_ksyms.c
--- 2.4.1-pre2/arch/i386/kernel/i386_ksyms.c	Thu Dec 14 22:33:59 2000
+++ 2.4.1-pre2-fxsr/arch/i386/kernel/i386_ksyms.c	Thu Jan 11 18:07:53 2001
@@ -116,6 +116,7 @@
 EXPORT_SYMBOL(mmx_clear_page);
 EXPORT_SYMBOL(mmx_copy_page);
 #endif
+EXPORT_SYMBOL(mmu_cr4_features);
 
 #ifdef CONFIG_SMP
 EXPORT_SYMBOL(cpu_data);
diff -urN -X /home/andrea/bin/dontdiff 2.4.1-pre2/arch/i386/kernel/i387.c 2.4.1-pre2-fxsr/arch/i386/kernel/i387.c
--- 2.4.1-pre2/arch/i386/kernel/i387.c	Thu Jan 11 17:52:05 2001
+++ 2.4.1-pre2-fxsr/arch/i386/kernel/i387.c	Thu Jan 11 18:55:52 2001
@@ -43,7 +43,7 @@
  * FPU lazy state save handling.
  */
 
-void save_init_fpu( struct task_struct *tsk )
+inline void __save_init_fpu( struct task_struct *tsk )
 {
 	if ( HAVE_FXSR ) {
 		asm volatile( "fxsave %0 ; fnclex"
@@ -53,6 +53,11 @@
 			      : "=m" (tsk->thread.i387.fsave) );
 	}
 	tsk->flags &= ~PF_USEDFPU;
+}
+
+void save_init_fpu( struct task_struct *tsk )
+{
+	__save_init_fpu(tsk);
 	stts();
 }
 
diff -urN -X /home/andrea/bin/dontdiff 2.4.1-pre2/arch/i386/lib/mmx.c 2.4.1-pre2-fxsr/arch/i386/lib/mmx.c
--- 2.4.1-pre2/arch/i386/lib/mmx.c	Tue Nov 28 18:39:59 2000
+++ 2.4.1-pre2-fxsr/arch/i386/lib/mmx.c	Thu Jan 11 19:23:53 2001
@@ -29,10 +29,7 @@
 	if (!(current->flags & PF_USEDFPU))
 		clts();
 	else
-	{
-		__asm__ __volatile__ ( " fnsave %0; fwait\n"::"m"(current->thread.i387));
-		current->flags &= ~PF_USEDFPU;
-	}
+		__save_init_fpu(current);
 
 	__asm__ __volatile__ (
 		"1: prefetch (%0)\n"		/* This set is 28 bytes */
@@ -98,10 +95,7 @@
 	if (!(current->flags & PF_USEDFPU))
 		clts();
 	else
-	{
-		__asm__ __volatile__ ( " fnsave %0; fwait\n"::"m"(current->thread.i387));
-		current->flags &= ~PF_USEDFPU;
-	}
+		__save_init_fpu(current);
 	
 	__asm__ __volatile__ (
 		"  pxor %%mm0, %%mm0\n" : :
@@ -136,10 +130,7 @@
 	if (!(current->flags & PF_USEDFPU))
 		clts();
 	else
-	{
-		__asm__ __volatile__ ( " fnsave %0; fwait\n"::"m"(current->thread.i387));
-		current->flags &= ~PF_USEDFPU;
-	}
+		__save_init_fpu(current);
 
 	/* maybe the prefetch stuff can go before the expensive fnsave...
 	 * but that is for later. -AV
diff -urN -X /home/andrea/bin/dontdiff 2.4.1-pre2/include/asm-i386/i387.h 2.4.1-pre2-fxsr/include/asm-i386/i387.h
--- 2.4.1-pre2/include/asm-i386/i387.h	Thu Jan 11 17:59:31 2001
+++ 2.4.1-pre2-fxsr/include/asm-i386/i387.h	Thu Jan 11 18:56:32 2001
@@ -20,6 +20,7 @@
 /*
  * FPU lazy state save handling...
  */
+extern void __save_init_fpu( struct task_struct *tsk );
 extern void save_init_fpu( struct task_struct *tsk );
 extern void restore_fpu( struct task_struct *tsk );
 

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

Could people with Athlons please verify that pre3 works for them?

It's basically Andrea's patch, but I moved the FPU save/restore games away
from arch/i386/lib/mmx.c, so that everything is properly done in one place
and others call the appropriate helper functions instead of thinking that
they know how the lazy FP switching is done.

It also makes the fxsr disable act the same way the TSC disable does.

(And yes, I forgot to update the Makefile release number - sue me, I'm
too lazy to upload a new patch with that fixed ;).

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 06:08:21PM -0800, Linus Torvalds wrote:
> 
> Could people with Athlons please verify that pre3 works for them?

It works fine.

> It also makes the fxsr disable act the same way the TSC disable does.

Note that there was a precise reason for not implementing it as the TSC disable
(infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
The reason is that the way TSC gets disabled breaks /proc/cpuinfo.  Furthmore
in english sense if "the cpu has fxsr or xmm" doesn't mean we can use them at
runtime in the kernel. Such wrong assumption was the source of the 2.4.0 md bug
in first place ;). So I'm not excited we're back in the old way. But of course
those are minor issues and I'm not that concerned /proc/cpuinfo changes even if
the CPU remains the same because nobody should need nofxsr and notsc anyways...

This is a leftover btw:

--- 2.4.1pre3/include/asm-i386/xor.h.~1~	Fri Jan 12 04:14:36 2001
+++ 2.4.1pre3/include/asm-i386/xor.h	Fri Jan 12 04:23:32 2001
@@ -843,7 +843,7 @@
 	do {						\
 		xor_speed(&xor_block_8regs);		\
 		xor_speed(&xor_block_32regs);		\
-	        if (HAVE_XMM)				\
+	        if (cpu_has_xmm)				\
 			xor_speed(&xor_block_pIII_sse);	\
 	        if (md_cpu_has_mmx()) {			\
 	                xor_speed(&xor_block_pII_mmx);	\
@@ -855,4 +855,4 @@
    We may also be able to load into the L1 only depending on how the cpu
    deals with a load to a line that is being prefetched.  */
 #define XOR_SELECT_TEMPLATE(FASTEST) \
-	(HAVE_XMM ? &xor_block_pIII_sse : FASTEST)
+	(cpu_has_xmm ? &xor_block_pIII_sse : FASTEST)



Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> 
> Note that there was a precise reason for not implementing it as the TSC disable
> (infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
> The reason is that the way TSC gets disabled breaks /proc/cpuinfo.

No.

It FIXES /proc/cpuinfo.

Your alternative patch is the thing that breaks.

We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
FSXR/XMM to not exist. That is true information, and is in fact something
that install scripts etc can find extremely useful.

In particular, imagine an installation script that wants to install the
proper optimized version of a library on a machine. How is it supposed to
know whether it should use the mmx version, the xmm version, or the
integer version?

This is _exactly_ the kind of thing that /proc/cpuinfo was supposed to be
able to deal with, and that means that if the kernel doesn't like to use
xmm for some reason (ie the user explicitly told it to), then it shouldn't
show up in /proc/cpuinfo - because on that machine XMM simply does not
exist as far as user-land is concerned.

Similarly, when we disable TSC, it's also telling user-land that this
machine does not appear to have a working TSC for some reason. User-land
applications may also care about the fact that TSC seems to skip time if
the machine is idle etc (which was apparently the problem with some broken
Cyrix chips).

After all, a user can always do a "cpuid" to get to know what the CPU
itself reports. /proc/cpuinfo is supposed to be a higher-level interface,
where the buggy bits have been removed or renamed (ie AMD extensions are
properly renamed and can be easily recognized as such, without each
user-mode application having to know about the magic meaning of bits in
"cpuid" on different machines).

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Thu, Jan 11, 2001 at 08:26:04PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> > 
> > Note that there was a precise reason for not implementing it as the TSC disable
> > (infact at first in 2.2.x I was clearing the bigflag in x86_capabilities too).
> > The reason is that the way TSC gets disabled breaks /proc/cpuinfo.
> 
> No.
> 
> It FIXES /proc/cpuinfo.
> 
> Your alternative patch is the thing that breaks.

In 2.2.*, 2.4.0, 2.4.1-pre[12] and 2.4.0ac* `fxsr' and `xmm' in /proc/cpuinfo
means "cpu_has", you changed their meaning in 2.4.1-pre3 to "can_I_use". So now
unless you check the `uname -r` first you don't know anymore what fxsr and xmm
means (if either "cpu_has" or "can_I_use").

This means 2.4.1-pre3 broke /proc/cpuinfo IMHO (while pre2 plus my patch
didn't break anything).

> We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
> FSXR/XMM to not exist. That is true information, and is in fact something
> that install scripts etc can find extremely useful.

The "cpu_has" is true information as well (certainly it's less interesting than
the "can_I_use" but that that's not a good reason for dropping the "cpu_has"
information while breaking the semantics of fxsr/xmm in /proc/cpuinfo).

> In particular, imagine an installation script that wants to install the
> proper optimized version of a library on a machine. How is it supposed to
> know whether it should use the mmx version, the xmm version, or the
> integer version?

Any userspace software that will use `fxsr' and `xmm' information in
/proc/cpuinfo as "can_I_use" will work correctly _only_ in 2.4.1-pre3 and later
kernels (unless it does checks on the kernel revision it's running on first)
and it will break in all 2.2.x, 2.4.0 and 2.4.1-pre[12] (if it's not
checking the kernel revision). This is also a proof of what I said above.

Nobody should ever consider fxsr and xmm as "can_I_use" for backwards
compatibilty reasons with 2.4.0 and 2.2.*.

> This is _exactly_ the kind of thing that /proc/cpuinfo was supposed to be
> able to deal with, and that means that if the kernel doesn't like to use

/proc/cpuinfo shows per-cpu infos, it's always been the "cpu_has" _per-cpu_
info (not the _global_ "can_I_use").

It doesn't make much sense to me to put the "can_I_use" global information in
the per-cpu slots, that's obviously the wrong place for it. We simply need to
add a new entry to /proc (say "/proc/osinfo") to provide the "can_I_use"
informations instead (TSC included).  Breaking /proc/cpuinfo isn't the way to
go IMHO.

> xmm for some reason (ie the user explicitly told it to), then it shouldn't
> show up in /proc/cpuinfo - because on that machine XMM simply does not
> exist as far as user-land is concerned.

So then why does bogomips and and f00f_bug and similar things show up in
/proc/cpuinfo if they aren't useful to user-land either?

/proc/cpuinfo is providing info that isn't just useful for user-land software
agreed, but it's useful for the user to see the details of his hw. That's
always been the case. In 2.2.x and 2.4.0 the user wasn't allowed to use xmm but
he _wanted_ to see "xmm" in the flags field to know the details of his
hardware. That's not an information for userland software but just for the
user.

> Similarly, when we disable TSC, it's also telling user-land that this
> machine does not appear to have a working TSC for some reason. User-land

And IMHO that's wrong too.

> After all, a user can always do a "cpuid" to get to know what the CPU
> itself reports. /proc/cpuinfo is supposed to be a higher-level interface,
> where the buggy bits have been removed or renamed (ie AMD extensions are
> properly renamed and can be easily recognized as such, without each
> user-mode application having to know about the magic meaning of bits in
> "cpuid" on different machines).

cpuid says the "cpu_has" not the "can_I_use" too.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Richard A Nelson]

On Fri, 12 Jan 2001, Andrea Arcangeli wrote:

> It doesn't make much sense to me to put the "can_I_use" global information in
> the per-cpu slots, that's obviously the wrong place for it. We simply need to
> add a new entry to /proc (say "/proc/osinfo") to provide the "can_I_use"
> informations instead (TSC included).  Breaking /proc/cpuinfo isn't the way to
> go IMHO.

Sorry, but you're not taking the long view here,  "can_I_use" most
definetly should be per-cpu...

Its fine either way on current x86 and many other platforms, but falls
on its face in the presence of asymetric MP.
-- 
Rick Nelson
Netscape is not a newsreader, and probably never shall be.
	-- Tom Christiansen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> 
> > It doesn't make much sense to me to put the "can_I_use" global information in
> > the per-cpu slots, that's obviously the wrong place for it. We simply need to
> > add a new entry to /proc (say "/proc/osinfo") to provide the "can_I_use"
> > informations instead (TSC included).  Breaking /proc/cpuinfo isn't the way to
> > go IMHO.
> 
> Sorry, but you're not taking the long view here,  "can_I_use" most
> definetly should be per-cpu...
> 
> Its fine either way on current x86 and many other platforms, but falls
> on its face in the presence of asymetric MP.

Point taken, feel free to have a can_I_use per-cpu instead of global but don't
overwrite the cpu_has with it. 

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

On Fri, 12 Jan 2001, Andrea Arcangeli wrote:

> On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> > 
> > Its fine either way on current x86 and many other platforms, but falls
> > on its face in the presence of asymetric MP.
> 
> Point taken, feel free to have a can_I_use per-cpu instead of global but don't
> overwrite the cpu_has with it. 

Andrea, the whole POINT of "cpu_has_xxx" is for the kernel to test for
features like this.

If you're not going to overwrite it when some feature is deemed disabled,
you're missing the whole _reason_ for having capabilities bitmaps in the
first place.

This is not negotiable. We used to have a damn mess in 2.2.x with all the
capabilities stuff, and 2.4.x finally cleans it up and gets it right
across different CPU's, exactly because we have a clean "this CPU can do
X" approach without any if's, but's and why's. 

The fact that 2.2.x has bad control over capabilities and is messy is NOT
an excuse to screw up forever. 

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Alan Cox]

> The fact that 2.2.x has bad control over capabilities and is messy is NOT
> an excuse to screw up forever. 

2.2 has a mix of 'can I use' and 'does the cpu have' so using 2.2 as an 
example doesnt work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Linus Torvalds]

In article <E14H8PC-0004hZ-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> The fact that 2.2.x has bad control over capabilities and is messy is NOT
>> an excuse to screw up forever. 
>
>2.2 has a mix of 'can I use' and 'does the cpu have' so using 2.2 as an 
>example doesnt work

The above was exactly what I meant by being messy and not having a good
control over capabilities, so I think it's a perfect example. 

The fact is, we've historically NOT had a good way of indicating which
features the kernel can try to take advantage of.  This is something
that 2.4.0 tries to fix - to have everything in one central place with
no way to get mixed up about whether the CPU has some feature or not. 
And then export that single source knowledge through /proc/cpuinfo. 

I happen to believe that it's a big advantage to have just a single
source of capability data, AND to have that capability data be available
to user mode - with no way for the user to be confused ("But
/proc/cpuinfo _said_ that the kernel had FXSR, why can't I use it?"). 

Andreas argument was that earlier kernels weren't consistent, and as
such we shouldn't even bother to try to make newer kernels consistent. 
We would be better off reporting our internal inconsistencies the way
earlier kernels did - the kernel would be confusing, but at least it
would be consistently confusing ;)

I don't buy that argument. I don't care that we got details like this
wrong before.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Fri, Jan 12, 2001 at 10:35:24AM -0800, Linus Torvalds wrote:
> Andreas argument was that earlier kernels weren't consistent, and as
> such we shouldn't even bother to try to make newer kernels consistent. 
> We would be better off reporting our internal inconsistencies the way
> earlier kernels did - the kernel would be confusing, but at least it
> would be consistently confusing ;)

The earlier kernels were 98% consistent in providing the "cpu_has" information
via /proc/cpuinfo that is true information too.

What I am suggesting is to fix the few places to make the /proc/cpuinfo 100%
consistent reporting "cpu_has", and to provide the "can_I_use" information in
another place (for example with /proc/osinfo or a new "osflags" row in
/proc/cpuinfo).

This way we are 100% consistent and we don't lose the "cpu_has" information.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Laramie Leavitt]

> On Fri, Jan 12, 2001 at 10:35:24AM -0800, Linus Torvalds wrote:
> > Andreas argument was that earlier kernels weren't consistent, and as
> > such we shouldn't even bother to try to make newer kernels consistent. 
> > We would be better off reporting our internal inconsistencies the way
> > earlier kernels did - the kernel would be confusing, but at least it
> > would be consistently confusing ;)
> 
> The earlier kernels were 98% consistent in providing the 
> "cpu_has" information
> via /proc/cpuinfo that is true information too.
> 
> What I am suggesting is to fix the few places to make the 
> /proc/cpuinfo 100%
> consistent reporting "cpu_has", and to provide the "can_I_use" 
> information in
> another place (for example with /proc/osinfo or a new "osflags" row in
> /proc/cpuinfo).
> 
> This way we are 100% consistent and we don't lose the "cpu_has" 
> information.
> 

Yes, but why?  If the features cannot be used by userspace, then 
2.2 should be fixed to use the current model.  If someone wants
the information about the cpu that is not provided by the 'cpu_allows'
(My view of 'can_I_use' ) can't they just do a 'cpuid' and get
it for themselves anyway?

Laramie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Mark Hahn]

> This way we are 100% consistent and we don't lose the "cpu_has" information.

but /dev/cpu/*/{msr|cpuid} are "cpu has".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli]

On Fri, Jan 12, 2001 at 09:35:14AM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 12 Jan 2001, Andrea Arcangeli wrote:
> 
> > On Fri, Jan 12, 2001 at 11:42:32AM -0500, Richard A Nelson wrote:
> > > 
> > > Its fine either way on current x86 and many other platforms, but falls
> > > on its face in the presence of asymetric MP.
> > 
> > Point taken, feel free to have a can_I_use per-cpu instead of global but don't
> > overwrite the cpu_has with it. 
> 
> Andrea, the whole POINT of "cpu_has_xxx" is for the kernel to test for
> features like this.

I'm only concerned about the semantics of fxsr and xmm in /proc/cpuinfo, _not_
about the kernel implementation and self contained #defines (that
I'd preferred if they really meant cpu_has and not can_I_use too, but
that's an our internal thing not visible from userspace).

fxsr and xmm in /proc/cpuinfo in 2.4.0, 2.4.1-pre[12], and 2.2.* means
"cpu_has" and _not_ "can_I_use".

So anybody using the fxsr and xmm in the "flags" row of /proc/cpuinfo as the
"can_I_use" will break in any kernel before 2.4.1-pre3.

Anybody reading fxsr and xmm as "cpu_has" will break in any kernel after
2.4.1-pre2.

This all I meant when I said that 2.4.1-pre3 broke /proc/cpuinfo.

I'd prefer if /proc/cpuinfo wasn't broken. That's all.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] i386/setup.c cpuinfo notsc

[Hugh Dickins]

On Thu, 11 Jan 2001, Linus Torvalds wrote
(under Subject: Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"):
> 
> We _want_ /proc/cpuinfo to reflect the fact that the kernel considers
> FSXR/XMM to not exist. That is true information, and is in fact something
> that install scripts etc can find extremely useful.
> 
> [snip]
>
> Similarly, when we disable TSC, it's also telling user-land that this
> machine does not appear to have a working TSC for some reason. User-land
> applications may also care about the fact that TSC seems to skip time if
> the machine is idle etc (which was apparently the problem with some broken
> Cyrix chips).

That's how "notsc" used to behave, but since 2.4.0-test11
"notsc" has left "tsc" in /proc/cpuinfo.  setup.c has a bogus
"#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".

HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
was of Andrea's persuasion, that we should not mask caps out
of (real CPU entries in) /proc/cpuinfo, so we made no change.

In discussion we found a more worrying error in the SMP case:
boot_cpu_data is supposed to be left with those x86_capabilities
common to all CPUs, but the code to do so was unaware that
boot_cpu_data is overwritten in booting each CPU.  Even if all
CPUs have the same features, I imagine the Linux-defined ones
(CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally
masked out of the final boot_cpu_data.

The patch below fixes both those issues, and also clears
"pse" from /proc/cpuinfo in the same way if "mem=nopentium".
Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted.

I think there are still anomalies in the Cyrix and Centaur TSC
handling - shouldn't dodgy_tsc() check Centaur too?  shouldn't
we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I
don't have those CPUs to test, I'm wary of disabling TSC since
finding RH7.0 installed on i686 needs rdtsc to run /sbin/init,
and even if they are wrong then "notsc" corrects the situation:
not 2.4.1 material.

Hugh

--- linux-2.4.1-pre3/arch/i386/kernel/setup.c	Fri Jan 12 15:20:33 2001
+++ linux/arch/i386/kernel/setup.c	Mon Jan 15 18:07:15 2001
@@ -148,6 +148,7 @@
 
 static int disable_x86_serial_nr __initdata = 1;
 static int disable_x86_fxsr __initdata = 0;
+static int disable_x86_pse __initdata = 0;
 
 /*
  * This is set up by the setup-routine at boot-time
@@ -550,6 +551,7 @@
 			if (!memcmp(from+4, "nopentium", 9)) {
 				from += 9+4;
 				clear_bit(X86_FEATURE_PSE, &boot_cpu_data.x86_capability);
+				disable_x86_pse = 1;
 			} else if (!memcmp(from+4, "exactmap", 8)) {
 				from += 8+4;
 				e820.nr_map = 0;
@@ -1884,6 +1886,9 @@
 	return have_cpuid_p();	/* Check to see if CPUID now enabled? */
 }
 
+static __u32 common_x86_capability[NCAPINTS] __initdata = {
+	0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff };
+
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
@@ -2007,8 +2012,12 @@
 	 * we do "generic changes."
 	 */
 
+	/* PSE disabled? */
+	if (disable_x86_pse)
+		clear_bit(X86_FEATURE_PSE, &c->x86_capability);
+
 	/* TSC disabled? */
-#ifdef CONFIG_TSC
+#ifndef CONFIG_X86_TSC
 	if ( tsc_disable )
 		clear_bit(X86_FEATURE_TSC, &c->x86_capability);
 #endif
@@ -2043,16 +2052,13 @@
 	       c->x86_capability[3]);
 
 	/*
-	 * On SMP, boot_cpu_data holds the common feature set between
-	 * all CPUs; so make sure that we indicate which features are
-	 * common between the CPUs.  The first time this routine gets
-	 * executed, c == &boot_cpu_data.
+	 * On SMP, boot_cpu_data is to hold the feature set common
+	 * between all CPUs.  But boot_cpu_data is rewritten by each CPU
+	 * as it boots, so overwrite that with common features each time.
 	 */
-	if ( c != &boot_cpu_data ) {
-		/* AND the already accumulated flags with these */
-		for ( i = 0 ; i < NCAPINTS ; i++ )
-			boot_cpu_data.x86_capability[i] &= c->x86_capability[i];
-	}
+	for ( i = 0 ; i < NCAPINTS ; i++ )
+		boot_cpu_data.x86_capability[i] =
+		common_x86_capability[i] &= c->x86_capability[i];
 
 	printk("CPU: Common caps: %08x %08x %08x %08x\n",
 	       boot_cpu_data.x86_capability[0],

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[H. Peter Anvin]

Hugh Dickins wrote:
> 
> That's how "notsc" used to behave, but since 2.4.0-test11
> "notsc" has left "tsc" in /proc/cpuinfo.  setup.c has a bogus
> "#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".
> 
> HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
> was of Andrea's persuasion, that we should not mask caps out
> of (real CPU entries in) /proc/cpuinfo, so we made no change.
> 
> In discussion we found a more worrying error in the SMP case:
> boot_cpu_data is supposed to be left with those x86_capabilities
> common to all CPUs, but the code to do so was unaware that
> boot_cpu_data is overwritten in booting each CPU.  Even if all
> CPUs have the same features, I imagine the Linux-defined ones
> (CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally
> masked out of the final boot_cpu_data.
> 
> The patch below fixes both those issues, and also clears
> "pse" from /proc/cpuinfo in the same way if "mem=nopentium".
> Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted.
> 
> I think there are still anomalies in the Cyrix and Centaur TSC
> handling - shouldn't dodgy_tsc() check Centaur too?  shouldn't
> we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I
> don't have those CPUs to test, I'm wary of disabling TSC since
> finding RH7.0 installed on i686 needs rdtsc to run /sbin/init,
> and even if they are wrong then "notsc" corrects the situation:
> not 2.4.1 material.
> 

I would personally prefer to export the global flags separately from the
per-CPU flags.  Not only is it more correct, it would help catch these
kinds of bugs!!!

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[Maciej W. Rozycki]

On Mon, 15 Jan 2001, H. Peter Anvin wrote:

> I would personally prefer to export the global flags separately from the
> per-CPU flags.  Not only is it more correct, it would help catch these
> kinds of bugs!!!

 That's what I am going to do.  Basically to recode cpu_has_* macros to
use global flags as that's the intuitive name and use a set of different
names for the SMP bootstrap code to access boot_cpu_data (possibly
boot_has_* or boot_cpu_has_*). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[H. Peter Anvin]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 15 Jan 2001, H. Peter Anvin wrote:
> 
> > I would personally prefer to export the global flags separately from the
> > per-CPU flags.  Not only is it more correct, it would help catch these
> > kinds of bugs!!!
> 
>  That's what I am going to do.  Basically to recode cpu_has_* macros to
> use global flags as that's the intuitive name and use a set of different
> names for the SMP bootstrap code to access boot_cpu_data (possibly
> boot_has_* or boot_cpu_has_*).
> 

Right, but I'd also like to see the global flags exported explicitly to
/proc/cpuinfo.

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[Maciej W. Rozycki]

On Mon, 15 Jan 2001, H. Peter Anvin wrote:

> Right, but I'd also like to see the global flags exported explicitly to
> /proc/cpuinfo.

 That's desirable, but how would we fit it into the existing layout? 
Would it be feasible to put it into /proc/cpuflags, instead?  Anyway, with
all necessary code and structures in place it will be a one-liner or so to
add, so I'll write the underlying code first.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[H. Peter Anvin]

Followup to:  <Pine.GSO.3.96.1010115224843.16619d-100000@delta.ds2.pg.gda.pl>
By author:    "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
In newsgroup: linux.dev.kernel
>
> On Mon, 15 Jan 2001, H. Peter Anvin wrote:
> 
> > Right, but I'd also like to see the global flags exported explicitly to
> > /proc/cpuinfo.
> 
>  That's desirable, but how would we fit it into the existing layout? 

I was thinking of having a global section at the top, without a
"Processor:" header.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i386/setup.c cpuinfo notsc

[Maciej W. Rozycki]

On Mon, 15 Jan 2001, Hugh Dickins wrote:

> That's how "notsc" used to behave, but since 2.4.0-test11
> "notsc" has left "tsc" in /proc/cpuinfo.  setup.c has a bogus
> "#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".

 Confirmed.

> HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
> was of Andrea's persuasion, that we should not mask caps out
> of (real CPU entries in) /proc/cpuinfo, so we made no change.

 The conclusion was to add something like common_cpu_data, which would be
independent from boot_cpu_data.

> In discussion we found a more worrying error in the SMP case:
> boot_cpu_data is supposed to be left with those x86_capabilities
> common to all CPUs, but the code to do so was unaware that
> boot_cpu_data is overwritten in booting each CPU.  Even if all
> CPUs have the same features, I imagine the Linux-defined ones
> (CXMMX, K6_MTRR, CYRIX_ARR, CENTAUR_MCR) were unintentionally
> masked out of the final boot_cpu_data.

 It's not supposed.  Another struct should be added.  Boot_cpu_data is
expected to be used during an early SMP boot only.  That's the original
semantics and it should be preserved, I think.  The SMP code relies on it.

> The patch below fixes both those issues, and also clears
> "pse" from /proc/cpuinfo in the same way if "mem=nopentium".
> Tempted to rename "tsc_disable" to "disable_x86_tsc", but resisted.

 Good spotting.

> I think there are still anomalies in the Cyrix and Centaur TSC
> handling - shouldn't dodgy_tsc() check Centaur too?  shouldn't
> we set X86_CR4_TSD wherever we clear X86_FEATURE_TSC? - but I
> don't have those CPUs to test, I'm wary of disabling TSC since
> finding RH7.0 installed on i686 needs rdtsc to run /sbin/init,
> and even if they are wrong then "notsc" corrects the situation:
> not 2.4.1 material.

 Yep, that needs glibc or whatever introduces rdtsc to be fixed.

 Thanks for the patch -- I'll see how to fit it within my point of view.
I'm somewhat time-constrained these days, but I might be able to spend an
hour or so on coding and testing this issue tonight.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] udf writepage UnlockPage

[Hugh Dickins]

Although fs/udf's args to writepage() were updated in 2.4.0-test12,
its page unlocking was overlooked.  udf_adinicb_writepage() should
now UnlockPage, udf_expand_file_adinicb() should not now UnlockPage
after udf_writepage i.e. block_write_full_page.  Al Viro posted a
patch for the latter, still lurking in Alan's -ac9; the former seems
to have gone unnoticed.  Warning: from source inspection: untested.

Hugh

--- linux-2.4.1-pre8/fs/udf/file.c	Fri Dec 29 22:07:57 2000
+++ linux/fs/udf/file.c	Thu Jan 18 15:42:11 2001
@@ -86,6 +86,7 @@
 	brelse(bh);
 	SetPageUptodate(page);
 	kunmap(page);
+	UnlockPage(page);
 	return 0;
 }
 
--- linux-2.4.1-pre8/fs/udf/inode.c	Tue Dec  5 17:41:51 2000
+++ linux/fs/udf/inode.c	Thu Jan 18 15:43:50 2001
@@ -203,7 +203,6 @@
 	udf_release_data(bh);
 
 	inode->i_data.a_ops->writepage(page);
-	UnlockPage(page);
 	page_cache_release(page);
 
 	mark_inode_dirty(inode);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] udf writepage UnlockPage

[Hugh Dickins]

Although fs/udf's args to writepage() were updated in 2.4.0-test12,
its page unlocking was overlooked.  udf_adinicb_writepage() should
now UnlockPage, udf_expand_file_adinicb() should not now UnlockPage
after udf_writepage i.e. block_write_full_page.  Al Viro posted a
patch for the latter, still lurking in Alan's -ac12; the former seems
to have gone unnoticed.  Warning: from source inspection: untested.

(Originally sent ten days ago against 2.4.1-pre8, no comments
received: today seems topical to resend against 2.4.1-pre10.)

Hugh

--- linux-2.4.1-pre10/fs/udf/file.c	Fri Dec 29 22:07:57 2000
+++ linux/fs/udf/file.c	Thu Jan 18 15:42:11 2001
@@ -86,6 +86,7 @@
 	brelse(bh);
 	SetPageUptodate(page);
 	kunmap(page);
+	UnlockPage(page);
 	return 0;
 }
 
--- linux-2.4.1-pre10/fs/udf/inode.c	Tue Dec  5 17:41:51 2000
+++ linux/fs/udf/inode.c	Thu Jan 18 15:43:50 2001
@@ -203,7 +203,6 @@
 	udf_release_data(bh);
 
 	inode->i_data.a_ops->writepage(page);
-	UnlockPage(page);
 	page_cache_release(page);
 
 	mark_inode_dirty(inode);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[TimO]

Linus Torvalds wrote:
> 
> Could people with Athlons please verify that pre3 works for them?
> 
> 
>                 Linus

Running now....uptime 6 minutes.

===============
-- Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Udo A. Steinberg]

Linus Torvalds wrote:
> 
> Could people with Athlons please verify that pre3 works for them?

It works very well wrt. fxsr.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Harold Oga]

On Thu, Jan 11, 2001 at 06:08:21PM -0800, Linus Torvalds wrote:
>
>Could people with Athlons please verify that pre3 works for them?
>
>It's basically Andrea's patch, but I moved the FPU save/restore games away
>from arch/i386/lib/mmx.c, so that everything is properly done in one place
>and others call the appropriate helper functions instead of thinking that
>they know how the lazy FP switching is done.
Hi Linus,
   Ok, 2.4.1-pre3 seems to work fine for me on my Thunderbird 900MHz system.
At least, XFree86 4.0.1 starts properly, and the output of ps aux looks
correct again, which wasn't the case with 2.4.1-pre1 (I never tried
2.4.1-pre2).

-Harold
-- 
"Life sucks, deal with it!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Floating point broken between 2.4.0-ac4 and -ac5?

[junio]

>>>>> "AC" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> A Duron box running 2.4.0-ac5 (and -ac6) shows NaN in many
>> places (such as df output showing usage "nan%").  Right now I
>> reverted back to 2.4.0-ac4 which does not show the problem.
>> The kernel was compiled with CONFIG_MK7 and without
>> MATH_EMULATION, if that makes any difference.

AC> If you boot with the nofxsr option does that fix the problem ?

Yes, it seems to fix it.  I guess this is the same problem as
Udo A Steinberg has reported earlier in ``XFree 4.0.2 and "w"''
thread Message-ID: <3A5C6417.6670FCB7@Hell.WH8.TU-Dresden.De>.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Floating point broken between 2.4.0-ac4 and -ac5?

[Aaron Lehmann]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Wed, Jan 10, 2001 at 08:58:00PM -0800, junio@siamese.dhis.twinsun.com wrote:
> A Duron box running 2.4.0-ac5 (and -ac6) shows NaN in many
> places (such as df output showing usage "nan%").  Right now I
> reverted back to 2.4.0-ac4 which does not show the problem.
> The kernel was compiled with CONFIG_MK7 and without
> MATH_EMULATION, if that makes any difference.

I just had exactly the same problem with ac6 and an Athlon. Many
floating point numbers were replaced with nan. XFree86 broke.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]