Re: ULE status, invalid load, buildkernel times.

From: Peter Wemm <peter_at_wemm.org>
Date: Thu, 26 Jul 2007 17:50:19 -0700
On Sunday 22 July 2007, Milos Vyletel wrote:
> On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote:
[...]
> > No problem,
> >
> > I've extracted it and made a patch. If someone is intrested, it's
> > on
> >
> > http://rulez.sk/~mv/cpu.patch
>
> Well, i've just updated my kernel and it paniced right after
> identifying cpu.
>
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz
> K8-class CPU) Origin = "AuthenticAMD"  Id = 0x20f32  Stepping = 2
>  
> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,
>PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
> Features2=0x1<SSE3>
>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>   AMD Features2=0x3<LAHF,CMP>
>   Cores per package: 2
> usable memory = 3211776000 (3062 MB)
> avail memory  = 3105628160 (2961 MB)
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x310
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x8:0xffffffff8033953c
> stack pointer           = 0x10:0xffffffff80855c70
> frame pointer           = 0x10:0xffffffff80855c80
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 0 ()
>
> this is output from from dmesg.
>
> Thanks for suggestions.
> Milos

Unfortunately this isn't much help.  What would be useful would be to 
get a backtrace.  If you're not running GENERIC, a copy of your kernel 
config would be useful.  Any other patches?

To get a backtrace, add these to your kernel config:
options KDB
options DDB
#options KDB_TRACE
#options KDB_UNATTENDED

The last two options would help automate it for you, but beware.  
KDB_TRACE shows a trace during the panic.  The problem is that ddb is 
activated before the machine actually panics, so you'd be dropped into 
ddb before the trace got printed.  Give a 'trace' command at the 'db>' 
prompt.  KDB_UNATTENDED prevents it dropping into ddb, and simply 
prints the trace and gets on with the panic.  It might be a bit harder 
to get a record of what happened. 

-- 
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Received on Thu Jul 26 2007 - 22:50:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC