ОШИБКА ядра в drivers/net/ethernet/intel/e1000e/netdev.c :3804!

kernel BUG at drivers/net/ethernet/intel/e1000e/netdev.c:3804!
kernel: [162559.916048] invalid opcode: 0000 [#1] SMP PTI
kernel: [162559.916126] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G        W         4.19.0-10-amd64 #1 Debian 4.19.132-1
kernel: [162559.916222] Hardware name: FUJITSU D3401-H1/D3401-H1, BIOS V5.0.0.11 R1.7.0.SR.2 for D3401-H1x                11/25/2015
kernel: [162559.916328] Workqueue: events e1000_reset_task [e1000e]
kernel: [162559.916410] RIP: 0010:e1000_flush_desc_rings+0x2a9/0x2f0 [e1000e]

Вы используете ядро ​​дистрибутива Debian, в котором есть несколько исправлений, примененных поверх основного исходного кода, поэтому мой быстрый анализ может быть не совсем точным. Но глядя на строку 3804 из drivers/net/ethernet/intel/e1000e/netdev.cв 4.19.170 восходящего источника , мы приходим к этой строке:

BUG_ON(tdt != tx_ring->next_to_use);

Это вызовет сообщение kernel BUG at...с трассировкой стека и всем прочим, если указанное условие истинно.

Эта строка находится в функции e1000_flush_tx_ring(), которая вызывается функцией e1000_flush_desc_rings(), которая, в свою очередь, упоминается как местоположение указателя инструкции в сообщении об ошибке:

RIP: 0010:e1000_flush_desc_rings+0x2a9/0x2f0 [e1000e]

Возможно, компилятор встроил или иным образом оптимизировал функцию e1000_flush_tx_ring(), чтобы она не отображалась как идентифицируемый символ для строки RIP:. Но похоже, что трассировка вызова соответствует :, что убедительно свидетельствует о том, что драйвер находился в процессе сброса сетевой карты, и очистка кольца TX явно является частью этого процесса.

Но зачем нужен сброс? Оказывается, Intel опубликовала обновление спецификации для сетевых карт I218/I219 .

5.Buffer Overrun While the I219 is Processing DMA Transactions

Problem:Intel® 100/200 Series Chipset platforms reduced the round-trip latency for the LAN Controller DMA accesses, causing in some high-performance cases a buffer overrun while the I219 LAN Connected Device is processing the DMA transactions.

Implication:I219LM and I219V devices can fall into unrecovered Tx hang under very stressfully UDP traffic and multiple reconnection of Ethernet cable. This Tx hang of the LAN Controller is only recovered if the system is rebooted.

Workaround:Slightly slow down DMA access by reducing the number of outstanding requests.This workaround could have an impact on TCP traffic performance and could reduce performance up to 5 to 15% (depending) on the platform. Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance.

Status: Intel® 100/200 Series Chipsets – NoFix

Intel® 300 Series Chipsets - Fixed

Таким образом, основная причина, по-видимому, связана с аппаратной (или, возможно, ошибкой встроенного ПО сетевой платы ). Драйвер обнаруживает, что структура кольцевого буфера TX повреждена, и предполагает, что причиной является сбой в драйвере. Но в этом случае кажется, что проблема в самом сетевом адаптере.

Рекомендуемый обходной путь — отключить функцию разгрузки TCP-сегментации(tso)сетевого адаптера :

ethtool -K eth0 tso off

Судя по всему, Fujitsu D3401 -H1 оснащен процессором Intel Core i7 -6700 поколения Skylake... поэтому я ожидаю, что вместе с ним будет установлен чипсет Intel серии 100. Похоже, что для этого набора микросхем нет исправлений, поэтому вам, вероятно, придется применить обходной путь.