Por que o Ubuntu não detecta toda a minha memória RAM em 64 bits? [duplicado]

Question

PROBLEMA IDENTIFICADO: bug do BIOS. Veja a saída do dmesg abaixo.

A pergunta é: como resolver isso? Mudança feita desde 2.6.32 introduziu isso. Existe algum patch que a Canonical ou os mantenedores do kernel podem fornecer para consertar isso? Para quem eu me refiro?

Obrigado a todos!

PERGUNTA ORIGINAL:

Eu acho que há um problema com o kernel 2.6.35 de 64 bits que vem com o Ubuntu 10.10. Eu tenho um Gigabtye GA-970A-UD3 com um processador AMD FX-8120, 16GB DDR3-1333, nVidia GTX550Ti e um SSD OCZ Agility 3 de 120GB.

Instalei o Ubuntu 10.10 nele para obter suporte a SSD TRIM com o kernel 2.6.35. No entanto, após a instalação bem-sucedida do SO, o Monitor do Sistema registra apenas 3,2 GB. Ele vê os 8 núcleos do FX-8120 e o uname -a reporta x86_64 . Além disso, dmidecode mostra os quatro bancos de memória sendo preenchidos. Suspeitando de memória, eu troquei o 16GB por 8GB de um fabricante diferente, mas ainda existe o mesmo problema. 10.10 com um kernel 2.6.35 não verá mais que 4GB em 64-bit.

Eu tenho uma instalação 10.04 LTS de 64 bits em um i7-960 com 24 GB de RAM e ele vê todos os 24 GB. Quando eu inicializo o 10.04 LTS de 64 bits na máquina FX-8120, ele vê todos os 16GB e 8 núcleos.

É evidente que algo mudou entre 2.6.32 e 2.6.35 para afetar o suporte de memória.

Estou atrás do suporte a TRIM do 2.6.35, mas não ao custo de perder 75% da minha RAM. Estou procurando alguma orientação ou sugestões. Um novo sinalizador de kernel é necessário ou preciso obter uma compilação personalizada de 2.6.33 em diante para resolver o problema de memória e suporte TRIM simultaneamente.

Qualquer ajuda apreciada!

ATUALIZAÇÃO: A versão do 10.04 LTS instalada é o que o site de download do Ubuntu fornece para a versão de 10.04 de 64 bits. Eu liguei o "Download de Atualizações" durante a instalação, então qualquer coisa que a 10.04 LTS faz atualmente em uma instalação limpa com aquela ISO é o que eu estou executando. Eu posso fornecer saídas para quaisquer comandos solicitados para determinar as construções / revisões exatas em que esta máquina está. Eu também vou testar o boot 10.10 no meu i7-960 para ver se ele relata 4GB contra 24GB. Isso eliminaria o suporte ao chipset como um problema em potencial, uma vez que cruzaria os limites da arquitetura e indicaria um problema no kernel.

UPDATE 2: É um bug da BIOS.

dmesg snippet de saída:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.35-22-generic (buildd@allspice) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 (Ubuntu 2.6.35-22.33-generic 2.6.35.4)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=9129347f-e2a2-4b97-965c-800823aaf090 ro quiet splash
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009a000 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cfda0000 (usable)
[    0.000000]  BIOS-e820: 00000000cfda0000 - 00000000cfdd1000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cfdd1000 - 00000000cfe00000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cfe00000 - 00000000cff00000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 000000042f000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x42f000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-C7FFF write-protect
[    0.000000]   C8000-FFFFF uncachable
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
[    0.000000]   2 base 0000C0000000 mask FFFFF0000000 write-back
[    0.000000]   3 base 0000CFE00000 mask FFFFFFE00000 uncachable
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] e820 update range: 00000000cfe00000 - 000000042f000000 (usable) ==> (reserved)
[    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13040MB of RAM.
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at /build/buildd/linux-2.6.35/arch/x86/kernel/cpu/mtrr/cleanup.c:971 mtrr_trim_uncached_memory+0x2d8/0x303()
[    0.000000] Hardware name: GA-970A-UD3
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.35-22-generic #33-Ubuntu
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8106077f>] warn_slowpath_common+0x7f/0xc0
[    0.000000]  [<ffffffff810607da>] warn_slowpath_null+0x1a/0x20
[    0.000000]  [<ffffffff81af7970>] mtrr_trim_uncached_memory+0x2d8/0x303
[    0.000000]  [<ffffffff81af2910>] setup_arch+0x422/0x79e
[    0.000000]  [<ffffffff815864c9>] ? printk+0x68/0x6f
[    0.000000]  [<ffffffff81aed9f3>] start_kernel+0xdd/0x390
[    0.000000]  [<ffffffff81aed341>] x86_64_start_reservations+0x12c/0x130
[    0.000000]  [<ffffffff81aed43f>] x86_64_start_kernel+0xfa/0x109
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] update e820 for mtrr

dmidecode -t memory:

# dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x0005, DMI type 5, 24 bytes
Memory Controller Information
    Error Detecting Method: 64-bit ECC
    Error Correcting Capabilities:
        None
    Supported Interleave: One-way Interleave
    Current Interleave: One-way Interleave
    Maximum Memory Module Size: 1024 MB
    Maximum Total Memory Size: 4096 MB
    Supported Speeds:
        70 ns
        60 ns
    Supported Memory Types:
        Standard
        EDO
    Memory Module Voltage: 3.3 V
    Associated Memory Slots: 4
        0x0006
        0x0007
        0x0008
        0x0009
    Enabled Error Correcting Capabilities:
        None

Handle 0x0006, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: A0
    Bank Connections: 1
    Current Speed: 53 ns
    Type: Other Unknown EDO
    Installed Size: 4096 MB (Double-bank Connection)
    Enabled Size: 4096 MB (Double-bank Connection)
    Error Status: OK

Handle 0x0007, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: A1
    Bank Connections: 2
    Current Speed: 53 ns
    Type: Other Unknown EDO
    Installed Size: 4096 MB (Double-bank Connection)
    Enabled Size: 4096 MB (Double-bank Connection)
    Error Status: OK

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: A2
    Bank Connections: 3
    Current Speed: 53 ns
    Type: Other Unknown EDO
    Installed Size: 4096 MB (Double-bank Connection)
    Enabled Size: 4096 MB (Double-bank Connection)
    Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: A3
    Bank Connections: 4
    Current Speed: 53 ns
    Type: Other Unknown EDO
    Installed Size: 4096 MB (Double-bank Connection)
    Enabled Size: 4096 MB (Double-bank Connection)
    Error Status: OK

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

Handle 0x002A, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0029
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: A0
    Bank Locator: Bank0/1
    Type: Unknown
    Type Detail: None
    Speed: 1333 MHz (0.8 ns)
    Manufacturer:  
    Serial Number:  
    Asset Tag:  
    Part Number:  

Handle 0x002B, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0029
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: A1
    Bank Locator: Bank2/3
    Type: Unknown
    Type Detail: None
    Speed: 1333 MHz (0.8 ns)
    Manufacturer:  
    Serial Number:  
    Asset Tag:  
    Part Number:  

Handle 0x002C, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0029
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: A2
    Bank Locator: Bank4/5
    Type: Unknown
    Type Detail: None
    Speed: 1333 MHz (0.8 ns)
    Manufacturer:  
    Serial Number:  
    Asset Tag:  
    Part Number:  

Handle 0x002D, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x0029
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: A3
    Bank Locator: Bank6/7
    Type: Unknown
    Type Detail: None
    Speed: 1333 MHz (0.8 ns)
    Manufacturer:  
    Serial Number:  
    Asset Tag:  
    Part Number:  

uname -a

Linux artemis 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux

    

Answer 1

O problema em questão com o suporte ao processador AMD FX é devido a mudanças no kernel do Linux, começando com 2.6.33. O kernel 2.6.32 que vem com o 10.04 funciona corretamente com o hardware ao ver toda a memória disponível.

Eu comecei com uma versão 10.04 LTS que está vendo 16GB de RAM. Então eu atualizei para um kernel 2.6.33 via kernel.ubuntu.com e a memória caiu para 3.2GB. relatórios de saída do dmesg:

WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13040MB of RAM

Seguido pelas informações de rastreio do kernel para a área exata do código-fonte do kernel que possui o problema.

Neste ponto, não importa mais se estou em 10.04 ou 10.10. Depois que a versão do kernel passa 2.6.32, esse problema se manifesta. Não é um problema com o processador FX. Até mesmo o kernel 2.6.32 reconhece corretamente com o número correto de núcleos. O BIOS da Gigabyte GA-970A-UD3 não tem uma opção para executar o remapeamento da memória, por isso provavelmente está sendo feito por padrão.

A inicialização do Ubuntu 11 em um kernel 3.0 faz com que a máquina congele na detecção de hardware. Eu ainda não tentei a versão alpha 12.04.

A solução lógica para permitir que kernels 2.6 rodem em hardware com bugs como minha placa-mãe é patch arch / x86 / kernel / cpu / mtrr / cleanup.c em kernels posteriores para usar o antigo código 2.6.32 que não executa a verificação MTRR. Pesquisas indicam que os MTRRs são componentes legados através do BIOS e parecem seguros para serem desativados.

Isso também permitirá que os usuários de hardware mais recente executem os sistemas mais antigos baseados em Linux 2.6 com drivers mais recentes e suportem SSDs corretamente.

Meu próximo passo é puxar para baixo os fontes para o kernel 2.6.33 que estou usando junto com o 2.6.32 e procurar executar o patch para ver o que acontece. Note que eu não sou um desenvolvedor de kernel e meu C está enferrujado, mas eu posso trabalhar bem o suficiente para tentar. Caso funcione, vou postar um patch para os mantenedores do kernel.