web-dev-qa-db-ja.com

ASUSラップトップのインテルイーサネットコントローラーI219-Vの不揮発性メモリ(NVM)のチェックサムを修復する方法

新しい ASUSPRO B8430UA ラップトップに問題があります。その Intelイーサネット接続I219-V はLinuxでは機能しません。実際、このモデルの2つの異なるラップトップを試しましたが、どちらも同じ問題がありました。

使用されるLinuxドライバーは e1000e であり、Linux(Ubuntu 16.04)のブート中に次のメッセージを生成します。

$ dmesg | grep e1000e 
[ 5.643760] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k 
[ 5.643761] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. 
[ 5.644308] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode 
[ 5.877838] e1000e 0000:00:1f.6: The NVM Checksum Is Not Valid 
[ 5.907340] e1000e: probe of 0000:00:1f.6 failed with error -5 

e1000eの最新バージョン3.3.4をインストールしようとしましたが、これは役に立ちませんでした(ただし、カーネルを汚染しました)。

e1000-devel メーリングリストでこれについて質問しましたが、ノートパソコンの製造元に連絡することをお勧めしました。有効」とは、イーサネットチップの不揮発性メモリの内容が破損しているか、少なくともチェックサムと一致していないことを意味します(残念ながら、私は専門家ではないため、これについて詳しく説明することはできません)。

私はIntelカスタマーサポートに質問を投げかけました。彼らはOEMシステム(ラップトップのオンボードイーサネットチップ)には対応しておらず、ASUSに連絡する必要があると答えました:

残念ながら、システムがOEMであるため、サポートオプションは非常に制限されています。ラップトップの製造元がソフトウェアまたはハードウェアを変更した可能性があるため、そのようなシステムのサポートとドライバーはラップトップの製造元から直接提供されます。

ASUSのカスタマーサポートに問い合わせましたが、NVMの内容を確認または修復するためのツールはありません。そのようなツールを見つけたら、喜んで知ってくれると回答しました。彼らはまた、元のハードウェアとソフトウェアの構成のみをサポートすることを想定しており、このラップトップモデルはWindows 7で販売されていることを説明しました。私が学んだことによると、Windowsは単にNVMチェックサムをチェックしません。

私は2011年に1つの類似したケースで、問題は Intel Ethernet Connections Boot Utility を使用して修正できることを発見しました:

https://thesorcerer.wordpress.com/2011/07/01/guide-intel-82573l-gigabit-ethernet-with-ubuntu-11-04-and-fix-pxe-e05/

ただし、最後の段落の免責事項は次のように警告しています。

おそらく、インテル(R)イーサネット接続ブートユーティリティは、オンボード(OEMとも呼ばれます)LANカード(PCIカード用)で使用するように設計されていないため、その相互作用を予測する確実な方法がないことを知っておく必要があります。 USBやSOUNDコントローラーなどのボードコンポーネントのその他のもの。

BootUtilバージョン1.6.13.0の description も、オンボードイーサネットコントローラでの使用を意図したものではないようです。

インテル(R)イーサネットフラッシュファームウェアユーティリティ(BootUtil)は、サポートされているインテルPCIおよびPCI-ExpressベースのネットワークアダプターのフラッシュメモリでPCIオプションROMをプログラムするために使用できるユーティリティです、および構成を更新します。

[...]

OEMは、OEMネットワークアダプター用のカスタムフラッシュファームウェアイメージを提供できます。 OEMの指示を参照してください。

しかし、私が理解できなかった段落があります:

PXE + EFIおよびiSCSI + EFIイメージの組み合わせは、すべてのOEM汎用アダプターでサポートされていますが、サポートは、両方のテクノロジーを個別のイメージとしてサポートするデバイスに限定されています。

さらに、e-1000eドライバー バグ が原因で NVMが破損していた の2008年の問題の コメント5 では、次のことをお勧めします。

Web上の一部のサイトがこの問題の修正を試みるよう提案しているため、ibautilを実行しないでください。 LAN機能を回復するには、マザーボードを交換する必要があります。

IBAUTILは、BootUtilの前身の1つです。

いずれにしても、「システムでサポートされているすべてのサポートされているIntelネットワークポートのリスト」を取得するために、コマンドラインオプションなしでLinuxからBootUtilを実行することにしました。これは私が持っているものです:

$ Sudo ./bootutil64e

Intel(R) Ethernet Flash Firmware Utility
BootUtil version 1.6.13.0
Copyright (C) 2003-2016 Intel Corporation

Type BootUtil -? for help

Port Network Address Location Series  WOL Flash Firmware                Version
==== =============== ======== ======= === ============================= =======
  1   D017C2201F59     0:31.6 Gigabit N/A FLASH Not Present

この文脈で「フラッシュが存在しない」の意味と、チェックサムを修正するためのオプションについて教えてください。


Update 1。「FLASH Not Present」に関するe1000-develメーリングリストから受け取ったコメントによると"、

フラッシュとNVMは2つの別個のアイテムです。フラッシュはPXEブートやiSCSIなどを有効にしますが、NVMはネットワークアドレスなどを保存します。


アップデート2。I219のIntelの データシート が見つかりました、セクション10.3.2.2チェックサムワードの計算さんのコメント:

チェックサムワード(ワード0x3F、NVMバイト0x7Eおよび0x7F)は、ベースNVMイメージが有効なイメージであることを確認するために使用されます。このワードの値は、チェックサムワード自体を含むすべてのワード(0x00-0x3F)/バイト(0x00-0x7F)を追加した後、合計が0xBABAになるように計算する必要があります。 16ビット加算レジスタの初期値は0x0000で、キャリービットは加算ごとに無視する必要があります。

5
Alexey

e1000-devel メーリングリストからの親切な助力を得て、NVMを修正する方法を以下に示しますethtool を使用したチェックサムワード

基本的に、私はまずLinuxでイーサネットチップにアクセスできるようにe1000eにパッチを適用し、次にethtoolを使用してI219のNVMの「チェックサム」領域から値を読み取りました-Vそしてそれを書き戻す。書き込み操作によりチェックサムが修正されました。

Linuxから私のイーサネットチップにアクセスするには、パッチe1000eを実行して、NVMチェックサム検証をスキップする必要がありました。ファイルsrc/netdev.cの最初の行を変更しました

for (i = 0;; i++) {
    if (e1000_validate_nvm_checksum(&adapter->hw) >= 0)
        break;
    if (i == 2) {
        dev_err(pci_dev_to_dev(pdev),
            "The NVM Checksum Is Not Valid\n");
        err = -EIO;
        goto err_eeprom;
    }
}

for (i = 0; false; i++) {

(ブロック全体を削除するか、コメント化することもできます。)

次に、パッチを当てたモジュールをインストールしました。私がした/srcディレクトリから:

Sudo make install
Sudo modprobe -r e1000e
Sudo modprobe e1000e
Sudo update-initramfs -u
reboot

これでチェックサム検証がスキップされ、イーサネットが機能し始めました。

チェックサムワードを修正する前に、インテルの datasheet のセクション10に記載されているI219のNVMの概要を調べました。チェックサムワードの使用については、セクション10.3.2.2で説明します。

NVMに書き込む前に、チェックサムワードを書き留めました。

$ Sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset      Values
------      ------
0x007e:     60 13 

enp0s31f6はイーサネットインターフェイスの名前です。)したがって、誤ったチェックサムワード値は0x1360でした。

Sudo ethtool -e enp0s31f6を使用してNVMのダンプを確認し、次にオフセット0x10のバイトを再度確認しました。

$ Sudo ethtool -e enp0s31f6 offset 0x10 length 1
Offset      Values
------      ------
0x0010:     ff 

(どうやらどの場所でも問題ありませんが、私の場合、オフセット0x10の値はまったく使用されなかったため、「安全」に見えました。)

ethtoolを使用してNVM(EEPROM)に書き込むには、「マジックキー」が必要でした。私は Unbricking a Intel Pro/1000(e1000)network interface を読み、私のマジックキーが0x15708086であることがlspci -nnを使用してわかった:

$ lspci -nn | grep Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)

次に、NVMでオフセット0x10に0xffを書き戻しました。

$ Sudo ethtool -E enp0s31f6 magic 0x15708086 offset 0x10 value 0xff

書き込みの前後にNVMのダンプを比較した後、予想どおり、変更されたのはチェックサムワードのみであることがわかりました。

$ Sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset      Values
------      ------
0x007e:     60 93 

したがって、新しい値は0x9360でした。

パッチを適用していないe1000eでカーネルを起動しましたが、イーサネットポートは正常に機能していました。

追伸チェックサムワードの最上位ビットのみが間違っていたことに少し心配です。

10
Alexey

統合されたIntel NIC)でIntelのLinuxにbootutilを使用して(2011の投稿で提案されているように)、再コンパイルやマジックを行わずにこのエラーを修正しました賛成投票で議論されたキー。それはうまくいきました インテルダウンロードサイト からツールをダウンロードしました

chmod +x ./bootutil64e
Sudo ./bootutil64e -NIC 1 -defcfg
6

Intel I219-V NICアダプタを搭載したASUS ROG MAXIMUS IX HEROマザーボードのe1000eドライバからFedora 24で同じエラーが発生しました。

NVMへのパッチ適用を必要とする受け入れられた解決策は危険すぎると思います。ハードウェアが役に立たなくなる可能性があります。

安全な解決策の1つは、デフォルト構成をNIC using Intel Ethernet Connections Boot Utility を使用して)に適用することです。これはそのままLinuxで機能し、ブートを作成する必要はありません。ディスク:

$ chmod +x bootutil64e
$ Sudo ./bootutil64e -NIC=1 -DEFAULTCONFIG

それだ。再起動するだけです(またはe1000eドライバを手動で再ロードします)。

4

試してください:

$ Sudo ./bootutil64e -NIC=XXX -BOOTENABLE=DISABLED.

これは、bootutil64eの最近のバージョンでうまくいくはずです。

1
elch

私は同じエラーがあり、NVMビットで遊ぶ前に他のすべてを試してみたかった。

これが問題を解決したかどうかはわかりませんが、魔法のように再び機能する前に最後に行ったのはEFI(IPv4)を使用してネットワーク経由で起動しようとするでした。次に、いくつかの黒魔術が私のNVMを修正したに違いありません。

環境

  • メインボード:Asus PRIME Z270-A(BIOS 0701)
  • NIC:00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-V [8086:15b8]
1
222

私の解決策ははるかに簡単です:

-UEFI BIOSユーティリティに入ります。
- 入る アドバンストモード
- 案内する Advanced\Network Stack Configuration ネットワークスタックを有効にするだけです(NATの背後に安全に残るためにIPv4のみを有効にします)。

NICを再起動してお楽しみください。どうやら、これはどういうわけか悪いNVMチェックサムをクリアするのに十分です。その後、戻って上記のスタックを無効にすることができます。
これは、Asus Prime z270-aマザーボードのBIOSバージョン8001(Arch Linuxのe1000eドライバー、カーネル4.9.11-1)の下にあります。

おそらく、この問題の原因は、EZ Flashユーティリティを介してインターネット経由で直接ファームウェアを更新しようとしたことです(DHCPモードと静的IPモードの両方で失敗しました)。ユーティリティが更新を試みるためにネットワークスタック(デフォルトではオフになっている)を有効にできるかどうか尋ねたのを覚えています。

0
ppparadox