apport information
** Attachment added: "PulseList.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287566/+files/PulseList.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "Lspci.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287559/+files/Lspci.txt
--
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/1843323
apport information
** Attachment added: "ProcInterrupts.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287564/+files/ProcInterrupts.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "ProcModules.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287565/+files/ProcModules.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "ProcCpuinfoMinimal.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287562/+files/ProcCpuinfoMinimal.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "CurrentDmesg.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287557/+files/CurrentDmesg.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Attachment added: "Lsusb.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287560/+files/Lsusb.txt
--
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/1843323
apport information
** Attachment added: "IwConfig.txt"
https://bugs.launchpad.net/bugs/1843323/+attachment/5287558/+files/IwConfig.txt
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
apport information
** Tags added: apport-collected bionic
** Description changed:
The latest kernel upgrade makes it impossible to use the scroll wheel of
one specific mouse.
Affected Ubuntu release: 18.04.3
Last working kernel version: 4.15.0-58
Affected kernel
** Tags added: input mouse
--
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/1843323
Title:
Kernel 4.15.0-59 (and onwards) breaks scroll wheel of USB mouse
(A4Tech X5-50D)
Status in
Public bug reported:
The latest kernel upgrade makes it impossible to use the scroll wheel of
one specific mouse.
Affected Ubuntu release: 18.04.3
Last working kernel version: 4.15.0-58
Affected kernel versions: 4.15.0-59, 4.15.0-60, 4.15.0-62, …
I've several X5-50D
I can confirm too that the BIOS update from ASUS fixed the problem
(nerve wrecking moment, though, for a someone new to Linux/Ubuntu).
Thanks for the help!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://lists.ubuntu.com/archives/kernel-team/2019-September/103672.html
--
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/1836912
Title:
ipv4: enable route flushing in network namespaces
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
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/1837223
Title:
shiftfs: add O_DIRECT support
Status in
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
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/1837231
Title:
UBUNTU: SAUCE: shiftfs: pass correct
See
https://lists.ubuntu.com/archives/kernel-team/2019-September/103670.html
--
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/1836912
Title:
ipv4: enable route flushing in network
After discussing this with the Team I really think it is ok to release this.
As stated before we confirmed:
- that on a good kernel the fix works
- the fix doesn't break features if not running on the new kernel
- the fix is confirmed to get in the kernel soon (this kernel cycle)
In addition
Thanks a lot Fabiano!
So I summarize:
- #7 is in no way a degradation to #4:
- all cap-ibs= modes are failing on that before and after
- that means the new qemu didn't break anything in that regard
- #9 confirms that as soon as we have a fixed kernel under that new disco-qemu
it will work
Thanks a lot faro...@br.ibm.com.
Especially for noting the known firmware featues influencing this in your case
and then combining cap-ibs=workaround,cap-ccf-assist=on to prove the new
features work.
I see that cap-ccf-assist=on can be used and successfully grants the guest
[0.00]
Per my Tests we already know that on DD2.0 HW things are fine, you can't enable
CCF which is expected, but it doesn't break formerly working cases there.
And I'm not sure if there is DD2.3 HW in the wild already.
Furthermore I was in contact with Leonardo yesterday, he is working with
the
I think I found the missing kernel bit.
As reported it needs:
2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to
kvmppc_get_cpu_char()
Which was brought into Bionic/Cosmic already as part of bug LP1822870.
This is only needed when I'd be on new HW/FW
Bionic: $ grep -Hrn
Back in bug 1822870 it was reported that the Disco kernel is only
missing 92edf8df which is still applied to Disco these days. Maybe due
to that 2b57ecd0208f was lost.
@Kernel Team - could you go through all changes that made up bug 1822870
and ensure whatever is missing will be added to Disco?
BTW - Thanks for the work on this Rafael!
--
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/1834522
Title:
Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as
Lacking better options I gave this some extra testing on a pre DD2.3 P9 box.
revision: 2.2 (pvr 004e 1202)
I though at least CCF=off I should be able to test with these chips and that
worked fine.
Summary:
- the new versions make cap-ibs=fixed-ibs work on DD2.2
- CCF=off works with
FYI - the related autopkgtest issues would now be resolved.
--
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/1832622
Title:
QEMU - count cache flush Spectre v2 mitigation (CVE) (required
(Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: In Progress
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received th
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Disco)
Status: New => Confirmed
** Changed in: linux (Ubuntu Disco)
Importance: Undecided => High
** No longer affects: linux (Ubuntu Cosmic)
** No longer affects: linux (Ubuntu
As qemu (seems) to be unable to do much I'll set it to triaged (we
understand what is going on) and low (can't do much).
** Changed in: qemu (Ubuntu)
Status: Incomplete => Triaged
** Changed in: qemu (Ubuntu)
Importance: Medium => Low
--
You received this bug notification because you
sudo lxc exec b1 -- rm dummy.file
sudo zfs list default/containers/b1 # will show +1GB on a non-fixed kernel and
-1GB on a fixed kernel
Target Kernels: All LTS kernels with shiftfs support.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner
This is a silly but useful distribution check with log10 of the allocation
sizes:
Fast:
108 3
1293 4
12133 5
113330 6
27794 7
1119 8
Slow:
194 3
1738 4
17375 5
143411 6
55 7
3 8
I got no warnings about missed
I modified the kernel to have a few functions non-inlined to be better tracable:
vfio_dma_do_map
vfio_dma_do_unmap
mutex_lock
mutex_unlock
kzalloc
vfio_link_dma
vfio_pin_map_dma
vfio_pin_pages_remote
vfio_iommu_map
Then run tracing on this load with limited to the functions in my focus:
$ sudo
(systemtap)
probe module("vfio_iommu_type1").function("vfio_iommu_type1_ioctl") {
printf("New vfio_iommu_type1_ioctl\n");
start_stopwatch("vfioioctl");
}
probe module("vfio_iommu_type1").function("vfio_iommu_type1_ioctl").return {
timer=read_stopwatch_ns("vfioioctl")
The iommu is locked in there early and the iommu element is what is passed from
userspace.
That represents the vfio container for this device (container->fd)
qemu:
if (ioctl(container->fd, VFIO_IOMMU_MAP_DMA, ) == 0
kernel:
static long vfio_iommu_type1_ioctl(void *iommu_data,
unsigned
FWIW, this just happened again while trying out the latest mainline
kernel from https://kernel.ubuntu.com/~kernel-ppa/mainline
* Kernels up to v5.3-rc5 work fine, but booting it takes up ~36MB of /run
(unpacking during boot)
on the Dom0 here.
* Kernel v5.3-rc6 seems to take up even more,
Each qemu (version) is slightly different in the road to this, but then
seems to behave.
This one is slightly better to get "in front" of the slow call to map all the
memory.
$ virsh nodedev-detach pci__21_00_1 --driver vfio
$ gdb /usr/bin/qemu-system-x86_64
(gdb) b vfio_dma_map
(gdb)
I could next build a test kernel with some debug around the vfio iommu dma map
to check how time below that call is spent.
I'm sure that data already is hidden in some of my trace data, but to
eventually change/experiment I need to build one anyway.
I expect anyway to summarize and go into a
Reference:
this is the call from qemu that I think we see above (on x86) is at [1].
If this time the assumption is correct the kernel place would be at
vfio_iommu_type1_ioctl.
For debugging:
$ gdb qemu/x86_64-softmmu/qemu-system-x86_64
(gdb) catch syscall 16
(gdb) run -m 131072 -smp 1
Many ioctls (as expected) but they are all fast and match what we knew from
strace.
Thread 1 "qemu-system-x86" hit Catchpoint 1 (call to syscall ioctl),
0x772fae0b in ioctl () at ../sysdeps/unix/syscall-template.S:78
78 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0
Just when I thought I understood the pattern.
Sixth run (again kill and restart)
6384 9.826097 <... ioctl resumed> , 0x7ffcc8ed6e20) = 0 <19.495688>
So for now lets summarize that it varies :-/
But it always seems slow.
--
You received this bug notification because you are a member of
The above was through libvirt, doing that directly in qemu now to throw
it into debugging more easily:
$ virsh nodedev-detach pci__21_00_1 --driver vfio
$ qemu/x86_64-softmmu/qemu-system-x86_64 -name guest=test-vfio-slowness
-m 131072 -smp 1 -no-user-config -drive
On x86 this looks pretty similar and at the place we have seen before:
45397 0.73 readlink("/sys/bus/pci/devices/:21:00.1/iommu_group",
"../../../../kernel/iommu_groups/"..., 4096) = 34 <0.20>
45397 0.53 openat(AT_FDCWD, "/dev/vfio/45", O_RDWR|O_CLOEXEC) = 31
I built qemu head from git
$ export CFLAGS="-O0 -g"
$ ./configure --disable-user --disable-linux-user --disable-docs
--disable-guest-agent --disable-sdl --disable-gtk --disable-vnc --disable-xen
--disable-brlapi --enable-fdt --disable-bluez --disable-vde --disable-rbd
--disable-libiscsi
I was by accident changing the kernel task, fixed now.
** Changed in: linux (Ubuntu Eoan)
Status: Fix Released => In Progress
** Changed in: libvirt (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: libvirt (Ubuntu Eoan)
Assignee: Christian Ehrhardt (p
Tests confirmed that the recent libvirt did in fact work fine.
FYI - this was analyzed in bug 1841066 which will also be the bug to track this
little qemu addition which has to go alongside the libvirt portion of this once
considering SRUs.
** Changed in: linux (Ubuntu Eoan)
Status: In
Hmm, with strace showing almost a hang on a single of those ioctl calls
you'D think that is easy to spot :-/
But this isn't as clear as expected:
sudo trace-cmd record -p function_graph -l vfio_pci_ioctl -O graph-time
Disable all but 1 CPUs to have less concurrency in the trace.
=> Not much
On this platform strace still confirms the same paths:
And perf as well (slight arch differences, but still mem setup).
46.85% [kernel] [k] lruvec_lru_size
16.89% [kernel] [k] clear_user_page
5.74% [kernel] [k]
As assumed this really seems to be cross arch and for all sizes.
Here 16 PU, 128G on ppc64el:
#1: 54 seconds
#2: 7 seconds
#3: 23 seconds
Upped to 192GB this has:
#1: 75 seconds
#2: 5 seconds
#3: 23 seconds
As a note, in this case I checked there are ~7 seconds before it does
into
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
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/1838677
Title:
shiftfs: allow overlayfs
Status in
** Tags removed: verification-needed-bionic verification-needed-disco
** Tags added: verification-done-bionic verification-done-disco
--
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/1836910
Another bunch of related changes might be important.
Not sure how much of that will go into SRUs - I hope not all of it.
Already in Eoan we should try to use a reduced set or we could go directly to
5.5 which has other known issues.
63acb7bf qemu_process: Prefer generic qemuMonitorGetGuestCPU
I started a test PPA [1] and an MP [2] to get this into Eoan.
@Rafael could you test this on the same system you used last time and review
the MP?
[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1828495-archcap-eoan
[2]:
Recent libvirt versions (5.5) added more for arch_capabilities.
Lets get that into Eoan before considering the SRUs back to Bionic afterwards.
commit ver subject
2674d00e 5.5 qemu: Drop MSR features from host-model with old QEMU
8eb4a89f 5.5 qemu: Forbid MSR features with old QEMU
c8ec678f 5.5
Progress
** Changed in: libvirt (Ubuntu Eoan)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** No longer affects: libvirt (Ubuntu Cosmic)
** No longer affects: linux (Ubuntu Cosmic)
** No longer affects: qemu (Ubuntu Cosmic)
--
You received this bug notification because you
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
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/1838677
Title:
shiftfs: allow overlayfs
Status in linux
As already outlined in the report by Daniel, on the libvirt side there is
nothing to action on.
While one might wonder about a downstream only feature being upstream, I don't
see much benefit in adding a delta to Ubuntus libvirt to remove it. It is an
opt-in feature and does not affect users in
Thanks Rafael, I reviewed the MP, thanks for the fixup.
I sponsored it into bionic-unapproved.
It would be great if the SRU Team could evaluate and accept this minor update
to the Former upload.
--
You received this bug notification because you are a member of Kernel
Packages, which is
@Ai Lim, it would be great to get your testing on the PPA asap.
@Rafael - we already have the fixup. I have provided feedback on the MP,
I think we can quickly sponsor something new. That means we don't need
to go the full verification-failed, reject, new upload path - instead we
will ask to
Per [1] this means "In Progress" until such a seed/dependency change is
done.
[1]: https://wiki.ubuntu.com/MIRTeam#Process_states
** Changed in: thunderbolt-tools (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages,
@cking - yes the comments by Seth and the later update of Doko a year ago are
clear.
This is ready to land just someone needs to add a dependency or seed change to
pull it in.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
Also I wonder if this should be a dup to 1838751 and better track all three
changes in one bug?
But so far I keep that a suggestion for the reporter or the kernel Team
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Changed to be a kernel bug, as this doesn't seem for bind9 (as reported
right now)
** Package changed: bind9 (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Changed to be a kernel bug, as this doesn't seem for bind9 (as reported
right now)
** Package changed: bind9 (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
SRU request here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677
Patchset here:
https://github.com/brauner/ubuntu-disco/tree/overlayfs_on_shiftfs
Mailing list patchset posting here:
https://lists.ubuntu.com/archives/kernel-team/2019-August/102741.html
** Changed in: linux (Ubuntu)
SRU request here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1838677
Patchset here:
https://github.com/brauner/ubuntu-disco/tree/overlayfs_on_shiftfs
Mailing list patchset posting here:
https://lists.ubuntu.com/archives/kernel-team/2019-August/102741.html
** Tags added: shiftfs
--
ce-cli containerd.io
sudo systemctl stop docker
cat < Christian Brauner (cbrauner)
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Kernel
You can do so even per-size via e.g.
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
As discussed the later the allocation the higher the chance to fail, so
re-check the sysfs file after each change if it actually got that much memory.
The default size is only a boot time parameter.
Summary:
As I mentioned before (on the other bug that I referred).
The problem is that with a PT device it needs to reset and map the VDIO devices.
So with >0 PT devices attached it needs an init that scales with memory size of
the guest (see my fast results with PT but small guest memory).
As I
** Description changed:
SRU Justification
Impact: Currently, the /proc/sys/net/bridge folder is only created in
the initial network namespace. This blocks use-cases where users would
like to e.g. not do bridge filtering for bridges in a specific network
namespace while doing so for
** Description changed:
SRU Justification
Impact: Currently, the /proc/sys/net/bridge folder is only created in
the initial network namespace. This blocks use-cases where users would
like to e.g. not do bridge filtering for bridges in a specific network
namespace while doing so for
to shiftfs.
Test Case: Compile kernel with patch and see that compiler does not
complain anymore.
Target Kernels: All LTS kernels with shiftfs support.
Patches:
https://github.com/brauner/ubuntu-disco/tree/shiftfs_direct_io
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
--
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/1837223
Title:
shiftfs: add O_DIRECT support
Status in linux
/ubuntu-disco/tree/shiftfs_direct_io
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Christian Brauner (cbrauner)
Status: Confirmed
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian B
eam kernel
Status in linux package in Ubuntu:
Fix Released
Bug description:
https://github.com/lxc/lxc/issues/1867
As of issue about Debian 9, Christian Brauner concluded
"unprivileged fuse mounts is a feature available in the Ubuntu kernel
only atm. We are actively working on
** Description changed:
- Tools such as vpnc try to flush routes when run inside network
- namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This
- currently does not work because flush is not enabled in non-initial
- network namespaces.
- Since routes are per network namespace it is
** Description changed:
- Currently, the /proc/sys/net/bridge folder is only created in the initial
- network namespace. This patch ensures that the /proc/sys/net/bridge folder
- is available in each network namespace if the module is loaded and
- disappears from all network namespaces when the
Relevant upstream commits are:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe
Relevant upstream commit is:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cdda5f1d6adde02da591ca2196f20289977dc56
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages,
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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/1836910
Title:
br_netfilter: namespace sysctl operations
Status in
Public bug reported:
Tools such as vpnc try to flush routes when run inside network
namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This
currently does not work because flush is not enabled in non-initial
network namespaces.
Since routes are per network namespace it is safe to enable
Public bug reported:
Currently, the /proc/sys/net/bridge folder is only created in the initial
network namespace. This patch ensures that the /proc/sys/net/bridge folder
is available in each network namespace if the module is loaded and
disappears from all network namespaces when the module is
Some updates to libvirt:
- we already have ssbd/md-clear through security updates
- rdctl-no, ibrs-all, skip-l1dfl-vmentry, mds-no are part of
c8ec678f cpu_map: Introduce IA32_ARCH_CAPABILITIES MSR features
- arch_capabilities itself comes in 511df17a
There are also updates to the
FYI - the related qemu changes have a PPA at
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1836154-s390x-
hwmodels/+packages
--
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/1836153
Tags pushed and uploaded to B/D unapproved for the SRU Team to do a
final review and accept.
I also marked Cosmic as Won't Fix as it will be out of support before
this SRU completes.
Further I added libvirt Tasks where the next step is for rafaeldtinoco
to find if/what we'd need to make the
Due to some accident on bug 1826410 it was closed by scripts/automation every
now and then.
To avoid this APW recommended to create a new bug and make the old bug a dup.
This was done and this is the clone that from now on shall be worked on without
these stray updates.
--
You received this
apport-collect makes no sense for this which is more a feature/packaging
request, setting confirmed
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Status: Confirmed => Triaged
** Changed in: linux (Ubuntu)
Importance: Undecided => High
**
*** This bug is a duplicate of bug 1836708 ***
https://bugs.launchpad.net/bugs/1836708
This is now a dup of its own clone per our IRC discussion:
[10:12] cpaelzer, it sometimes is just easier to make a new bug and dup
the old against it :)
[10:18] to get rid of the stray tracking updates
Public bug reported:
Hi,
Debian packages libbpf and so far does so out of the kernel source [1].
There is some movement to separate that from the kernel source [2] but this
isn't ready yet. So far it is just a sync of the subtree out of the kernel
sources.
Since we do not share our kernel
Debian:
root@d10-sid:~# apt-cache show libbpf-dev libbpf4.19
Package: libbpf-dev
Source: linux
Version: 4.19.37-5
Installed-Size: 378
Maintainer: Debian Kernel Team
Architecture: amd64
Depends: libbpf4.19 (= 4.19.37-5)
Description-en: eBPF helper library (development files)
libbpf is a library
The Disco upload is in disco-unapproved waiting for the SRU Teams review
now.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1831775
Title:
ss seems
And qemu 4.0 is in Eoan, so this release is "fix released" (for the
scope of adding the features, not the just discussed versioned CPUs)
** Changed in: qemu (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: qemu (Ubuntu Eoan)
Assignee: Christian Ehrhar
Public bug reported:
One common case of facing a new dkms build error is on new uploads to the
Ubuntu archive.
Proposed migration will trigger the dkms install of a bunch of modules and e.g.
some of them will fail on a new kernel.
The default behavior has a local system & user in mind and will
The series was merged in 3a1acf5d47295d22ffdae0982a2fd808b802a7da as a prep to
qemu 4.1.
But the changes are rather invasive and after a review I think for the SRU we
will not add them.
For example the changes around:
"model runnability guarantees won't apply to unversioned CPU models
** Changed in: linux (Ubuntu)
Status: Expired => Fix Released
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Per [1] this symbol is present in: firejail, elogind, valgrind, glibc,
musl, linux, systemd, strace, stress-ng, libseccomp, qemu
At least for qemu I checked and those are only references in the
embedded linux headers. No rebuild needed for that, most of the others
seem safe as well - maybe
It is yet unclear if there is an issue in the userspace tools, hence I
made the sibling bug a dup and added the tools as a task here marked as
incomplete for now.
As I mentioned providing the extra kernel data might help to get the
triaging by the kernel team started.
** Also affects:
@rafael - One more question about Stepping 5/6.
I have formerly read your explanation that stepping 6 would be
required to be able to enable arch_capabilities.
And we planned to add all SRUs with stepping 6 right away and keep the
Delta to consider all versions to be stepping 6.
But then I have
> ssbd
> md-clear
> bpb
> ibrs-all
> rdctl-no
> rsba
> skip-l1dfl-vmentry
>
> I guess that we will have to backport this support in libvirt, in order
> to allow QEMU to pick specific CPU mitigation flags.
Those are not all missing at least. I have seen ssbd and md-clear for
sure in Bionic e.g.
Thanks Kellen,
I took your kernel/initrd and IPXE booted it fine via http from qemu's IPXE on
a 2G guest.
In the past we tried more (use squash, use tftp instead of http, use the same
parmlines as maas, ...), but it all comes down to the same thing every time -
only occurs inside Maas.
@rafaeldtinoco: I found some forther more ugly detail for the stepping change
from 5 to 6.
Qemu 3.1 as in Disco had Cascade lake with the stepping 5.
So for Disco the SRU will change the definition.
Which is different to Bionic/Cosmic where we can say "our Cascade definition
will just always
This also affects "Cascadelake-Server" defined guests migrating from
patched Bionic to unpatched Disco - that will fail. But requiring
updates being applied is fine, only the enforced guest restart (which
doesn't apply to the just mentioned use-case) is the thing that is
really bad.
Overall maybe
601 - 700 of 1329 matches
Mail list logo
