Problemas com o adaptador de rede I219 e em 7.6.2

0

Acabei de instalar o FreeBSD (11.0-RELEASE-p1) em um sistema com o adaptador de rede Intel I219-V. Esta versão do FreeBSD tem em v7.6.1, que (eu acredito ... talvez seja apenas o erro de soma de verificação EEPROM? Leia em ...) não suporta este chipset de rede, então eu procurei a versão atualizada, v7.6.2 , do site da Intel .

Seguindo o leia-me, instalei assim:

  1. Descompactar / descompactar
  2. make
  3. make install
  4. Adicione if_em_load="YES" ao /boot/loader.conf
  5. Adicione ifconfig_em0="DHCP" ao /etc/rc.conf

Após a reinicialização, ainda recebo as seguintes mensagens em dmesg.boot :

module_register: cannot register pci/em from kernel; already loaded from if_em.ko
Module pci/em failed to register: 17
...
em0: <Intel (R) PRO/1000 Network Connection 7.6.1-k> mem 0xdf300000-0xdf31ffff irq 16 at device 31.6 on pci0
em0: Using an MSI interrupt
em0: The EEPROM Checksum Is Not Valid
device_attach: em0 attach returned 5

E o adaptador não é reconhecido pelo sistema.

Há duas coisas a notar aqui - a soma de verificação incorreta, à qual retornarei mais tarde, e o fato de que a v.7.6.1 está carregando, mesmo que eu tenha acabado de instalar a v7.6.2!

Eu tentei descobrir onde cada versão está vivendo:

$ strings /boot/kernel/if_em.ko
...
7.6.1-k
...
$ strings /boot/modules/if_em.ko
...
7.6.2
...

Portanto, o if_em_load="YES" está carregando o driver antigo encontrado em / boot / kernel. Eu suponho que isso não seja surpreendente, já que man kldload diz que parece lá, mas /boot/defaults/loader.conf contém module_path="/boot/modules" .

O carregamento manual da versão v7.6.2 via kldload /boot/modules/if_em.ko fornece esta saída:

em0: <Intel (R) PRO/1000 Network Connection 7.6.1-k> mem 0xdf300000-0xdf31ffff irq 16 at device 31.6 on pci0
em0: Using an MSI interrupt
em0: The EEPROM Checksum Is Not Valid
device_attach: em0 attach returned 5
em0: <Intel (R) PRO/1000 Network Connection 7.6.2> mem 0xdf300000-0xdf31ffff irq 16 at device 31.6 on pci0
em0: Using an MSI interrupt
em0: The EEPROM Checksum Is Not Valid
device_attach: em0 attach returned 5

Portanto, ainda tendo o problema de Checksum da EEPROM, mas outra pergunta é por que o kldload tenta carregar a v7.6.1 antes da v7.6.2, que é o arquivo para o qual ela está explicitamente apontada?

Por fim, decidi ver o que acontece se ignorar a verificação de soma de verificação, que exigia a correção de if_em.c e if_lem.c , os dois locais em que a string "A soma de verificação EEPROM não é válida" existe no código do driver. p>

Como assim

--- if_em.c 2017-05-16 01:44:07.189792000 -0700
+++ if_em_patch.c   2017-05-16 01:44:28.885779000 -0700
@@ -730,10 +730,10 @@
        ** if it fails a second time its a real issue.
        */
        if (e1000_validate_nvm_checksum(hw) < 0) {
-           device_printf(dev,
+           /*device_printf(dev,
                "The EEPROM Checksum Is Not Valid\n");
            error = EIO;
-           goto err_late;
+           goto err_late;*/
        }
    }

e assim

--- if_lem.c    2017-05-16 01:39:27.605399000 -0700
+++ if_lem_patch.c  2017-05-16 01:44:47.661294000 -0700
@@ -641,10 +641,10 @@
        ** if it fails a second time its a real issue.
        */
        if (e1000_validate_nvm_checksum(&adapter->hw) < 0) {
-           device_printf(dev,
+           /*device_printf(dev,
                "The EEPROM Checksum Is Not Valid\n");
            error = EIO;
-           goto err_hw_init;
+           goto err_hw_init;*/
        }
    }

Agora, um make; make install; restart ainda me fornece a v7.6.1 no dmesg.boot, mas a execução de kldunload if_em; kldload /boot/modules/if_em.ko fornece a saída como:

em0: <Intel (R) PRO/1000 Network Connection 7.6.1-k> mem 0xdf300000-0xdf31ffff irq 16 at device 31.6 on pci0
em0: Using an MSI interrupt
em0: The EEPROM Checksum Is Not Valid
device_attach: em0 attach returned 5
em0: <Intel (R) PRO/1000 Network Connection 7.6.2> mem 0xdf300000-0xdf31ffff irq 16 at device 31.6 on pci0
em0: Using an MSI interrupt
em0: Ethernet address: xx:xx:xx:xx:xx:xx

Funciona! E eu posso obter um IP via dhclient em0 e ping 8.8.8.8 vai bem.

Então, aqui estão minhas perguntas:

  1. Por que minha soma de verificação da EEPROM está errada? Eu não fiz nada que pudesse mexer com o firmware ou o que quer que seja. O que posso fazer para corrigir isso (que não é precedido por um aviso à la "isso não deve funcionar para adaptadores integrados", como todas as respostas que encontrei - por exemplo, este )?
  2. Por que o kernel ainda está carregando a v7.6.1 quando eu digo explicitamente para carregar a v7.6.2 com kldload /boot/modules/if_em.ko ?
  3. Por que o kernel está carregando o v7.6.1 na inicialização quando module_path="/boot/modules" em /boot/defaults/loader.conf? O que posso fazer para somente carregar a v7.6.2? Eu tenho que excluir o /boot/kernel/if_em.ko? Isso parece um pouco errado.

Eu entendo que eu aprecio a "diversão" (e realmente, é divertido) de fazer com que todo o meu hardware e software funcionem corretamente quando eu escolho rodar o FreeBSD, mas isso parece um pouco demais.

EDIT: Após atualizar para o 11.0-RELEASE-p9 agora que a conectividade de rede existia, os mesmos problemas permanecem sem alteração.

    
por Scott Colby 16.05.2017 / 11:03

1 resposta

1

em0: a soma de verificação da EEPROM não é válida

Conforme você escreve, a soma de verificação da EEPROM está relacionada ao firmware. Eu acredito que você encontrou a solução para si mesmo. As isenções de responsabilidade parecem datadas dos antigos ibautil dias. Este relata sucesso com as placas da Supermicro com NICs incorporadas e alguém com um Intel D975XBX2 .

Gostaria de fazer o download da versão mais recente e verificar se consegui listar meu adaptador. Se assim for - eu não ficaria com tanto medo de tentar redefinir a configuração do PXE. Mas YMMV.

A correção sugerida para checksum errado é redefinir a configuração padrão do PXE usando:

bootutil -nic=1 -defcfg

- ou -

bootutil -all -defcfg

As opções podem ser encontradas em bootutil.txt

module_path

Você deve verificar como module_path é realmente definido em seu sistema. Você pode fazer isso com kenv .

# kenv module_path
/boot/kernel;/boot/modules

Você também pode verificá-lo usando kldconfig , que até sugere a solução:

# kldconfig -r
/boot/kernel;/boot/modules

É module_path , que determina a ordem e onde procurar .ko arquivos. O padrão é definido em sys / boot / common / module.c . Isso seria mais fácil de entender se module_path fosse removido de /boot/defaults/loader.conf ou conf / 73535 foi implementado. Eu também fiquei confuso com isso.

Você pode alterá-lo usando kldconfig .

Como /boot/kernel é atualizado pelo sistema e parte do sistema básico do FreeBSD, pode ser melhor não tocá-lo. Por outro lado, alterar a ordem do caminho pode causar surpresas também. Eu já vi outras pessoas sugerirem fazer um softlink de /boot/kernel .

    
por 16.05.2017 / 15:42