From owner-freebsd-current Mon Feb 8 16:42:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03536 for freebsd-current-outgoing; Mon, 8 Feb 1999 16:42:36 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from picnic.mat.net (b133.mat.net [206.246.122.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03509 for ; Mon, 8 Feb 1999 16:42:31 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.2/8.8.5) with ESMTP id TAA34710; Mon, 8 Feb 1999 19:40:13 -0500 (EST) Date: Mon, 8 Feb 1999 19:40:12 -0500 (EST) From: Chuck Robey To: Mike Smith cc: tcobb@staff.circle.net, current@FreeBSD.ORG Subject: Re: Tracking a Fatal Double Fault In-Reply-To: <199902090016.QAA01652@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Feb 1999, Mike Smith wrote: > > The machine is running a custom kernel, but nothing > > very unusual. My instinct is that it may be related to > > something with the 3c905B 3COM cards that I reported > > earlier, I'm trying with Intel EtherExpresses right now > > and getting no fault problems. > > > > The double-fault does not occur consistently, unfortunately, > > and typically only occurs during my rc.local stuff (loading > > a bunch (100+) of chrooted daemons) on boot-up. > > > > Would the eip/esp/ebp values be worth sending? > > They're meaningless without your kernel, but even then all you're going > to be able to tell is where in the fault handler things died; you won't > know the address of the original fault. > > There's nothing immediately obvious in the xl driver that would suggest > that it uses excessive kernel stack either. 8( Maybe someone has some > clues on measuring stack usage (or simply on how to increase the kernel > stack allocation...). While you guys are on this subject, I'd like to sneak in a question on a subject that's close by. A while back, I had a kernel problem, and went about finding out how to use kgdb and kernel dumps. Unfortunately, by the time I was completely ready to do it, the problem (you guys remember the GPL_MATH_EMULATE thing?) went away. Just for grins, I'd like to force a kernel dump, so I can go the rest of the way in making sure my test setup works, and I can get more used to it. What's the safest way to force a kernel dump (hopefully without screwing filesystems)? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message