From owner-freebsd-i386@FreeBSD.ORG Thu Jan 6 20:40:40 2005 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E49216A4E2 for ; Thu, 6 Jan 2005 20:40:40 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE4F443D2F for ; Thu, 6 Jan 2005 20:40:31 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j06KeVcU082384 for ; Thu, 6 Jan 2005 20:40:31 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j06KeVrU082383; Thu, 6 Jan 2005 20:40:31 GMT (envelope-from gnats) Resent-Date: Thu, 6 Jan 2005 20:40:31 GMT Resent-Message-Id: <200501062040.j06KeVrU082383@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bartosz Fabianowski Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99A8716A4CE for ; Thu, 6 Jan 2005 20:39:57 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F38343D3F for ; Thu, 6 Jan 2005 20:39:57 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j06Kdvto016949 for ; Thu, 6 Jan 2005 20:39:57 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j06KdvU7016948; Thu, 6 Jan 2005 20:39:57 GMT (envelope-from nobody) Message-Id: <200501062039.j06KdvU7016948@www.freebsd.org> Date: Thu, 6 Jan 2005 20:39:57 GMT From: Bartosz Fabianowski To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: i386/75898: Exception and reboot: Loader and kernel use SSE2 instructions before they get enabled X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 20:40:40 -0000 >Number: 75898 >Category: i386 >Synopsis: Exception and reboot: Loader and kernel use SSE2 instructions before they get enabled >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 06 20:40:31 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Bartosz Fabianowski >Release: 5.3-STABLE >Organization: >Environment: FreeBSD takahe.local 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Dec 29 17:52:52 CET 2004 root@takahe.local:/usr/obj/usr/src/sys/TAKAHE i386 >Description: bsd.cpu.mk as of version 1.42 on 6.0-CURRENT and 1.40.2.1 on 5.3-STABLE recognizes the setting CPUTYPE=pentium-m in /etc/make.conf, which enables code generation and optimization for the Pentium M family. One of the features enabled by this switch is SSE2. This works fine once the systems is up and running, but breaks the boot process. The problem is that for SSE and SSE2 instructions to be available, the OSFXSR bit in CR4 must be set. This has to be done by the operating system, as the bit is off by default. At system startup, the kernel sets the bit at some point. However, the code that runs before this point in time already tries to use SSE2 instructions and fails miserably with an UD exception (invalid opcode), which in turn leads to an instant reboot. The code that runs before the OSFXSR bit is set is the entire loader and part of the kernel. To confirm that the problems lies in SSE2 instructions being used too early, I recompiled with CPUTYPE=pentium3 and the system started up as expected. Others have reported the same issue with CPUTYPE=athlon-xp, which also has SSE support. It might be that some motherboards silently set OSFXSR, in which case this problem would not appear on the respective systems and therefore is a bit hard to chase. >How-To-Repeat: * Build world and / or kernel on a machine with above mentioned version of bsd.cpu.mk and CPUTYPE=pentium-m * Reboot * If the BIOS does not set OSFXSR in CR4, watch the UD exception and the instant reboot >Fix: One way of fixing this would be to specifically disable SSE and SSE2 support in the Makefiles of those parts of the system that run before the OSFXSR bit is set. However, it might be hard to find all the Makefiles and to maintain those fixes over a long time. Another way would be to enable the OSFXSR bit earlier on in the boot process. NOTE however that this bit also indicates that XMM registers are saved on context switch, so with setting this bit comes the obligation to always used FXSAVE and FXRSTOR. >Release-Note: >Audit-Trail: >Unformatted: