[Bug 1486670] [NEW] using ipsec, many connections result in no buffer space error

(e.g. overnight) the buffers will be cleaned up and connections can be made again. this happens even on the latest net-next kernel. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Dan Streetman (ddstreet) Status: In Progress ** Changed in: linux (Ubuntu

[Bug 1479031] Re: attached block devices not showing up

** Changed in: linux (Ubuntu Precise) Assignee: (unassigned) = Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1479031 Title: attached block devices not showing up

[Bug 1479031] Re: attached block devices not showing up

Here is a PPA with a fix for this: https://pad.lv/ppa/ddstreet/lp1479031 There was no code change required; the only change is the acpiphp driver is built-in, instead of a module. During boot, when the pci-acpi driver is loaded, it enumerates the bus. Later when the acpiphp driver is loaded, it

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

This is caused by a bug that appears to have been present since ~2008. Proposed upstream patch: http://marc.info/?l=linux-netdev=144596262420164=2 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

Short summary: ipsec uses a struct dst_ops object per net-namespace (e.g. per container), but does not correctly initialize each dst_ops object's percpu counter. This results in incorrect values for each net namespace's dst_ops counter. Full details: ipsec uses xfrm objects, which contain dst

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Yep it would definitely be useful to see a repro with the test/debug kernel, thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497428 Title: kernel BUG at

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Changed in: linux (Ubuntu Precise) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: linux (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: linux (Ubuntu Wily) Assignee: (unassigned) => Dan Streetman (ddstreet) *

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Hi Dave, are you able to reproduce the bug? The trace by itself isn't terribly helpful, all it really says is the pageblock spans zones, which means move_freepages_block() logic for detecting that failed for some reason. I have a debug kernel ppa here: pad.lv/ppa/ddstreet/lp1497428 that

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using ipsec, many connections result in no buffer space error To manage notifications about this bug go to:

[Bug 1497428] [NEW] kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Public bug reported: The kernel triggers a BUG when it finds it is in move_freepages() but the start and end pfns for the move are in different zones. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Dan Streetman (ddstreet) Status: New ** Tags: sts ** Changed

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

** Tags added: trusty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497428 Title: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968 To manage notifications about this bug go to:

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Chris, this bug is for a Canonical STS issue I'm debugging. I'll add more details as I get them. ** Tags removed: needs-apport-collect ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

No, I can't add any details just yet, I don't have direct access to the failing system, but I'm working with the reporter to debug it. This bug is currently just a placeholder so I can provide a debug ppa, pad.lv/ppa/ddstreet/lp1497428. It's okay that nobody else can help debug yet, because I'm

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

** Changed in: linux (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: linux (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchp

[Bug 1506550] Re: quassel can't play audio notifications in wily

Yes, the default sounds are from the kde-runtime-data package. You can also select sounds from the oxygen-sounds package, they're in the same directory (/usr/share/sounds/) and have similar names. In quassel configuration under Notifications it lets you choose the sound file for each event. I'm

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

To clarify the bug, a bit of background is needed first (specific numbers apply only to this situation). The kernel refers to all pages under a single PMD (midlevel page table) as a "pageblock". It's the same size as a hugepage, 2M. In the function triggering the BUG(), it's expecting that the

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

The newer kernel may have some change/fix that prevents this bug, as I haven't seen any reports of this (from google, at least) on any other kernel. Plus, the unusual requirement of the memory having to end at not a multiple of 2M. > But the “Node 0 Normal” zone, judging from (start_pfn,

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

This is in the ipsec (git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git) tree, but not yet in net-next (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git). Once it hits net-next, I'll request it for the net stable queue (if needed). -- You received this bug

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

For reference, here's a pasted sample of the Oops (taken from Diego's log above): [415478.493013] [ cut here ] [415478.496056] kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968! [415478.496056] invalid opcode: [#1] SMP [415478.496056] Modules linked in:

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Diego, thanks, although the log doesn't provide any new info, and it's doubtful this is related to hugepages. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497428 Title: kernel BUG at

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

i booted a c4.8xlarge flavor AWS instance and got the same memory/numa layout as comment 16. To clarify though, the /proc/iomem output isn't representative of the actual memory layout; specifically it is: [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

I've dl'ed the dump and I'm reviewing it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1505564 Title: Soft lockup with "block nbdX: Attempted send on closed socket" spam To manage notifications

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

notsc" parameter, which will change the udelay function to use a simple loop instead of the TSC, and reproduce the softlockup? ** Changed in: linux (Ubuntu) Assignee: Rafael David Tinoco (inaddy) => Dan Streetman (ddstreet) -- You received this bug notification because you are a mem

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

> I won't pretend to know how numactl interleaves the memory across the nodes, > but I can't help but think high memory usage on these nodes combined with > forced interleaving might be why we hit this issue? The numactl interleaving just causes memory to be allocated from all nodes on a

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

Patch is now in mainline; I'll request it gets added to net stable. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using ipsec, many connections result in no buffer space error To

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

Ok, nm about the sosreport - I got the info from some older emails from axino, nova is using qemu-nbd to locally mount images and access the partitions inside them. I was able to trivially reproduce this simply by creating an image, attaching it with qemu-nbd to /dev/nbd0, partitioning it and

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

axino or nick, can either of you attach an sosreport from an affected system? The crashdump doesn't include any userspace data so I can't see what exactly the qemu-nbd userspace program is doing, nor can i see what params it's started with. I'll need that info to be able to debug the qemu-nbd

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

Well, yes I agree, it does look like the serial port causing the softlockup is probably separate - but caused by - the nbd closed socket errors. However, the serial port output definitely shouldn't be causing a softlockup - no matter how much data it has to send, the serial port driver in the

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

Andrew, Rodrigo, James, do any of you have a crash dump from a system where the problem has happened? or any way to more easily reproduce it? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1403152

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

** Changed in: linux (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1454286 Title: BNX2X firmware an hang on Trusty (3.13) and Uto

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

kernel module to add debug for this mm BUG(). This module is for kernel 3.13.0-71-generic only. ** Attachment added: "lp1497428.ko" https://bugs.launchpad.net/ubuntu/trusty/+source/linux/+bug/1497428/+attachment/4537000/+files/lp1497428.ko -- You received this bug notification because you

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Can anyone seeing this problem, if you're on the 3.13.0-71-generic kernel, please load the above attached module? It will initially check the node/zone start/end locations for validity, and also will check every time move_freepages is called, and if it detects the BUG() will be hit it prints out

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

BTW, I've only seen this situation - with a node end pfn not on a pageblock boundary - happen with the AWS flavors "c4.8xlarge" and "m4.10xlarge". If anyone else sees this bug anywhere besides those Amazon AWS instances, please let me know. -- You received this bug notification because you are

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

> It turns out, the kernel booted through kexec fails booting probably because > of the notsc option : > https://pastebin.canonical.com/146714/ hmm, that's weird, but if notsc is all that changed i assume it is the problem. > I'm a bit worried about the following line : > [ 0.00] tsc:

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

Great. I'll send the patch upstream, and open a new bug for the serial port hanging issue. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1505564 Title: Soft lockup with "block nbdX:

[Bug 1578654] Re: multipath does not set fiberchannel params correctly

Tester reported: Looks good to me. I enabled the proposed repository, and downgraded multipath-tools-boot and associated packages to 0.4.9-3ubuntu7.12. I rebooted and confirmed that the dev_loss_tmos were stuck at 30 despite the config saying to put them at 5. Then I ran an upgrade which pulled

[Bug 1578654] Re: multipath does not set fiberchannel params correctly

** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1578654 Title: multipath does not set fiberchannel params correctly To manage

[Bug 1534216] Re: serial port driver under heavy load can hang system

Ah ok, thnx. bug title updated. ** Summary changed: - serial port driver in some virtual systems can hang + serial port driver under heavy load can hang system -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1534216] [NEW] serial port driver in some virtual systems can hang

to schedule itself off the cpu it's using during that time. That results in other cpus hanging, waiting for the serial port driver's cpu to become avaiable. I'll update the bug with more details as I debug. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Dan Streetman (ddstreet

[Bug 1505564] Re: Soft lockup with "block nbdX: Attempted send on closed socket" spam

opened bug 1534216 to track the serial port issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1505564 Title: Soft lockup with "block nbdX: Attempted send on closed socket" spam To manage

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** 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/1486670 Title: using ipsec, many connections result in no buffer

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Changed in: linux (Ubuntu Vivid) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using ipsec, many connections res

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

and a reminder - the /proc/sys/net/ipv4/xfrm4_gc_thresh param is a per- netns value, so it should be changed in each container. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

> To speed up reproduction of this bug, lower the xfrm4_gc_thresh to a value > ABOVE (2 * 4096 * CPUS), but close to it - > e.g. something like 10k * CPUS sorry got the math wrong on the verification - the xfrm4_gc_thresh should be set to above ((4096 * CPUS) / 2), so something like 4K * CPUS,

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

I individually cherry-picked each relevant commit to the bnx2x driver, leading up to the commit referenced above, to the trusty kernel. A test ppa is here: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1454286 please test with this ppa to verify it fixes the firmware hangs. -- You

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Changed in: linux (Ubuntu Precise) Status: In Progress => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using ipsec, many connections result in no buffer space

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

Cristian ok thnx. I'll keep investigating. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1403152 Title: unregister_netdevice: waiting for lo to become free. Usage count To manage notifications

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

> The LXC images failed to start under linux-image-4.2.0-28-generic, with a kernel oops. this bug isn't about kernel oopses. > Setting /proc/sys/net/ipv4/xfrm4_gc_thresh to 5 causes the failure almost > immediately. > > I would like to confirm my procedure however. I've been changing >

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

Update: after some discussion, I'm going to pull specific commits into the trusty 3.13 bnx2x driver, instead of pulling the entire 3.19 bnx2x driver back. I'll update this bug when I have something new to test. -- You received this bug notification because you are a member of Ubuntu Bugs, which

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

Note: commit 6260412 is *definitely* not appropriate, as it simply updates the driver version, which is wrong to do without also updating the driver with all the preceeding commits. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

For reference, to repeat the commit hashes that Rafael mentioned above (in standard reverse chronological order): ddstreet@toughbook:~/linux$ git show 6260412 | head -5 commit 626041248d3fb5b2fca5c9af172f00fa3bb6dcfe Author: Yuval Mintz Date: Sun Aug 17 16:47:46 2014

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

Note: commit e42780b actually updates the driver to use the new firmware: diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h b/drivers/net/ethernet/broadcom/bnx2x/b index 5ba8af5..3b6cbd2 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h +++

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

I should note that I'm pretty sure this new problem is almost certainly a different bug (different cause) than the original bug fixed in comment 59 and earlier; just the symptoms appear the same. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

I've backported the bnx2x driver from lts-vivid (3.19) to trusty (3.13) and have it included in this ppa: https://launchpad.net/~ddstreet/+archive/ubuntu/lp1454286 Anyone having problems with the bnx2x driver on trusty (3.13), please test with this kernel PPA. -- You received this bug

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

Also, if anyone is using bnx2x with trusty lts-utopic (3.16 kernel), please let me know, as I'd rather not spend the time backporting to a kernel that's scheduled for EOL later this year, unless there's a need for it. -- You received this bug notification because you are a member of Ubuntu Bugs,

[Bug 1454286] Re: BNX2X firmware an hang on Trusty (3.13) and Utopic (3.16).

** Changed in: linux (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: linux (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1497428] Re: kernel BUG at /build/buildd/linux-3.13.0/mm/page_alloc.c:968

Matt, I think it's fine that upstream has demoted the BUG_ON, as I haven't heard anyone report this with a kernel later than 3.13; I assume whatever is causing it is fixed in later kernels. At this point there's not much more I can do, as I can't reproduce it and don't have much debug info on

[Bug 1549332] [NEW] xfrm4_gc_thresh should default to INT_MAX

n't actually control xfrm dst gc, it only causes failures when exceeded. Thus is should simply be set to INT_MAX. Upstream commit that fixes this is c386578f1cdb4dac230395a951f88027f64346e3 ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Dan Streetman (ddstreet) Sta

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Tags removed: verification-needed-wily ** Tags added: verification-done-wily -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1486670 Title: using ipsec, many connections result in no buffer space

[Bug 1549332] Re: xfrm4_gc_thresh should default to INT_MAX

** Changed in: linux (Ubuntu) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1549332 Title: xfrm4_gc_thresh should default to INT_MAX To manage

[Bug 1549332] Re: xfrm4_gc_thresh should default to INT_MAX

Requested commit go into stable queue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1549332 Title: xfrm4_gc_thresh should default to INT_MAX To manage notifications about this bug go to:

[Bug 1547680] Re: bonded interfaces in bridge do not have LRO turned off

This can be reproduced on any system with a nic that supports lro. For example: $ sudo ethtool -k eth5 | grep large-receive-offload large-receive-offload: on $ sudo modprobe bonding $ sudo ifenslave bond0 eth5 $ sudo brctl addbr br0 $ sudo brctl addif br0 bond0 without the patch, lro will

[Bug 1549332] Re: xfrm4_gc_thresh should default to INT_MAX

** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1549332 Title: xfrm4_gc_thresh should default to INT_MAX To manage notifications about this bug go to:

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** 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/1486670 Title: using ipsec, many connections result in no buffer space error

[Bug 1547680] Re: bonded interfaces in bridge do not have LRO turned off

The result of this bug is, some VMs on an affected host system will receive some packets, but not all, so in the VM it appears that the network doesn't work. This was specifically seen on Windows guests, in this case. -- You received this bug notification because you are a member of Ubuntu

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

i'll attach debdiffs shortly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545173 Title: systemtap does not work on trusty lts-vivid kernel To manage notifications about this bug go to:

[Bug 1545173] [NEW] systemtap does not work on trusty lts-vivid kernel

Public bug reported: Attempting to use systemtap results in: In file included from /usr/share/systemtap/runtime/linux/task_finder.c:17:0, from /usr/share/systemtap/runtime/linux/runtime.h:188, from /usr/share/systemtap/runtime/runtime.h:24, from

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

note, the order of the patches I listed isn't chronological, just the order I pulled them in to fix the individual separate compile errors. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545173

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

>From the upstream repo, git://sourceware.org/git/systemtap.git, these commits are required (in reverse chronological order): 4f570bf5df317f3d5275b8e8a0cb5de8c2232f25 c91d2e7cc991068fd701d75a4814db87913d57bd 22a78a3e79331f83932372f576eb8338543abb0f f1676ba1a5f60281fe64f96fbef37d484da6204c

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

In sequential order, with more detail: ==> 0001-Fixed-compile-problem-on-3.18-kernels-caused-by-remo.patch <== >From 547f6291433b574186e82f4afe233b00b7eb242e Mon Sep 17 00:00:00 2001 From: David Smith Date: Tue, 6 Jan 2015 10:07:01 -0600 Subject: [PATCH] Fixed compile problem

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

** Patch added: "debdiff of the required patches, listed above." https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1545173/+attachment/4573809/+files/lp1545173.debdiff ** Changed in: systemtap (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You rece

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

** Tags removed: verification-needed-vivid ** Tags added: 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/1486670 Title: using ipsec, many connections result in no buffer

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

** Changed in: systemtap (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545173 Title: systemtap does not work on trusty lts-vivid kernel To manage

[Bug 1547644] [NEW] systemtap does not work on wily kernel, hrtimer_get_res

Public bug reported: systemtap fails with: In file included from /usr/share/systemtap/runtime/timer.c:17:0, from /tmp/stapNgYUlz/stap_d73751f21cb6a8e35c1e92f712612cc2_4574_src.c:869: /usr/share/systemtap/runtime/linux/timer.c: In function ‘_stp_hrtimer_init’:

[Bug 1545330] Re: [wily][regression] completely broken by new kernels

I've sent a kernel patch to correct this also, which IMHO is the correct fix. https://lkml.org/lkml/2016/2/19/533 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545330 Title: [wily][regression]

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

** Changed in: systemtap (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545173 Title: systemtap does not work on trusty lts-vi

[Bug 1547644] Re: systemtap does not work on wily kernel, hrtimer_get_res

** Changed in: systemtap (Ubuntu) Status: New => Fix Committed ** Changed in: systemtap (Ubuntu Wily) Status: New => In Progress ** Changed in: systemtap (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemtap (Ubuntu Wily)

[Bug 1547644] Re: systemtap does not work on wily kernel, hrtimer_get_res

** Patch added: "debdiff with required patch" https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1547644/+attachment/4575919/+files/lp1547644.debdiff ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

and on wily, this patch is required on top of the patch from comment 14: probe kernel.function("xfrm_resolve_and_create_bundle") { if ($family == 2) { -dst_count[$pols[0]->xp_net->loopback_dev] = $pols[0]->xp_net->xfrm->xfrm4_dst_ops->pcpuc_entries->count +

[Bug 1547680] [NEW] bonded interfaces in bridge do not have LRO turned off

ied by LRO and then lost when passing through the bridge. Commit fbe168ba91f7c327856f205699404284c2f09e36 updates dev_disable_lro() to work for all types of interfaces, including bonds. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Dan Streetman (ddstreet) Status: I

[Bug 1547680] Re: bonded interfaces in bridge do not have LRO turned off

** Changed in: linux (Ubuntu Trusty) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: linux (Ubuntu Trusty) Status: New => In Progress ** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification be

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

the systemtap script below can be used to monitor the dst count for all net namespaces. When any of the counts goes significantly negative (more than 32 * CPUS negative) it indicates this bug is reproduced - meaning, the count from one net namespace was incorrectly shifted to another net

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

> To test this fix, multiple containers must be started (just 2 is fine). note - it can be reproduced with just 2, but it happens exponentially faster with a higher number of containers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1486670] Re: using ipsec, many connections result in no buffer space error

correction on the script above, to only show each netns count once (script above duplicates netns counts) probe kernel.function("xfrm_resolve_and_create_bundle") { if ($family == 2) { -dst_count[&$pols[0]->xp_net] = $pols[0]->xp_net->xfrm->xfrm4_dst_ops->pcpuc_entries->count +

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

Andrew Ruthven that's your patch also ^ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1403152 Title: unregister_netdevice: waiting for lo to become free. Usage count To manage notifications about

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

> James Dempsey, the upstream commit you referenced is in trusty lts- vivid at Ubuntu-lts-3.19.0-49.55_14.04.1 specifically, upstream it's commit 30f7ea1c2b5f5fb7462c5ae44fe2e40cb2d6a474 and in the trusty lts branch it's commit a8412804321b96aac2665527535ac28a934ed0e2 -- You received this bug

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

James Dempsey, the upstream commit you referenced is in trusty lts-vivid at Ubuntu-lts-3.19.0-49.55_14.04.1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1403152 Title: unregister_netdevice:

[Bug 1403152] Re: unregister_netdevice: waiting for lo to become free. Usage count

Rodrigo, just in case the problem you're seeing is fixed by ^ commit, please try the latest trusty lts-vivid (at version I listed above, or later). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1557673] Re: systemtap does not work on xenial, struct module changes

> Upstream commit 3f040971e7e should fix this. yep > (Also, we plan to have a systemtap 3.0 release shortly, with this and other fixes.) great; does that cover wily also? because this is broken there also with wily/lts-xenial kernel. (As well as lp bug 1547644.) -- You received this bug

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

** Description changed: - Attempting to use systemtap results in: + [Impact] + + Attempting to use systemtap on trusty with the lts-vivid kernel fails + with: In file included from /usr/share/systemtap/runtime/linux/task_finder.c:17:0, - from

[Bug 1545173] Re: systemtap does not work on trusty lts-vivid kernel

** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1545173 Title: systemtap does not work on trusty lts-vivid kernel To manage notifications about this bug go to:

[Bug 1547644] Re: systemtap does not work on wily kernel, hrtimer_get_res

debdiff containing above commit ** Patch removed: "debdiff with required patch" https://bugs.launchpad.net/ubuntu/wily/+source/systemtap/+bug/1547644/+attachment/4575919/+files/lp1547644.debdiff ** Patch added: "lp1547644.debdiff"

[Bug 1557673] Re: systemtap does not work on xenial, struct module changes

** Changed in: systemtap (Ubuntu) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemtap (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchp

[Bug 1557673] [NEW] systemtap does not work on xenial, struct module changes

Public bug reported: Systemtap doesn't work on xenial, due to changes in struct module in the kernel: ubuntu@xenial:~$ sudo stap test.stap In file included from /usr/share/systemtap/runtime/print.c:17:0, from /usr/share/systemtap/runtime/runtime_context.h:22,

[Bug 1547644] Re: systemtap does not work on wily kernel, hrtimer_get_res

this can be reproduced with any stap script using a timer, e.g.: #!/usr/bin/stap probe timer.sec(1) { println("tick") } ** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1557673] Re: systemtap does not work on xenial, struct module changes

debdiff with backported systemtap upstream commit 3f040971e7efb4d323fcb63d83b4337f355c60db. Note the upstream commit also changes tapset/linux/context.stp, but the current xenial systemtap source does not include other commits that require this patch to update context.stp, so I removed the

[Bug 1537125] Re: ubuntu-14.04.04: fail to run systemtap test suites

> I tested systemtap on latest ubuntu16.04 ,make check error and other failures are not yet fixed. it works fine for me, although i'm on x86 so you may be seeing a ppc64-specific failure? # uname -a Linux systemtap 4.4.0-17-generic #33-Ubuntu SMP Tue Mar 29 17:17:28 UTC 2016 x86_64 x86_64

[Bug 1547644] Re: systemtap does not work on wily kernel, hrtimer_get_res

systemtap patched with attached debdiff tested and verified to fix the compilation error. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547644 Title: systemtap does not work on wily kernel,

[Bug 1557673] Re: systemtap does not work on xenial, struct module changes

** Description changed: - Systemtap doesn't work on xenial, due to changes in struct module in the - kernel: + [Impact] - ubuntu@xenial:~$ sudo stap test.stap + Attempting to use systemtap on xenial with the 4.4 kernel results in: + + ubuntu@xenial:~$ sudo stap test.stap In file included

  1   2   3   4   5   6   7   8   9   10   >