From owner-freebsd-mobile Mon Jul 15 22:58:03 1996 Return-Path: owner-mobile Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA08726 for mobile-outgoing; Mon, 15 Jul 1996 22:58:03 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA08713; Mon, 15 Jul 1996 22:57:57 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id XAA22922; Mon, 15 Jul 1996 23:57:46 -0600 (MDT) Date: Mon, 15 Jul 1996 23:57:46 -0600 (MDT) Message-Id: <199607160557.XAA22922@rocky.mt.sri.com> From: Nate Williams To: freebsd-mobile@freebsd.org, current@freebsd.org CC: davidg@freebsd.org Subject: Cause of APM_DSVALUE_BUG found (but not completely fixed yet) Sender: owner-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I got some email from John Kohl from the NetBSD project, and during our discussions I mentioned that on the IBM ThinkPad's I needed a hack because the APM data segment was getting corrupted. He mentioned that this used to be a problem in NetBSD until recently when they changed the way they determine the base and extended memory sizes. Both FreeBSD and previously NetBSD use the BIOS values stored in the RTC CMOS RAM (instead of probing). This is normally a 'good thing, except that these values are apparently stored *before* such niceties as the APM BIOS have a whack at things. Apparently the APM bios 'steals' the last page of base-memory for itself, and then subtracts this from the BIOS's value of base memory. But, since this is called after the data is stored in RTC we have no way of finding out using the RTC interface. However, our bootblocks read the BIOS information after ever everything else has run, and they provide the (correct!) amount of base and extended memory to the kernel. Currently, the kernel prints out a warning message if the RTC value and the bootblock value doesn't match, but it still uses the RTC value. Now, if this space is taken up by DOS-like things we may as well re-take that space back, but in this case it's a bad thing since it doesn't allow us to use the APM bios w/out significant hacks (which also uses up an additional 42K of memory on my box). The following patch fixes the BIOS problem, but it brings up another problem that I don't yet have a 'acceptable' solution for. On bootup, all of the memory is mapped read-only, and then specific parts are mapped read/write/no-cacheable etc.. The 'normal' ISA memory hole starting at 640K and continuing for the next 384K is mapped differently. Then, in machdep.c, the 'basemem' is mapped into the kernel for general use (read/write, etc.) However, with the below patch, the kernel only maps the 'actual' basemem the BIOS reports into 'general' memory. This leaves the 'stolen' memory mapped read-only (the default unless specified otherwise) which doesn't work for a data-segment that gets written to. The NetBSD kernel has a function to map the page read/write, but their kernel is *vastly* different from ours. I'm in contact with some of the kernel gurus on how best to solve this, but I wanted to give everyone the heads up before I go on a mini-vacation, in case anyone gets a wild hair and decides to fix this the 'correct' way. In my opinion, the proper solution would be to either: a) Map the memory read-write in machdep.c when we determine that the BIOS reported by the RTC and the bootblocks doesn't match. OR b) Map the memory read-write in the APM driver. The former assumes that *something* will use it later on, and the latter implies that any driver which has a use for that memory will do it's own mapping, since the driver may not have to do any modification. I'm not sure which one I prefer, but given my lack of experience with the pmap() functions and no success with the couple of attempts I did today, I probably won't get the 'correct' solution done this week. Finally, the patch below hasn't been reviewed and may not go into the FreeBSD as it stands, but it is provided to show the bug and part of the solution. It has been tested and doesn't cause anything bad to happen though, so you should feel safe in applying it to a -current system. (It may also apply to 2.1.5, but I haven't checked). Nate -------- Index: machdep.c =================================================================== RCS file: /home/CVS/src/sys/i386/i386/machdep.c,v retrieving revision 1.194 diff -u -r1.194 machdep.c --- machdep.c 1996/07/08 19:44:39 1.194 +++ machdep.c 1996/07/11 19:19:07 @@ -1239,12 +1239,16 @@ * the official interface should be used. */ if (bootinfo.bi_memsizes_valid) { - if (bootinfo.bi_basemem != biosbasemem) + if (bootinfo.bi_basemem != biosbasemem) { printf("BIOS basemem (%ldK) != RTC basemem (%dK)\n", bootinfo.bi_basemem, biosbasemem); - if (bootinfo.bi_extmem != biosextmem) + biosbasemem = bootinfo.bi_basemem; + } + if (bootinfo.bi_extmem != biosextmem) { printf("BIOS extmem (%ldK) != RTC extmem (%dK)\n", bootinfo.bi_extmem, biosextmem); + biosextmem = bootinfo.bi_extmem; + } } /*