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 ask
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) becaus
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 sa
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-
resume.serv
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 su
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
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 00:20:1
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 Ubunt
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 not
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. Theref
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 -j
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 f
@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 b
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. For
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 "co
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 old
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 subsc
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 w
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
he same with 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
*** 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 ord
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.
https://bugs.launchpad.net/bugs/184655
*** 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 breakpoi
*** 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 se
28 matches
Mail list logo