Messages in this thread | | | Date | Mon, 2 Jun 2008 14:37:56 -0700 | From | Suresh Siddha <> | Subject | Re: CONFIG_PREEMPT causes corruption of application's FPU stack |
| |
On Sun, Jun 01, 2008 at 06:47:29PM +0200, Jürgen Mell wrote: > On Sonntag, 1. Juni 2008, Andi Kleen wrote: > > j.mell@t-online.de writes: > > > or it is restored more than > > > once. Please keep in mind, that I am always running two Einstein > > > processes simultaneously on my two cores! > > > I am willing to do further testing of this problem if someone can give > > > me a hint how to continue. > > > > My bet would have been actually on > > aa283f49276e7d840a40fb01eee6de97eaa7e012 because it does some nasty > > things (enable interrupts in the middle of __switch_to). > > > > I looked through the old patchkit and couldn't find any specific > > PREEMPT problems. All code it changes should run with preempt_off > > > > You could verify with sticking WARN_ON_ONCE(preemptible()) into > > all the places acc207616a91a413a50fdd8847a747c4a7324167 > > changes (__unlazy_fpu, math_state_restore) and see if that triggers > > anywhere. > > No, that did not trigger. I put the WARN_ON_ONCE into process.c, traps.c > and also into the __unlazy_fpu macro in i387.h but I got no messages > anywhere (dmesg, /var/log/messages, /var/log/warn) when the trap #8 > occurred. > Meanwhile I am also running the tests on another machine to make sure it is > not a hardware-related problem. > > Any new ideas are welcome! > > Meanwhile I will go back to 2.6.20 and revert > aa283f49276e7d840a40fb01eee6de97eaa7e012. Maybe I got on a wrong track...
2.6.20 doesn't have the commit 'aa283f49276e7d840a40fb01eee6de97eaa7e012'
As you are seeing this corruption problem starting from 2.6.20, atleast recent(in 2.6.26 series) fpu changes don't play a role in this.
I will try to reproduce your issue.
thanks, suresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |