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
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to