** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Jay Vosburgh (jvosburgh)
** Changed in: linux (Ubuntu Precise)
Assignee: (unassigned) = Jay Vosburgh (jvosburgh)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Public bug reported:
Note: this occurs when booting the 14.04 desktop installer ISO as well,
not just on the installed system. Booting any of 13.10, 12.04 or Fedora
20 does not exhibit the same problem on the same machines.
For the installed system, after logging in, the desktop comes up and
Public bug reported:
SRU Justification:
Impact:
Reduced TCP/IP receive performance for network devices that do not split
packet headers into skb linear area (e.g., mlx4). The trusty kernel has
incorporated
commit eff44f9cc9a02aad53d568d3ae5020b6792ae4f6
Author: Jerry Chu hk...@google.com
17e96834fd35997ca7cdfbf15413bcd5a36ad448
Author: Govindarajulu Varadarajan _gov...@gmx.com
Date: Thu Dec 18 15:58:42 2014 +0530
enic: fix rx skb checksum
commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e
Author: Jay Vosburgh jay.vosbu...@canonical.com
Date: Fri Dec 19 15:32:00 2014 -0800
net/core: Handle csum
ifupdown 0.7.48.1ubuntu9 resolves the original problem for me on a fresh
vivid install with the daily build for today.
Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1442828
Title:
Public bug reported:
The change to ifup@.service done as part of LP 1425376 appears to break the
ordering of units marked as After=network-online.target. In my specific
case, a new service script with After=network-online.target is erroneously
run concurrently with dhclient. As the new
Public bug reported:
Running Ubuntu instances on azure, testing basic networking between two
instances. This involves configuring VXLAN between the two instances and
running iperf and rsync of the kernel tree between the instances, e.g.,
ip link add vxlan0 type vxlan id 999 local 10.88.0.12
Yes, it did, although it seemed to be easier to reproduce with vxlan
configured.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508706
Title:
Networking hangs on azure using hv_netvsc; bisected
To
I set up a similar configuration locally, and I see the bridge correctly
forwarding the IPv6 NS packets. The ping functions as expected. I have
different network cards, and used IPv6 ULA addresses (fc00:1234::/64)
but I'm not sure how that would affect the bridge forwarding decision.
I'm also
The original patch had an error in it; I believe I've found it and once
I verify that and clean it up a bit I"ll attach it to the bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463911
Title:
** Patch added: "Backport patch for vivid 3.19"
https://bugs.launchpad.net/nova/+bug/1463911/+attachment/4520984/+files/ubuntu-vivid-sru.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463911
SRU Justification:
Impact:
This bug causes issues when ip6tables modules are loaded with IPv6
fragmented packets traversing a bridge. The extant conntrack processing
will reassemble the IPv6 fragments for netfilter processing, but is
incapable of re-fragmenting these datagrams for
** Patch added: "Backport patch for trusty 3.13"
https://bugs.launchpad.net/nova/+bug/1463911/+attachment/4520982/+files/ubuntu-trusty-3.13-sru.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "Backport patch for trusty 3.16"
https://bugs.launchpad.net/nova/+bug/1463911/+attachment/4520983/+files/ubuntu-trusty-3.16-sru.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I have done a backport of
commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd
Author: Bernhard Thaler
Date: Sat May 30 15:30:16 2015 +0200
netfilter: bridge: forward IPv6 fragmented packets
to the trusty 3.13 kernel. This necessitated pulling in some bits from
Just looking at the log, it might be this:
commit fa11cb3d16a9b9b296a2b811a49faf1356240348
Author: Anjali Singhai Jain
Date: Wed May 27 12:06:14 2015 -0400
i40e: Make sure to be in VEB mode if SRIOV is enabled at probe
If SRIOV is enabled we need to be
We are testing this patch immediately (overnight US time) and will
report our results as soon as they are available
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508706
Title:
Networking hangs on
Test methodology performed on 3.19 kernel with patch applied:
Host A: fd01:::1/64 direct connect to host C
ip addr add fd01:::1/64 dev eth0
Host B: fd01:::2/64 direct connect to host C
ip addr add fd01:::2/64 dev eth0
host C: direct connect interfaces for Hosts A & B bridged
The equivalent testing to comment #20 was also performed on the 3.13 and
3.16 kernels, additionally, a customer separately validated the 3.13 and
3.16 patches in their environment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I have tested the patch referenced in comment #5 and it appears to
resolve the network hang.
I first built and tested the Ubuntu LTS 3.19.0-31.36~14.04.1 kernel and
reproduced the issue using the methodology described in the original bug
description. This is commit
commit
SRU Justification:
Impact:
Bug causes easily reproducible freeze of networking on affected
systems when under moderate to high network load. Ordinary benchmark
tools such as iperf induce the problem without difficulty. Affected
systems are virtual machine instances running on Azure,
Public bug reported:
The /usr/share/initramfs-tools/hook-functions contains what appears to be a
variable name update (from root to dev_node) error.
It appears that one instance of root was not updated correctly; this causes
mkinitramfs to fail with the error:
mkinitramfs: for device /dev/vda1
Yes, the patch has been committed for the next Ubuntu kernel releases.
I have no information on a Centos patch; you would need to file a bug
against Centos or RHEL.
No patch to Neutron is required.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The Wily kernel (4.2) already contains the fixes for this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463911
Title:
IPV6 fragmentation and mtu issue
To manage notifications about this bug
** Tags removed: verification-needed-trusty verification-needed-vivid
** Tags added: verification-done-trusty verification-done-vivid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463911
Title:
I haven't tested this patch, but fanctl had the same issue, and I
believe the fix is that the subnet math has to be "overlay_width + ( 32
- underlay_width )", not "overlay_width + underlay_width".
Patch attached.
** Patch added: "fanatic patch"
I haven't tested this patch, but fanctl had the same issue, and I
believe the fix is that the subnet math has to be "overlay_width + ( 32
- underlay_width )", not "overlay_width + underlay_width".
Patch attached.
** Patch added: "fanatic.patch"
I haven't tested this patch, but fanctl had the same issue, and I
believe the fix is that the subnet math has to be "overlay_width + ( 32
- underlay_width )", not "overlay_width + underlay_width".
Patch attached.
** Patch removed: "fanatic patch"
This issue may be fixed by this upstream commit:
commit f60439bc21e3337429838e477903214f5bd8277f
Author: Alexander Duyck
Date: Thu Aug 11 14:51:56 2016 -0700
ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths
When I was adding the code for enabling
Patch proposal to modify ipconfig to use one packet socket per interface
** Patch added: "klibc-fix-1.patch"
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+attachment/4806861/+files/klibc-fix-1.patch
--
You received this bug notification because you are a member of Ubuntu
The patch added to nominally fix this issue is incorrect; it is setting
the wrong bit in the BOOTP flags field for broadcast:
+ bootp.flags = htons(0x800);
The correct value should be 0x8000. This is causing issues with
switches that reject the packet as having bits set in a "must be
** Changed in: klibc (Ubuntu)
Status: Confirmed => In Progress
** Tags removed: kernel-bug-exists-upstream kernel-bug-exists-
upstream-4.10-rc1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just a note that I'm setting up to try the reproduction instructions
from comment #35
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1652348
Title:
initrd dhcp fails / ignores valid response
To
without major rework to utilize one packet
socket per interface.
** Tags removed: kernel-key
** Package changed: linux (Ubuntu) => klibc (Ubuntu)
** Changed in: klibc (Ubuntu)
Status: Triaged => Confirmed
** Changed in: klibc (Ubuntu)
Assignee: (unassigned) => Jay Vosburgh (
I have reproduced the described issue locally using the instructions
from comment 35; will start looking into the cause.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1652348
Title:
initrd dhcp
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1683947
Title:
ubuntu 4.8 kernel, virtio_net error causes NAT packets to be lost
test by resettting the test client instance and watch for
serial output:
% gcloud compute instances reset nat-client --zone us-central1-a
Wait a minute or so for new boot, then check the serial-port-output as
above.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Jay
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1700834
Title:
Intel i40e PF reset under load
To manage
proposed kernel tested by customer
** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697053
Title:
Missing IOTLB
Importance: Undecided
Assignee: Jay Vosburgh (jvosburgh)
Status: New
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jay Vosburgh (jvosburgh)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1700834
Title:
Intel i40e PF reset under load
To manage notifications about this
Jason,
I work for Canonical; the issue came up with one of our customers.
FWIW, I debugged the issue by first using kprobes and ftrace on the
kernel of a running instance to trace the packet path through the
kernel. Once it seemed that the affected packets were not being dropped
somewhere on
The panic appears to be fixed upstream via:
commit 9c3f3794926a997b1cab6c42480ff300efa2d162
Author: Liping Zhang
Date: Sat Mar 25 16:35:29 2017 +0800
netfilter: nf_ct_ext: fix possible panic after
nf_ct_extend_unregister
If one cpu is doing
Customer has verified that 4.4.0-79-generic resolves the issue in their
environment that would previously panic.
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Sam / Christian,
This sort of issue is not unheard of in cases where an IP address moves
from interface to interface, or between hosts. Most situations that
expect this type of issue (e.g., bonding link failover) already issue
gratuitous ARPs in order to update L2 peers.
I think the bottom line
it resolves the issue.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Jay Vosburgh (jvosburgh)
Status: New
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jay Vosburgh (jvosburgh)
--
You received this bug notification because you are a member of Ubu
** Changed in: linux (Ubuntu)
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1697053
Title:
Missing IOTLB flush causes DMAR errors with SR-IOV
To manage
Albert,
This is the lspci from my X220 T:
-[:00]-+-00.0 Intel Corporation 2nd Generation Core Processor Family DRAM
Controller
+-02.0 Intel Corporation 2nd Generation Core Processor Family
Integrated Graphics Controller
+-16.0 Intel Corporation 6 Series/C200 Series
Just a comment that I have observed this bug as well, on an X220 T. The
test kernel from comment #11 also appears to resolve the problem (so
far). I do not have any external USB controllers attached, though, so
I'm not sure what the failure path was.
--
You received this bug notification
The dev_disable_lro warning is happening due to some logic issues in the
features code. The LRO on the VLAN (bond0.200, e.g.) that's being
warned about does end up being disabled by a NETDEV_FEAT_CHANGE callback
when the underlying bond0's features are updated, so the warning is
spurious.
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1765241
Title:
virtio_scsi race can corrupt memory, panic kernel
I would suggest testing
commit de77ecd4ef02ca783f7762e04e92b3d0964be66b
Author: Mahesh Bandewar
Date: Mon Mar 27 11:37:33 2017 -0700
bonding: improve link-status update in mii-monitoring
and
commit d94708a553022bf012fa95af10532a134eeb5a52
Author: WANG Cong
We've seen a similar-sounding issue in the past, but couldn't get it
tracked down to the root cause.
Is it possible to enable some instrumentation in the /etc/network/interfaces and
obtain some data on a failing occurrence?
What we've used in the past is adding something like
pre-up echo 'file
Joe,
No, I'm not seeing the issue now; running 4.13.0-16 for the last 10 days
or so.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1716747
Title:
linux 4.12 - high system load and mouse delays -
SRU Justification:
Impact:
This issue can cause system panics of systems using the
virtio_scsi driver with the affected Ubuntu kernels. The issue manifests
irregularly, as it is timing dependent.
Fix:
The issue is resolved by adding synchronization between the two
code paths
SRU Justification:
Impact:
This issue can cause system panics of systems using the
virtio_scsi driver with the affected Ubuntu kernels. The issue manifests
irregularly, as it is timing dependent.
Fix:
The issue is resolved by adding synchronization between the two
code paths that race with
ts: linux (Ubuntu)
Importance: Undecided
Assignee: Jay Vosburgh (jvosburgh)
Status: Confirmed
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jay Vosburgh (jvosburgh)
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification
Joe,
I didn't try anything in between, I went from 4.13.0-16 to -36 and -36
started wigging out again so I backed down to -16. I can try some
interim kernels next week when I don't need to do work on the laptop in
question.
--
You received this bug notification because you are a member of
Joe,
The issue has returned on my X220 tablet; running 4.13-0.36-generic and
the fully updated 17.10 user space.
Every time it happens the laptop display freezes for about 10 or 15
seconds. A concurrent ssh session is unaffected.
[94261.464884] pipe A vblank wait timed out
[94261.464948]
Reproducer for ptype_all corruption. Pass ifindex of an
administratively down interface on the command line.
** Attachment added: "packet-fry.c"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1800254/+attachment/5206100/+files/packet-fry.c
--
You received this bug notification
Public bug reported:
SRU Justification:
Due to changes added as part of c108ac876c02 ("packet: hold bind lock when
rebinding to fanout hook"), it is possible for fanout_add to add a
packet_type handler via dev_add_pack and then kfree the memory backing the
packet_type. This corrupts the
** Tags removed: verification-needed-trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800254
Title:
packet socket panic in Trusty 3.13.0-157 and later
To manage notifications about this bug
Regarding #2 from comment #19:
As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the
device's MTU, and the existing API returns an error if the ipv6.mtu is
out of range, I think it's reasonable for a configuration with the
ipv6.mtu > device MTU to fail.
--
You received this bug
Public bug reported:
User reports a hang under heavy I/O:
The IO hang problem on our cloud is caused by IO hang in block-wbt wbt_wait.
The fix commit id is 2887e41b910bb14fd847cf01ab7a5993db989d88. It is a block
write buffer throttle queue lock contention and thundering herd issue in
** Also affects: pciutils (Ubuntu Precise)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815237
Title:
stop shipping "update-pciids" in /usr/sbin
To
Public bug reported:
SRU Justification
Impact:
During PCI Express Downstream Port Containment (DPC) recovery,
certain types of failures do not recover due to a logic flaw
in pcie_do_recovery().
The upstream git commit log explains the change:
PCI/ERR: Update error status after reset_link()
Public bug reported:
SRU Justification:
Impact:
Since upstream commit eed85ff4c0da7 (4.16), control of PCIe DPC
(Downstream Port Containment) is coupled with control of AER (Advanced
Error Reporting), eliminating the option for the kernel to separately
manage DPC (which was previously
wgrant, you said:
That :a-152 is meant to be /sys/kernel/slab/:a-152. Even a
working kernel shows some trouble there:
$ uname -a
Linux 5.4.0-42-generic #46~18.04.1-Ubuntu SMP Fri Jul 10 07:21:24
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ ls -l /sys/kernel/slab | grep a-152
Si-Wei,
In the test environment I'm using, the only change needed was to
initramfs-tools. I suspect the udevd change you're thinking of was an
alternate implementation that we did not proceed with due to the
regression it introduced (that network interface names would change).
--
You received
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834322
Title:
Losing port aggregate with 802.3ad port-channel/bonding
Thimo,
Thanks for the update; just to clarify, for your "procedure to recover,"
are you saying that that procedure will always resolve the damage, or
that even after that procedure, there may be corruption?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Si-Wei,
What environment and methodology are you testing with? I do not see the
same results you are reporting. I am using the instructions you
previously provided, and with an 18.04.5 Ubuntu image, I see the
expected network interface naming (ens3, ens3nsby), and do not see
Harry,
I'm still working to reproduce this, without success. I have set
the .autoconf sysctl to 0 (which controls creation of local addresses in
response to received Router Advertisements), as well as setting
.addr_gen_mode to 1 (to disable SLAAC (fe80::) addresses).
In any
Harry,
I am attempting to reproduce the behavior you describe, but have been
unable to do so. Could you clarify some of the configuration specifics,
as follows:
Starting with step 2,
"2. On the host, create a bridge and vlan with two ports, each with the
chosen vlan as PVID and egress
74 matches
Mail list logo