cvs commit: src/sys/amd64/amd64 fpu.c
David Schultz
FreeBSD src repository
Modified files:
sys/amd64/amd64 fpu.c
Log:
Initialize the MXCSR to the appropriate default value at startup.
Tested on: tjr
Revision Changes Path
1.150 +4 -0 src/sys/amd64/amd64/fpu.c
_______________________________________________
cvs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-u...@freebsd.org"
David Malone
> Modified files:
> sys/amd64/amd64 fpu.c
> Log:
> Initialize the MXCSR to the appropriate default value at startup.
This seems to result in a "Fault trap 1: privileged instrustion
fault while in the kernel" while executing the ldmscsr instruction.
If I comment it out, everything works fine again.
> Tested on: tjr
This must be a situation where testing on humans is bad ;-)
David.
Tim Robbins
> On Fri, Jun 04, 2004 at 08:13:39PM -0700, David Schultz wrote:
> > Modified files:
> > sys/amd64/amd64 fpu.c
> > Log:
> > Initialize the MXCSR to the appropriate default value at startup.
>
> This seems to result in a "Fault trap 1: privileged instrustion
> fault while in the kernel" while executing the ldmscsr instruction.
> If I comment it out, everything works fine again.
>
> > Tested on: tjr
>
> This must be a situation where testing on humans is bad ;-)
It works fine here.
CPU: AMD Athlon(tm) 64 Processor 3000+ (2002.57-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0xf48 Stepping = 8
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow!+,3DNow!>
Tim
David Schultz
FreeBSD src repository
Modified files:
sys/amd64/amd64 fpu.c
Log:
Back out revision 1.150, since dwmalone reports that it causes a panic
upon startup on his machine.
Revision Changes Path
1.151 +0 -4 src/sys/amd64/amd64/fpu.c
David Schultz
> On Fri, Jun 04, 2004 at 08:13:39PM -0700, David Schultz wrote:
> > sys/amd64/amd64 fpu.c
> > Log:
>
> This seems to result in a "Fault trap 1: privileged instrustion
> fault while in the kernel" while executing the ldmscsr instruction.
> If I comment it out, everything works fine again.
Sorry, I just backed it out for the mean time. Can you send me
your dmesg|head please?
David Schultz
> das 2004-06-06 09:16:02 UTC
>
> FreeBSD src repository
>
> sys/amd64/amd64 fpu.c
> Log:
> upon startup on his machine.
It would be great if someone could pick this up and devise the
appropriate fix. I want to see this bug fixed, but I don't have the
hardware to do amd64 kernel hacking. I'm happy to help anyone who is
interested.
So far I have one report that the patch I just backed out seems to
work, and another that it panics on startup, so this seems to point to
a CPU-specific problem. ldmxcsr is supposed to fail if an attempt is
made to set unsupported bits in the CSR, but at the same time, the
defaults in the AMD64 architecture manual ought to work! If this is
indeed the problem, there is a simple way to work around it.
David Malone
> > fault while in the kernel" while executing the ldmscsr instruction.
> > If I comment it out, everything works fine again.
> Sorry, I just backed it out for the mean time. Can you send me
> your dmesg|head please?
Sure - included below. I tried the same instruction in userland and
it caused no problems.
David.
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-CURRENT #3: Sun May 30 22:14:07 GMT 2004
dwma...@sweetums.eastwall.dwmalone.net:/usr/src/sys/amd64/compile/GENERIC
WARNING: WITNESS option enabled, expect reduced performance.
Preloaded elf kernel "/boot/kernel.old/kernel" at 0xffffffff8091e000.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 238 (1804.10-MHz K8-class CPU)
Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow!+,3DNow!>
real memory = 3756982272 (3582 MB)
avail memory = 3623555072 (3455 MB)
ACPI APIC Table: <VIAK8 AWRDACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
David Malone
> It would be great if someone could pick this up and devise the
> appropriate fix. I want to see this bug fixed, but I don't have the
> hardware to do amd64 kernel hacking. I'm happy to help anyone who is
> interested.
I think I've figured out the problem. On SMP systems, fpuinit() is
called before enable_sse() for secondary processors. The ldmxcsr
instruction counts as a sse instruction, so you get an illegal
instruction fault. The patch below switches the order of fpuinit()
and enable_sse() and fixes the problem on my system anyway.
David.
Index: mp_machdep.c
===================================================================
RCS file: /cvs/FreeBSD-CVS/src/sys/amd64/amd64/mp_machdep.c,v
retrieving revision 1.237
diff -u -r1.237 mp_machdep.c
--- mp_machdep.c 16 May 2004 22:11:50 -0000 1.237
+++ mp_machdep.c 7 Jun 2004 09:36:08 -0000
@@ -429,12 +429,12 @@
/* set up CPU registers and state */
cpu_setregs();
- /* set up FPU state on the AP */
- fpuinit();
-
/* set up SSE registers */
enable_sse();
+ /* set up FPU state on the AP */
+ fpuinit();
+
/* A quick check from sanity claus */
if (PCPU_GET(apic_id) != lapic_id()) {
printf("SMP: cpuid = %d\n", PCPU_GET(cpuid));
John Baldwin
> das 2004/06/04 20:13:39 PDT
>
>
> Modified files:
> sys/amd64/amd64 fpu.c
> Log:
>
FreeBSD/tjr? :)
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
David Schultz
> On Sun, Jun 06, 2004 at 02:17:58AM -0700, David Schultz wrote:
> > It would be great if someone could pick this up and devise the
> > appropriate fix. I want to see this bug fixed, but I don't have the
> > hardware to do amd64 kernel hacking. I'm happy to help anyone who is
> > interested.
>
> I think I've figured out the problem. On SMP systems, fpuinit() is
> called before enable_sse() for secondary processors. The ldmxcsr
> instruction counts as a sse instruction, so you get an illegal
> instruction fault. The patch below switches the order of fpuinit()
> and enable_sse() and fixes the problem on my system anyway.
Nice catch. That would certainly explain the problem, and both of
the machines with reported problems (yours and sledge) are SMP.
Care to commit this?
Peter Wemm
FreeBSD src repository
Modified files:
sys/amd64/amd64 fpu.c
Log:
Reapply rev 1.151 after enable sse/fpuinit order fixed in mp_machdep.c
Obtained from: das
Revision Changes Path
1.152 +4 -0 src/sys/amd64/amd64/fpu.c
Peter Wemm
FreeBSD src repository
Modified files:
sys/amd64/amd64 fpu.c
Log:
Fix my silly typo in asm statement in previous commit.
Revision Changes Path
1.153 +1 -1 src/sys/amd64/amd64/fpu.c
David Schultz
> peter 2004-06-08 01:14:39 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/amd64/amd64 fpu.c
> Log:
Thanks!
David Schultz
> On Friday 04 June 2004 11:13 pm, David Schultz wrote:
> > das 2004/06/04 20:13:39 PDT
> >
> >
> > Modified files:
> > sys/amd64/amd64 fpu.c
> > Log:
> >
> > Tested on: tjr
>
> FreeBSD/tjr? :)
* No actual FreeBSD committers were panicked in the testing of
this patch (but one got a little uneasy.)