Date: Sun, 19 Jan 2003 20:16:37 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-current@freebsd.org Subject: Re: STABLE->CURRENT rl fails Message-ID: <20030120031637.B8ABC2EA@pinyon.org> In-Reply-To: Message from Robert Watson <rwatson@freebsd.org> of "Sun, 19 Jan 2003 20:37:09 EST." <Pine.NEB.3.96L.1030119202919.67385I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030120031637.B8ABC2EA>