Eu costumava escrever BIOSes para ganhar a vida e ainda estou envolvida nesse negócio, mas não consigo fazer muita codificação interessante.
Respondendo a resposta: por que eu iria querer comprar uma placa-mãe cara com capacidade limitada de expansão PCI-e para uma estação de trabalho? Quando melhor hardware está disponível muito mais barato? Eu acho que a resposta é óbvia. É para mim. Eu quero o melhor hardware para o meu desenvolvimento de software. E os benefícios da placa do servidor (um iBMC e suporte para gerenciamento remoto) não parecem valer muito para mim nas minhas circunstâncias.
No entanto, sei que 16 GB de memória não-ECC (minha configuração de destino) vai gerar pânicos e setores corrompidos em meus discos rígidos com bastante regularidade. Números como uma falha de memória a cada poucos dias parecem bastante comuns em artigos na web que discutem sistemas com essa quantidade de RAM.
Com 16 GB de memória não-ECC nesta placa-mãe, estou vendo de 2 a 3 falhas por semana executando um diagnóstico de memória de estoque (não consegui testar a configuração de ECC, é claro, mas esperaria a falha probabilidade de cair para praticamente 0 se eu exigisse que 2 dessas 3 falhas ocorressem na mesma palavra de 64 bits).
Isso parece muito bem o que eu devo esperar, e é um problema o suficiente para mim que estou disposto a colocar algum esforço de codificação para eliminar o problema.
Eu também não quero apenas voar e fazer um hack sozinho se alguém já tiver feito alguma investigação da situação. Infelizmente, não conheço pessoas suficientes que hackearam BIOS para ter conexões pessoais. Assim, a questão.
Mas se eu for o único a olhar para o problema, estou um pouco surpreso, mas não me importo de aprofundar o hacking de um BIOS. Pode ou não valer a pena.
É por isso que coloco a questão em uma área de perguntas de programação, não em uma área administrativa. Isso requer alterar o código do BIOS (eu ficaria muito surpreso se não, francamente).
Estou bastante confiante de que o hardware do sistema (com a possível exceção de falta de 8 ou 16 fios para os 8 bits de paridade) é capaz de rodar em modo ECC completo - o processador inclui um controlador de memória compatível com ECC, os DIMMs são sem buffer DIMMs ECC com os mesmos requisitos elétricos que os DIMMs não-ECC sem buffer têm, portanto, o único recurso da placa-mãe envolvido é o conjunto de fios e componentes passivos que conectam os dois.E em resposta ao comentário de que 85% das placas de consumo não conseguirão inicializar com o ECC: minha experiência está no mesmo parque. Sem modificar o conteúdo do EEPROM do SPD nos DIMMs, a placa do consumidor EVERY que inicialize não inicializa com DIMMs ECC instalados (todos eram placas DDR e DDR2, não DDR3, Apesar). No entanto, com DIMMs ECC hackeados, todos eles foram inicializados com sucesso e os que executaram diags de memória foram executados por dias sem erros. Portanto, a falha na inicialização é uma decisão tomada pelo firmware / BIOS da placa-mãe ou qualquer outra coisa que leia o conteúdo do EEPROM do SPD.
WRT a nota sobre a seqüência de falhas fazendo sentido: o que me incomoda é que eu vejo nenhuma indicação de que o BIOS está seguindo essa seqüência. Parece que está testando validamente DIMMs ECC instalados primeiro (já que não vejo nenhum código PORT80 exibido no caso dos DIMMs ECC instalados de forma válida), depois faz algumas outras coisas (vários códigos PORT80) e finalmente informa que os DIMMs ECC instalados inválidos não são instalado nos slots corretos.
Na verdade, acho isso promissor, pois acho que pode haver um teste explícito para DIMMs ECC executados no início do POST (possivelmente para evitar que o sistema seja executado com um processador Xeon e DIMMs ECC) .