From owner-freebsd-hackers Tue Dec 7 6:12:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8064114EF0; Tue, 7 Dec 1999 06:12:45 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id JAA27117; Tue, 7 Dec 1999 09:12:32 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id JAA87970; Tue, 7 Dec 1999 09:12:02 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Dec 1999 09:12:01 -0500 (EST) To: Peter Wemm Cc: Ed Hall , Matthew Dillon , "Jonathan M. Bresler" , kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-Reply-To: <19991207120139.869F01CC6@overcee.netplex.com.au> References: <199912062126.NAA30946@screech.weirdnoise.com> <19991207120139.869F01CC6@overcee.netplex.com.au> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14413.5148.670641.885572@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > > In all cases the panics were extremely "strange". The original fxp+ncr > combination changed it's crash pattern when we put extra debugging in it to > sanity check and check conditions. The results varied from registers getting > clobbered (as though an interrupt happened and the trapframe on the stack got > changed by the interrupt handler and then returned with garbage contents in > some registers.. this is what seems to be happening in the fxp_add_rfabuf() > panics - %esi was getting loaded earlier on and when it got to do the > vtophys() it was zero. People have printed the contents of "rfa" on the stack > and seen garbage - in fact it's a register variable under normal circumstances. > Adding debugging caused it to be stored in the local variable rather than > being left in %esi, and then the panics moved elsewhere (!).) > > It had the markings of "something trashing something somewhere and then crashing > quite a bit later". :-( I had a very similar experience when debugging what I thought were problems with the fxp driver when FreeBSD/alpha was used as a router. After the problem moved to the xl driver when we changed out NICs, my focus moved elsewhere. It turns out that the real problem was that the alpha port had serious interrupt handling problems inherited from NetBSD. There was a large window where the ipl was lowered to zero which allowed another interrupt to come in while still running on the interrupt stack. The interrupt stack grew very large & eventually trashed some critical areas of memory. Any chance that something like this could be happening on the i386? Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message