Followup to previous post: Atlon/VIA Instabilities
Hi, So it seems that CONFIG_X86_USE_3DNOW is simply used to enable access to the routines in mmx.c (the athlon-optimized routines on CONFIG_K7 kernels), so then it appears that somehow this is corrupting memory / not behaving as it should (very technical, right?) :)... --Seth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> So it seems that CONFIG_X86_USE_3DNOW is simply used to > enable access to the routines in mmx.c (the athlon-optimized > routines on CONFIG_K7 kernels), so then it appears that somehow > this is corrupting memory / not behaving as it should (very > technical, right?) :)... Feel free to go over those routines in detail by hand. I've been over them and I can't see any problems. The obvious candidates would be races in the kernel_fpu_begin/end code but that also seems watertight to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> So it seems that CONFIG_X86_USE_3DNOW is simply used to
> enable access to the routines in mmx.c (the athlon-optimized
> routines on CONFIG_K7 kernels), so then it appears that somehow
> this is corrupting memory / not behaving as it should (very
> technical, right?) :)...
Do you use any unusual (binary only/with source) kernel modules?
mmx.c stores the current contents on the fpu registers into
current->thread.i387.f{,x}save.
If another module modifes the fpu registers and calls memmove it will
cause fpu corruptions.
I checked that a few months ago, and no module in the main kernel tree
does that.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
Manfred Spraul wrote:
>
> > So it seems that CONFIG_X86_USE_3DNOW is simply used to
> > enable access to the routines in mmx.c (the athlon-optimized
> > routines on CONFIG_K7 kernels), so then it appears that somehow
> > this is corrupting memory / not behaving as it should (very
> > technical, right?) :)...
>
> Do you use any unusual (binary only/with source) kernel modules?
>
> mmx.c stores the current contents on the fpu registers into
> current->thread.i387.f{,x}save.
> If another module modifes the fpu registers and calls memmove it will
> cause fpu corruptions.
>
> I checked that a few months ago, and no module in the main kernel tree
> does that.
No, actually the instability starts right after/when the root
filesystem is mounted (it seems). I have no foreign modules installed
when this error occurs. Even if I did, why would the Abit KA7 with the
same [other] hardware and software NOT show this problem, even with all
opts enabled?
--Seth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> No, actually the instability starts right after/when the root > filesystem is mounted (it seems). I have no foreign modules installed > when this error occurs. Even if I did, why would the Abit KA7 with the > same [other] hardware and software NOT show this problem, even with all > opts enabled? In my experience I've noticed motherboards can have a huge impact on stability despite the chipsets, hardware used, etc. Abit is well known and liked in the overclocking circles, consequently I would strongly suspect that their motherboards are generally highly stable when compared to most others. In fact, my experience with them seams to support this thesis. Its possible that the other motherboard you were using is just flaky. Does the other one happen to be a PC-Chips one? These generally can be quite cheap, feature rich, and even have the best chipsets but still have proved themselves to be quite flaky to me in the past. FIC seams to have a similar problem, although they actually improve on their boards stability over time (have some rock solid high volume servers on "stabilized" FIC boards); sometimes with just a conveniently available BIOS update. Shuttle also seams to have gone downhill but that might have just been a one time occurrence. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
Seth Goldberg wrote: > > Hi, > > So it seems that CONFIG_X86_USE_3DNOW is simply used to > enable access to the routines in mmx.c (the athlon-optimized > routines on CONFIG_K7 kernels), so then it appears that somehow > this is corrupting memory / not behaving as it should (very > technical, right?) :)... > > --Seth This is a shot in the dark. Do you have floating-point emulation on (CONFIG_MATH_EMULATION=y)? Tom -- The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
Hi Tom, Nope. No emulation here. Thanks for trying tho ;). --Seth Tom Leete wrote: > > Seth Goldberg wrote: > > > > Hi, > > > > So it seems that CONFIG_X86_USE_3DNOW is simply used to > > enable access to the routines in mmx.c (the athlon-optimized > > routines on CONFIG_K7 kernels), so then it appears that somehow > > this is corrupting memory / not behaving as it should (very > > technical, right?) :)... > > > > --Seth > > This is a shot in the dark. Do you have floating-point emulation on > (CONFIG_MATH_EMULATION=y)? > > Tom > > -- > The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
