| 2022-11-24 13:58:57 |
Felix Ruess |
bug |
|
|
added bug |
| 2022-11-24 14:14:10 |
Felix Ruess |
attachment added |
|
lspci-vvnn.log https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632632/+files/lspci-vvnn.log |
|
| 2022-11-24 14:51:48 |
Felix Ruess |
attachment added |
|
kernel_bug.txt https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632652/+files/kernel_bug.txt |
|
| 2022-11-24 17:02:32 |
Felix Ruess |
description |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2022-11-24 17:02:43 |
Felix Ruess |
description |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff -s 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2022-11-24 17:58:07 |
Felix Ruess |
description |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff -s 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff -s 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.4.0-131-generic
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2022-11-24 18:42:15 |
Felix Ruess |
description |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff -s 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.4.0-131-generic
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
With a high MTU (9000) set on the interface, sending packets containing over ~3000 zero bytes to a network card using the igb driver results in broken packets or in the worst case for some packet sizes even leads to kernel panics or full freeze.
So far I observed this for Intel I350 and I210 network cards which use the igb driver.
This is easy to reproduce:
* set MTU to 9000
* send ping of death: ping -M do -p 00 -s 3016 <ip>
-> kernel panic or complete freeze of system
If the data is not zero, it works fine:
ping -M do -p ff -s 3016 <ip>
Depending on packet length:
* < 3000: fine
* 3016: panic/freeze
* > 3030: packet not complete
I also tested this with the following kernel versions:
* 5.4.0-131-generic -> OK
* 5.8.0-63-generic -> OK
* 5.11.0-46-generic -> OK
* 5.13.0-52-generic -> broken
* 5.15.0-41-generic -> broken
* 5.19.5-051905-generic mainline -> broken
We noticed that since we have GigE Vision cameras which send the data via UDP with packet sizes up to 9000. When we turned off the light (and hence many bytes in the payload were zero), the packets would not be complete anymore (checked with tcpdump/wireshark) or even lead to kernel panics.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.15.0-53-generic 5.15.0-53.59~20.04.1
ProcVersionSignature: Ubuntu 5.15.0-53.59~20.04.1-generic 5.15.64
Uname: Linux 5.15.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.25
Architecture: amd64
CasperMD5CheckResult: skip
Date: Thu Nov 24 13:16:00 2022
SourcePackage: linux-signed-hwe-5.15
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2022-11-25 08:45:01 |
Launchpad Janitor |
linux-signed-hwe-5.15 (Ubuntu): status |
New |
Confirmed |
|
| 2022-11-25 17:40:09 |
Felix Ruess |
attachment added |
|
kernel panic with 4port I210 card with firmware=1.63 https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632807/+files/nuvo_7166GC_i210_kernel_panic.txt |
|
| 2022-11-25 17:41:44 |
Felix Ruess |
attachment added |
|
kernel panic with 4port I350 card with firmware=1.63 https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632808/+files/nuvo_7166GC_i350_kernel_panic.txt |
|
| 2022-11-25 17:42:13 |
Felix Ruess |
attachment added |
|
kernel panic with 4port I210 card with firmware=3.16 https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632809/+files/nuvo_7166GC_i210_kernel_panic.txt |
|
| 2022-11-25 17:55:01 |
Felix Ruess |
attachment removed |
kernel panic with 4port I210 card with firmware=1.63 https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.15/+bug/1997764/+attachment/5632807/+files/nuvo_7166GC_i210_kernel_panic.txt |
|
|
