NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-i386/52266: Double fault early in boot with Transmeta Crusoe CPU



The following reply was made to PR port-i386/52266; it has been noted by GNATS.

From: Simon Burge <simonb%NetBSD.org@localhost>
To: Kimihiro Nonaka <nonakap%gmail.com@localhost>
Cc: "gnats-bugs%netbsd.org@localhost" <gnats-bugs%netbsd.org@localhost>,
    port-i386-maintainer%netbsd.org@localhost,
    "gnats-admin%netbsd.org@localhost" <gnats-admin%netbsd.org@localhost>,
    "netbsd-bugs%netbsd.org@localhost" <netbsd-bugs%netbsd.org@localhost>
Subject: Re: port-i386/52266: Double fault early in boot with Transmeta Crusoe CPU
Date: Sat, 08 Jul 2017 17:10:33 +1000

 Kimihiro Nonaka wrote:
 
 > Could you send a dmesg and a result of cpuctl identify 0 with old kernel?
 
 I get the same problem on my Soekris net4801 with the following cpu:
 
 	cpu0: highest basic info 00000002
 	cpu0: highest extended info 80000005
 	cpu0: "Geode(TM) Integrated Processor by National Semi"
 	cpu0: National Semiconductor Geode GX1 (586-class)
 	cpu0: family 0x5 model 0x4 stepping 0 (id 0x540)
 	cpu0: features 0x808131<FPU,TSC,MSR,CX8,CMOV,MMX>
 	cpu0: ITLB 1 4KB entries 112-way
 	cpu0: Initial APIC ID 0
 
 If I change lapic_is_x2apic() to unconditionally return false, my
 Soekris boots (at least to single user mode).
 
 I tried to get lapic_is_x2apic() to store the value of the MSR it
 reads by changing that function to:
 
 	uint64_t x2apic_msr;
 
 	bool
 	lapic_is_x2apic(void)
 	{
 		x2apic_msr = rdmsr(MSR_APICBASE);
 		return false;
 	}
 
 but that just faulted/paniced too, but slightly differently:
 
 	> boot net8 -s
 	17730720+696076+839124 [776736+802655]=0x13e1cbc
 	fatal protection faufatal double fault in supervisor mode
 	trap type 13 code 0xc0118298 eip 0x8 cs 0x246 eflags 0xc054bbf6 cr2 0 ilevel 0x8 esp 0xc11ea760
 	curlwp 0xc125f360 pid 0 lid 1 lowest kstack 0xc14e32c0
 	kernel: user trap double fault, code=0
 	Stopped in pid 0.1 (system) at  8:      invalid address
 	db{0}> 
 
 The chopped off "fatal protection fau" is new.  Could the rdmsr() itself
 be faulting then??
 
 Is there any further info I get to help?
 
 Cheers,
 Simon.
 


Home | Main Index | Thread Index | Old Index