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

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

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

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>

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

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

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.

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.

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

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!

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

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

@Joseph, I tried with 4.10.0-20-generic

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

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

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

Any progress in fixing this issue for xenial hwe kernel ?

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? :-(

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

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.

@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

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

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.

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.

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!

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

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

@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/

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"

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

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.

Hi @narurien and @gaetan-trellu,

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

Success.
#38 works with bnx2x
Thanks a lot.

Success.
#38 works with ixgbe

@Jesse thanks and good job !

mlx4_en ( Mellanox Technologies MT26448 )
4.8.0-49-generic

->

enp3s0: Invalid MTU 9000 requested, hw max 68

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

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 :-(

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

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

@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.

Downgraded to 4.4 series. :(

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

Thanks!

@Thiago, yes I confirm.

Nice goldyfruit, thank you!

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

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!

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

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

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.

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

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.

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?

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.

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.

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

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.

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!

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
...

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

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.

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.

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

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

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...

Any progress on Zesty?

@vaaend:

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

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?

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.

@shapemaker:

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

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

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

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).

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.

# 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?

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.

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.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

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

> 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)