From owner-freebsd-arch@FreeBSD.ORG Thu Oct 16 02:22:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C7C7A9B for ; Thu, 16 Oct 2014 02:22:17 +0000 (UTC) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) (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 43123601 for ; Thu, 16 Oct 2014 02:22:17 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.6 #37010) id <01PDSIR06YTS000821@tmk.com> for freebsd-arch@freebsd.org; Wed, 15 Oct 2014 22:22:04 -0400 (EDT) Date: Wed, 15 Oct 2014 21:54:38 -0400 (EDT) From: Terry Kennedy Subject: Re: [rfc] Add boot-time warning messages to PAE kernels To: freebsd-arch@freebsd.org Message-id: <01PDSJPDFY7O000821@tmk.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 02:22:17 -0000 > WRT user 32bit code which does not run on amd64 kernel, you obviously > did not tried hard. The compat32 is lacking; the simple (from the PoV > of the kernel facilities used) programs do run, but anything more > involved has a chance to meet unimplemented functionality. Well, everything I've ever tried (including a rather large variety of commercial software) has worked without problems. The only specific case I've ever heard of something not working was Wine, and that only in some anecdotes from others. Improving compatibility, both of FreeBSD-i386 (compat32) and Linux, is a topic for another discussion. Is there a way to search the bug database for this type of enhancement request? I might tackle some of them if I can reproduce the test case(s). > Perhaps it's the 'amd' in the name? That always struck me as insane, > but it's too late to change now. AMD got there first in this case, since Intel was fiddling with their Itanium architecture and seem to have actively resisted extending the x86 architecture to 64 bits. Perhaps this is something that can be ad- dressed in the hardware notes, to make it more obvious that amd64 is not limited to AMD processors. > > Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" > > statements disabling hardware which is not supported by the PAE kernel, as > > well as a complete disabling of module building. > > The fact that we actively propagate the myth doesn't make it right. The > comment even notes that the drivers are "either don't work or untested" > I suspect most fall into the latter category. I use a couple devices on > the list. I use modules as well, despite the comment that that doesn't > work. If there are drivers in the nodevice list that are known to work, that would seem to be good info to get into a future revision of the PAE file. Likewise the bit about modules not working. And the PAE manpage has some scary notes (in the BUGS section) as well. > I'm not sure where you got the idea that i386 hardware is long out of > production. google "industrial single-board computer" some time for an > alternate take on what's producing and shipping and still in control of > a non-trivial slice of our daily lives. When we ship i386-based > products at $work it's using brand new hardware. I was speaking of the general x86 desktop / workstation / server market. I had assumed that embedded use of FreeBSD required rather extensive cus- tiomization to fit it in the desired memory space. I had not considered the issue with the NX bit. Like many things with the x86 architecture, it seems to have "just happened", rather than being architected. It might have been better (looking at this in hindsight) if PAE was enabled by default in i386 kernels, but limiting memory accesses to only the memory below the 4GB line unless a tunable enabling the extra memory was set. That seems to have been the method used by Windows to add NX sup- port (minus the tunable). Oh well... In closing, let me withdraw this RFC and withdraw from the field of battle. If someone else wants to float jhb's suggestion for a configur- able warning for an i386 kernel on amd64-capable hardware, either always or for systems with > 4GB, feel free to pick it up. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA