Re: ULE status, invalid load, buildkernel times.

From: Attilio Rao <attilio_at_freebsd.org>
Date: Fri, 27 Jul 2007 15:47:53 +0200
2007/7/27, Attilio Rao <attilio_at_freebsd.org>:
> Peter Wemm wrote:
> > 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?
>
> The patch is not going to work as the slot for SI_ORDER_SECOND was
> alredy held by kern/subr_smp.c::mp_start() function.
>
> Could you please try this comprehensive patch?
> It has a fix for the mp_start / lapic_init confusion and some tricks
> with CNXT-ID bit which should exactly identify HTT:
> http://people.freebsd.org/~attilio/machdep_lapic.diff
>
> I have still to stress test it, so please use caution. I will update
> soon if I will have more information (a 'work for me' / 'don't work for
> me' would be very appreciated though).

For what can I see it works for me and for 2 users which alredy tested
it (which were experiencing problems recently).

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Fri Jul 27 2007 - 11:47:55 UTC

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