Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Oct 2002 21:15:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Oct 2002 21:15:10 -0400 Received: from pizda.ninka.net ([216.101.162.242]:18403 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id ; Fri, 4 Oct 2002 21:15:08 -0400 Date: Fri, 04 Oct 2002 18:13:11 -0700 (PDT) Message-Id: <20021004.181311.31550114.davem@redhat.com> To: torvalds@transmeta.com Cc: viro@math.psu.edu, linux-kernel@vger.kernel.org Subject: Re: oops in bk pull (oct 03) From: "David S. Miller" In-Reply-To: References:

X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 977 Lines: 24 From: Linus Torvalds Date: Fri, 4 Oct 2002 18:02:15 -0700 (PDT) On Fri, 4 Oct 2002, Alexander Viro wrote: > Hell knows. The only explanation I see (and that's not worth much) is that > we somehow confuse the chipset and get crapped on something like next cache > miss. I don't see any better explanation right now, so I guess we just revert that thing. The people seeing this don't happen to be on Serverworks chipsets are they? I've seen a bug on serverworks where back to back PCI config space operations can cause some to be lost or corrupted. Another theory is that some device just dislikes being given a 0 in one of it's base registers, but somehow ~0 is ok :-) - 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/