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

2001-01-12 Thread 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/

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

2001-01-12 Thread 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 > > earli

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

2001-01-12 Thread 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

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

2001-01-12 Thread Linus Torvalds
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 exact

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

2001-01-12 Thread 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

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

2001-01-12 Thread 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 me

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

2001-01-12 Thread 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-c

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

2001-01-12 Thread 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 entr

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

2001-01-12 Thread 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 r

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

2001-01-12 Thread 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

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

2001-01-11 Thread 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/

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

2001-01-11 Thread TimO
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 PROTECTE

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

2001-01-11 Thread 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 /

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

2001-01-11 Thread 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 d

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

2001-01-11 Thread 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 k

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

2001-01-11 Thread 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 fxs

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

2001-01-11 Thread 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 @@ > de

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

2001-01-11 Thread 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 cours

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

2001-01-11 Thread 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/

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

2001-01-11 Thread 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 o

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

2001-01-11 Thread 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

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

2001-01-11 Thread 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_ha

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

2001-01-11 Thread 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.

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

2001-01-11 Thread Linus Torvalds
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

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

2001-01-10 Thread Jonathan Hudson
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

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

2001-01-10 Thread 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 th

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

2001-01-10 Thread 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 model

2.4.1-pre1 breaks XFree 4.0.2 and "w"

2001-01-10 Thread 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