Sobre placa-mãe e memória RAM antigas

Olá!

Estou usando um hardware antigo para aprimorar minha experiência com o Linux. A minha placa mãe, nesse caso que relato, é uma Asus M5A78L-M LX/BR. Bem antiguinha, mesmo! O último uso em produção já se passou há bastante tempo, como Windows 10. Recentemente, resolvi enfiar um Linux nesse trem!

Uma das coisas que nunca entendi nessa placa foi coisa dela não aceitar 16Gb de RAM, embora isso nunca tenha sido declarado. Vai Windows, vai Linux, os dois slots preenchidos com pentes de 8Gb DDR3 e o S.O. sempre dizendo que eu só tinha… 8Gb de RAM utilizável. Placa mané!

Pois bem, eu não desisti. Só podia ser coisa de software, já que, mesmo trabalhando efetivamente com 8Gb de RAM, o dmidecode mostrava lá os dois pentes de 8Gb. Hoje as coisas mudaram e eu estou muito feliz!

Compilei o kernel 6.14.2 despretenciosamente. Depois que o fiz, passei um “pente fino” nas configurações, coisa que sempre faço, mudando o kernel ou não. Vejam só:

marcio@deskium-Debian:~$ free -h
               total       usada       livre    compart.  buff/cache  disponível
Mem.:           15Gi       4,9Gi       6,2Gi       111Mi       4,9Gi        10Gi
Swap:           15Gi          0B        15Gi

Cara, feliz demais aqui! Um kernelzinho abençoado esse que compilei!

3 curtidas

Que bacana! Geralmente essas limitações tem ligação com a BIOS e com pentes de diferentes tipos. Antigamente tinha uma questão de o pente ter os semicondutores só de um lado, ou dos dois lados.

Teoricamente o sistema operacional deveria receber apenas a informação dos endereços de ram utilizáveis, não necessariamente entrando em detalhes sobre os tipos de circuitos integrados usados. Porém um teste de memória na inicialização poderia encontrar algum erro e desabilitar o segundo pente de memória que estaria numa faixa “não convencional” de endereços.

Se você ainda estiver com o kernel anterior instalado, seria interessante confirmar que usar o kernel 6.14 conseguiu resolver, enquanto na versão anterior continua com problema. Se for esse o cenário, é possível que algum bug na BIOS dessa placa não deixasse o sistema operacional remapear alguns endereços de memória, mas que nessa versão houve algum contorno nessa situação, talvez usando essa faixa “não convencional” (tô na suposição).

Porém eu diria que a fonte do problema seria bug na BIOS desse modelo em específico. No site do fabricante para esse modelo (M5A78L-M LX/BR - Suporte) há indicação de correção na versão 0502 de 2011 e ainda há algumas atualizações até 2017. Vale verificar qual é a atual versão da BIOS instalada, e se for anterior a essa 0502 é possível que o problema já tivesse sido resolvido pelo fabricantes muitos anos atrás.

3 curtidas

DDR3 e Antigo, duas frases bem paralelas…
Se o generic tem suporte a hardware 486 do seculo passado imagina se seu hardware não vai ter kkkkkk
Comunidade nisso tem boa vontade

2 curtidas

Boa noite rapaz.
A minha é uma Asus M5A78L-M PLUS/USB3 e ela tá a todo vapor nas minhas distros com 32GB ddr3 1600

2 curtidas

Olá!

Outro dia eu comentei aqui, em algum lugar (sei lá onde rsrsrsrsrs!) que tenho uma placa mãe antigona, uma Asus ASUS M5A78L-M LX/BR. Resolvi trabalhar nela com o Linux Debian Trixie (“testing” do Debian 13). O problema: a placa informa a capacidade máxima de 8Gb de RAM para trabalho. A realidade:

marcio@deskium-Debian:~$ sudo dmidecode -t memory
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.

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

Handle 0x002E, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK0
	Type: Other
	Type Detail: Synchronous
	Speed: 667 MT/s
	Manufacturer: Manufacturer0
	Serial Number: SerNum0
	Asset Tag: AssetTagNum0
	Part Number: PartNum0

Handle 0x0030, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x002C
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: DIMM1
	Bank Locator: BANK1
	Type: Other
	Type Detail: Synchronous
	Speed: 667 MT/s
	Manufacturer: Manufacturer1
	Serial Number: SerNum1
	Asset Tag: AssetTagNum1
	Part Number: PartNum1

É isso aí! Eu tenho dois pentes de 8Gb DDR3 nessa placa. Como, raios, o dmidecode reconhece esses 16Gb de RAM mas a porcaria da placa não me deixa trabalhar com todos eles, apenas com 8Gb?

Brincando com a compilação do kernel, eu fiz funcionar o 6.14.2. “Magicamente” o sistema passou a reconhecer os meus 16Gb de RAM:

marcio@deskium-Debian:~$ free -h
               total       usada       livre    compart.  buff/cache  disponível
Mem.:           15Gi       2,5Gi        10Gi        50Mi       2,5Gi        13Gi
Swap:           15Gi          0B        15Gi

Magicamente uma ova!!! Não me conformei com uma explicação tão boba de que de um kernel para o outro tudo pudesse ser resolvido. Aqui vai, então, o que descobri na marra e que pode ajudar alguém de vocês.

Existe uma “flag” que se instrui no arquivo “.config” no momento da compilação do kernel que permite o suporte a mais memória RAM, mesmo quando a BIOS (ou a DMI via dmidecode) relata um limite inferior. Apenas acrescente no final do seu .config:

CONFIG_HIGHMEM64G=y

Eu sei que é uma bela bostinha, mas imaginem minha felicidade depois de conseguir trabalhar com meus 16Gb de RAM quando pensava que a bostinha da placa só podia me entregar 8Gb…

1 curtida

Realmente parece ser uma limitação da BIOS, pois essa informação de máximo possível de 8G vem de lá. Usando a CONFIG_HIGHMEM64G (Select this if you have a 32-bit processor and more than 4 gigabytes of physical RAM) habilita extensões (PAE - physical address extension) para utilizar memória acima do reportado pela BIOS.

Essa opção não é habilitada por padrão nas distribuições 64-bits pois não é necessária. Então pra corrigir um bug da bios, habilitar essa extensão que seria exclusiva de sistemas 32-bits acabou “dando um jeito”.

O efeito colateral é que, toda vez que quiser atualizar o kernel, precisará compilá-lo, pois essa opção é desabilitada nas distribuições e não é possível setá-la em tempo de execução, nem mesmo por parâmetro do kernel na inicialização.

2 curtidas

Poderia só ver qual é a versão da bios da sua placa? Veja com
sudo dmidecode -t bios | grep Version

Talvez isso não me incomode tanto. Eu acabo me adiantando às liberações oficiais, sempre.d

Sim, é um bug dessa placa-mãe.

Essa aqui:

marcio@deskium-Debian:~$ sudo dmidecode -t bios

dmidecode 3.6

Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 1201
Release Date: 03/04/2017
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 2 MB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 8.15

Handle 0x002A, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Abbreviated
Installable Languages: 1
en|US|iso8859-1
Currently Installed Language: en|US|iso8859-1

1 curtida

A última BIOS desse hardware é de 2017. É exatamente a que está instalada nesse PC.

Cara! Me empresta umas RAMS aí! Kkkkkkk

1 curtida

Pois é… A gente acaba se sentindo antigo porque o Windows sempre exige mais e mais e mais hardware. Vide a questão do TPM 2… O Linux… Ah, o Linux! É mesmo um outro mundo!

1 curtida

Na minha placa fiz a última instalação de atualização da bios que melhorou o desempenho do meu processador FX 8350


Essa atualização veio na hora certa, ela melhorou e muito os FX

Outra coisa rapaz, a sua placa e a minha não são tão antigas assim, elas tem muito carvão para queimar, experimente um dia colocar um FX e depois você me conta sua experiência.

2 curtidas

A minha tem um FX-8320E.

Essa versão de BIOS aí, 2101, de 2015… Sabe as diferenças para a 1201, de 2017?

Ah! Já descobri aqui. São versões que não competem entre si, porque a 2101 não serve na minha, nem a 1201 serve na sua. Beleza.

Agora é abrir um arquivo, colocar a lista de comando da compilação dentro em sequencia, assim vc automatiza as próximas compilações.
Vc pode pedir uma IA para te ajudar com isso.

Não duvido nada que seja bug na BIOs já que essas placas M5A78L da Asus são antigos projetos da M4A78L só que com chipset 760G cambiarrado da AMD para suportar os processadores FXs.

1 curtida

Sei que talvez essa placa pode não ser das melhores daquela epoca, ela não chega perto das 990FX que eram as mais tops naquele tempo mas ela cumpre as suas funções. Antigamente eu tinha a GA-78LMT-USB3 (rev. 6.0) da gigabyte que eu achava ser a melhor placa-mãe, me enganei até conhecer a M5A78L-M PLUS/USB3 que muitos falavam bem dela exceto em processadores FX 9xxx que não tem suporte.
Bom eu não sei vocês mas essa placa para mim é muito boa comprada em 2016 e escrevendo no diolinux aqui nesse tópico em 2025 nela, a cada seis meses faço manutenção e troca da pasta do processador.
Ela não vai durar para sempre, isso é um fato.
Outra coisa que as vezes fico irado com ela é que ela roda DDR3 2000 OC e minhas DDR3 são só 1600 32GB