** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
** Changed in: linux (Ubuntu Xenial)
Status: New => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570195
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: dpdk (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
This bug was fixed in the package dpdk - 2.2.0-0ubuntu8
---
dpdk (2.2.0-0ubuntu8) xenial; urgency=medium
* d/p/ubuntu-backport-[36-37] fix virtio issues (LP: #1570195):
- don't let DPDK initialize virtio devices still in use by the kernel
- this avoids conflicts between
Never mind, it is working now...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570195
Title:
Net tools cause kernel soft lockup after DPDK touched VirtIO-pci
devices
Status in
Just for the record, after upgrading DPDK (proposed repo),
OpenvSwitch+DPDK isn't not starting up anymore when inside of a VM...
I am double checking everything again...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
This bug was fixed in the package dpdk - 2.2.0-0ubuntu9
---
dpdk (2.2.0-0ubuntu9) yakkety; urgency=medium
* d/p/ubuntu-backport-[36-37] fix virtio issues (LP: #1570195):
- don't let DPDK initialize virtio devices still in use by the kernel
- this avoids conflicts between
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570195
Title:
Net tools cause kernel soft lockup after DPDK touched
FYI - Verified in Proposed.
Next I need to prep some Y tests to reasonably request an upload to
Yakkety to allow migration as Martin indicated.
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
Hello Thiago, or anyone else affected,
Accepted dpdk into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/dpdk/2.2.0-0ubuntu8 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Xenial is released, so we are back in SRU mode.
Therefore I add the matching SRU Template for the upload of 2.2.0ubuntu8 which
is in the unapproved queue atm.
[Impact]
* using devices by DPDK and the kernel at once drives the system into hangs
* the fix avoids using devices in DPDK that are
I'll try to make the rejecting error more "readable" and check the docs to
still match.
Other than that it will be in the next upload for DPDK.
Until then (at your own risk) one can try
https://launchpad.net/~paelzer/+archive/ubuntu/dpdk-packaging-tests
--
You received this bug notification
Now working - a device still "in touch" by the kernel will be rejected
to be used.
EAL: probe driver: 1af4:1000 rte_virtio_pmd
EAL: Error - exiting with code: 1
Cause: Requested device :00:05.0 cannot be used
You have to at least unbind them now to use them with DPDK:
sudo dpdk_nic_bind
The attachment "printk debugging around the issue of never getting out
of the loop in virtnet_send_command" seems to be a patch. If it isn't,
please remove the "patch" flag from the attachment, remove the "patch"
tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the
team.
[This
Discussing with Thomas Monjalon revealed a set of post 2.2 patches.
These will no more let you intialize DPDK while a kernel driver - like
virtio-pci is still bound.
I already proved before on this bug that reinitializing it to virtio-pci will
properly set it up and make it workable again.
So I
Tested latest upstream versions to be sure we not just miss a patch that
already exists.
Bug still happens with linux-4.6-rc4.tar.xz
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570195
** Patch added: "printk debugging around the issue of never getting out of the
loop in virtnet_send_command"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1570195/+attachment/4639236/+files/debug-virtio-hang-dpdk.patch
--
You received this bug notification because you are a member of
Before going into discussions how it "should" be I added more debug code
and gatherered some good case vs bad case data.
First of all it is "ok" to have no more buffers.
I had a prink in a codepath that only triggers when !more_used triggers.
And I've seen plentry for all kind of idx values.
On
pull-lp-source linux 4.4.0-18.34
Build from source with oldconfig and such
Enable all kind of debug for virtio
Add some checks where we expect it to fail
mkdir /home/ubuntu/4.4.0-debug
# not needed make INSTALL_MOD_PATH=/home/ubuntu/4.4.0-debug modules_install
make
Breaking on the two check functions and the calling one to see where
things break:
b virtnet_send_command
# virtqueue_get_buf gets hit by __do_softirq -> napi_poll -> virtnet_poll ->
virtnet_receive -> virtqueue_get_buf all the time.
Need to keep that disabled and step INTO from
Since ftrace failed me I switched to gdb via the qemu -s parameter.
Debuginfo and source of guest kernel on the Host:
sudo apt-get install linux-tools-4.4.0-18-dbgsym
sudo pull-lp-source linux 4.4.0-18.34
sudo mkdir -p /build/linux-XwpX40; sudo ln -s /home/ubuntu/linux-4.4.0
Other than in the upstream discussion I linked above around a similar - but it
seems not related - issue in our case interrupts, memory, and such from lspci
and /proc/interrupts stay just "as-is".
No change due to running dpdk on that device.
I'd not even consider it all too broken if the tools
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570195
Title:
Net tools cause kernel soft lockup after DPDK touched
There is no obvious run-until-success loop in any of the involved code.
Only this in virtnet_send_command could be related
/* Spin for a response, the kick causes an ioport write, trapping
* into the hypervisor, so the request should be handled immediately.
*/
while (!virtqueue_get_buf(vi->cvq,
23 matches
Mail list logo
