Public bug reported:
If I suspend my HP EliteBook 8740w, the screen goes blank.
Other portions of the system still function, such as sound, and
networking.
This is a fresh install of 14.04; I did not have SSH installed yet, but
now I do. So I can recreate the issue and gather more information
FYI, I can confirm this on a Clevo W230SS. (It has both an nvidia an
Intel chipset, but I keep it in Intel-only mode.) Let me know if I can
do anything to assist.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I just tried again with two logical CPUs and the core set to "Westmere"
(I think that was the default), and didn't see the bug. So this seems
related specifically to "[x] Copy host CPU configuration" being checked.
Here's the /proc/cpuinfo from the "virtual Westmere" where it works:
Also, the hypervisor's /proc/cpuinfo reports the following CPU
configuration (8 cores of the same):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode : 0x1e
Public bug reported:
The symptom I saw was this (note the segfault, and apt-get upgrade hangs
after this):
Setting up linux-image-3.13.0-71-generic (3.13.0-71.114) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts:
For what it's worth, unchecking "[ ] Copy host CPU configuration" in
virt-manager and selecting "Hypervisor default" for the CPU is a
workaround. (/proc/cpuinfo reports "QEMU Virtual CPU version 2.4.0")
--
You received this bug notification because you are a member of Kernel
Packages, which is
On my Trusty VM with "[x] Copy host CPU configuration" checked in virt-
manager, running 'sudo modprobe -r raid6_pq && sudo modprobe raid6_pq'
is enough to reproduce the kernel exception in dmesg (though I didn't
see it print "Segmentation Fault", so that may be somewhat of a red
herring).
Here's
@Serge, A workaround for me is to use "hypervisor default" in virt-
manager. I'm not sure what the equivalent is in virt-install, but maybe
using --cpu=host-model-only would be a workaround?
>From the man page:
Expose the host CPUs configuration to the guest. This enables
the
Changing status to "Confirmed". I don't think there are any relevant
logs for this issue. Here's some anecdotal evidence, though:
# dmesg | grep oom-killer
[1389379.248406] apt-mirror invoked oom-killer: gfp_mask=0x26000c0, order=2,
oom_score_adj=0
[1399428.772409] chrome invoked oom-killer:
Public bug reported:
On my system, running a couple of LXD containers and VMs (16 GB RAM, 16
GB swap) seems to cause the kernel oom-killer to be frequently
triggered.
In order to try to resolve this, first I tried limiting the memory my
containers were allowed to use, such as by using:
lxc
Hm. Oddly enough, pulseaudio seemed to have problems for me until I set
the overcommit ratio higher (to 150).
--
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/183
Title:
Default VM
After a few days of uptime I still saw issues with the ratio set to 100.
I'll give 0 a try.
--
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/183
Title:
Default VM overcommit sysctls
I have tested this on kernel 4.4.0 (in Xenial) and I don't think the fix
that went into 3.19 fixed the entire issue.
My understanding is that since nmap uses a relatively long pcap_select()
timeout, and the packet buffers in the kernel aren't filling up fast
enough, the packet loss can still be
Inspired by the flow-disruptor workaround, I did a proof-of-concept nmap
workaround as follows:
http://paste.ubuntu.com/23176851/
Obviously, this is nowhere near production-ready code, but I wanted to
convince myself that the pcap_set_immediate_mode() workaround could work
in nmap as well.
--
** Project changed: tcpdump => libpcap
--
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/1457472
Title:
TPACKET_V3 in Linux before 3.19 causes packet loss in libpcap
Status in libpcap:
I discussed this with cgregan on IRC and I think we came to the
conclusion that the MAAS/curtin bug is simply that the two kernels
(commissioning vs. ephemeral deployment) gather different (or missing)
unique identifiers for each drive.
To validate that, I would run the following on each kernel
After further troubleshooting with cgregan, we've further narrowed this
down.
We ran the following script on the node that was having trouble:
https://gist.github.com/pontillo/0b92a7da2fba43fb5dce705be2dcf38b
Unlike all the other devices MAAS works with, the Intel NVMe device
reports a serial
Marking this bug 'New' for the kernel, since this has to do with the
Intel NVMe device links, not the related SMP issue that came up.
** Changed in: maas
Status: Invalid => Won't Fix
** Summary changed:
- [2.1.1] MAAS has nvme0n1 set as boot disk, curtin fails
+ Intel NVMe driver does
Workaround:
grep -q 'LLMNR=no' /etc/systemd/resolved.conf || \
echo 'LLMNR=no' | sudo tee -a /etc/systemd/resolved.conf
sudo service systemd-networkd restart
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
** Description changed:
When testing MAAS on Bionic, we noticed sluggish performance that we
could not immediately explain.
After comparing the results from a run of the test suite on Xenial to a
run on Bionic, we determined that the slowdowns had to do with DNS
lookups. In
I just tested with the Xenial kernel and Bionic userspace and observed
that the bug still occurs, so marked Invalid for 'linux'.
** Changed in: linux (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is
Interesting; the first thing I tried when triaging this was to edit
/etc/nsswitch.conf as follows:
# hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
hosts: files dns
... to eliminate the possibility that it was multicast DNS causing the
slowdown. But it appears I'm
Public bug reported:
When testing MAAS on Bionic, we noticed sluggish performance that we
could not immediately explain.
After comparing the results from a run of the test suite on Xenial to a
run on Bionic, we determined that the slowdowns had to do with DNS
lookups. In particular, if MAAS
Note: I doubt this bug is in the kernel itself; I initially attempted to
file it under glibc at first, but for some reason the `linux` package
was selected.
I also added `systemd` in case the difference in behavior can be
explained by the addition of resolved.
Note that these tests were run on
** Tags added: 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/1739672
Title:
Regression in getaddrinfo(): calls block for much longer on Bionic
(compared to Xenial)
Status in
This seems to be a regression on bionic; I have been using libvirtd
inside a container for several weeks; today when I tore down and rebuilt
the container I hit this bug.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Nothing has changed regarding privileged vs. unprivileged settings.
I just set this up again with a privileged container, and I believe the
cause of the regression to actually be in libvirt. I think it must have
silently ignored the bridge configuration error before and marked the
network active
To be fair, it's also possible that I did something like the following
in my previous test container and forgot about it. ;-)
cat << EOF > maas.xml
maas
EOF
virsh net-define maas.xml
rm maas.xml
virsh net-start maas
virsh net-autostart maas
--
You received this bug notification
My 2nd theory was correct. ;-) Sorry for polluting this bug report with
my thinking-out-loud.
--
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/1784501
Title:
libvirtd is unable to
@tyhicks, I don't have an Artful test system, but I confirmed on Xenial
(4.4.0-116-generic) that `apparmor=0` is a workaround, without the
`noibpb` option and with intel-microcode version
3.20180312.0~ubuntu16.04.1.
--
You received this bug notification because you are a member of Kernel
Here's the log from the failing VM. Doesn't look too unusual to me...
https://paste.ubuntu.com/p/JpmSxmwjfM/
** Description changed:
Using latest MAAS master, I'm unable to compose a VM over the UI
- successfully. BY this it means that the VM is created, but it fails with
- a kernel panic.
-
** Summary changed:
- Composing a VM in MAAS with exactly 2048 MB RAM causes kernel panic
+ Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Here's an example of working XML (with 2047 MB RAM) that MAAS generated:
https://paste.ubuntu.com/p/mkF6Kp4hx8/
And here's an example of non-working XML (with 2048 MB RAM) that MAAS
generated:
https://paste.ubuntu.com/p/27HHDrzwm8/
** Changed in: linux (Ubuntu)
Status: Incomplete =>
Here's the version information.
libvirt-bin:
Installed: 4.0.0-1ubuntu8.5
Candidate: 4.0.0-1ubuntu8.5
Version table:
*** 4.0.0-1ubuntu8.5 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
4.0.0-1ubuntu8.2 500
** Merge proposal unlinked:
https://code.launchpad.net/~newell-jensen/maas/+git/maas/+merge/343053
--
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/713556
Title:
Sharkoon Fireglider
Here's a full console log from the failure.
https://paste.ubuntu.com/p/zmS7CP7NKr/
--
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/1797581
Title:
Composing a VM in MAAS with exactly
Adding the linux package; we should narrow down the issue to see if it's
in kernel space or user space.
** Summary changed:
- [2.5, UI] Composing a VM over the UI is broken - VM has kernel panic
+ [2.5] Composing a VM with 2048 MB RAM causes kernel panic
** Changed in: maas
Status:
To be clear, the kernel panic is seen when a VM is composed in MAAS with
exactly 2048 MB of RAM. Composing with 2047 or 2049 MB RAM results in a
working VM.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
We can't run apport-collect since the machine doesn't boot, but this was
seen with a non-tainted 4.15.0.36-generic kernel in my environment.
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Summary changed:
- [2.5] Composing a VM with 2048 MB RAM causes kernel panic
+ Composing
It's an empty image - MAAS PXE boots the VM.
Could you give it a try with MAAS? I can help you with the setup if
needed - just ping me on IRC.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Looking again at the date stamps, I don't see any squashfs filesystems
older than October 15th. The kernels are all from ~September 25th. So I
feel like this must have been an interaction between the kernel
September 25th and whatever the previous squashfs was.
--
You received this bug
After triaging this again on a call with Andres (who originally reported
this) this morning, we determined that this issue is no longer
reproducible with MAAS. The only way for me to explain it at this point
was that there was something wrong with the daily image MAAS was using
last week, and a
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
** Changed in: maas
Status: Invalid => Incomplete
** Changed in: qemu (Ubuntu)
Status: Invalid => Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
** Changed in: qemu (Ubuntu)
Status: Incomplete => 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/1797581
Title:
Composing a VM in MAAS with exactly 2048 MB RAM causes
I agree that this doesn't look like a QEMU issue, and I agree that it
doesn't look like a [general] networking hiccup.
@paelzer, the easiest way to get the exact configs you need would be to
install MAAS similar to how I've described on our discourse forum[1].
The PXE config will be /similar/ to
Good idea @rharper. It's easy for MAAS to attempt commissioning on
Xenial or Bionic, so I gave Xenial a try. It works fine![1]
[1]: Console log -
https://paste.ubuntu.com/p/58hfBX6BhY/
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
... it's interesting that [practically?] the same kernel version that
fails consistently with Bionic works just fine with Xenial.
--
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/1797581
I just tried Xenial with the HWE kernel - same result (success). FYI.
https://paste.ubuntu.com/p/WpqHnzbsS7/
--
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/1797581
Title:
Composing a
Setting to 'Confirmed' in the kernel, although it's not clear what the
actual fix would entail. It would certainly be nice to be able to tell a
Linux virtual bridge to transparently strip off priority tags before L2
forwarding occurs. That would prevent the issue with iPXE.
** Changed in: linux
Sorry for the confusion.
To be clear, the idea of using MAAS on Xenial was in order to test if
the newly-modified iPXE (on Bionic) can support iSCSI boot.
But come to think of it, I don't think that's a good test. If I remember
correctly, MAAS used TFTP to transfer the kernel and initrd, /then/
Yes, MAAS 2.3 (the last revision of MAAS supported on Xenial) can
support iSCSI when it is placed in backward compatibility mode; how to
do this is documented in the changelog as follows:
maas $PROFILE maas set-config name=http_boot value=False
MAAS 2.2 and earlier (no longer supported) used
Unfortunately, a modern MAAS no longer uses iSCSI; it will fetch all
necessary data over HTTP.
--
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/1805920
Title:
iPXE ignores vlan 0 traffic
FWIW, I switched back to ext4 and am no longer experiencing the same
issues.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-5.19 in Ubuntu.
https://bugs.launchpad.net/bugs/2028186
Title:
zfs with encryption: sluggish
I'm seeing a similar issue on a laptop which was working fine until I
reinstalled Ubuntu Jammy with ZFS (with full-disk encryption enabled).
Sometimes it freezes for several seconds, but sometimes I wait hours and
it never recovers.
I don't think this is a gnome-shell issue, but I'm unsure how to
ack; filed bug 2028186.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1973827
Title:
Laptop freezes when recovering from suspend / sleep mode
Status in gnome-shell package in
Public bug reported:
I had been using Jammy on a Thinkpad T470 for months without problems.
I decided to try a fresh Ubuntu Desktop install using ZFS, using the
install-time option for full-disk encryption.
After using the fresh install for a little while, I noticed that the
system was "more
56 matches
Mail list logo
