From owner-freebsd-current Sun Jan 19 19:16:41 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D3437B401 for ; Sun, 19 Jan 2003 19:16:39 -0800 (PST) Received: from pinyon.org (quine.pinyon.org [65.101.5.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4440743EB2 for ; Sun, 19 Jan 2003 19:16:38 -0800 (PST) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id B8ABC2EA for ; Sun, 19 Jan 2003 20:16:37 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-current@freebsd.org Subject: Re: STABLE->CURRENT rl fails In-Reply-To: Message from Robert Watson of "Sun, 19 Jan 2003 20:37:09 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Jan 2003 20:16:37 -0700 From: "Russell L. Carter" Message-Id: <20030120031637.B8ABC2EA@pinyon.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks Robert, I'm looking into this now. Unfortunately, now the symptom is a hard wedge on "large" transfers over rl0, no response to anything obvious, other than hard reset. So I'm seeing what I can do to tickle it into something more informative. That previous dmesg quoted below I think was the result of leaving the system (in disgust) wedged overnight. Nope, any large transfers wedge the system tight, which ever side initiates. I waited for the background disk checks to complete and then rebooted clean in between tests. Very tedious. Constant pings with occasional ntpd and dns client traffic succeed fine overnight (last night) though. System configured per advice... I've run quite large transfers through this system on stable with no issues at all, since June '02. Best, Russell "large transfer" is $ cd /usr/ports/distfiles ; scp *.gz target:/usr/tmp : : On Fri, 17 Jan 2003, Russell L. Carter wrote: : : > rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514) : > rl0: discard oversize frame (ether type fbf7 flags 3 len 2992 > max 1514) : > rl0: discard oversize frame (ether type 2e3d flags 3 len 55442 > max 1514) : > rl0: discard oversize frame (ether type 904 flags 3 len 36106 > max 1514) : > : > Fatal trap 12: page fault while in kernel mode : > fault virtual address = 0x46 : > fault code = supervisor read, page not present : > instruction pointer = 0x8:0xc02f19c0 : > stack pointer = 0x10:0xd9344ca4 : > frame pointer = 0x10:0xd9344cbc : > code segment = base 0x0, limit 0xfffff, type 0x1b : > = DPL 0, pres 1, def32 1, gran 1 : > processor eflags = interrupt enabled, resume, IOPL = 0 : > current process = 832 (reboot) : > trap number = 12 : > panic: page fault : : I'm probably no good on the if_rl and ACPI issues, but I can give this one : a try. This panic is a NULL pointer dereference, apparently in the : shutdown. If this is reproduceable, here's what would be most helpful to : debug it: take a copy of the GENERIC kernel config, and make sure it : contains debugging symbols. I.e., the kernel configuration contains : "makeoptions DEBUG=-g". Configure kernel dumps using the dumpdev option : in /etc/rc.conf -- typically people use their swap device. You may : already have debugging symbols for your kernel if you're using GENERIC : from -current. When the crash occurs, a dump will be performed, and then : when you boot up next, it will be saved in /var/crash (assuming you have : room -- if it's smaller than your system memory, symlink to /usr/crash and : create an appropriate target directory). Finally, run: : : gdb /usr/obj/.../kernel.debug /var/crash/vmcore.0 : : (replace the first path with the path to your kernel target build : directory) : (replace the second path with the most recent kernel dump) : : Type in "backtrace" to generate a trace, and respond to this e-mail with : the trace. : : Another popular debugging option is to compile your kernel with "options : DDB" which will allow you access to the live kernel debugger, which can be : used to generate traces on a panic. However, that's most useful if you : have a serial console, and can copy/paste the results into an e-mail. : There should be a fair amount of information on kernel debugging in the : handbook if you need guidance on the details on how to do the above. : : Robert N M Watson FreeBSD Core Team, TrustedBSD Projects : robert@fledge.watson.org Network Associates Laboratories : : : : To Unsubscribe: send mail to majordomo@FreeBSD.org : with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message