From owner-freebsd-current@FreeBSD.ORG Thu May 8 12:52:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 024A637B401 for ; Thu, 8 May 2003 12:52:26 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0274E43FAF for ; Thu, 8 May 2003 12:52:25 -0700 (PDT) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h48JqOqo014269; Thu, 8 May 2003 21:52:24 +0200 Received: (nullmailer pid 2267 invoked by uid 1000); Thu, 08 May 2003 19:52:23 -0000 Date: Thu, 8 May 2003 21:52:23 +0200 From: Mark Santcroos To: "Alan L. Cox" Message-ID: <20030508195223.GC676@laptop.6bone.nl> References: <20030506162410.M66653@daneel.foundation.hs> <20030506171632.GA767@laptop.6bone.nl> <20030508111807.GB1390@laptop.6bone.nl> <20030508155123.G78057@daneel.foundation.hs> <20030508142234.GA1359@laptop.6bone.nl> <3EBAB353.4E5F8440@imimic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBAB353.4E5F8440@imimic.com> User-Agent: Mutt/1.4.1i X-Handles: MS6-6BONE, MS18417-RIPE cc: freebsd-current@freebsd.org Subject: Re: data corruption with current (maybe sis chipset related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 19:52:26 -0000 On Thu, May 08, 2003 at 02:43:15PM -0500, Alan L. Cox wrote: > For the record, this is not completely correct. DISABLE_PSE does > control the use of 4MB pages. DISABLE_PG_G is, however, something > entirely different. Normally, on a process context switch TLB entries > for the old address space are flushed. If a TLB entry corresponds to an > in-kernel virtual-to-physical mapping, there is no reason to flush that > entry because all processes share the same kernel address space. > Setting the "G"lobal bit on a page table entry accomplishes this. In > other words, the TLB entry persists across context switches. > DISABLE_PG_G disables this. > > The problem with PG_G is that the "flush all" TLB entries operation, > just like a context switch, has no effect on entries marked as global. > Such entries have to be flushed by specifying their address in a "flush > single page" operation. Sometimes the failure to flush an entry is > covered up by a combination of DISABLE_PG_G and a lucky context switch. > > So, in summary, it does make sense to try these options separately. This is not my expertise, so take me with a grain of salt :) I think Terry also already mentioned this. PSE for the 4M pages and PG_G for the global pages. I also think that last time we concluded that they are both needed. He mentioned I guess that while using only one of them might "solve" the problem, but that would only be hiding the problem for a bit longer. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM