> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> 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
> >
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
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> 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
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 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
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
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
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
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
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
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
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
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
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
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
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] 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
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
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
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED]
Please read the FAQ at
Linus Torvalds wrote:
>
> Could people with Athlons please verify that pre3 works for them?
>
>
> Linus
Running nowuptime 6 minutes.
===
-- Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
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
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
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
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
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 @@
>
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
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> #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
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
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
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.
In article <[EMAIL PROTECTED]>,
Udo A. Steinberg <[EMAIL PROTECTED]> 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
In article [EMAIL PROTECTED],
Udo A. Steinberg [EMAIL PROTECTED] 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
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.
-
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)
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
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
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).
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 @@
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
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
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
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
In article <[EMAIL PROTECTED]>,
"Udo A. Steinberg" <[EMAIL PROTECTED]> 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
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
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
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.
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
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.
In article [EMAIL PROTECTED],
"Udo A. Steinberg" [EMAIL PROTECTED] 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
52 matches
Mail list logo
