Re: Xeon X3430 = immediate panic

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Fri, 27 Nov 2009, Christoph Egger wrote:
> Stephen Borrill wrote:
> > This is on a brand new IBM X3250 M3 with QC Xeon X3430
> >
> > NetBSD 5.99.22 (X3250) #0: Fri Nov 27 15:04:26 GMT 2009
> >         root@laptop:/usr/obj/current/i386/sys/arch/i386/compile/X3250
> > total memory = 2037 MB
> > avail memory = 1991 MB
> > mainbus0 (root)
> > ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16
> > (0/tbfadt-707)
> > cpu0 at mainbus0 apid 0: Intel 686-class, 2394MHz, id 0x106e5
> > fatal protection fault in supervisor mode
> > trap type 4 code 0 eip c021e4f4 cs 8 eflags 10296 cr2 0 ilevel 8
> > kernel: supervisor trap protection fault, code=0
> > Stopped in pid 0.1 (system) at  netbsd:rdmsr+0x4:       rdmsr
> >
> > db{0}> bt
> > rdmsr(c093d5c0,106e5,c0b08af8,c0477e43,f37867f,85,31000000,4d203333,c0007a48,144a4b)
> > at netbsd:rdmsr+0x4
> > cpu_identify(c093d5c0,1,c0b08b38,c021dbe0,cc7ee21c,c0b08b24,c0b08b38,c0b08b98,cc7ee600,c093d5c0)
> > at netbsd:cpu_identify+0x155
> > cpu_attach(cc7ee200,cc7ee600,c0b08b98,cc7ee600,2163,cc7fb000,cc7ee600,cc7f902c,cc7f9092,cc7ee200)
> > at netbsd:cpu_attach+0x211
> > config_attach_loc(cc7ee200,c092d698,c0b08ba4,c0b08b98,c04a5b00,c0593750,0,e,0,8)
> > at netbsd:config_attach_loc+0x15c
> > mpacpi_config_cpu(cc7f902c,cc7ee200,0,c0477ed1,cc7ee000,a,c0b08be8,cc7ee200,cc7ee000,a)
> > at netbsd:mpacpi_config_cpu+0x6c
> > acpi_madt_walk(c04a5a30,cc7ee200,c0b08bf8,c04a590f,ffffffed,cc7ee200,c0b08c68,c04849fd,cc7ee200,c0b08c58)
> > at netbsd:acpi_madt_walk+0x33
> > mpacpi_scan_apics(cc7ee200,c0b08c58,c0b08c68,c0484a2e,8,5,0,0,c0b08c74,0)
> > at netbsd:mpacpi_scan_apics+0x66
> > mainbus_attach(0,cc7ee200,0,cc7ee200,0,c092d890,cc7ee200,0,c08b0094,c09e1280)
> > at netbsd:mainbus_attach+0x17d
> > config_attach_loc(0,c092d890,0,0,0,c092d890,1,0,c08b0094,c09e1280) at
> > netbsd:config_attach_loc+0x15c
> > config_attach(0,c092d890,0,0,c0b06010,b06000,c0b08d08,c01d48c5,c08b0094,0)
> > at netbsd:config_attach+0x1d
> > config_rootfound(c08b0094,0,c0b08d08,c01d48b6,c2fc4800,c0b06010,c0b08d38,c03e4cdc,0,0)
> > at netbsd:config_rootfound+0x27
> > cpu_configure(0,0,0,0,0,0,c0b08d48,c0b06010,b06000,b0d000) at
> > netbsd:cpu_configure+0x25
> > main(0,c01002ca,0,0,0,0,0,0,0,0) at netbsd:main+0x1ec
> >
> > This kernel config is just MONOLITHIC with "no options
> > ENHANCED_SPEEDSTEP". Vanilla MONOLITHIC does the same thing.
>
> Accessing an MSR raises a #GP when
>
> - the MSR doesn't exist
> - set reserved bits (never happens on a read)

Disabling ENHANCED_SPEEDSTEP and INTEL_CORETEMP gets it booting.
CPUs are:

cpu0: Intel Pentium Pro, II or III (686-class), 2394.15 MHz, id 0x106e5
cpu0: features  0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features  0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR>
cpu0: features  0xbfebfbff<SSE,SSE2,SS,HTT,TM,SBF>
cpu0: features2 0x98e3fd<SSE3,DTES64,MONITOR,DS-CPL,VMX,SMX,EST,TM2,SSSE3>
cpu0: features2 0x98e3fd<CX16,xTPR,PDCM,SSE41,SSE42,POPCNT>
cpu0: features3 0x28100000<XD,EM64T>
cpu0: features4 0x1<LAHF>
cpu0: "Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz"
cpu0: I-cache 32KB 64B/line 4-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 256KB 64B/line 8-way
cpu0: ITLB 128 4KB entries 4-way
cpu0: DTLB 64 4KB entries 4-way
cpu0: L3 cache 8MB 64B/line 16-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: family 06 model 0e extfamily 00 extmodel 01

Tracing through the ENHANCED_SPEEDSTEP patch, the guilty rdmsr() is in 
p3_get_bus_clock():

        case 0xe: /* Core Duo/Solo */
        case 0xf: /* Core Xeon */
                msr = rdmsr(MSR_FSB_FREQ);
                bus = (msr >> 0) & 0x7;

So it looks like this MSR, which is listed as "Core Duo/Solo only" in 
sys/arch/x86/include/specialreg.h (but is actually in pretty widespread 
use in p3_get_bus_clock()) is no longer valid.

Perhaps we need a whole new function for i7 CPUs?

--
Stephen