Re: Followup to previous post: Atlon/VIA Instabilities

Re: Followup to previous post: Atlon/VIA Instabilities

[Manfred Spraul]

> 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

Re: Followup to previous post: Atlon/VIA Instabilities

[Seth Goldberg]

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

Re: Followup to previous post: Atlon/VIA Instabilities

[Linux Kernel Developer]

>   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.

Re: Followup to previous post: Atlon/VIA Instabilities

[Seth Goldberg]

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

Re: Followup to previous post: Atlon/VIA Instabilities

[Tom Leete]

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

Re: Followup to previous post: Atlon/VIA Instabilities

[Alan Cox]

>   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.

Followup to previous post: Atlon/VIA Instabilities

[Seth Goldberg]

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