From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 22:11:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D730C63E for ; Fri, 20 Feb 2015 22:11:30 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62CDE1AE for ; Fri, 20 Feb 2015 22:11:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1KMBNr3013411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2015 00:11:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1KMBNr3013411 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1KMBMpX013410; Sat, 21 Feb 2015 00:11:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Feb 2015 00:11:22 +0200 From: Konstantin Belousov To: Andrew Wilcox Subject: Re: i386 port no longer bootable on non-SSE CPUs Message-ID: <20150220221122.GN34251@kib.kiev.ua> References: <00c401d04d51$905fedc0$b11fc940$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c401d04d51$905fedc0$b11fc940$@Wilcox-Tech.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 22:11:30 -0000 On Fri, Feb 20, 2015 at 03:09:49PM -0600, Andrew Wilcox wrote: > Hello, > > The i386 port, both 10-STABLE and 11-CURRENT, will not boot on systems without SSE support. This is caused by r273995, as using `svn merge -c -273995` (and hacking-and-sloshing through the few compiler errors afterwards) makes it once again bootable. > > This crash happens very early on in boot, before even mi_startup (as the author line is never even printed): http://i.imgur.com/SAty1mT.jpg > > This breaks support for all i486, Pentium, Pentium Pro, and Pentium II-based CPUs and computers. These are not only found in older computers that are useful as routers and file servers, but there are some new SoCs still using these chips: > > Intel Galileo board > http://www.frys.com/product/8080584 > Pentium core, no MMX/SSE whatsoever. Released late 2014. > > AMD Elan SC520, Geode series > http://www.eurotech.com/en/products/CPU-1421 > http://www.amd.com/en-us/products/embedded/processors/lx > While the Elan is no longer manufactured, it still remains popular. The new Geode LX series of processors only implement MMX (so are roughly equivalent to a Pentium Pro in terms of instruction set). > > Backing out r273995 allows boot to proceed normally, as shown here: http://imgur.com/a/WWsa5 > > I attempted to revert locore.S to see if it was related to the stack setup changes found in that commit and it made no difference; the panic was the same. > > I would be willing to test any patches/diffs on any or all of the systems I have, but unfortunately I'm in a bit over my head trying to figure out which part of this commit is causing it. > I just booted HEAD on the qemu configured to emulate Pentium II, i.e. MMX but no SSE/SSE2. So I think what you describe is based on the generalization from single fact. Double fault usually means that the stack overflown. The values for the %eip and %esp on the screen look fishy. My advise is to add debugging printfs to see how far execution went before double fault occur. From the dmesg, your machine fails somewhere in init386(). Try to add some printfs() there, probably around npxinit(true) call for the start. Also, providing us with the verbose dmesg for successfull boot could be useful.