From owner-freebsd-current Thu May 27 10:56: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id C383315935 for ; Thu, 27 May 1999 10:56:00 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id MAA03552 for ; Thu, 27 May 1999 12:55:56 -0500 (CDT) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id MAA04543; Thu, 27 May 1999 12:55:55 -0500 Message-ID: <19990527125555.63299@right.PCS> Date: Thu, 27 May 1999 12:55:55 -0500 From: Jonathan Lemon To: current@freebsd.org Subject: Request for testers; removing VM86 as an option. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a patch that reworks the memory calculation at bootup, and correctly obtains the physical memory map from the BIOS using the INT 15, AX=E820 call. This should allow correct operation on machines which reserve certain segments of memory for non-OS use (ThinkPads). It can also preserve the ACPI tables for later use. If 15/E820 is not supported, various other methods are tried, including falling back to the current scheme of speculative probing. I'd like some testers (preferrably a ThinkPad user with > 64M of memory) to try this out and see if it correctly detects all usable memory; and also if the system boots without needing to specify MAXMEM (or npx0 size). If it works, great. If not, boot with `-v', and send me back the SMAP lines from the dmesg output. Barring any serious objections(*), I'd like to merge this into -current, and then `unifdef -DVM86' to make it mandatory. There appears to be no other reliable way to detect > 64M of memory on modern PC hardware. PC98 developers - this should actually simplify things, as it moves the memory calculations into their own routine. The -current patch is ftp://sumatra.americantv.com/pub/memsize.patch There is a bootable -stable picobsd floppy too, for those who don't want to compile a kernel: ftp://sumatra.americantv.com/pub/picobsd.bin -- Jonathan (*) I don't consider FBSDBOOT.EXE a serious objection; it may or may not have worked before, and it may or may not work now. (As discussed to death on earlier threads on this list). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message