Date: Tue, 7 Dec 1999 09:12:01 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@netplex.com.au> Cc: Ed Hall <edhall@screech.weirdnoise.com>, Matthew Dillon <dillon@apollo.backplane.com>, "Jonathan M. Bresler" <jmb@hub.freebsd.org>, kris@hub.freebsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) Message-ID: <14413.5148.670641.885572@grasshopper.cs.duke.edu> In-Reply-To: <19991207120139.869F01CC6@overcee.netplex.com.au> References: <edhall@screech.weirdnoise.com> <199912062126.NAA30946@screech.weirdnoise.com> <19991207120139.869F01CC6@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14413.5148.670641.885572>