Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 28 Mar 2003 09:50:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 28 Mar 2003 09:50:22 -0500 Received: from modemcable226.131-200-24.mtl.mc.videotron.ca ([24.200.131.226]:14591 "EHLO montezuma.mastecende.com") by vger.kernel.org with ESMTP id ; Fri, 28 Mar 2003 09:50:21 -0500 Date: Fri, 28 Mar 2003 09:57:56 -0500 (EST) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: Linux Kernel cc: Linus Torvalds Subject: Re: [PATCH][2.5] reproducible smp_call_function/_interrupt cache update race. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1130 Lines: 29 On Fri, 28 Mar 2003, Zwane Mwaikambo wrote: > Hi > I'm not quite sure how to describe this. I have a 3 Processor > Pentium 133 system which has been oopsing reliably (i have over 5 of > these oopses). What appears to be the problem is that the current memory > barrier in smp_call_function is a simple gcc anti optimisation barrier, we > really need a memory barrier there so that the other cpu's get the right > value when they get IPI'd immediately afterwards. The system was going > down reliably under my test load in under 5minutes, i have run with this > patch for; > > 02:11:24 up 45 min, 5 users, load average: 175.21, 174.89, 160.77 11:00:31 up 8:29, 5 users, load average: 2.06, 2.28, 2.33 And still going strong, it finally even completed the dbench 128 run (first time since 2.5.66 got released). Linus please apply. Zwane -- function.linuxpower.ca - 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/