Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757409AbXEJJtV (ORCPT ); Thu, 10 May 2007 05:49:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756421AbXEJJtO (ORCPT ); Thu, 10 May 2007 05:49:14 -0400 Received: from one.firstfloor.org ([213.235.205.2]:51073 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753643AbXEJJtO (ORCPT ); Thu, 10 May 2007 05:49:14 -0400 Date: Thu, 10 May 2007 11:49:08 +0200 From: Andi Kleen To: Zhao Forrest Cc: discuss@x86-64.org, linux-kernel@vger.kernel.org Subject: Re: [discuss] A question about GART aperture unmap Message-ID: <20070510094908.GB14898@one.firstfloor.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1016 Lines: 24 > After commenting out clear_kernel_mapping() line, the system would > have sync flood and reset from time to time. However when with this > clear_kernel_mapping() line, no system reset happened. Hmm, that should not happen. Normally the problems fixed by this are expected to be very rare and you also should not get sync flood, but just cache line corruption. While it might be possible for random corruption to then cause sync flood that should be again rather unlikely. If it's repeatable quickly something else must be wrong. > > As we know that CPU prefetch never cross the page boundary, in this That only applies to sequential prefetch. But speculative execution can prefetch pretty much any address. That is why the clear_kernel_mapping is needed. -Andi - 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/