64-Bit-Linux erkennt meinen RAM zwischen 3 und 32 GB nicht

8

Meine Probleme wurden durch ein fehlerhaftes Speichermodul und möglicherweise eine defekte Kernel-Binärdatei verursacht.


Ich habe gerade meinen PC mit brandneuer Hardware gebootet. Ich habe Debian 6.0 AMD64 schon einmal ausgeführt und dort keine Änderung vorgenommen (im wahrsten Sinne des Wortes; ich habe nur die Festplatten vom alten Motherboard getrennt und sie wieder mit dem neuen verbunden), aber etwas Merkwürdiges gefunden:

  • Ich habe 4 x 8 GB RAM physisch installiert
  • Das UEFI / BIOS-Setup meldet 16383 MB RAM
  • Linux free -mmeldet 2985 MB RAM

2985 MB scheinen zu nahe an der magischen 3-GB-Marke zu liegen, als dass es sich um einen reinen Zufall handeln könnte, sondern um uname -rDrucke 2.6.32-5-amd64. eindeutig ein 64-Bit-Kernel, der alles ist, was jemals auf dem von mir verwendeten Systemlaufwerk installiert wurde. Das neue Motherboard ist ein Asus M5A97 Pro mit vier DDR3-Steckplätzen, die angeblich 8-GB-Module unterstützen. Die Speichermodule selbst sind identisch, vier Corsair XMS3 PC12800 8 GB, zusammen gekauft.

Ich habe mich nicht im Detail im UEFI-Setup umgesehen, sondern es durchsucht und nichts gesehen, was geändert werden müsste, um große Mengen an RAM zu aktivieren.

Bearbeiten: Weitere Bestätigung, dass ich wirklich 64-Bit verwende:

# file `which free`
/usr/bin/free: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
#

Was ist damit los und was kann ich dagegen tun?

Bearbeiten Sie 2: dmesg, dmidecode und meminfo, wie gewünscht. Ich habe momentan keinen physischen Zugriff auf das System, muss also bis heute Abend warten, um einige Module herauszuholen und zu sehen, was das bewirkt. (Beachten Sie, dass dmidecode 3 x 8 GB plus einen leeren DIMM-Steckplatz meldet. Beachten Sie auch die MTRR-Nichtübereinstimmungsnachricht vom Kernel, die zu einem Verlust von 13 GB führt, was zumindest dem entspricht, was das Motherboard selbst meldet.)

# dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.7 present.

Handle 0x0026, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Multi-bit ECC
        Maximum Capacity: 32 GB
        Error Information Handle: Not Provided
        Number Of Devices: 4

Handle 0x0028, DMI type 17, 34 bytes
Memory Device
        Array Handle: 0x0026
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8192 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM0
        Bank Locator: BANK0
        Type: <OUT OF SPEC>
        Type Detail: Synchronous
        Speed: 1333 MHz (0.8 ns)
        Manufacturer: Manufacturer0
        Serial Number: SerNum0
        Asset Tag: AssetTagNum0
        Part Number: Array1_PartNumber0

Handle 0x002A, DMI type 17, 34 bytes
Memory Device
        Array Handle: 0x0026
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8192 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM1
        Bank Locator: BANK1
        Type: <OUT OF SPEC>
        Type Detail: Synchronous
        Speed: 1333 MHz (0.8 ns)
        Manufacturer: Manufacturer1
        Serial Number: SerNum1
        Asset Tag: AssetTagNum1
        Part Number: Array1_PartNumber1

Handle 0x002C, DMI type 17, 34 bytes
Memory Device
        Array Handle: 0x0026
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 8192 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM2
        Bank Locator: BANK2
        Type: <OUT OF SPEC>
        Type Detail: Synchronous
        Speed: 1333 MHz (0.8 ns)
        Manufacturer: Manufacturer2
        Serial Number: SerNum2
        Asset Tag: AssetTagNum2
        Part Number: Array1_PartNumber2

Handle 0x002E, DMI type 17, 34 bytes
Memory Device
        Array Handle: 0x0026
        Error Information Handle: Not Provided
        Total Width: Unknown
        Data Width: 64 bits
        Size: No Module Installed
        Form Factor: DIMM
        Set: None
        Locator: DIMM3
        Bank Locator: BANK3
        Type: Unknown
        Type Detail: Synchronous
        Speed: Unknown
        Manufacturer: Manufacturer3
        Serial Number: SerNum3
        Asset Tag: AssetTagNum3
        Part Number: Array1_PartNumber3
#
======================================================================
# cat /proc/meminfo
MemTotal:        3056820 kB
MemFree:         1470820 kB
Buffers:          390204 kB
Cached:           194660 kB
SwapCached:            0 kB
Active:           488024 kB
Inactive:         419096 kB
Active(anon):     231112 kB
Inactive(anon):    96660 kB
Active(file):     256912 kB
Inactive(file):   322436 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:        322320 kB
Mapped:            33012 kB
Shmem:              5472 kB
Slab:             613952 kB
SReclaimable:     597404 kB
SUnreclaim:        16548 kB
KernelStack:        2384 kB
PageTables:        19472 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1528408 kB
Committed_AS:     621464 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      294484 kB
VmallocChunk:   34359429080 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        9216 kB
DirectMap2M:     2054144 kB
DirectMap1G:     1048576 kB
#
======================================================================
# dmesg | grep -i memory
[    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM.
[    0.000000] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_amd64_none/arch/x86/kernel/cpu/mtrr/cleanup.c:1092 mtrr_trim_uncached_memory+0x2e6/0x311()
[    0.000000]  [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[    0.000000]  [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[    0.000000]  [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] init_memory_mapping: 0000000000000000-00000000bdf00000
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000bd94d000 - 00000000bd99c000
[    0.000000] PM: Registered nosave memory: 00000000bd99c000 - 00000000bd9a6000
[    0.000000] PM: Registered nosave memory: 00000000bd9a6000 - 00000000bdade000
[    0.000000] PM: Registered nosave memory: 00000000bdade000 - 00000000bdaef000
[    0.000000] PM: Registered nosave memory: 00000000bdaef000 - 00000000bdb02000
[    0.000000] PM: Registered nosave memory: 00000000bdb02000 - 00000000bdb04000
[    0.000000] PM: Registered nosave memory: 00000000bdb04000 - 00000000bdb0d000
[    0.000000] PM: Registered nosave memory: 00000000bdb0d000 - 00000000bdb13000
[    0.000000] PM: Registered nosave memory: 00000000bdb13000 - 00000000bdb75000
[    0.000000] PM: Registered nosave memory: 00000000bdb75000 - 00000000bdd78000
[    0.000000] Memory: 3046732k/3111936k available (3075k kernel code, 4728k absent, 60476k reserved, 1879k data, 584k init)
[    1.636730] Freeing initrd memory: 9501k freed
[    1.647370] Freeing unused kernel memory: 584k freed
[    4.876602] [TTM] Zone  kernel: Available graphics memory: 1528410 kiB.
[    4.876615] [drm] radeon: 256M of VRAM memory ready
[    4.876617] [drm] radeon: 512M of GTT memory ready.
[   25.571018] VBoxDrv: dbg - g_abExecMemory=ffffffffa051d6c0
#

Grepping für e820 zeigt eine Reihe von Bereichen, die mit abrunden e820 update range: 00000000bdf00000 - 000000043f000000 (usable) ==> (reserved). 43f000000 ist 16 GiB, bdf00000 ist 3039 MiB. Ich nicht sehen , dass sein zufällig.

# dmesg | grep -i e820
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009d800 (usable)
[    0.000000]  BIOS-e820: 000000000009d800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bd94d000 (usable)
[    0.000000]  BIOS-e820: 00000000bd94d000 - 00000000bd99c000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bd99c000 - 00000000bd9a6000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bd9a6000 - 00000000bdade000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdade000 - 00000000bdaef000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bdaef000 - 00000000bdb02000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdb02000 - 00000000bdb04000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bdb04000 - 00000000bdb0d000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdb0d000 - 00000000bdb13000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bdb13000 - 00000000bdb75000 (reserved)
[    0.000000]  BIOS-e820: 00000000bdb75000 - 00000000bdd78000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bdd78000 - 00000000bdf00000 (usable)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec10000 - 00000000fec11000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec20000 - 00000000fec21000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed61000 - 00000000fed71000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed80000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000fef00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100001000 - 000000043f000000 (usable)
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 update range: 00000000bdf00000 - 000000043f000000 (usable) ==> (reserved)
[    0.000000] update e820 for mtrr
# 

EDIT 3/4 - Teilerfolg:

  • Ein Upgrade des UEFI-BIOS von der Version 0705 x64 08/23/2011auf 1007 02/10/2012hat nicht geholfen: Es blieb genau das gleiche Problem.
  • Durch das Entfernen eines DIMM-Moduls (ich hatte die glückliche Vermutung, welcher Steckplatz # 4 war: der am weitesten von der CPU entfernte) konnte das BIOS die verbleibenden 24 GB erkennen und verwenden, obwohl eine Drei-DIMM-Konfiguration laut dem nicht "empfohlen" wird Diagramm in der Bedienungsanleitung. Wenn Sie eines der verbleibenden DIMMs in Steckplatz 4 einsetzen, kann es weiterhin verwendet werden, sodass der Steckplatz in Ordnung ist. Durch das erneute Einsetzen des "ursprünglichen" DIMM in diesen Steckplatz bin ich wieder an meinem Ausgangspunkt angelangt.
  • Das Booten von der Debian 6.0.3 AMD64-Installations-CD in eine Rettungsumgebung und das Überprüfen der dmesgAusgabe zeigt keine ähnlichen MTRR-Fehler . In dieser Umgebung mit 3 x 8 GB werden 24 GB (plus oder minus Epsilon mal pi oder so; ich habe nicht genau gerechnet) als verwendbar angezeigt free.
  • Das Aktualisieren / Neuinstallieren des Kernels (es war ein kleines Upgrade verfügbar) scheint auch die MTRR-Probleme behoben zu haben. dmesgmeldet jetzt insgesamt 26198016 KB und keine MTRR-Fehler, was mit dem übereinstimmt, was ich bei 3 x 8 GB erwartet hätte. free -mJetzt werden 24114 MB Gesamtspeicher gemeldet, was mir ehrlich gesagt nahe genug ist.

Dies riecht nach einem Barfed-DIMM und einem Kernel, der aus irgendeinem Grund beschädigt wurde. Letzteres ist möglicherweise während des Stromausfalls passiert (obwohl ich sagen muss, dass der Kernel auf seltsame Weise kaputt geht!). Das nicht funktionierende DIMM wird zum Reseller zurückkehren, sobald ich mit ihm spreche (hoffentlich morgen).

(hoffentlich) FINAL EDIT

Ich habe eines der beiden DIMM-Paare per RMA erhalten, es wurde vom Wiederverkäufer als beschädigt akzeptiert und sie haben mir ein neues Paar geschickt, das anscheinend einwandfrei funktioniert. Ich bin jetzt also im Grunde dort, wo ich es vor fast einem Monat ursprünglich beabsichtigt hatte (obwohl ein großer Teil dieser Zeit nicht wirklich auf den Reseller zurückzuführen war), mit 32 GB RAM nutzbar; free -mmeldet 32194 MB Gesamtspeicher, und der Kernel meldet 34586624kRAM bei der Initialisierung, die beide meinen Erwartungen entsprechen.

ein CVn
quelle
2
Nach Ihrer ersten Aussage klingt es so, als hätten Sie Festplatten mit einem installierten Betriebssystem auf eine neue Systemplatine verschoben? Ein wirklich guter Test wäre, eine Live-Distribution herunterzuladen und darin zu booten. Slax, DSL, Ubuntu oder was auch immer. Wenn dadurch die richtige RAM-Größe erkannt wird, treten wahrscheinlich HAL / udev-Probleme auf. An diesem Punkt sparen Sie viel mehr Zeit beim Sichern und Neuinstallieren als beim Versuch, das Problem zu beheben. Es sei denn, Sie sind ein Geek wie ich und möchten Stunden oder Tage damit
verschwenden
2
Bitte posten Sie die Ausgabe von dmidecode --type memoryund die ersten hundert Zeilen der Ausgabe von dmesg(stellen Sie sicher, dass Sie alles einschließen, was so aussieht, als ob es sich um Speicher handelt).
Gilles 'SO - hör auf böse zu sein'
1
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM.Nun, da fehlt dein 13G.
Mat
1
@Mat, nicht das andere fehlende 16G. Diese werden sich wahrscheinlich etwas mehr umsehen müssen.
Ein Lebenslauf
1
Mich würde interessieren, was ein Debian-Live-Boot (/ ubuntu, da es das nächstgelegene ist) sagen würde, da damit leicht zwischen Problemen mit Ihrer Hardware und Problemen mit Ihrer Konfiguration unterschieden werden kann.
dtech

Antworten:

14

Erstens, wenn Ihr BIOS / UEFI Ihren RAM nicht richtig erkennt, wird Ihr Betriebssystem nicht besser. Sie müssen nicht weiter gehen, wenn Ihr BIOS falsche Informationen zu Ihrem Setup anzeigt.

=> Sie haben wahrscheinlich zumindest ein Hardwareproblem.

EDIT : Aus Ihrem dmesg | grep memory, es scheint, dass Sie tatsächlich ein Hardwareproblem haben, das sich in Ihrem eingebetteten BIOS befindet. Zumindest hat Linux es erkannt und warnt Sie davor : WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM. Es scheint auch, dass eines Ihrer 4-RAM-Module falsch erkannt oder eingesetzt wurde.

Sie können es entweder Ihrem Hersteller melden, Ihr BIOS aktualisieren und Ihr Motherboard ändern. Es besteht die Möglichkeit, dass Sie mit weniger RAM nicht auf diesen Fehler stoßen.

Als Randnotiz können Sie diesem berühmten Zitat von Linus Torvalds über BIOS-Hersteller zustimmen :

BIOS-Autoren sind ausnahmslos völlig inkompetente, rissabhängige Affen

Zweitens, wenn Ihr BIOS mit dem, was Sie wirklich auf Ihrem Motherboard haben, in Ordnung ist, können Sie einen Blick auf Linux werfen /proc/meminfo. Es ist oft sehr klar, was Ihr Linux-System mit Ihrem Speicher weiß und macht. Folgendes habe ich auf meinem 64-Bit / 8-GB-RAM:

$ cat /proc/meminfo 
MemTotal:        8175652 kB
MemFree:         5476336 kB
Buffers:           63924 kB
Cached:          1943460 kB
SwapCached:            0 kB
[...]

Informationen zum Startvorgang und zu den Funktionen, die vom Linux-Kernel verwendet / freigegeben werden, finden Sie unter dmesg:

$ dmesg | grep Memory
[    0.000000] Memory: 8157672k/8904704k available (6138k kernel code, 534168k absent, 212864k reserved, 6896k data, 988k init)

BEARBEITEN : Wie Gilles sagte, dmidecode --type memorykönnen Sie mit Details zu Ihrer Hardwarekonfiguration haben. Für ein 4x2Gb-System sieht es so aus:

$ sudo dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.6 present.

Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 32 GB
    Error Information Handle: Not Provided
    Number Of Devices: 4

Handle 0x0022, DMI type 17, 28 bytes
Memory Device
    Array Handle: 0x0020
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 2048 MB
    [...]
[This block is repeated for each module]
Coren
quelle
5

Suchen Sie in / var / log / dmesg nach Speicherzuordnung (grep für 'e820') und zählen Sie, wie viele Speicher dort als verwendbar gemeldet werden. Dies sagt das BIOS dem geladenen Betriebssystem für den Speicher.

(Dies ist nur für einen Boot im alten Stil korrekt. Ich weiß nicht, wie der Speicher gemeldet wird, wenn ein Boot im EFI-Stil verwendet wird, aber ich denke, es gibt einen ähnlichen Bericht.)

Das Melden von 16 GB per BIOS während der Installation von 32 GB bedeutet außerdem eine gewisse Verrücktheit bei der Speichereinrichtung. Versuchen Sie, den installierten Speicher auf 4 oder 8 GB zu reduzieren und die Effekte zu vergleichen.

Netch
quelle
Siehe meine Bearbeitung für e820-Daten. Das physische Entfernen von Speichermodulen, um zu sehen, was dies bewirkt, muss bis heute Abend warten. Die einzigen DDR3-Module, die ich habe, sind jeweils 8 GB.
Ein Lebenslauf
Nun, das scheint jetzt genug zu sein - Sie haben sowohl Hardware als auch Software, die richtig funktionieren. Die letzte Aktion besteht darin, das richtige Speichermodul zu installieren, um es zu füllen und den Zweikanalbetrieb zu gewährleisten. Herzliche Glückwünsche.
Netch
0

Viele ältere AMD-Karten haben möglicherweise 4 Steckplätze, aber wenn Sie den letzten Steckplatz füllen, fragen Sie nach Problemen. Es ist ein Chipsatz-Problem, das nicht behoben werden kann.

Rick
quelle
Ich würde das Asus M5A97 Pro nicht als "älteres" Motherboard betrachten (ich kenne das genaue Herstellungsdatum nicht, aber es basiert auf dem AMD 970-Chipsatz, und Wikipedia legt die 900er-Serie auf ein Erscheinungsdatum im Juni 2011, weniger als ein Jahr zuvor war diese Frage im März 2012 aktuell). Und das Ausführen von den Installationsmedien zeigte aus Sicht des Betriebssystems ein ganz anderes Bild der Realität. Und die Probleme wurden letztendlich gelöst, indem das fehlerhafte Speichermodul durch ein funktionierendes ersetzt und der Kernel neu installiert wurde (wie ganz oben auf der Frage steht).
Ein Lebenslauf vom