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 anymore
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
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
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 b
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 fo
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 packa
*** 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
[1
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 bug
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
** C
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 added
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
Tit
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 cascade/icela
See lightdm and gpu-manager services in
http://paste.ubuntu.com/p/5QyzgMKhmr/ for an example how that looks like
from a guests POV.
--
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/1795857
T
Thanks cascardo for testing power8 already.
This came up in bug 1823152 as well and made me aware of this.
If qemu is not run in commandline most frontends set something else than "-vga
std" therefore I wasn't aware. But I can confirm seeing the issue.
I think I can test x86 quite easily, is the
** Attachment added: "journal of the boot including the crash"
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1823618/+attachment/5253943/+files/GPU-crash.1.log
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification
FYI: The system becomes unresponsive after the crash so I can only
report the bug while rebooted into the former HWE kernel version.
--
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/1823618
I was unsure which package to file it against as it is hwe, please feel
free to adapt the bug tasks accordingly.
--
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/1823618
Title:
4.18.0-17 c
Apport seems to collect and send stuff, but it does not show up here - I'll
stop hitting send for now to not have 50 attachments in 10 minutes :-/
Just let me know what you need and I'll make it available.
--
You received this bug notification because you are a member of Kernel
Packages, which i
** Attachment added: "dmidecode.log"
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1823618/+attachment/5254000/+files/dmidecode.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/
Confirmed to silence the bot, attaching a few logs on my own since
apport refuses to do so
--
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/1823618
Title:
4.18.0-17 crashes on i915 driver
Setting linux-hwe per discussion
** Package changed: linux-signed-hwe (Ubuntu) => linux-hwe (Ubuntu)
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux-hwe (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ub
** Attachment added: "lspci.log"
https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1823618/+attachment/5254001/+files/lspci.log
--
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/182
Apport still refuses to attach data :-/
But I since I have the journal with the crash attached that should be ok.
** Changed in: linux-hwe (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: linux-hwe (Ubuntu)
** Description changed:
On 2019-04-03 I updated to the latest linux-image-generic-
hwe-18.04:amd64 and then I got on a trip where things worked fine at
first. Back home I realized that the new version 4.18.0-17-generic has
issues initializing gnome with multiple monitors.
Steps to rep
We discussed if just the Graphics output might be dead, I'll set up SSH
and try to retrigger.
** Description changed:
On 2019-04-03 I updated to the latest linux-image-generic-
hwe-18.04:amd64 and then I got on a trip where things worked fine at
first. Back home I realized that the new vers
As usual - thanks bug - with a proper ssh set up and logged in it just doesn't
trigger anymore :-/
I tried multiple reboots and we can keep the bug if others are affected to join
forces, but for now it is incomplete as I can no more reproduce it :-/
** Changed in: linux-hwe (Ubuntu Bionic)
This is in all newer versions of iproute2 (newer than Xenial), setting
the general task to Fix Released
** Changed in: iproute2 (Ubuntu)
Status: Invalid => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ub
@Timo - Ack, this should be enabled again. And if really still an issue
for PPC then a different solution than to disable it should be evaluated
(can we do arch specific blakclisting?).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux
Hi Robert,
I haven't found the reason.
For my limited kernel knowledge I have checked and discussed a bit.
in [1] I found
$ grep -Hrn autofs debian.master/contro*
debian.master/control.d/generic.inclusion-list:181:fs/autofs4/autofs4.ko
But then was made aware that with 4.18 ther kernel started to
Thank you Timo!
--
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/1795857
Title:
enable CONFIG_DRM_BOCHS
Status in kmod package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
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 are
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 c
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]:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/lib
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
cc
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 thi
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] inacti
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 bet
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 Pr
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
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 --disab
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
<0.33>
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
file=/var/lib/uvtool/libvirt
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 Ker
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 0x772
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 -no-user-co
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 dis
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) command
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, &map) == 0
kernel:
static long vfio_iommu_type1_ioctl(void *iommu_data,
unsigne
(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")
printf("Complet
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 tra
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 call
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
** 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 Eo
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
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 Bionic
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
passthrough
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?
-
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 KVM_PPC
@sfeole Thanks for the Dup hit that as well now - as all others I ask
you to please help to catch the data needed to finally recreate and
debug this.
>From IRC:
[07:00] sfeole: please attach your guest XML, and the used initrd
and kernel to the bug
[07:02] best would be also the pxeconfig that
Added to the description what we need from anyone affected.
@Maas Team see former comment for the requested guiding of users how to get
this data.
The Maas task is back from incomplete to confirmed for providing these howto's
** Changed in: maas
Status: Incomplete => Confirmed
--
You re
So I guess we should then file the bug against nvidia-driver-430 then?
** Also affects: nvidia-graphics-drivers-418 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drive
Since 430 is still from a PPA https://launchpad.net/~graphics-
drivers/+archive/ubuntu/ I used 418 being the closest one.
Do you hit the same with 418?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-418 in Ubuntu.
The top three qemu patches are in qemu 4.0 which we plan as minimum for Ubuntu
19.10.
Tagging up to be part of the Qemu work in Ubuntu 19.10.
The rest of the qemu patches is already in qemu 3.1 which is in Ubuntu
19.04
** Tags added: qemu-19.10
** Changed in: qemu (Ubuntu)
Status: Confir
Sure you mean Disco and not Eoan?
... checking
--
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/1826410
Title:
Please package libbpf (which is done out of the kernel src) in Debian
[for
Hmm,
no libbpf-dev package in any -proposed just yet.
Neither die I find it in a new queue?
The one place I found it is in:
* Please package libbpf (which is done out of the kernel src) in Debian [for
19.10] (LP: #1826410)
- SAUCE: tools -- fix add ability to disable libbfd
of https://l
After some discussion, probably just a bad bug ref in changelog?
** Tags removed: verification-needed-disco
** Tags added: verification-failed-disco
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.n
TL;DR only occurs with HWE kernel - odd
Results of:
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Host Bionic: 4.18.0-20-generic / 2.11+dfsg-1ubuntu7.13
Guest-lvl1: 3.13.0-170-generic / 2.0.0+dfsg-2ubuntu1.46
Vulnerable: Clear CPU buffers attempted, SMT Host state unknown
Guest-lvl2: 3.13.
E.g. in /proc/cpuinfo the whole section is missing:
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
mds
^^ this is not there when "Not affected" is reported
Separating kernels:
3.13 on both: Works
4.4 on lvl1, 3.13 on lvl2: Fail
3.13 on lvl1, 4.4 on lvl2: Works
So i
Note: support on nested is and always was "best effort" as it is
famously known to work great until it doesn't. Recently upstreams stance
on this changed and in the last few versions nested x86 got some love
(due to some big players using it now), but I'm more looking to 20.04
than anything before
Further I realized that I can trigger this with T3.13/Q2.5/B4.15:
trusty-lvl1-mitaka kernel: [ 931.946357] kvm [2356]: vcpu0 unhandled rdmsr:
0x140
trusty-lvl1-mitaka kernel: [ 932.236914] kvm [2356]: vcpu0 unhandled rdmsr:
0x1c9
trusty-lvl1-mitaka kernel: [ 932.238337] kvm [2356]: vcpu0 unha
oO :-/, that crash also happens to the older qemu on trusty as soon as
you have more than 1 lvl1 or lvl2 guest it seems. Anyway - same
workaround to tets MDS applies
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://
Of course I spoke too soon, on T3.13/Q2.0/B4.15 I now hit an FPU issue.
That builds up to a kernel stack crash (recursive)
[2.394255] Bad FPU state detected at fpu__clear+0x6b/0xd0, reinitializing
FPU registers.
[...]
BUG: stack guard page was hit at (ptrval) (stack is (ptrval
Hmm with that workaround for 4.15 I get the md bug affects in the guest,
but not the md-clear feature.
$ uname -r; cat /sys/devices/system/cpu/vulnerabilities/mds; cat /proc/cpuinfo
| grep -e ^bug -e ^flags | grep md
4.15.0-50-generic
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Hos
I re-checked all that you and I found, lets write a List with all that
we know if there are patterns.
Host (should not matter, but be rather new) - in my case B4.18 Q2.11
For new qemu I'm using Mitaka.
In this case being from
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-sta
My initial testcase will be 07 "T4.4 / Q2.0 T3.13"
Bisect is rather complex as we'd need the md-clear patches on top at each step.
Sorry that it took a while.
Adaptions:
- non ubuntu machine type (using 2.0 to work on all builds)
- remove VNC in xml as we built a reduced feature qemu
- place buil
Bisect result is
git bisect start
# good: [a9e8aeb3755bccb7b51174adcf4a3fc427e0d147] Update version for v2.0.0
release
git bisect good a9e8aeb3755bccb7b51174adcf4a3fc427e0d147
# bad: [a8c40fa2d667e585382080db36ac44e216b37a1c] Update version for v2.5.0
release
git bisect bad a8c40fa2d667e58538208
That finds us the fix as:
commit 120eee7d1fdb2eba15766cfff7b9bcdc902690b4
Author: Eduardo Habkost
Date: Tue Jun 17 17:31:53 2014 -0300
target-i386: Set migratable=yes by default on "host" CPU mooel
Having only migratable flags reported by default on the "host" CPU model
is saf
Theory given what we know so far:
- only fails if LVL1 is at 4.4
- not failing if LVL1 is at 3.13
- 4.4 might have more CPU features
- qemu 2.0 when using host-model is passing ALL features
- qemu 2.5 works, but we now know it filters some flags that 2.0 doesn't
=> one of these extra flags disturbs
Jason,
thanks for chiming in - so far this was non-reproducible every time we looked
at it. We had plenty of approaches with the MAAS team to this and later on with
Thiago, but still miss the right data to continue.
Last time I asked - I think it was still Mike - that I'd really like to
get the
Ok, thanks Jason.
That is great info, but about as much as we had so far :-/
Can you set your deployment up in a way that if that happens again you
can collect these binaries?
If it right now still triggers if you (re)deploy a 2G guest use the
chance to finally give us the bits that we will need
*** This bug is a duplicate of bug 1808389 ***
https://bugs.launchpad.net/bugs/1808389
Yep, the changes accepted to B/C-unapproved as part of an SRU should be what we
need.
Marking as a Duplicate so that we can test that SRU as well to hopefully
resolve it for all of us.
** This bug has bee
src:linux-firmware is only accepted into cosmic-proposed but still waiting in
Bionic-unapproved.
AFAIK the current status of "Fix committed" will make it not to be seen by the
SRU Team (at least for similar cases I had in the past).
Therefore to increase the chance to get also the Bionic portion
I have had no issues anymore since I switched to my self built
1.177~ppa0f22c85 (PPA) - while before they were rather common.
Thanks for accepting that into Bionic-Proposed.
I have switched to 1.173.5 from Proposed and unplugged the cables.
The install (a downgrade for me as outlined) itself work
After a weekend using the wireless (on Bionic) I have got no new
"kernel: iwlwifi :04:00.0: Microcode SW error detected. Restarting
0x200."
entries and I'm still connected (also before it hit really fast).
Therefore I'd think this firmware in proposed is as good as the PPA I used int
h
Now that this is released, can we set it back to open again to reflect
the real state in the archive?
--
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/1826410
Title:
Please package libbpf
Hi Sean,
for >1TB due to the defaults being for safety you need to set a different
machine type.
The suffix is "-hpb" like "pc-i440fx-bionic-hpb" in your case.
I have written about it here:
https://cpaelzer.github.io/blogs/005-guests-bigger-than-1tb/
Changing the default is an upstream decisio
** Tags added: qemu-19.10
--
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/1812822
Title:
Guest crashed when detaching the ovs interface device
Status in Ubuntu on IBM z Systems:
Incomp
FYI things resurfaced with monitors of higher resolution.
But it was so bad that I sent them back, so no testbed available atm.
--
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/1823618
Title
Yeah, it seems to only occur with the TFTP setup that maas creates - and in all
former cases it resolved a few days later - most likely by size of images
changing.
That is the reason we need the files from an affected case.
@Reto - please see in the bug description above, there is a section "If
Hi pragyansri,
If you track the progress on the merge proposal that is linked this looks good
atm and will soon be in a PPA [2] with proposed changes for pre-evaluation with
Bionic/Cosmic/Disco/Eoan.
>From there the next steps are:
- test the new feature from the PPA on cascade lake machines
- g
@Dmitrii - we were at the "junk in ..." in comment #21 already.
The "broken padding" is interesting but might be the same issue with a
different message as the newer kernel understands slightly more about it.
That it does only occur with Xenial-HWE but on the same initrd not with
the base Xenial
Ran with:
- the cloud-image of Xenial of 20190419 [1]
- XML with a memory definition of:
2097152
2097152
- kernel&initrd are from the host
/var/lib/libvirt/images/bug-1797581-bionic-base
/var/lib/libvirt/images/bug-1797581-bad-initrd
- The attached broken initrd of comment #56
- Otherwise
Fro experimenting with sizes things can easily be padded with zeros:
$ truncate -s 8000 bug-1797581-bad-initrd-extended
$ truncate -s 900 bug-1797581-xenial-base-extended
Boots just as well afterwards.
--
You received this bug notification because you are a member of Kernel
Packages, whi
After a longer session on IRC this is now also for Dmitrii un-reproducible.
Lets summarize the current status for the next oen coming by:
Current ideas still are:
a) at 2G the placement of kernel/initrd is too close (as placed by pxelinux),
then when the kernel unpacks it overwrites the initrd
b)
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 packa
apport-collect makes no sense for this which is more a feature/packaging
request, setting confirmed
** 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.
http
ubuntu@cosmic-autofs:~$ find /lib/modules -name '*autofs4*'
ubuntu@cosmic-autofs:~$ modinfo autofs4
modinfo: ERROR: Module autofs4 not found.
Installed linux-headers-4.18.0-19 from proposed
ubuntu@cosmic-autofs:~$ find /lib/modules -name '*autofs4*'
/lib/modules/4.18.0-19-generic/kernel/fs/autofs
After upgrade:
$ find /lib/modules -name '*autofs4*'
/lib/modules/5.0.0-14-generic/kernel/fs/autofs/autofs4.ko
That was missing before -> verified
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
--
You received this bug notification because you are a member of
** Description changed:
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
FYI here the package info from buster as of today
root@d10-buster:~# apt-cache show libbpf-dev libbpf4.19
Package: libbpf-dev
Source: linux
Version: 4.19.28-2
Installed-Size: 350
Maintainer: Debian Kernel Team
Architecture: amd64
Depends: libbpf4.19 (= 4.19.28-2)
Description-en: eBPF helper librar
1 - 100 of 698 matches
Mail list logo
