From owner-freebsd-hackers Thu May 3 8:49:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from temphost.dragondata.com (temphost.dragondata.com [63.167.131.128]) by hub.freebsd.org (Postfix) with ESMTP id A931137B422 for ; Thu, 3 May 2001 08:49:14 -0700 (PDT) (envelope-from toasty@temphost.dragondata.com) Received: (from toasty@localhost) by temphost.dragondata.com (8.9.3/8.9.3) id KAA74358; Thu, 3 May 2001 10:51:32 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200105031551.KAA74358@temphost.dragondata.com> Subject: Re: NMI during procfs mem reads (#2) To: imp@village.org (Warner Losh) Date: Thu, 3 May 2001 10:51:32 -0500 (CDT) Cc: hackers@FreeBSD.ORG, kevind@ikadega.com In-Reply-To: from "Warner Losh" at May 03, 2001 09:45:52 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > In message <200105022149.QAA00364@temphost.dragondata.com> Kevin Day writes: > : I tried sending this from my work account, but our new exchange server isn't > : exactly sending mail correctly... Excuse the duplicate post if you see it. > : :) > > It sounds like the PCI card that you are trying to read from is > generating the pci fault cycles to cause the bridge to generate an > nmi. Either that, or you have one of those handy nmi switches that > you used to break into the debugger. > > Warner > The PCI target itself isn't doing anything like that, but it's possible that the PCI-PCI bridge we're going through might be. In any case, getting the NMI isn't really all that bad, it's stopping the chipset from getting hung on a infinite retry. My only concern is the NMI handler while in the kernel may be too aggressive in causing a panic. -- Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message