From owner-cvs-all@FreeBSD.ORG Sat Mar 29 22:06:46 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5484437B401; Sat, 29 Mar 2003 22:06:46 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 615AD43FB1; Sat, 29 Mar 2003 22:06:45 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.8/8.12.8) with ESMTP id h2U6D2xS031200; Sun, 30 Mar 2003 01:13:02 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.8/8.12.8/Submit) id h2U6D2q9031199; Sun, 30 Mar 2003 01:13:02 -0500 (EST) Date: Sun, 30 Mar 2003 01:13:01 -0500 From: Jake Burkholder To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: <20030330061301.GC21973@locore.ca> References: <200303300524.h2U5Ora7061852@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303300524.h2U5Ora7061852@repoman.freebsd.org> User-Agent: Mutt/1.4i Subject: HEADS UP Re: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 bios.c locore.s machdep.c mpboot.s pmap.c vm86bios.s vm_machdep.c src/sys/i386/include _types.h bus_at386.h param.h pmap.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2003 06:06:49 -0000 Apparently, On Sat, Mar 29, 2003 at 09:24:53PM -0800, Jake Burkholder said words to the effect of; > jake 2003/03/29 21:24:53 PST > > FreeBSD src repository > > Modified files: > sys/conf options.i386 > sys/i386/i386 bios.c locore.s machdep.c mpboot.s pmap.c > vm86bios.s vm_machdep.c > sys/i386/include _types.h bus_at386.h param.h pmap.h > Log: > - Add support for PAE and more than 4 gigs of ram on x86, dependent on the > kernel opition 'options PAE'. This will only work with device drivers > which either use busdma, or are able to handle 64 bit physical addresses. There are a few issues still to be resolved, but for the most part this is complete and works. As I mentioned this will only work with certified device drivers. The drivers that I was able to test this with in a machine with more than 4G of ram are: ahc, ata, em, and the usual other drivers which don't use dma (syscons etc). Device drivers which use busdma, and which create their dma tags properly should work, bounce buffers will be used if required. Device drivers which don't use busdma and are unable to use 64bit pci addressing will not work and may cause massive data corruption if used in a system with more than 4 gigs of ram. This is serious. Do not test random device drivers in such machines with PAE enabled unless you know what you are doing and can handle file system corruption. I lost several file systems during development. Many many drivers will not compile with PAE because they are not written properly to handle 64 bit vm_paddr_t or 64 bit bus_addr_t. There is a problem with cam, in that it tries to store a physical address in a pointer for certain types of requests. These requests are not implemented in cam, and are not actually used by any device drivers, but casting a pointer to a 64 bit bus_addr_t causes them to not compile. I have applied a temporary fix to ahc because I know it works with 39 bit addressing. A better solution to this will need to be found, but in the mean time maintainers should ensure their drivers will work properly with 64 bit physical addresses before just making them compile. Also, you must not use kernel modules if you enable PAE. PAE is like KVA_PAGES in that it changes all kinds of things about the kernel address space. Basically any module which calls pmap_mapdev, pmap_kextract or vtophys (actually pmap_kextract) or which uses the stack gap must be statically compiled into the kernel. This includes acpi. The MAC framework has similar problems and the only real solution is for modules to be built with the same options headers as the kernel. I'm told a solution to this is being worked on. Given these caveats, if anyone has a large memory system with a suitable hardware configuration I would appreciate feedback. I would like to thank Robert Watson for finding the funding for this, and once again would like to thank Lanny Baron for his loan of a 6G machine, without which this would not have been possible. Have fun. Jake