Hi Daniel,
In my understanding, the crash is not reproducible after my workaround
(switching to the nvidia driver), because the nvidia-resume.service is not
masked (my theory).
Therefore, I switched back to the Nouveau driver, and I reproduced the
problem and collected the system logs as you
Interesting update
Given the "Unit nvidia-resume.service is masked" complain by systemd-
logind in my previous comment, I thought it could be related with the
switching on and off the proprietary nvidia driver: after turning it on,
I turned it off (switching to Nouveau)
Hi Daniel,
unfortunately, there are no crash files in /var/crash/. I've checked also:
https://errors.ubuntu.com/user/ but there are no crashes reported
in the last month.
It looks like the "crash" is not caused by a fatal signal like SIGSEGV
and no core dump is generated.
But, still from the
If I grep for `systemd`, after the first meaningful message:
Nov 10 00:20:06 lenovo systemd-logind[11553]: Power key pressed.
The first error is:
Nov 10 00:20:11 lenovo systemd-logind[11553]: Error during inhibitor-
delayed operation (already returned success to client): Unit nvidia-
I just tried suspending my machine while running a Wayland session
("Ubuntu"), instead of an Xorg session ("Ubuntu on Xorg") and I got the
same problem. Therefore, the issue has *nothing* to do with Xorg itself.
** Summary changed:
- GDM Xorg session crashes on suspend
+ GDM session crashes on
Public bug reported:
Since I started using kernel 5.13.0-20 (and 5.13.0-21) on Ubuntu 21.10,
my GDM session crashes when I try to put my laptop to standby.
I've attached a relevant slice of the system journal that starts from
the moment I pressed the power button, configured to trigger suspend,
I guess the most relevant part from the system journal is the following:
-
Nov 10 00:20:13 lenovo gdm-launch-environment][18707]:
pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 10
Major update
--
I've discovered that by switching to the open source Nouveau display
driver the problem disappears, even with the newest Ubuntu 5.13.0-20
kernel.
The problem was related to the "nvidia-driver-470" for my video card: GM107M
[GeForce GTX 950M].
The older 5.11.0-37
Interesting update. I've followed the build instructions for the Ubuntu
kernel: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
By cloning the repo: git://kernel.ubuntu.com/ubuntu/ubuntu-impish
And building the kernel tagged as: Ubuntu-5.11.0-20.21+21.10.1
Which is *older* than the last _good_
** Tags added: kernel-bug kernel-therm
** Tags removed: kernel-bug
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1947614
Title:
Laptop fans spin at ~50% w/o CPU load with kernel 5.13
To manage
To check the theory about the Ubuntu-specific patches, I tried to boot
another Linux distro (Fedora Live 35) in order to see if the problem
would exist: it did not.
The kernel used was: 5.14.10-300.fc35.x86_64.
Which is more recent that the kernel 5.13.0-20, currently used by Ubuntu
21.10.
Given that the problem exist with kernel 5.13.0-19 and newer but not
with kernel 5.11.0-37, I tried to find which the change triggered this
weird behavior using git bisect. I used bisect in the range [v5.11,
v5.13] (official tags) and I've built the standard non-ubuntu kernel(s)
using:
make
Public bug reported:
After upgrading from Ubuntu 21.04 to Ubuntu 21.10 a few days ago, I
noticed that the fans of my laptop (Lenovo ideapad 700-15ISK) were
spinning all the time at about ~50%, no matter the CPU load.
I forced all my cores to run at 100% with a simple while(1) loop to see
if the
@dundir Maybe you're right, I don't know.
I just tried to do what I believed is best for Ubuntu, the distro I've been
using since 2008 or so: to speak out giving my feedback, hoping it will be
heard by the right people. If things won't change I'll look elsewhere, clearly.
--
You received this
You're failing to understand the concept of "show-stopper" bug, also known as
"ship-stopper".
The severity of such a bug is so big, that the whole release a product must be
postponed, until the bug is fixed. Bugs of this kind are ones that
substantially compromise the usability of a product.
Hi Jonathan,
I'm happy to start a dialogue about this issue.
1. It's great to hear that the problem will be fixed in 21.04. Maybe a
backport to the 20.04 LTS should be considered as well?
2. I know, I don't have problems with fixing things by myself, per se.
I'm irritated that this was not a
Guys, this is a *BRUTAL* regression. It's NOT acceptable to break the
desktop experience like that in a LTS release because "the legacy code
was unmaintainable". Either replace the legacy code with a mature, well-
written extension which works *exactly* the same way, or continue to
maintain the
I was happy to contribute, Christian :-)
I just wanted to add that after sending the e-mail to ipxe-
de...@lists.ipxe, I received an automatic response explaining that my
e-mail will have to be approved by a moderator because I'm not a member
of that mailing list. I just hope that my e-mail won't
Thanks for the whole investigation, Laszlo.
I sent an e-mail to ipxe-de...@lists.ipxe.org forwarding your analysis with
a quick summary of mine on the top, indicating the probable first bad commit.
Vlad
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hi Laszlo,
thanks for investigating the problem so rapidly.
So, I downgraded the ipxe-qemu package from
1.0.0+git-20190109.133f4c4-0ubuntu3 (focal) to 1.0.0+git-20180124
.fbe8c52d-0ubuntu2 (bionic) and the problem completely disappeared. Your
theory looks absolutely correct to me.
For what it's
Thanks for the quick response, I'm attaching the debug.log file.
** Attachment added: "QEMU's debug log file"
https://bugs.launchpad.net/qemu/+bug/1882671/+attachment/5382085/+files/debug.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
th older OVMF versions as well.
Please take a look at it, as the bug is NOT a corner case. QEMU 4.2.0 cannot
boot with an UEFI firmware (OVMF) while virtualizing a x86_64 machine AT ALL.
Thank you very much,
Vladislav K. Valtchev
** Affects: qemu
Importance: Undecided
Status: New
**
*** This bug is a duplicate of bug 1846557 ***
https://bugs.launchpad.net/bugs/1846557
Thanks Miroslav for opening this bug, two weeks after me opening bug #1846557.
Unfortunately, it took proving that gdb couldn't debug properly _any_ 32-bit
program, not just kernels running on QEMU, in
A fix was released after bug #1848200, reporting the same problem, was
opened.
** Changed in: gdb (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
*** This bug is a duplicate of bug 1846557 ***
https://bugs.launchpad.net/bugs/1846557
** This bug has been marked a duplicate of bug 1846557
Unable to debug any kernel on i386 qemu machine
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Hi guys,
any update on this?
Just to be sure, I tried to the Linux kernel 4.19.16 in the same
scenario and I got the same result. I built the kernel with buildroot
and I launched QEMU with:
qemu-system-i386 -kernel bzImage -S -s -append 'nokaslr'
I know it needs an initrd and a hdd img in order
Public bug reported:
Hi,
On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu
8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM
(qemu-system-i386) by just doing the following:
> target remote localhost:1234
> b term.c:694
and then, when the
*** This bug is a duplicate of bug 346856 ***
https://bugs.launchpad.net/bugs/346856
Hi,
I'm using Ubuntu 18.04 and Evolution 3.28-5 and I believe I'm hitting the same
problem (10 years later!).
The spell checker marks every word as misspelled when Bulgarian is used,
while with English it
28 matches
Mail list logo
