** Description changed:
- systemtap fails with:
+ [Impact]
+
+ Attempting to use systemtap with any timer on wily fails with:
In file included from /usr/share/systemtap/runtime/timer.c:17:0,
- from
/tmp/stapNgYUlz/stap_d73751f21cb6a8e35c1e92f712612cc2_4574_src.c:869:
+
verified the package from -proposed fixes the complilation error on the
vivid 3.19 kernel, and does not regress on the trusty 3.13 kernel.
** Tags removed: verification-needed
** Tags added: verification-done verification-trusty-done
verification-vivid-done
--
You received this bug
If anyone is able to reproduce this, I have a debug kernel at this ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152
it prints a debug line when any loopback interface is dev_put/dev_hold,
which may help show where the extra loopback reference is coming from
when this problem
** 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/1547644
Title:
systemtap does not work on wily kernel, hrtimer_get_res
To manage
** 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/1545330
Title:
[wily][regression] systemtap script compilation broken
** 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/1505564
Title:
Soft lockup with "block nbdX: Attempted send on
verification can be done with this script:
#!/bin/bash
modprobe nbd
qemu-nbd -d /dev/nbd0
truncate /tmp/testfile -s 20G
qemu-nbd -c /dev/nbd0 /tmp/testfile
for n in $( seq 1 250 ) ; do
echo $n
( dd if=/dev/zero of=/dev/nbd0 bs=1 & )
done
qemu-nbd -d /dev/nbd0
after running that, on an
I've tested this backported driver for basic functionality - boots, can
connect to the interface, ran iperf tests and several flent tests - but
I can't reproduce this problem, so I can't test to verify this backport
and updated firmware actually fixes it.
Anyone who can reproduce this problem,
This isn't actually an issue with the serial port driver, it's the
printk code that is failing to schedule while printing out all the msgs.
During printk(), if the console lock is held, the msgs are queued up,
and inside console_unlock() any queued msgs are sent to the console
before unlocking:
** Summary changed:
- serial port driver under heavy load can hang system
+ lots of printk to serial console can hang system for long time
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1534216
> /usr/share/systemtap/runtime/linux/print.c:242:20: error: ?struct module? has
> no member named ?module_core?
> THIS_MODULE->module_core,
...
> root@ubuntu:~/systemtap-2.9# uname -a
> Linux ubuntu 4.4.0-15-generic #31-Ubuntu SMP Fri Mar 18 19:06:23 UTC 2016
> ppc64le ppc64le ppc64le GNU/Linux
this is (mostly) fixed in 2 commits, from the original bug (bug 1505564)
kernel level commit 5a3a466ae3c86ad6b8fc36c2efc5f541ef0ed89e (from
git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git lts-backport-vivid)
partially fixes this problem, by using the console_may_schedule var
correctly. The
** Patch added: "lp1578654-trusty-v2.debdiff"
https://bugs.launchpad.net/ubuntu/trusty/+source/multipath-tools/+bug/1578654/+attachment/4664865/+files/lp1578654-trusty-v2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
second version of the debdiff attached, updated as an unrelated patch
was added to multipath while working on 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/1578654
Title:
multipath does
** Changed in: multipath-tools (Ubuntu Trusty)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: multipath-tools (Ubuntu Trusty)
Importance: Undecided => Medium
** Changed in: multipath-tools (Ubuntu Trusty)
Status: New => In Progress
--
You received
This is a dup of bug 1545330, and should be fixed with kernel
4.4.0-10.25
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577579
Title:
Problems on rawhide, incorrect inclusion of runtime.h
To
Verified without patch, multipath does not change fiberchannel
dev_loss_tmo parameter, and with patch multipath does change parameter.
--
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:
_tmo
It should show the value that was configured in multipath.conf.
[Regression Potential]
none. This fixes multipath to correctly set sysfs attributes, as it did
not work at all before.
** Affects: multipath-tools (Ubuntu)
Importance: Medium
Assignee: Dan Streetman (ddstreet)
Stat
** Patch added: "lp1578654-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1578654/+attachment/4656460/+files/lp1578654-trusty.debdiff
** Changed in: multipath-tools (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification
bug is only in trusty; precise has older code that is not broken, and
wily/xenial already have this commit.
--
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 sysfs
** Description changed:
[Impact]
multipath has configuration settings such as "dev_loss_tmo" and
"fast_io_fail_tmo" which multipath uses to change the underlying
device's parameters. However, it fails to set any of them; it is trying
to write the parameters to the sysfs device's
or -i386 or any
other qemu-system-* besides -ppc and -ppc64.
** Affects: libvirt (Ubuntu)
Importance: Medium
Assignee: Dan Streetman (ddstreet)
Status: In Progress
** Tags: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Description changed:
[impact]
qemu's various architecture-specific emulators expect the pci bus to be
referred to either as 'pci' or 'pci.0', and libvirt must know which to
use. On trusty, the latest qemu-system-ppc (and ppc64) emulators
require 'pci.0' when using the 'pseries'
** Description changed:
[impact]
qemu's various architecture-specific emulators expect the pci bus to be
referred to either as 'pci' or 'pci.0', and libvirt must know which to
use. On trusty, the latest qemu-system-ppc (and ppc64) emulators
require 'pci.0' when using the 'pseries'
** Description changed:
[impact]
qemu's various architecture-specific emulators expect the pci bus to be
referred to either as 'pci' or 'pci.0', and libvirt must know which to
use. On trusty, the latest qemu-system-ppc (and ppc64) emulators
require 'pci.0' when using the 'pseries'
** Patch added: "lp1571075.debdiff"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571075/+attachment/4637910/+files/lp1571075.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
To check any qemu-system-* emulator's expected pci bus naming:
$ qemu-system-ppc64 -nographic -nodefconfig -nodefaults -machine pseries
-monitor stdio
QEMU 2.0.0 monitor - type 'help' for more information
(qemu) Warning: Disabling some instructions which are not emulated by TCG (0x0,
0x4)
> should we close this bug?
probably, yeah.
> Can you explain under which cases this bug is needed? Does it depend
on the specific ppc64 hardware?
i suspect this is a problem on trusty, when using ppc hardware or x86
hardware (meaning, setting up a ppc guest with virsh on either x86 or
ppc host
also, I'm also using xfce window manager, and upgraded from wily to
xenial last night.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1568604
Title:
xubuntu 16.04 beta loses mouse cursor when
this happens even without suspending; I can just close my laptop (which
is set to only lock screen), and when I open it and unlock, the pointer
is not visible (except the lock screen, where the pointer is visible).
in my Xorg.0.log, the screen lock/unlock logs:
[ 5359.220] (II) intel(0): switch
> can anyone affected check that a switch to vt1 and back to vt7 brings
cursor back
yep, that does restore the pointer cursor, at least on my system.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
there appear to be other problems with qemu-system-ppc64, as the ubuntu
powerpc iso fails immediately after the boot menu, so this bug probably
doesn't really matter.
** Changed in: libvirt (Ubuntu)
Importance: Medium => Low
--
You received this bug notification because you are a member of
v3: same as previous debdiff, but with (LP: #1578654) corrected in the
debian/changelog (was missing "#" in v2)
** Patch added: "lp1578654-trusty-v3.debdiff"
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1578654/+attachment/4670099/+files/lp1578654-trusty-v3.debdiff
--
You
Public bug reported:
ifupdown changes a device's mtu differently, between "inet" section mtu
and "inet6" section mtu. For "inet", ifupdown changes the device's mtu,
using 'ip link set DEV mtu NNN'. However for "inet6", ifupdown changes
the interface's IPv6 mtu, using 'sysctl -q -e -w
moving this to wontfix as i cant get a response from the original
reporter.
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
** Changed in: linux (Ubuntu Trusty)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of
> moving this to wontfix as i cant get a response from the original
reporter.
meaning original reporter who can reproduce this, not meaning Rafael.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> and the tl;dr is that IPv6 supports per protocol, rather than
interface.
the ipv6 mtu is for situations where the host's ipv6 connection uses (at
some point down the line) ipv6 tunneling, for example 6in4 or 6rd. The
ipv6 mtu is strictly a subset of the device mtu; it can never be more
than
> In the original bug where one is comparing ip output of MTU; is there
something *not* working ?
in that original bug, the user is trying to set up ipv6 tunneling:
"This scenario is quiet common when using tunnels (e.g. Sixxs) to provide IPv6
connectivity. My IPv6 MTU needs to be 20 bytes
> In what circumstances do dhcpv6 servers hand out an IPv6 address without also
> reporting
> the prefix length the client should use? Something seems wrong here. (Is it
> me? :)
unfortunately the dhcpv6 spec (RFC 3315) doesn't provide a way for a
dhcpv6 server to tell a client what the
Public bug reported:
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address
has a /64 prefix, but that is not necessarily true, and if the subnet is
different than /64 those clients will not be able to reach other
addresses in that /64 prefix because the other systems
** Patch added: "lp1609898-precise.debdiff"
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714181/+files/lp1609898-precise.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "lp1609898-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714182/+files/lp1609898-trusty.debdiff
** Patch removed: "lp1609898.debdiff"
Patched builds for precise, trusty, xenial at ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1609898
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1609898
Title:
dhclient incorrectly
** Patch added: "lp1609898-xenial.debdiff"
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714183/+files/lp1609898-xenial.debdiff
** Changed in: isc-dhcp (Ubuntu)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: isc
yakkety build also at ppa
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1609898
Title:
dhclient incorrectly assumes a /64 ipv6 prefix
To manage notifications about this bug go to:
** Patch added: "lp1609898-yakkety.debdiff"
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714232/+files/lp1609898-yakkety.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "lp1609898.debdiff"
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714179/+files/lp1609898.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> I understand this scenario; however, what I don't understand is why
> if we're setting mtu 9002 on the underlying devices, why the mtu on the
> "virtual" device (bond0)
> matters vs. the mtu setting of the ipv6 link, especially since this is ipv6
> only.
I think the slave interface mtu will be
Patch is still in development, please don't evaluate the debdiff yet.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1661324
Title:
add pull-ca-source to ubuntu-dev-tools
To manage notifications
As a comment to those expecting that disabling swap will prevent kswapd
from doing anything, that's incorrect. kswapd also is responsible for
clearing out the page cache, so even with swap disabled you'll still see
it doing work, especially during heavy IO that uses the page cache. For
example,
with udev version 204-5ubuntu20.22 the /dev/disk/by-id/ symlinks are
incorrect:
ubuntu@ip-172-31-27-212:/dev/disk/by-id$ apt list --installed udev
Listing... Done
udev/trusty-updates,now 204-5ubuntu20.22 amd64 [installed,upgradable to:
204-5ubuntu20.24]
ubuntu@ip-172-31-27-212:/dev/disk/by-id$
debdiff containing patch to zesty pull-lp-source. This applies to T/X/Y
pull-lp-source also.
** Bug watch added: Debian Bug tracker #854010
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854010
** Also affects: ubuntu-dev-tools (Debian) via
Looks like Corey Bryant already wrote a similar 'pull-uca-source' script:
http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/view/head:/pull-uca-source
however that one only uses the LP -staging PPAs, and doesn't support
using binary package names. It also pulls the entire list of
** Patch removed: "lp1661324-zesty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1661324/+attachment/4812145/+files/lp1661324-zesty.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Move devel to a git clone of the ubuntu-dev-tools bzr repo.
https://code.launchpad.net/~ddstreet/+git/ubuntu-dev-
tools/+ref/lp1661324
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1661324
Title:
Corey merged this, thanks!
** Changed in: ubuntu-dev-tools (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1661324
Title:
add pull-ca-source to
Public bug reported:
The ubuntu-dev-tools package provides very useful scripts to get source
for packages in debian and ubuntu, but a tool to get source from the
Cloud Archive is also needed.
** Affects: ubuntu-dev-tools (Ubuntu)
Importance: Low
Assignee: Dan Streetman (ddstreet
** Patch added: "lp1661324-zesty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1661324/+attachment/4812145/+files/lp1661324-zesty.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
PPA with x/y/z builds containing a devel version of the pull-ca-source script:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1661324
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1661324
Title:
Has this been committed into trusty yet? I rebased my trusty pull
request from comment 24; those patches will apply cleaning into the
trusty systemd repository. I'm not sure if there is any other bug
holding up trusty.
--
You received this bug notification because you are a member of Ubuntu
Actually, the commit that introduces the problem is the one before
ad740b71fba84e3d17bc0507d2cb696935cd944b. The actual offending commit
is:
6c39aa938110688cbbd9ad8628f2dc388926e384 ("ixgbe: Add support for VLAN
promiscuous with SR-IOV")
which is cherry-picked from upstream commit
> Invalid
** Changed in: linux (Ubuntu Xenial)
Status: Invalid => In Progress
** Changed in: linux (Ubuntu Zesty)
Status: In Progress => Invalid
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: linux (Ubuntu Xenial)
The commit that fixes this, f60439bc21e3337429838e477903214f5bd8277f, is
already in yakkety and later; this is needed only for Xenial.
Additionally, since the problem commit that this fixes was not included
in 4.4 - it was backported into the Xenial kernel via bug 1536473 - the
commit that fixes
fyi to those following, kernel-team list submission:
https://lists.ubuntu.com/archives/kernel-team/2017-January/082033.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1658491
Title:
VLAN SR-IOV
> hey @ddstreet I've just tried your kernel at
> https://launchpad.net/~ddstreet/+archive/ubuntu/lp1626894 and it now shows
> both disks for me.
> Please let me know how we can get this moved along. Happy to test.
It's already in -proposed, please see
** Changed in: linux (Ubuntu)
Status: Fix Committed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1651602
Title:
NVMe driver regression for non-smp/1-cpu systems
To manage
> Could someone please look at the autopkgtest regressions in
> http://people.canonical.com/~ubuntu-
> archive/pending-sru.html against systemd please?
I'll ignore the no-longer-supported LTS kernel tests, so that leaves:
> Regression in autopkgtest for network-manager (ppc64el): test log
This
So the only new autopkgtest failures are:
> Regression in autopkgtest for umockdev (armhf): test log
this fails with:
ERROR:tests/test-umockdev-record.c:706:t_system_single: assertion failed
(_tmp10_ == ""): ("Cannot access device /dev/loop0: No such file or
directory\n" == "")
this is the
It looks like that specific uvtool version did get released for Utopic,
so maybe the build system rejected it as a duplicate...I suppose the
version should be 0~bzr92-0ubuntu1.1 instead to avoid the version
collision? (My bad on putting the wrong version string in the debdiff,
sorry)
** Patch removed: "lp1372368-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/uvtool/+bug/1372368/+attachment/4778042/+files/lp1372368-trusty.debdiff
** Patch added: "lp1372368-trusty.debdiff"
updated debdiff to replace the bad (duplicate in Utopic) version
0~bzr92-0ubuntu2 with version 0~bzr92-0ubuntu1.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1372368
Title:
VM creation fails on
Verified with udev 229-4ubuntu16, all /dev/disk/by-id/ NVMe symlinks are
present and correct.
** 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.
> 1) The mechanism employed of redirecting s and l (destination buffer and
> length remaining count) means that the code inside the redirection is
> incredibly fragile. The code inside the switch should be pulled out into
> a separate function. Then the redirection would become unnecessary.
> This seems a bit inconsistent to me, for example the symlink for sdb's does
> not include Model/Serial, where as they do for nvme's. That alone is a
> format difference on how the symlinks are being created and which is why I
> was asking, as it seems weird to me.
there's no required format for
https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/lp1453330
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1453330
Title:
pull-{lp,debian}-source not getting source for binary because DDE is
Verified with kernel 3.13.0-109-generic on AWS instance NVMe drives are
all initialized.
** 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.
PPA containing build with commit f60439bc21e3337429838e477903214f5bd8277f
backported to Xenial kernel:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1658491
** Tags added: sts sts-sru
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Verified, with the 4.4.0-62 kernel, two guests with SRIOV interfaces
configured for different vlans were able to communicate with each other
(incorrect behavior). With kernel 4.4.0-63, the same guests were not
able to communicate (correct behavior).
** Tags removed: verification-needed-xenial
**
** Patch added: "lp1657489-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1657489/+attachment/4805880/+files/lp1657489-trusty.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
[Impact]
Without this patch, Xen guest devices that use MSI interrupts may use
the incorrect pirq and fail to re-configure their MSI interrupts. For
example, Xen guests with multiple NVMe controllers will fail to
correctly configure all their MSI interrupts, due to the way
** Description changed:
[Impact]
This bug fixes the root problem reported in bug 1648449, so its
description can be mostly reused here:
On an Amazon AWS instance that has NVMe drives, the NVMe drives fail to
initialize, and so aren't usable by the system. If one of the NVMe
** Description changed:
[Impact]
Without this patch, Xen guest devices that use MSI interrupts may use
the incorrect pirq and fail to re-configure their MSI interrupts. For
example, Xen guests with multiple NVMe controllers will fail to
correctly configure all their MSI interrupts,
Wayne, Guillaume, roots, Stéphane, can any/all of you test with the
-proposed kernel (using directions from comment 39) to verify the bug is
fixed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Verified with the 4.4.0-62-generic kernel on an AWS i3 instance, all the
NVMe drives initialized successfully.
** 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
Verified with the 4.8.0-36-generic kernel on an AWS i3 instance, all the
NVMe drives initialized successfully. Checked the git log and verified
the initial commit had been fully reverted (see comment 7).
** Tags removed: verification-needed-yakkety
** Tags added: verification-done-yakkety
--
Booted the 4.8.0-36-generic kernel with maxcpus=0 parameter and verified
all NVMe drives were initialized.
** Tags removed: verification-needed-yakkety
** Tags added: verification-done-yakkety
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Verified with the 4.8.0-36-generic kernel on an AWS i3 instance, all the
NVMe drives initialized successfully.
** Tags removed: verification-needed-yakkety
** Tags added: verification-done-yakkety
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
This is reproducable with the latest upstream kernel as well (4.10), so
this isn't a bug in the ubuntu kernel; it will require an upstream fix
and backport that into xenial/yakkety.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** 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.
I have a quick reproducer now:
NCPUS=...whatever...
for n in $( seq 1 $NCPUS ) ; do ( dd if=/dev/zero of=/mnt/test/out$n bs=1024k
count=1024k ) & done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On an i3 instance in east-1, where i can reproduce fairly easily, the
errors i'm getting unfortunately don't help. the nvme controller is
failing some requests, but it isn't providing any useful info about why
it doesn't like the requests. for example, here is some debug I added:
[ 1464.634709]
Note on above; once hotadd is disabled, the xen balloon driver will
still perform the memory hotplug, but the added pages won't be available
for use. So you can check /proc/zoneinfo, and look at the Normal zone,
e.g.:
with hotadd enabled (the default in Ubuntu):
Node 0, zone Normal
pages free
> * When would you (roughly) expect an AMI to be available?
it's too early to say, there are various steps before the fix lands in
an AMI.
> * How high is your confidence in the 40-vm-hotadd.rules change
workaround? Sounds like very high?
100%. if it doesn't work for you, please let me know.
@rram can you try to reproduce with us-west-2? I'm able to repro in
east-1 but not in west-2.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1668129
Title:
Amazon I3 Instance Buffer I/O error on
@rram what region are you using?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1668129
Title:
Amazon I3 Instance Buffer I/O error on dev nvme0n1
To manage notifications about this bug go to:
@matt-e do you have a quicker reproducer I can use? I've been trying
bonnie++ from the description, but that doesn't repro at all in west-2
for me, and only once in east-1 so far. Also what AMI are you using in
west-2 that shows the problem?
--
You received this bug notification because you
This is a side effect / duplicate of bug 1224007. The initial problem
is the high vlan mtu setting, and the "File Exists" error is because
ifup doesn't unwind on failure, so the interface is ip but not
configured, which causes ifup to keep failing because it isn't expecting
the interface to
** Summary changed:
- VM creation fails on Utopic
+ VM creation fails on Utopic/Trusty
** Description changed:
[impact]
"uvt-kvm create foo" produces the error:
uvt-kvm: error: libvirt: internal error: process exited while connecting
to monitor: 2014-09-22T09:27:46.422743Z
This debdiff adds the original patch from this bug to trusty.
** Patch added: "lp1372368-trusty.debdiff"
https://bugs.launchpad.net/ubuntu/+source/uvtool/+bug/1372368/+attachment/4730232/+files/lp1372368-trusty.debdiff
** Description changed:
+ [impact]
+
"uvt-kvm create foo" produces
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1372368
Title:
VM creation fails on Utopic
To manage notifications about this bug go to:
101 - 200 of 4672 matches
Mail list logo
