Also, ich bin absolut nicht sicher ob ich hier richtig liege:
(und mit dem vergelich den Pierre gespostet hat)
Das aus deinem iomem:
00100000-cff7ffff : System RAM
00200000-004c1564 : Kernel code
004c1565-005d3b2f : Kernel data
00633000-00721957 : Kernel bss
Der Kernel beginnt hier bei 00200000.
Das rührt IMHO her durch die Kernel-Config:
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
Bei meinem i686 ist in iomem:
00100000-4feeffff : System RAM
00100000-003709de : Kernel code
003709df-00445cdb : Kernel data
00495000-0056de4b : Kernel bss
Hier beginnt der kernel bei 00100000, da die i686-kernelconfig lautet:
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
Da Relocatable bei beiden nicht gesetzt ist heißt das IMHO das dieser Bereich nicht wieder
genutzt werden kann wenn er frei werden würde.
Es gab auch etliche Posts (lkml, redhat, etc) wo über die generelle Abschaffung dieser
festgelegte Speicheradresse diskustiert wurde.
Beschreibung (Auszug) zu CONFIG_PHYSICAL_START
So if you are using bzImage for capturing the crash dump, leave
- the value here unchanged to 0x200000 and set CONFIG_RELOCATABLE=y.
- Otherwise if you plan to use vmlinux for capturing the crash dump
- change this value to start of the reserved region (Typically 16MB
- 0x1000000). In other words, it can be set based on the "X" value as
- specified in the "crashkernel=YM at XM" command line boot parameter
- passed to the panic-ed kernel. Typically this parameter is set as
- crashkernel=64M at 16M. Please take a look at
- Documentation/kdump/kdump.txt for more details about crash dumps.
Ich bin mir nicht sicher, warum hier bei i686 die Adesse bei 0x1000000 steht und bei
x86_64 bei 0x2000000. Auch warum CONFIG_RELOCATABLE in dem Fall nicht auf y
steht.
Weiterhin bin ich mir auch nicht im klaren, ob das überhaupt am Problem etwas
ändern würde.
Rausfinden könntest du das nur indem du dir den Arch-Kernel evtl. mit diesem
angepassten Wert kompillierst und vergleichst (und schaust ob es noch stabil ist).
Zu den mtrr Werten bin ich mir auch nicht sicher:
Das mit den uncachable ist sicher teilweise ok (es gibt halt Speicherbereiche - ist ja
nicht nur RAM - die nicht cachable sind. Bei Pierre tauch ja sowas garnicht auf, bei
mir z.B.
eg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 256MB: write-back, count=1
reg02: base=0x4ff80000 (1279MB), size= 512KB: uncachable, count=1
(also 512KB)
Bei dir sind es ja wesentlich höhere Werte (MB-Bereiche). Allerdings könnten das natürlich
auch Controller-RAM, etc. sein da ja eigentlich dein RAM in reg02:
reg02: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
abgedeckt ist.
Was noch auffällt ist in dmesg:
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
Wegen sowas fragte ich auch nach dem Verhalten des Systems wenn du weniger RAM
angibst. Ich habe mittlerweile von etlichen Boards (v.a. Gigabyte) gelesen, bei denen
ein fehlerhaftes BIOS dafür sorgte das mit 8GB das System lahm wurde und gerade
die mtrr-Ausgabe "fehler" und "Unstimmigkeiten" zeigte. Nach einem BIOS-Upgrade
wurde das dann besser.
Deshalb würde ich auch mal schauen, welche BIOS-Version du hast und was Asus
evtl. anbietet.
Wie gesagt: ich stochere hier aber mehr als das ich mir sicher bin.
Zur Windows-Anzeige nochmal: Das ist sicher kein Gradmesser was
angezeigt wird.
Auch der Windows-Kernel kann das intern ganz anders handhaben.