bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.8 / 4.10 in XENIAL LTS

Bug #1679823 reported by Gaëtan Trellu
216
This bug affects 38 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Triaged
Medium
Unassigned
Xenial
Confirmed
Undecided
Unassigned
Yakkety
Fix Released
Medium
Jesse Sung
Zesty
In Progress
Medium
Jesse Sung
linux-hwe (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Undecided
Unassigned
Yakkety
Fix Committed
Undecided
Unassigned
Zesty
Confirmed
Undecided
Unassigned
linux-hwe-edge (Ubuntu)
Confirmed
Undecided
Unassigned
Xenial
Confirmed
Undecided
Unassigned
Yakkety
Fix Committed
Undecided
Unassigned
Zesty
Confirmed
Undecided
Unassigned

Bug Description

Since I upgraded the kernel from linux-image-4.8.0-46-generic to linux-image-extra-4.10.0-14-generic I'm facing an issue when I want to change the MTU.

It seems to be known bug already fixed: https://bugzilla.kernel.org/show_bug.cgi?id=194763

# ip l sh eno49
2: eno49: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:61:e9 brd ff:ff:ff:ff:ff:ff

# ip l sh eno50
3: eno50: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:61:e9 brd ff:ff:ff:ff:ff:ff

# ip l sh bond0
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 5c:b9:01:8a:61:e9 brd ff:ff:ff:ff:ff:ff

# ip l set mtu 9000 bond0
RTNETLINK answers: Invalid argument

root@controller002[SRV][YUL]:~# tail -1 /var/log/syslog
Apr 4 19:36:28 controller002 kernel: [ 8869.077853] bond0: Invalid MTU 9000 requested, hw max 1500

# modinfo ixgbe
filename: /lib/modules/4.10.0-14-generic/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko
version: 4.4.0-k
license: GPL
description: Intel(R) 10 Gigabit PCI Express Network Driver

# modinfo bonding
filename: /lib/modules/4.10.0-14-generic/kernel/drivers/net/bonding/bonding.ko
author: Thomas Davis, <email address hidden> and many others
description: Ethernet Channel Bonding Driver, v3.7.1
version: 3.7.1

CVE References

Revision history for this message
In , daznis (daznis-linux-kernel-bugs) wrote :
Download full text (4.2 KiB)

Bond0 interface doesn't accept MTU higher than 1500.I can set MTU perfectly fine for the slave devices. Recreating the bond0 didn't help to up the MTU.

05:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
05:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

[ 1626.840818] bond0: Invalid MTU 9000 requested, hw max 1500
[ 1668.913497] ixgbe 0000:05:00.0 enp5s0f0: changing MTU from 1500 to 9000
[ 1669.176015] ixgbe 0000:05:00.0 enp5s0f0: speed changed to 0 for port enp5s0f0
[ 1669.237523] ixgbe 0000:05:00.0 enp5s0f0: detected SFP+: 5
[ 1669.487920] ixgbe 0000:05:00.0 enp5s0f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 1675.591234] ixgbe 0000:05:00.1 enp5s0f1: changing MTU from 1500 to 9000
[ 1675.855232] ixgbe 0000:05:00.1 enp5s0f1: speed changed to 0 for port enp5s0f1
[ 1675.911259] ixgbe 0000:05:00.1 enp5s0f1: detected SFP+: 6
[ 1676.159087] ixgbe 0000:05:00.1 enp5s0f1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 1684.745389] bond0: Invalid MTU 9000 requested, hw max 1500

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: 90:e2:ba:15:68:20
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 13
        Partner Key: 221
        Partner Mac Address: 02:1c:73:b2:9a:29

Slave Interface: enp5s0f0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 90:e2:ba:15:68:20
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: 90:e2:ba:15:68:20
    port key: 13
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 02:1c:73:b2:9a:29
    oper key: 221
    port priority: 16000
    port number: 373
    port state: 61

Slave Interface: enp5s0f1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 90:e2:ba:15:68:21
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: 90:e2:ba:15:68:20
    port key: 13
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 02:1c:73:b2:9a:29
    oper key: 221
    port priority: 17000
    port number: 33141
    port state: 61

Settings for enp5s0f0:
        Supported ports: [ FIBRE ]
        Supported link modes: 1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Advertised link modes: 1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetr...

Read more...

Revision history for this message
In , jarod (jarod-linux-kernel-bugs) wrote :

The fix for this has been added to the net tree and is queued up for 4.10-stable.

no longer affects: vlan (Ubuntu)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux-hwe-edge (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

The upstream bug report says the fix will be send to v4.10 stable. Do you happen to know the mainline SHA1?

tags: added: kernel-da-key zesty
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Sam Yaple (s8m) wrote :

This fix was merged and landed in 4.10.5

commit be18cce7e665b09406c4168fd3da32492dd5d8f3
Author: Jarod Wilson <email address hidden>
Date: Mon Mar 6 08:48:58 2017 -0500

    team: use ETH_MAX_MTU as max mtu

    [ Upstream commit 3331aa378e9bcbd0d16de9034b0c20f4050e26b4 ]

    This restores the ability to set a team device's mtu to anything higher
    than 1500. Similar to the reported issue with bonding, the team driver
    calls ether_setup(), which sets an initial max_mtu of 1500, while the
    underlying hardware can handle something much larger. Just set it to
    ETH_MAX_MTU to support all possible values, and the limitations of the
    underlying devices will prevent setting anything too large.

    Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra")
    CC: Cong Wang <email address hidden>
    CC: Jiri Pirko <email address hidden>
    CC: <email address hidden>
    Signed-off-by: Jarod Wilson <email address hidden>
    Signed-off-by: David S. Miller <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

I had a kernel upgrade 4.8.0-46 to 4.8.0.49 and I had the same issue.

# ip l set eno49 mtu 9000
RTNETLINK answers: Invalid argument

# tail -1 /var/log/kern.log
Apr 25 14:10:20 controller001 kernel: [64170.180920] eno49: Invalid MTU 9000 requested, hw max 68

# dpkg -l | grep linux-image-4.8
ii linux-image-4.8.0-46-generic 4.8.0-46.49~16.04.1 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP
ii linux-image-4.8.0-49-generic 4.8.0-49.52~16.04.1 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

As above the same issue degraded my system after reboot from 4.8.0-46 to 4.8.0-49.

Apr 25 17:08:40 nermal systemd-udevd[165]: Could not set Alias, MACAddress or MTU on eth1: Invalid argument
Apr 25 17:08:40 nermal kernel: eth0: Invalid MTU 9000 requested, hw max 68

/etc/systemd/network/bslav1.link

# -*- Systemd -*-
[Match]
MACAddress=xx:xx:xx:xx:xx

[Link]
Name=bslave1
MTUBytes=9000

Changed in linux-hwe (Ubuntu):
status: New → Confirmed
Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

This bug is a serious blocker, because after kernel update (4.8.0-49) it renders the system unusable if in a link file jumbo frames are specified.

On recent server hardware this is a normal use case.

summary: - bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.10
+ bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.10 (or
+ 4.8.0-49)
Revision history for this message
In , dirk (dirk-linux-kernel-bugs) wrote :
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

The fix to this bug is in the Ubuntu-4.10.0-15.17 kernel.

I'll build a 4.8 test kernel with the patch and post a link to it shortly.

Changed in linux (Ubuntu Zesty):
importance: Undecided → Medium
status: New → Fix Released
Changed in linux (Ubuntu Yakkety):
assignee: nobody → Joseph Salisbury (jsalisbury)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

@Joseph, 4.10.0-20-generic works for me.
Thanks !

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

I built a Yakkety test kernel with a pick of commit 3331aa378e9bcbd0d16de9034b0c20f4050e26b4. The test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1679823/

Can folks affected by this bug give this kernel a test?

Thanks in advance!

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

Still having and issue, for the physical interface it's working as expected but for virtual interfaces I got the same error.

I'm trying to change MTU on an OpenVswitch interface in a kernel namespace. If I switch back to 4.8.0-46 everything is OK.

Apr 25 19:44:11 controller003 kernel: [ 58.255163] ha-b5c29032-6c: Invalid MTU 8950 requested, hw max 1500
Apr 25 19:44:13 controller003 kernel: [ 60.227413] ha-f1dd45e0-53: Invalid MTU 8950 requested, hw max 1500
Apr 25 19:44:14 controller003 kernel: [ 61.453602] ha-855d4750-e4: Invalid MTU 8950 requested, hw max 1500
Apr 25 19:44:30 controller003 kernel: [ 76.610249] ha-bd9574b4-21: Invalid MTU 8950 requested, hw max 1500

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

@goldyfruit, your still having an issue with the test kernel I posted in comment #12?

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

@Joseph, I tried with 4.10.0-20-generic

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

1. xenial is missing in linux-hwe distributions
2. @jsalisbury: The systems here running xenial with hwe kernel.

MIYATA Tadaaki (andesm)
no longer affects: neutron
Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

It affects Neutron, qr-* and ha-* interfaces can be set with a MTU higher than 1500.
Look the output in #13 comment.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-hwe (Ubuntu Yakkety):
status: New → Confirmed
Changed in linux-hwe (Ubuntu Zesty):
status: New → Confirmed
Changed in linux-hwe-edge (Ubuntu Yakkety):
status: New → Confirmed
Changed in linux-hwe-edge (Ubuntu Zesty):
status: New → Confirmed
Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

Any progress in fixing this issue for xenial hwe kernel ?

Revision history for this message
Thiago Martins (martinx) wrote :

I was experiencing issues with OpenStack deployed with Networking OVN and just saw this message in my dmesg:

---
[ 12.241706] 8021q: adding VLAN 0 to HW filter on device eno2
[ 15.077293] eno2: Invalid MTU 9000 requested, hw max 68
---

And the IP of my eno2.600 VLAN is gone! So, the Instances can't ping each other because that is where my data path (GENEVE / VXLAN) tunnels are created on!

How a bug like this ended up into an LTS release? :-(

Revision history for this message
newsworthy39 (newsworthy39) wrote :

Can confirm, this bug, is present in 4.8.0-49

dpkg -l | grep linux-image
ii linux-image-4.8.0-49-generic 4.8.0-49.52~16.04.1 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP
ii linux-image-extra-4.8.0-49-generic 4.8.0-49.52~16.04.1 amd64 Linux kernel extra modules for version 4.8.0 on 64 bit x86 SMP
ii linux-image-generic-hwe-16.04 4.8.0.49.21 amd64 Generic Linux kernel image

# dmesg | tail -n 10
[26794.190251] enp1s10: Invalid MTU 9000 requested, hw max 68
[26814.409107] enp1s10: Invalid MTU 9000 requested, hw max 68
[27052.974824] enp1s10: Invalid MTU 4500 requested, hw max 68
[27057.685078] enp1s10: Invalid MTU 1600 requested, hw max 68
[27066.995768] enp0s7: Invalid MTU 9000 requested, hw max 68

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can folks affected by this bug see if it is fixed with the kernel posted in comment #12? To test that kernel you would need to install both the linux-image and linux-image-extra .deb packages. You should see this bug number in the output of uname -a if it the kernel is installed and booted.

Revision history for this message
Jesse Sung (wenchien) wrote :

@jsalisbury: I can still reproduce this issue with the kernel in #12...

$ uname -a
Linux cola 4.8.0-49-generic #52~lp1679823 SMP Tue Apr 25 17:29:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg | grep enp4s0
[ 1.194350] e1000e 0000:04:00.0 enp4s0: renamed from eth0
[ 53.469795] enp4s0: Invalid MTU 9000 requested, hw max 68
$ dpkg -l | grep 4.8.0-49
ii linux-headers-4.8.0-49 4.8.0-49.52~lp1679823 all Header files related to Linux kernel version 4.8.0
ii linux-headers-4.8.0-49-generic 4.8.0-49.52~lp1679823 amd64 Linux kernel headers for version 4.8.0 on 64 bit x86 SMP
ii linux-image-4.8.0-49-generic 4.8.0-49.52~lp1679823 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP
ii linux-image-extra-4.8.0-49-generic 4.8.0-49.52~lp1679823 amd64 Linux kernel extra modules for version 4.8.0 on 64 bit x86 SMP

Revision history for this message
Ralf Trezeciak (r-uone) wrote :

any news about kernel 4.10.0-20 to fix also openvswitch interfaces (bug 1685742) ?

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Thanks for the testing feedback on my test kernel. I suspect more than just commit 3331aa378e9bcbd0d16de9034b0c20f4050e26b4 is needed. dev->max_mtu being set to ETH_MAX_MTU must be needed in other spots. I'll investigate and post another test kernel shortly.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

It appears commit 3331aa378e9 fixes commit 91572088e3fd. However, commit 91572088e3fd was introduced in v4.10-rc1 and not cc'd to stable. The Yakkety 4.8 kernel never had commit 91572088e3fd applied. That explains why my test kernel did not fix this bug.

Comment #6 says that this same issue happened when upgrading from 4.8.0-46 to 4.8.0.49. The 4.8 regression must have been due to a different change. I'll investigate and respond shortly.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

After a review, Yakkety did get the following commits via other bug reports:

d37117d ethernet: use net core MTU range checking in more drivers
6426a88 net: use core MTU range checking in virt drivers
89110d9 net: use core MTU range checking in virt drivers
e84f31d net: centralize net_device min/max MTU checking
fe5473b hv_netvsc: remove excessive logging on MTU change

This changed the MTU checking in some places and not all. I think commits 91572088e3f and 3331aa378e9b are needed.

I built a V2 Yakkety test kernel with these two commits. It can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1679823/

Can folks affected by this bug give this kernel a test?

Thanks in advance!

Revision history for this message
Jesse Sung (wenchien) wrote :

It still fails with the kernel in #31.

$ uname -a
Linux cola 4.8.0-49-generic #52~lp1679823v2 SMP Mon May 1 21:32:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg | grep enp4s0
[ 1.197150] e1000e 0000:04:00.0 enp4s0: renamed from eth0
[ 52.924244] enp4s0: Invalid MTU 9000 requested, hw max 68
$ dpkg -l | grep 4.8.0-49
ii linux-headers-4.8.0-49 4.8.0-49.52~lp1679823v2 all Header files related to Linux kernel version 4.8.0
ii linux-headers-4.8.0-49-generic 4.8.0-49.52~lp1679823v2 amd64 Linux kernel headers for version 4.8.0 on 64 bit x86 SMP
ii linux-image-4.8.0-49-generic 4.8.0-49.52~lp1679823v2 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP
ii linux-image-extra-4.8.0-49-generic 4.8.0-49.52~lp1679823v2 amd64 Linux kernel extra modules for version 4.8.0 on 64 bit x86 SMP

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Thanks, Jesse. I'll investigate further. I'll probably try to reproduce the bug to make debugging faster.

Revision history for this message
Jesse Sung (wenchien) wrote :

@jsalisbury: I figured it out...

We're talking about two issues here.

The first one is unable to set MTU larger than 1500 on some devices.

Commit e84f31d (yakkety), "net: centralize net_device min/max MTU checking", introduced net_device.min_mtu and net_device.max_mtu. These values will be checked before net_device_ops.ndo_change_mtu().

Then the second commit 04db90d (yakkety) set the default value of min_mtu to ETH_MIN_MTU(68) and max_mtu to ETH_DATA_LEN(1500), removed *most* of the ndo_change_mtu() callback, and initialize min_mtu/max_mtu in each driver if it should be something different than the default values.

Here I say most because intel drivers are not modified by this commit. Intel drivers are handled by commit 91c527a5. My e1000e works properly after this commit is merged. For bonding devices it's commit 31c0541.

The second issue is it shows
"Invalid MTU 9000 requested, hw max 68"
instead of
"Invalid MTU 9000 requested, hw max 1500".

This is a typo in commit 04db90d and can be fixed by commit a0e65de.

A test kernel with 91c527a5, 31c0541, and a0e65de merged can be found at
https://people.canonical.com/~jesse/lp1679823/

Revision history for this message
Henning Stener (narurien) wrote :

Unfortunately still failing for me with kernel from #34

Summary of testing on Xenial (bnx2x NIC driver):

4.8.0-46: all OK
4.8.0-49: all interfaces fail with "hw max 68"
4.10.0-20: physical interfaces work, openvswitch bridges fail with "hw max 1500"
4.8.0-52: all interfaces fail with "hw max 1500"

Revision history for this message
Jesse Sung (wenchien) wrote :

Another commit is required for bnx2x, let me build a test kernel with it.

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

Hi Jesse,

Same behavior for me as @Henning.

Kernel:
ii linux-image-4.8.0-52-generic 4.8.0-52.55~16.04.1

Error:
kernel: [ 53.900687] ha-4fbfe106-23: Invalid MTU 8950 requested, hw max 1500

ixgbe NIC driver.

Revision history for this message
Jesse Sung (wenchien) wrote :

Hi @narurien and @gaetan-trellu,

Please try
https://people.canonical.com/~jesse/lp1679823v2/

Revision history for this message
Henning Stener (narurien) wrote :

Success.
#38 works with bnx2x
Thanks a lot.

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

Success.
#38 works with ixgbe

@Jesse thanks and good job !

Revision history for this message
Michal Linuxak (opruz) wrote :

mlx4_en ( Mellanox Technologies MT26448 )
4.8.0-49-generic

->

enp3s0: Invalid MTU 9000 requested, hw max 68

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

@michal did you try this kernel: https://people.canonical.com/~jesse/lp1679823v2/ ?

Revision history for this message
Michal Linuxak (opruz) wrote :

Sorry, I can't do experiments on production server :-(

I was hoping that on stable LTS release they would avoid doing experiments to avoid such... bummers :-(

Revision history for this message
Thiago Martins (martinx) wrote :

I also have a production environment running into network issues... Planning to downgrade the kernel to 4.4 series... =(

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Rey Tucker (rtucker) wrote :

The kernel in #38 does fix this for Zerotier TAP interfaces as well.

summary: bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.10 (or
- 4.8.0-49)
+ 4.8.0-49, xenial-hwe)
Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote : Re: bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.10 (or 4.8.0-49, xenial-hwe)

@martinx - To mitigate the problem I've dropped temporally jumbo frames from the configuration of my servers.

Hopefully the bug will be fixed also for xenial-hwe and not only for yakkety ;-)

I agree that this is a *blocker* for xenial.

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

Downgraded to 4.4 series. :(

Revision history for this message
Thiago Martins (martinx) wrote :

@goldyfruit, can you confirm if it also fixes the BUG: https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/1685742 ?

Thanks!

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

@Thiago, yes I confirm.

Revision history for this message
Thiago Martins (martinx) wrote :

Nice goldyfruit, thank you!

Revision history for this message
Michal Linuxak (opruz) wrote :

Any chance, that xenial will be fixed anytime soon? :-)

Revision history for this message
Thiago Martins (martinx) wrote :

I'm also expecting this on Xenial ASAP!

I'm using OpenStack with OVN, and the OpenFlow rules does not work with Kernel 4.4! And MTU does not work with 4.8!

Very bad situation... :-(

Also expecting the fix for:

https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/1685742

...in one shot!

Revision history for this message
Gaëtan Trellu (goldyfruit) wrote :

@Thiago, same for us. Hope it will be fixed soon !

Revision history for this message
Jesse Sung (wenchien) wrote :

Re-open zesty task because some patches are still missing (for example the fix for openvswitch).

Changed in linux (Ubuntu Yakkety):
assignee: Joseph Salisbury (jsalisbury) → Jesse Sung (wenchien)
Changed in linux (Ubuntu Zesty):
assignee: nobody → Jesse Sung (wenchien)
status: Fix Released → In Progress
Xav Paice (xavpaice)
tags: added: canonical-bootstack
summary: - bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.10 (or
- 4.8.0-49, xenial-hwe)
+ bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.8 / 4.10 in
+ XENIAL LTS
Revision history for this message
JuanJo Ciarlante (jjo) wrote :

We really need to get xenial added for its HWE kernels:
we have several BootStacks running with them, mainly for
latest needed drivers while keeping LTS (mellanox for
VNFs as an example)- all these are now obviously at
risk on the next reboot.

Note also that recovering from this issue does usually
require OOB access to the node, as typically bonded
interfaces are used for both mgmt and data planes.

Changed in linux (Ubuntu Yakkety):
status: In Progress → Fix Committed
Changed in linux-hwe (Ubuntu Yakkety):
status: Confirmed → Fix Committed
Changed in linux-hwe-edge (Ubuntu Yakkety):
status: Confirmed → Fix Committed
no longer affects: linux-meta-hwe (Ubuntu)
no longer affects: linux-meta-hwe (Ubuntu Yakkety)
no longer affects: linux-meta-hwe (Ubuntu Zesty)
Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

Just a question - is there any progress to fix this showstopper in xenial ?

Revision history for this message
cellard0or (cellard0or) wrote :

I second question #56. However, Xenial is not present in the list at the top so maybe it is being overlooked right now? I could not find out how to add it, though.

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

Hi,

Guys, it should be there for both the Yakkety kernel and linux-generic-hwe-16.04:

http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=7570ffb5145abf4413421c154077bc31abad1264

http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/?id=5e0bc558603351c8ce573913ba64b16908269b67

There are no HWE packages for non-LTS releases so the fix-commited for Yakkety belongs to both linux-generic in yakkety and linux-generic-hwe-16.04 in xenial as I understand it.

$ lsb_release -r
Release: 16.04
$ apt update

$ apt show linux-generic-hwe-16.04
Package: linux-generic-hwe-16.04
Version: 4.8.0.52.23 # <--- the same version as in the ubuntu-xenial git repo tag
Priority: optional
Section: kernel
Source: linux-meta-hwe
Origin: Ubuntu
Maintainer: Ubuntu Kernel Team <email address hidden>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 10.2 kB
Depends: linux-image-generic-hwe-16.04 (= 4.8.0.52.23), linux-headers-generic-hwe-16.04 (= 4.8.0.52.23)
Supported: 5y
Download-Size: 1,808 B
APT-Sources: http://ru.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
Description: Complete Generic Linux kernel and headers
 This package will always depend on the latest complete generic Linux kernel
 and headers.

--

Or are you saying that this issue is present in 4.4 as well?

Revision history for this message
cellard0or (cellard0or) wrote :

I am running Ubuntu 16.04.2 LTS with 4.8.0-52-generic (#55~16.04.1-Ubuntu) and still have the problem as reported in [#6](https://bugs.launchpad.net/ubuntu/+source/linux-hwe-edge/+bug/1679823/comments/6). Everything should be up to date on my side, linux-generic-hwe-16.04 is of version 4.8.0.52.23.

Revision history for this message
Jesse Sung (wenchien) wrote :

These patches are in 4.8.0-53, which is in -proposed right now. It will be available in -updates with next SRU release if everything goes well.

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

Sorry about the confusion: the commits are tagged with -53 and I mentioned -52 in the apt output.

Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

The fixes for this issue are also included on Xenial linux-hwe 4.8.0-53.56~16.04.1 which is currently on -proposed.

Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-yakkety' to 'verification-done-yakkety'. If the problem still exists, change the tag 'verification-needed-yakkety' to 'verification-failed-yakkety'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-yakkety
Revision history for this message
Jesse Sung (wenchien) wrote :

With 4.8.0-53 in -proposed, e1000e works without any problem.

$ uname -a
Linux cola 4.8.0-53-generic #56-Ubuntu SMP Tue May 16 00:23:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ ifconfig eth1
...
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
...

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

Works inside a virtual machine

Linux vt-xenial-server 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:14:44 UTC 2017 i686 i686 i686 GNU/Linux
ifconfig lan1

          UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

Linux odie 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Here the answer is yes and no.

The mtu is configured via systemd-networkd:
# grep MTU /etc/systemd/network/*
/etc/systemd/network/10-c42-bond0.netdev:MTUBytes=9000
/etc/systemd/network/10-c42-bslave1.link:MTUBytes=9000
/etc/systemd/network/10-c42-bslave2.link:MTUBytes=9000

After boot the MTU on all these interfaces is 1500.

It needs the command 'ip l set bond0 mtu 9000'
to switch all these interfaces together to jumbo frames.

Before this bug occurs (e.g. 4.8.0-46), it has been working without explicitly setting the MTU on the command line.

The same misbehaviour is on a second hardware:
Linux dilbert 4.10.0-21-generic #23~16.04.1-Ubuntu SMP Tue May 2 12:57:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

So the situation is for me:
Jumbo Frames are working again, but there seems to be a conflict with systemd 229.

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

So for me the situation with 4.8.0-53 is that in contradiction to 4.8.0-49 the system is working again and doesn't suffer from broken network configuration.
So it isn't a blocker any more.

But there is a conflict with the bond0 configuration on my systems now.

tags: added: verification-done-yakkety
removed: verification-needed-yakkety
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 4.8.0-53.56

---------------
linux (4.8.0-53.56) yakkety; urgency=low

  * linux: 4.8.0-53.56 -proposed tracker (LP: #1690956)

  * bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.8 / 4.10 in
    XENIAL LTS (LP: #1679823)
    - Revert "ethernet: use net core MTU range checking in more drivers"
    - Revert "Drivers: hv: ring_buffer: count on wrap around mappings in
      get_next_pkt_raw() (v2)"
    - Revert "hyperv: Fix spelling of HV_UNKOWN"
    - Revert "uio-hv-generic: new userspace i/o driver for VMBus"
    - Revert "UBUNTU: [Config] CONFIG_UIO_HV_GENERIC=m"
    - Revert "Drivers: hv: balloon: Add logging for dynamic memory operations"
    - Revert "Drivers: hv: balloon: Fix info request to show max page count"
    - Revert "Drivers: hv: balloon: Disable hot add when CONFIG_MEMORY_HOTPLUG is
      not set"
    - Revert "hv: change clockevents unbind tactics"
    - Revert "Drivers: hv: vss: Improve log messages."
    - Revert "Drivers: hv: utils: Fix the mapping between host version and
      protocol to use"
    - Revert "Drivers: hv: utils: reduce HV_UTIL_NEGO_TIMEOUT timeout"
    - Revert "vmbus: add support for dynamic device id's"
    - Revert "tools: hv: remove unnecessary header files and netlink related code"
    - Revert "tools: hv: fix a compile warning in snprintf"
    - Revert "net: use core MTU range checking in virt drivers"
    - Revert "hv_netvsc: fix a race between netvsc_send() and netvsc_init_buf()"
    - Revert "net: use core MTU range checking in virt drivers"
    - Revert "net: deprecate eth_change_mtu, remove usage"
    - Revert "net: centralize net_device min/max MTU checking"
    - Revert "hv_netvsc: remove excessive logging on MTU change"
    - Revert "scsi: storvsc: Payload buffer incorrectly sized for 32 bit kernels."
    - Revert "PCI: hv: Use the correct buffer size in new_pcichild_device()"
    - Revert "PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal"
    - Revert "PCI: hv: Use device serial number as PCI domain"
    - [Config] Add uio_hv_generic to modules.ignore for 4.8.0-52.55 abi

 -- Thadeu Lima de Souza Cascardo <email address hidden> Mon, 15 May 2017 21:06:52 -0300

Changed in linux (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux-hwe - 4.8.0-53.56~16.04.1

---------------
linux-hwe (4.8.0-53.56~16.04.1) xenial; urgency=low

  * linux-hwe: 4.8.0-53.56~16.04.1 -proposed tracker (LP: #1690957)

  * linux: 4.8.0-53.56 -proposed tracker (LP: #1690956)

  * bond0: Invalid MTU 9000 requested, hw max 1500 with kernel 4.8 / 4.10 in
    XENIAL LTS (LP: #1679823)
    - Revert "ethernet: use net core MTU range checking in more drivers"
    - Revert "Drivers: hv: ring_buffer: count on wrap around mappings in
      get_next_pkt_raw() (v2)"
    - Revert "hyperv: Fix spelling of HV_UNKOWN"
    - Revert "uio-hv-generic: new userspace i/o driver for VMBus"
    - Revert "UBUNTU: [Config] CONFIG_UIO_HV_GENERIC=m"
    - Revert "Drivers: hv: balloon: Add logging for dynamic memory operations"
    - Revert "Drivers: hv: balloon: Fix info request to show max page count"
    - Revert "Drivers: hv: balloon: Disable hot add when CONFIG_MEMORY_HOTPLUG is
      not set"
    - Revert "hv: change clockevents unbind tactics"
    - Revert "Drivers: hv: vss: Improve log messages."
    - Revert "Drivers: hv: utils: Fix the mapping between host version and
      protocol to use"
    - Revert "Drivers: hv: utils: reduce HV_UTIL_NEGO_TIMEOUT timeout"
    - Revert "vmbus: add support for dynamic device id's"
    - Revert "tools: hv: remove unnecessary header files and netlink related code"
    - Revert "tools: hv: fix a compile warning in snprintf"
    - Revert "net: use core MTU range checking in virt drivers"
    - Revert "hv_netvsc: fix a race between netvsc_send() and netvsc_init_buf()"
    - Revert "net: use core MTU range checking in virt drivers"
    - Revert "net: deprecate eth_change_mtu, remove usage"
    - Revert "net: centralize net_device min/max MTU checking"
    - Revert "hv_netvsc: remove excessive logging on MTU change"
    - Revert "scsi: storvsc: Payload buffer incorrectly sized for 32 bit kernels."
    - Revert "PCI: hv: Use the correct buffer size in new_pcichild_device()"
    - Revert "PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal"
    - Revert "PCI: hv: Use device serial number as PCI domain"
    - [Config] Add uio_hv_generic to modules.ignore for 4.8.0-52.55 abi

 -- Thadeu Lima de Souza Cascardo <email address hidden> Mon, 15 May 2017 21:06:52 -0300

Changed in linux-hwe (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

This bug was fixed in the package linux-hwe - 4.8.0-54.57~16.04.1

---------------
linux-hwe (4.8.0-54.57~16.04.1) xenial; urgency=low

  * linux-hwe: 4.8.0-54.57~16.04.1 -proposed tracker (LP: #1692590)

  * linux: 4.8.0-54.57 -proposed tracker (LP: #1692589)

  * CVE-2017-0605
    - tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

  * Populating Hyper-V MSR for Ubuntu 13.10 (LP: #1193172)
    - SAUCE: (no-up) hv: Supply vendor ID and package ABI

  * [Hyper-V] Implement Hyper-V PTP Source (LP: #1676635)
    - hv: allocate synic pages for all present CPUs
    - hv: init percpu_list in hv_synic_alloc()
    - Drivers: hv: vmbus: Prevent sending data on a rescinded channel
    - hv: switch to cpuhp state machine for synic init/cleanup
    - hv: make CPU offlining prevention fine-grained
    - Drivers: hv: vmbus: Fix a rescind handling bug
    - Drivers: hv: util: kvp: Fix a rescind processing issue
    - Drivers: hv: util: Fcopy: Fix a rescind processing issue
    - Drivers: hv: util: Backup: Fix a rescind processing issue
    - Drivers: hv: vmbus: Move the definition of hv_x64_msr_hypercall_contents
    - Drivers: hv: vmbus: Move the definition of generate_guest_id()
    - Revert "UBUNTU: SAUCE: (no-up) hv: Supply vendor ID and package ABI"
    - Drivers: hv vmbus: Move Hypercall page setup out of common code
    - Drivers: hv: vmbus: Move Hypercall invocation code out of common code
    - Drivers: hv: vmbus: Consolidate all Hyper-V specific clocksource code
    - Drivers: hv: vmbus: Move the extracting of Hypervisor version information
    - Drivers: hv: vmbus: Move the crash notification function
    - Drivers: hv: vmbus: Move the check for hypercall page setup
    - Drivers: hv: vmbus: Move the code to signal end of message
    - Drivers: hv: vmbus: Restructure the clockevents code
    - Drivers: hv: util: Use hv_get_current_tick() to get current tick
    - Drivers: hv: vmbus: Get rid of an unsused variable
    - Drivers: hv: vmbus: Define APIs to manipulate the message page
    - Drivers: hv: vmbus: Define APIs to manipulate the event page
    - Drivers: hv: vmbus: Define APIs to manipulate the synthetic interrupt
      controller
    - Drivers: hv: vmbus: Define an API to retrieve virtual processor index
    - Drivers: hv: vmbus: Define an APIs to manage interrupt state
    - Drivers: hv: vmbus: Cleanup hyperv_vmbus.h
    - hv_util: switch to using timespec64
    - Drivers: hv: restore hypervcall page cleanup before kexec
    - Drivers: hv: restore TSC page cleanup before kexec
    - Drivers: hv: balloon: add a fall through comment to hv_memory_notifier()
    - Drivers: hv: vmbus: Use all supported IC versions to negotiate
    - Drivers: hv: Log the negotiated IC versions.
    - Drivers: hv: Fix the bug in generating the guest ID
    - hv: export current Hyper-V clocksource
    - hv_utils: implement Hyper-V PTP source
    - SAUCE: (no-up) hv: Supply vendor ID and package ABI

  * CIFS: Enable encryption for SMB3 (LP: #1670508)
    - SMB3: Add mount parameter to allow user to override max credits
    - SMB2: Separate Kerberos authentication from SMB2_sess_setup
    - SMB2: Separate RawNTLMSSP authentication from SMB2_s...

Read more...

Changed in linux-hwe (Ubuntu Xenial):
status: New → Fix Released
status: New → Fix Released
Revision history for this message
Endre Vaade (vaaend) wrote :

Any progress on Zesty?

Revision history for this message
Jesse Sung (wenchien) wrote :

@vaaend:

@smb pointed out that it is part of the stable 4.10.16: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691369

Revision history for this message
Mikko Tanner (shapemaker) wrote :

4.10 series (hwe-edge) kernel doesn't seem to have gotten these fixes yet, as 4.10.0-22-generic #24~16.04.1-Ubuntu still fails to set openvswitch MTU correctly. When can we expect a fix to be released for -edge?

Revision history for this message
Mikko Tanner (shapemaker) wrote :

Ok, so the fix is rather trivial. I've verified that building 4.10.0-22 kernel from Ubuntu sources with the following patch fixes the OpenvSwitch MTU issue:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/openvswitch/vport-internal_dev.c?id=425df17ce3a26d98f76e2b6b0af2acf4aeb0b026

Here's the instructions for people who want the fixed kernel asap:

# apt-get source linux-image-4.10.0-22-generic
# apt-get build-dep linux-image-4.10.0-22-generic
<apply the vport-internal_dev.c patch above>
# fakeroot debian/rules binary-headers binary-generic binary-perarch

Install needed DEBs, reboot.

Revision history for this message
Jesse Sung (wenchien) wrote :

@shapemaker:

Since it's "fix committed" for lp:1691369, the fix will be included in the next SRU release.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux (Ubuntu Xenial):
status: New → Confirmed
Changed in linux-hwe-edge (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
Amad Ali (amad) wrote :

linux-generic-hwe-16.04-edge from xenial-proposed repo fixes the problem.

$ sudo cat /etc/apt/sources.list | grep proposed
deb http://archive.ubuntu.com/ubuntu xenial-proposed main

$ sudo apt-cache policy linux-generic-hwe-16.04-edge
linux-generic-hwe-16.04-edge:
  Installed: 4.10.0.23.16
  Candidate: 4.10.0.23.16
  Version table:
 *** 4.10.0.23.16 500
        500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     4.10.0.22.15 500
        500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 Packages

$ uname -a
Linux <hostname-omitted> 4.10.0-23-generic #25~16.04.1-Ubuntu SMP Fri Jun 9 10:45:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ ip link show | grep bond0
bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master br-bond0 state UP mode DEFAULT group default qlen 1000

$ sudo ovs-vsctl list-br | grep br-int
br-int

$ ip link show | grep br-int
32: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

$ sudo ip link set br-int mtu 9000
$ ip link show | grep br-int
32: br-int: <BROADCAST,MULTICAST> mtu 9000 qdisc noop state DOWN mode DEFAULT group default qlen 1000

also solves BUG mentioned in LP#1685742

Revision history for this message
Mikko Tanner (shapemaker) wrote :

The MTU problem affecting OpenvSwitch bridges still exists (or resurfaced) in linux-generic-hwe-16.04-edge (4.10.0.24.17).

# grep -i mtu /var/log/syslog
[...] br-int: Invalid MTU 9000 requested, hw max 1500
[...] lxcbr0: Invalid MTU 9000 requested, hw max 1500

Pretty please STOP BREAKING things. No network access is especially annoying to fix remotely. Luckily I tested this before upgrading more critical systems (as everyone should, of course).

Revision history for this message
Jesse Sung (wenchien) wrote :

4.10.0-24 is a 4.10.0-22 with CVE fix applied, that's why it doesn't have the fix for openvswitch which is in 4.10.0-23.

Revision history for this message
Mikko Tanner (shapemaker) wrote :

# apt update
[...]
# apt install linux-image-4.10.0-23-generic
N: Unable to locate package linux-image-4.10.0-23-generic

(yes I know it is in proposed)

However, 4.10.0-24 does exist and gets installed with -edge. And it is known broken. Why push it out at all? Am I wrong to assume that a later numbered (point?) release would have the fixes contained in previous versions?

Revision history for this message
Jesse Sung (wenchien) wrote :

It happens when test for kernel in -proposed (in this case 4.10.0-23) is not yet completed, and an important security issue must be addressed. In this case 4.10.0-24 is based on a fully tested 4.10.0-22, and changes in 4.10.0-23 will be included in later release instead.

Revision history for this message
Thomas (t.c) wrote : apport information

AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Feb 16 13:45 seq
 crw-rw---- 1 root audio 116, 33 Feb 16 13:45 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
DistroRelease: Ubuntu 16.04
HibernationDevice: RESUME=UUID=7d50a0ab-30df-4053-8e22-891d5d2a1aa3
InstallationDate: Installed on 2018-02-14 (8 days ago)
InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8)
IwConfig: Error: [Errno 2] No such file or directory
Lsusb:
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. PowerEdge T110 II
Package: linux-hwe-edge (not installed)
PciMultimedia:

ProcEnviron:
 TERM=xterm
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
ProcFB: 0 mgadrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-32-generic root=UUID=9d3c0aa3-a21f-406e-a1e4-96f5cd2565cc ro splash vt.handoff=7
ProcVersionSignature: Ubuntu 4.13.0-32.35~16.04.1-generic 4.13.13
RelatedPackageVersions:
 linux-restricted-modules-4.13.0-32-generic N/A
 linux-backports-modules-4.13.0-32-generic N/A
 linux-firmware 1.157.16
RfKill: Error: [Errno 2] No such file or directory
Tags: xenial xenial xenial xenial
Uname: Linux 4.13.0-32-generic x86_64
UnreportableReason: Der Bericht gehört zu einem nicht installierten Paket.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: False
dmi.bios.date: 03/13/2012
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.0.5
dmi.board.name: 0W6TWP
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 17
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.0.5:bd03/13/2012:svnDellInc.:pnPowerEdgeT110II:pvr:rvnDellInc.:rn0W6TWP:rvrA01:cvnDellInc.:ct17:cvr:
dmi.product.name: PowerEdge T110 II
dmi.sys.vendor: Dell Inc.

tags: added: apport-collected xenial
Revision history for this message
Thomas (t.c) wrote : CRDA.txt

apport information

Revision history for this message
Thomas (t.c) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Thomas (t.c) wrote : JournalErrors.txt

apport information

Revision history for this message
Thomas (t.c) wrote : Lspci.txt

apport information

Revision history for this message
Thomas (t.c) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Thomas (t.c) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Thomas (t.c) wrote : ProcModules.txt

apport information

Revision history for this message
Thomas (t.c) wrote : UdevDb.txt

apport information

Revision history for this message
Thomas (t.c) wrote : WifiSyslog.txt

apport information

Revision history for this message
Thomas (t.c) wrote :

I have the same problem with my DELL server. Can't set MTU > 1500 with current kernel.

Revision history for this message
Dan Streetman (ddstreet) wrote :

> I have the same problem with my DELL server. Can't set MTU > 1500 with current kernel.

Your hardware is limited, you are not seeing a kernel bug. Your tg3 chip has a "jumbo capable" flag and it seems it not set - meaning your NIC does not support frames larger than the standard 1500.

/* hardware minimum and maximum for a single frame's data payload */
#define TG3_MIN_MTU ETH_ZLEN
#define TG3_MAX_MTU(tp) \
        (tg3_flag(tp, JUMBO_CAPABLE) ? 9000 : 1500)

Revision history for this message
In , kkimdavenport (kkimdavenport-linux-kernel-bugs) wrote :

We have added the fix to the net tree and it is scheduled for 4.10-stable.
https://flappy-bird.co

Revision history for this message
In , reg2005 (reg2005-linux-kernel-bugs) wrote :

Many weed seeds https://cannacraftcorner.com exhibit dormancy, a state in which seeds remain inactive until conditions are favorable for germination. This trait ensures their https://pureplantpleasures.com survival through adverse conditions such as drought or extreme temperatures.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.