On Thu, Nov 8, 2012 at 10:29 AM, John Baldwin <[email protected]> wrote: > On 10/31/12 8:50 AM, Tommy Sonne Alstrøm wrote: >> The following reply was made to PR amd64/173235; it has been noted by GNATS. >> >> From: =?ISO-8859-1?Q?Tommy_Sonne_Alstr=F8m?= <[email protected]> >> To: Andriy Gapon <[email protected]> >> Cc: [email protected] >> Subject: Re: amd64/173235: Have received two crashes within 1 day after >> installing >> new packages: Fatal trap 12: page fault in kernel mode >> Date: Wed, 31 Oct 2012 13:44:01 +0100 >> >> I'm very sorry, I just realized that I copied the 1st readout twice. The >> 2nd readout was like this >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x6 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff809da0cc >> stack pointer = 0x28:0xffffff8451f549b0 >> frame pointer = 0x28:0xffffff8451f54a40 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 1068 (named) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff808680fe at kdb_backtrace+0x5e >> #1 0xffffffff80832cb7 at panic+0x187 >> #2 0xffffffff80b185a0 at trap_fatal+0x290 >> #3 0xffffffff80b188e9 at trap_pfault+0x1f9 >> #4 0xffffffff80b18daf at trap+0x3df >> #5 0xffffffff80b0324f at calltrap+0x8 >> #6 0xffffffff809f75a7 at udp6_bind+0xa7 >> #7 0xffffffff808a152e at kern_bind+0xde >> #8 0xffffffff808a15a1 at sys_bind+0x41 >> #9 0xffffffff80b17e90 at amd64_syscall+0x4e0 >> #10 0xffffffff80b03537 at Xfast_syscall+0xf7 >> Uptime: 9h41m13s >> Dumping 3411 out of 16088 >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Both of your panics involve faults where the bad pointer only has a > single bit set. They are also in very different places. I suspect > you are having a hardware failure (e.g. single-bit memory errors).
Which ones are you looking at? A fault va of 0x20 and 0x6 is what I'd normally suspect of being a null pointer + structure member offset dereference. Given: >> instruction pointer = 0x20:0xffffffff809da0cc I'd be curious to see the kgdb output of (kgdb) l *0xffffffff809da0cc (and same for the first crash if that kernel is still available) -- Peter Wemm - [email protected]; [email protected]; [email protected]; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "[email protected]"
