Re: 'real mem' in dmesg much lower than expected?
On Thu, 18 Aug 2011, Dave Anderson wrote: I've been looking at a bunch of notebook dmesgs (i386, single processor) recently and have noticed that the value reported for 'real mem' is almost always much lower than the amount of memory actually installed. A typical example is OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 2900148224 (2765MB) spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600 SO-DIMM I understand that i386 cannot see more than 4GB due to architecture restrictions, but even allowing for that well over a gigabyte has vanished here. A quick look at the code that generates this number shows that it's skipping various areas reserved by the BIOS, etc., but the total amount being skipped seems absurd. Is there really supposed to be this much reserved space, or is something wrong? Thanks to all who've replied. It seems kind of disgusting that a modern video card can grab 1/4 of the available physical address space on i386, but I suppose that pretty much everyone with such a card is running amd64 instead. I've been testing with i386 since the hardware I have at home is all old enough that I can't use it to install amd64, but I'll get around that somehow (possibly by using one of the demo machines I'm testing to install amd64 to my test USB stick) and start testing with amd64/mp instead. Dave -- Dave Anderson d...@daveanderson.com
Re: 'real mem' in dmesg much lower than expected?
On Sat, 20 Aug 2011, Dave Anderson wrote: Thanks to all who've replied. It seems kind of disgusting that a modern video card can grab 1/4 of the available physical address space on i386, but I suppose that pretty much everyone with such a card is running amd64 instead. If you want to feel disgusted even more: some popular and frequently used chipsets for amd64 CPU's, such as Intel 82945GM, address memory with 32 bits only. With such a chipset you suffer similar limitation with amd64 as you would with i386 (available RAM minus devices' address space minus shared video memory etc.). But these chipsets are not produced anymore, I hope. Regards, David
Re: 'real mem' in dmesg much lower than expected?
On 2011-08-18, Dave Anderson d...@daveanderson.com wrote: Is there really supposed to be this much reserved space very often, yes.
Re: 'real mem' in dmesg much lower than expected?
On Thu, 18 Aug 2011, Dave Anderson wrote: Oops! I forgot to include the full dmesg; here it is. I've been looking at a bunch of notebook dmesgs (i386, single processor) recently and have noticed that the value reported for 'real mem' is almost always much lower than the amount of memory actually installed. A typical example is OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 2900148224 (2765MB) spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600 SO-DIMM I understand that i386 cannot see more than 4GB due to architecture restrictions, but even allowing for that well over a gigabyte has vanished here. A quick look at the code that generates this number shows that it's skipping various areas reserved by the BIOS, etc., but the total amount being skipped seems absurd. Is there really supposed to be this much reserved space, or is something wrong? Thanks, Dave OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC RTC BIOS diagnostic error 80clock_battery cpu0: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX real mem = 2900148224 (2765MB) avail mem = 2842660864 (2710MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/25/11, BIOS32 rev. 0 @ 0xef735, SMBIOS rev. 2.7 @ 0xe6780 (32 entries) bios0: vendor Hewlett-Packard version F.13 date 04/25/2011 bios0: Hewlett-Packard HP Pavilion dv7 Notebook PC acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC SSDT BOOT ASPT SSDT SSDT SSDT SSDT acpi0: wakeup devices P0P1(S3) LID_(S3) GLAN(S4) EHC1(S3) EHC2(S3) HDEF(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S3) PXSX(S4) RP03(S3) PXSX(S4) RP04(S3) PXSX(S4) RP05(S3) PXSX(S4) RP06(S3) PXSX(S4) RP07(S3) PXSX(S4) RP08(S3) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 7 (RP01) acpiprt3 at acpi0: bus 13 (RP02) acpiprt4 at acpi0: bus 19 (RP03) acpiprt5 at acpi0: bus 25 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus 1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpibat0 at acpi0: BAT0 not present acpiac0 at acpi0: AC unit online acpidock0 at acpi0: DOCK not docked (0) acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 bios0: ROM list: 0xc/0xf000 cpu0: Enhanced SpeedStep 1996 MHz: speeds: 2001, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 ppb0 at pci0 dev 1 function 0 Intel Core 2G PCIE rev 0x09: apic 0 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel GT2 Video rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp at vga1 not configured Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x05: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x05: msi azalia0: codecs: IDT 92HD81B1X, Intel/0x2805, using IDT 92HD81B1X audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb5: apic 0 int 17 pci2 at ppb1 bus 7 re0 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E-VL (0x2c80), apic 0 int 16, address 2c:27:d7:aa:e6:43 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 ppb2 at pci0 dev 28 function 1 Intel 6 Series PCIE rev 0xb5: apic 0 int 16 pci3 at ppb2 bus 13 iwn0 at pci3 dev 0 function 0 Intel WiFi Link 1000 rev 0x00: msi, MIMO 1T2R, BGS, address 8c:a9:82:76:34:fe ppb3 at pci0 dev 28 function 2 Intel 6 Series
Re: 'real mem' in dmesg much lower than expected?
On 2011-08-18 21.16, Dave Anderson wrote: I've been looking at a bunch of notebook dmesgs (i386, single processor) recently and have noticed that the value reported for 'real mem' is almost always much lower than the amount of memory actually installed. A typical example is OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 2900148224 (2765MB) spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600 SO-DIMM I understand that i386 cannot see more than 4GB due to architecture restrictions, but even allowing for that well over a gigabyte has vanished here. A quick look at the code that generates this number shows that it's skipping various areas reserved by the BIOS, etc., but the total amount being skipped seems absurd. Is there really supposed to be this much reserved space, or is something wrong? The most likely culprit is your graphics adapter. Nowadays video memory of 512 MB - 1GB seems to be more norm than exception, and it has to co- exist with the processor's memory in the 32 bit addressable space. Use amd64 instead and you'll likely get all your memory back, and since you seem to be running a recent snapshot you'll have no 4GB barrier to cope with either. /B -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: 'real mem' in dmesg much lower than expected?
On 18-08-2011 20:16, Dave Anderson wrote: I've been looking at a bunch of notebook dmesgs (i386, single processor) recently and have noticed that the value reported for 'real mem' is almost always much lower than the amount of memory actually installed. A typical example is OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 2900148224 (2765MB) spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600 SO-DIMM I understand that i386 cannot see more than 4GB due to architecture restrictions, but even allowing for that well over a gigabyte has vanished here. A quick look at the code that generates this number shows that it's skipping various areas reserved by the BIOS, etc., but the total amount being skipped seems absurd. Is there really supposed to be this much reserved space, or is something wrong? Thanks, Dave Have you checked if the Video Card uses shared memory ? Regards, Pedro de Oliveira
Re: 'real mem' in dmesg much lower than expected?
i386 port has access to 32-bit (4 GB) address space but only allows you to use up to 3 GB of RAM at most, the last 1 GB of address space is used for addressing devices, and as others are saying here, video card shared mem also eats up space 4 GB openbsd didn't bother with PAE on i386, it's too complicated and not worth it because amd64 exists the solution is to move to the amd64 port which has a 64-bit virtual address space (17179869184 GB) which is what you'll need to run google chrome soon anyways. Dave Anderson [d...@daveanderson.com] wrote: I've been looking at a bunch of notebook dmesgs (i386, single processor) recently and have noticed that the value reported for 'real mem' is almost always much lower than the amount of memory actually installed. A typical example is OpenBSD 5.0 (GENERIC) #39: Mon Aug 8 14:53:43 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 2900148224 (2765MB) spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 SO-DIMM spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600 SO-DIMM I understand that i386 cannot see more than 4GB due to architecture restrictions, but even allowing for that well over a gigabyte has vanished here. A quick look at the code that generates this number shows that it's skipping various areas reserved by the BIOS, etc., but the total amount being skipped seems absurd. Is there really supposed to be this much reserved space, or is something wrong? Thanks, Dave -- Dave Anderson d...@daveanderson.com -- the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
