From mboxrd@z Thu Jan 1 00:00:00 1970 From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] missing memory MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-kyqkulojdohntgexkgsvbblvvt" Message-Id: <20020121180423.2EFC919981@mail.cse.psu.edu> Date: Mon, 21 Jan 2002 13:04:15 -0500 Topicbox-Message-UUID: 3fa3552c-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-kyqkulojdohntgexkgsvbblvvt Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit IF you look int the ramscan routine you will see it reads NVRAM locations 0x18 and 0x17. It would be interesting to know what is in there as that will limit the amount of physical memory the routine scans. Put *maxmem=0xFF79000 in your plan9.ini and see if the whole memory is detected (and can be used). --upas-kyqkulojdohntgexkgsvbblvvt Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Jan 21 12:10:17 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Jan 21 12:10:16 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 48053199EE; Mon, 21 Jan 2002 12:10:07 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from ms0.nttdata.co.jp (ms0.nttdata.co.jp [163.135.193.231]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3DAB519981 for <9fans@cse.psu.edu>; Mon, 21 Jan 2002 12:09:21 -0500 (EST) Received: from mail1.nttdata.co.jp ([163.135.10.21]) by ms0.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/01) with ESMTP id CAA20922 for <9fans@cse.psu.edu>; Tue, 22 Jan 2002 02:09:47 +0900 (JST) From: iwanek@nttdata.co.jp Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/01) with ESMTP id CAA15156 for <9fans@cse.psu.edu>; Tue, 22 Jan 2002 02:09:59 +0900 (JST) Received: from noanet03.noanet.nttdata.co.jp (noanet03.noanet.nttdata.co.jp [10.1.49.13]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id CAA03762 for <9fans@cse.psu.edu>; Tue, 22 Jan 2002 02:07:48 +0900 (JST) Received: by noanet03.noanet.nttdata.co.jp with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 02:07:56 +0900 Message-ID: <50F591D39557D511B12C0090274DCEBC03B6754D@noanet03.noanet.nttdata.co.jp> To: 9fans@cse.psu.edu MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [9fans] missing memory Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Tue, 22 Jan 2002 02:07:48 +0900 Hello 9fans, About a month ago, I reported a problem of getting the panic: exception/interrupt 14 from floppy installation. Not quite sure what I did differently (BIOS power management setting, maybe), somehow I got through it. Now I have new problem and would like to ask the list for help again. My PC is a Dell Dimension 8200. This monster has a 1.6GHz Pentium4, i850 chipset (danger here?) and 256MB RIMM. 9pcdisk detects only 64MB of RAM. Setting MEMDEBUG to 1 in /sys/src/9/pc/memory.c, I get maxmem 30000000 D0000000 maxpa = F9DC -> 3F77000, maxpa1 = F9DC maxpa2 = 280 00006000 00099C00 0009FC00 # rmapram 001F9000 03E07000 04000000 # rmapram 000D0000 00020000 000F0000 # rmapumb 04000000 FC000000 00000000 # rmapupa from memdebug(). I guess the range 04000000-10000000 should be RAM but is classified as UPA (what is it anyway, and its size FC000000?). Also I don't have rmapumbrw at all. Strange. I read ramscan() code, and although many details of dealing with MMU are beyond me, I can't tell why this doesn't work. If you know anything about how to fix this problem, please let me know. By the way, linux 2.4.something recognizes all 256MB. Here is its idea of memory map: 00000000000000000 - 00000000000A0000 (usable) 000000000000F0000 - 0000000000100000 (reserved) 00000000000100000 - 000000000FF77000 (usable) 0000000000FF77000 - 000000000FF79000 (ACPI NVS) 0000000000FF79000 - 0000000010000000 (reserved) 000000000FEC00000 - 00000000FEC10000 (reserved) 000000000FEE00000 - 00000000FEE10000 (reserved) 000000000FFB00000 - 0000000100000000 (reserved) Note that linux found out about this using BIOS's ACPI service (INT 15h, AX=E820h). I think you can use this only from *real* mode (horror...). - kazumi --upas-kyqkulojdohntgexkgsvbblvvt--