[Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
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 asked. Now prevboot.txt contains the logs from a clean boot, through the session crash and ends with a (user requested) reboot. Just for the record, these are the steps to reproduce the bug: 1. Install Ubuntu 21.10 on a laptop(?) with an nvidia GPU 2. Open "Software & Updates" -> "Additional Drivers" 3. Select the latest driver (470) 4. Reboot 5. Login normally on GDM 6. Open "Software & Updates" -> "Additional Drivers" 7. Select "Nouveau display driver" and apply the changes 8. Reboot 9. Login normally on GDM 10. Try to suspend the system 11. You should observe a session crash here ** Attachment added: "System journal for the previous boot, as requested in update #8" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950393/+attachment/5540130/+files/prevboot.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
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) because of this other bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614 So, I opened the "Software & Updates" tool and in "Additional Drivers" I turned nvidia-driver-470 on again and... voila', the session-crash-on-suspend bug disappeared. It looks like to me that the tool messed up some systemd units like nvidia-resume.service and it didn't return them to the previous state after I switched back to Nouveau. Note: the only thing I used to turn on and off the nvidia driver is that "Software & Updates" tool, no custom configurations/hacks at all. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
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 same log file (attached), I noticed that systemd- logind exited with a failure: -- Nov 10 00:20:13 lenovo upowerd[3602]: Could not acquire inhibitor lock: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Nov 10 00:20:13 lenovo dbus-daemon[1120]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' requested by ':1.178' (uid=1000 pid=12386 comm="/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/use" label="unconfined") Nov 10 00:20:13 lenovo gsd-power[12749]: Unable to inhibit suspend: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Nov 10 00:20:13 lenovo gsd-media-keys[12746]: Unable to inhibit suspend: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Nov 10 00:20:13 lenovo systemd[1]: Starting SSSD PAM Service responder... Nov 10 00:20:13 lenovo systemd[1]: systemd-logind.service: Main process exited, code=exited, status=1/FAILURE Nov 10 00:20:13 lenovo systemd[1]: systemd-logind.service: Failed with result 'exit-code'. -- Later, I observe that gnome-session cannot communicate with systemd using GDBus and ends up failling back to a "non-systemd procedure": -- Nov 10 00:20:13 lenovo gnome-session[18803]: gnome-session-binary[18803]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Nov 10 00:20:13 lenovo gnome-session-binary[18803]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Nov 10 00:20:13 lenovo systemd[12345]: Failed to start GNOME Wacom tablet support service. Nov 10 00:20:13 lenovo systemd[12345]: org.gnome.SettingsDaemon.Power.service: Failed with result 'exit-code'. Nov 10 00:20:13 lenovo systemd[12345]: Failed to start GNOME power management service. Nov 10 00:20:13 lenovo gnome-session[18803]: gnome-session-binary[18803]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Nov 10 00:20:13 lenovo gnome-session-binary[18803]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Nov 10 00:20:13 lenovo gnome-session[18803]: gnome-session-binary[18803]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Nov 10 00:20:13 lenovo gnome-session-binary[18803]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist -- Could this be a systemd bug? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
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.service is masked. And later: Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) systemd- logind disappeared (stopped/restarted?) ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
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 suspend on Ubuntu 21.10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1950393
Title:
GDM session crashes on suspend on Ubuntu 21.10
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1950393/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] [NEW] GDM Xorg session crashes on suspend
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, in my case. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Nov 10 00:47:13 2021 DistUpgraded: 2021-10-16 23:05:19,206 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 530 [17aa:380a] Subsystem: Lenovo GM107M [GeForce GTX 950M] [17aa:380b] InstallationDate: Installed on 2020-03-17 (602 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 80RU ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-21-generic root=UUID=0e855d19-79da-402d-9586-b7bfe9a9622a ro SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to impish on 2021-10-16 (24 days ago) dmi.bios.date: 08/09/2017 dmi.bios.release: 1.61 dmi.bios.vendor: LENOVO dmi.bios.version: E5CN61WW dmi.board.asset.tag: No Asset Tag dmi.board.name: Lenovo ideapad 700-15ISK dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 700-15ISK dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrE5CN61WW:bd08/09/2017:br1.61:efr1.22:svnLENOVO:pn80RU:pvrLenovoideapad700-15ISK:rvnLENOVO:rnLenovoideapad700-15ISK:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapad700-15ISK:skuLENOVO_MT_80RU_BU_idea_FM_Lenovoideapad700-15ISK: dmi.product.family: IDEAPAD dmi.product.name: 80RU dmi.product.sku: LENOVO_MT_80RU_BU_idea_FM_Lenovo ideapad 700-15ISK dmi.product.version: Lenovo ideapad 700-15ISK dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 ** Affects: ubuntu Importance: Undecided Status: New ** Tags: amd64 apport-bug crash impish ubuntu ** Attachment added: "Selected logs from the system journal" https://bugs.launchpad.net/bugs/1950393/+attachment/5539318/+files/selected_crash_log.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM Xorg session crashes on suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1950393] Re: GDM Xorg session crashes on 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 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: Fatal server error: Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) systemd-logind disappeared (stopped/restarted?) Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: Please consult the The X.Org Foundation support Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: at http://wiki.x.org Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: for help. Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) Please also check the log file at "/home/vlad/.local/share/xorg/Xorg.0.log" for additional information. Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (II) AIGLX: Suspending AIGLX clients for VT switch Nov 10 00:20:13 lenovo upowerd[3602]: Could not acquire inhibitor lock: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Nov 10 00:20:13 lenovo dbus-daemon[1120]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' requested by ':1.178' (uid=1000 pid=12386 comm="/usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/use" label="unconfined") - From which gdm-x-session complains that systemd-logind "disappeared". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM Xorg session crashes on suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1950393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] Re: Laptop fans spin at ~50% w/o CPU load with kernel 5.13
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 Ubuntu did not had this problem, because simply there were no Nvidia drivers built by DKMS for it. Probably, I switched to the Nvidia proprietary driver after upgrading to Ubuntu 21.10, so the older kernel remained without the Nvidia modules. I'm not sure at the moment if this still a bug for this place. I'll leave this decision to you guys. At least, it will be useful for other people with the same issue. ** Summary changed: - Laptop fans spin at ~50% w/o CPU load with kernel 5.13 + nvidia-driver-470 makes fans spin at ~50% w/o any load -- 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: nvidia-driver-470 makes fans spin at ~50% w/o any load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] Re: Laptop fans spin at ~50% w/o CPU load with kernel 5.13
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_ Ubuntu kernel I have (5.11.0-37) left installed from the previous version of Ubuntu (21.04, Hirsute) but the problem is *reproducible*. This means that the issue is a combination between the configuration in Ubuntu 21.10 and some Ubuntu kernels built from the ubuntu-impish repo. I have to try building another Ubuntu kernel from the Hirsute repo and see what happens. Apparently all mainstream kernels >= 5.11 and all Ubuntu Impish kernels have this issue, when running Ubuntu 21.10 (desktop). -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] Re: Laptop fans spin at ~50% w/o CPU load with kernel 5.13
** 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] Re: Laptop fans spin at ~50% w/o CPU load with kernel 5.13
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. Therefore, it looks that both the older Ubuntu-specific kernel and the newest Fedora kernel do _not_ have the problem, thanks to some custom patches that (apparently) do _not_ exist in 5.13.0-19 nor in the mainstream Linux kernel. It's getting even more tricky. An alternative long-shot theory is that thermal management policies changed in the newest Ubuntu, but does not activate with kernel 5.11 because of the lack of some kernel feature. That would explain why the problem exists with the mainstream kernel as well, but not on another distro. -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] Re: Laptop fans spin at ~50% w/o CPU load with kernel 5.13
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 -j4 bindeb-pkg LOCALVERSION=-custom As config, I used the Ubuntu one from: /boot/config-5.11.0-37-generic and accepted all the new config options as default. But, before finishing to test all the bisect steps, I found that even with the first kernel, v5.11, commit: f40ddce88593482919761f74910f42f4b84c004b, the problem already exists. Therefore, it looks like there were some Ubuntu-specific patches in 5.11.0-37 that prevented the problem to happen. In the original v5.11 kernel, the fans spin at ~50% apparently no matter the CPU load. Apparently, those Ubuntu patches that prevented the problem from happening, got changed in 5.13.0-19. Does anybody have a clue what could that be? Thanks, Vlad -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1947614] [NEW] Laptop fans spin at ~50% w/o CPU load with kernel 5.13
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 fan speed would increase but nothing. Apparently, no matter the CPU load and temperature, with kernel 5.13.0-19 the fans of my laptop spin at the same RPM. From their noise, I believe that's about 50%. Therefore, I decided to boot the same Ubuntu 21.10 with the older kernel 5.11.0-37 and the problem disappeared. Looks like in the newer kernel there is a problem with the control of fans for my HW. To complete the picture, I built and booted kernel v5.15-rc5 to see if with a bleeding edge kernel the problem would disappear: it didn't. Therefore, the problem appears to be introduced somewhere between kernel 5.11 and kernel 5.13. The output of `sensors`, unfortunately doesn't show any fans and that's the same no matter the kernel version: pch_skylake-virtual-0 Adapter: Virtual device temp1:+54.5°C BAT0-acpi-0 Adapter: ACPI interface in0: 12.25 V coretemp-isa- Adapter: ISA adapter Package id 0: +39.0°C (high = +100.0°C, crit = +100.0°C) Core 0:+37.0°C (high = +100.0°C, crit = +100.0°C) Core 1:+38.0°C (high = +100.0°C, crit = +100.0°C) Core 2:+39.0°C (high = +100.0°C, crit = +100.0°C) Core 3:+38.0°C (high = +100.0°C, crit = +100.0°C) acpitz-acpi-0 Adapter: ACPI interface temp1:+39.0°C (crit = +99.0°C) temp2:+42.0°C (crit = +85.0°C) ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: linux-image-5.13.0-19-generic 5.13.0-19.19 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu70 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: vlad 5972 F pulseaudio /dev/snd/controlC0: vlad 5972 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Oct 18 19:04:03 2021 InstallationDate: Installed on 2020-03-17 (579 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 80RU ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-19-generic root=UUID=0e855d19-79da-402d-9586-b7bfe9a9622a ro RelatedPackageVersions: linux-restricted-modules-5.13.0-19-generic N/A linux-backports-modules-5.13.0-19-generic N/A linux-firmware 1.201 SourcePackage: linux UpgradeStatus: Upgraded to impish on 2021-10-16 (1 days ago) dmi.bios.date: 08/09/2017 dmi.bios.release: 1.61 dmi.bios.vendor: LENOVO dmi.bios.version: E5CN61WW dmi.board.asset.tag: No Asset Tag dmi.board.name: Lenovo ideapad 700-15ISK dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 700-15ISK dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrE5CN61WW:bd08/09/2017:br1.61:efr1.22:svnLENOVO:pn80RU:pvrLenovoideapad700-15ISK:skuLENOVO_MT_80RU_BU_idea_FM_Lenovoideapad700-15ISK:rvnLENOVO:rnLenovoideapad700-15ISK:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapad700-15ISK: dmi.product.family: IDEAPAD dmi.product.name: 80RU dmi.product.sku: LENOVO_MT_80RU_BU_idea_FM_Lenovo ideapad 700-15ISK dmi.product.version: Lenovo ideapad 700-15ISK dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish -- 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813441] Re: Can no longer drag and drop files between desktop and applications
@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 bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813441 Title: Can no longer drag and drop files between desktop and applications To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1813441/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813441] Re: Can no longer drag and drop files between desktop and applications
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 example, a bug in a browser's rendering engine that doesn't allow a single major website (social networks, search engines etc.) to render correctly. Millions of people won't use that browser because of that. Another example? A GCC bug that doesn't allow the Linux kernel to compile or, even worse, compiles but generates incorrect instructions and the kernel doesn't boot. Even if that C compiler had a TON of new and cool features and it was 200% faster than its predecessor, would you allow it to be released knowing the you cannot compile Linux? I wouldn't, never. Most of the time, we make trade-offs, both in software development and in release management as well. For example? We've fixed 100 bugs at the price of introducing 5 new ones. That's fine, generally. BUT, some bugs are critical and cannot even be put in the equation. I don't need the whole "decision tree" for that. Such bugs, have priority above everything else combined. The 10,000 new features of KDE 4 were worthless, compared to the fact that it was not stable and crashed the whole time. I wanted so much to use it at the time, because it was so cool and visually pleasing. But, at the end I gave up because of its instability and switched to GNOME. A car is *worthless* if its breaking system doesn't work. A compromise can be made when the breaking system is relatively worse than the one in the previous model, but it's still working, it's still doing an acceptable job. So, how to decide which bugs are show-stoppers? Well, there are user experience people, product managers, VPs etc, but ultimately, such a decision is SUBJECTIVE. I have no "mathematical proof" that this was a show-stopper bug, neither do you that this wasn't. I expressed my opinion, trying to make the Ubuntu leadership to reconsider such decision making. Maybe I failed, maybe I didn't. But if nobody makes criticism, it's almost impossible for the leadership to get a feedback and improve its decision-making. At the end, given users' feedback, I hope Ubuntu leaders will ask themselves: "was that the right call to make?". Maybe, just maybe, the next time they'll be more conservative when releasing an LTS. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813441 Title: Can no longer drag and drop files between desktop and applications To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1813441/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813441] Re: Can no longer drag and drop files between desktop and applications
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 "corner case" that a few will people will even notice. It's a "show stopper" bug. I'm criticizing the *decision making* here. 3. Yes, I realize that's GNOME's fault. So, the solution was to simply stick to the older version of GNOME, wasn't it? It's a BAD idea to upgrade to the latest version of XYZ, when it's broken, in particular when we're talking about an LTS release, that's supposed to be super- stable. That's simply *bad judgement*. Of course Canonical cannot fix every GNOME bug, I totally agree. I'm a very practical person. Just, don't upgrade the package; it's simple as that. A Linux distribution maintainers' main job is choose carefully which version each software package to include in the distro. The typical questions are: "is the package XYZ stable enough for our release?", "shall we use libxyz 1.23 instead of libxyz 1.22 to fix the problem PR123, but risking to break something else?". Also, did "desktop-icons-ng-ding" exist in 2020 before the release of the LTS? Not a rhetorical question, I honestly don't know. If it did, than the LTS should have included it. Otherwise, the LTS should have just used the older version of GNOME. No matter how you put it, no technical reason justifies breaking this way the user interface. Again, if it were something affecting < 1% of the users, I would have understood. But not in this case. It's not a glitch hidden somewhere, it's one of the first things people notice after installing Ubuntu. I noticed it in a matter of minutes. It's *NOT* a problem of resources, it's a decision-making problem. Vlad -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813441 Title: Can no longer drag and drop files between desktop and applications To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1813441/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813441] Re: Can no longer drag and drop files between desktop and applications
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 dirty (whatever) code, until you have a VALID replacement. You're *under-estimating* the impact of such a bug. Desktop icons have been "a thing" for the last 30 years or so and are the first thing any user sees. And I'm not talking only about non-technical people: I'm talking about people like me that have been using Linux since 1998. Now, not only arrow keys and drag'n'drop don't work, but even just creating or deleting a file on the desktop causes an ugly refresh. Sometimes, just moving an icon causes the whole gnome shell to crash. I was hoping this bug would be fixed ASAP after the 20.04 release or, at most, for the 20.10 release, but still nothing. And, no, I don't wanna use dirty workarounds which will break on upgrade. I'd like an officially-supported fix. For instabilities like these "the world" stopped using KDE 4 and switched to GNOME. Even MANY years later now, with KDE perfectly stable etc., people still use GNOME. Do you really want to loose the desktop segment? People will stop using Ubuntu for things like that. This bug's "Importance" should be: "VERY HIGH", not "Medium". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813441 Title: Can no longer drag and drop files between desktop and applications To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1813441/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled
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 rot there indefinitely. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ipxe/+bug/1882671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1882671] Re: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled
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 subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title: unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ipxe/+bug/1882671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios
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 worth, I just discovered that, even with the buggy ipxe- qemu in Focal, the OVMF distributed with QEMU itself (/usr/share/qemu/OVMF.fd) worked, but ONLY with it. I tried with multiple other versions of OVMF and all of them caused QEMU to stuck at boot, probably because of that ASSERT in the 82540em.efi driver. Vlad -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1882671] Re: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios
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 to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1882671] [NEW] qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios
Public bug reported: The version of QEMU (4.2.0) packaged for Ubuntu 20.04 hangs indefinitely at boot if an OVMF bios is used. This happens ONLY with qemu-system- x86_64. qemu-system-i386 works fine with the latest ia32 OVMF bios. NOTE[1]: the same identical OVMF bios works fine on QEMU 2.x packaged with Ubuntu 18.04. NOTE[2]: reproducing the fatal bug requires *no* operating system: qemu-system-x86_64 -bios OVMF-pure-efi.fd On its window QEMU gets stuck at the very first stage: "Guest has not initialized the display (yet)." NOTE[3]: QEMU gets stuck no matter if KVM is used or not. NOTE[4]: By adding the `-d int` option it is possible to observe that QEMU is, apparently, stuck in an endless loop of interrupts. For the first few seconds, registers' values vary quickly, but at some point they reach a final value, while the interrupt counter increments: 2568: v=68 e= i=0 cpl=0 IP=0038:07f1d225 pc=07f1d225 SP=0030:07f0c8d0 env->regs[R_EAX]= RAX= RBX=07f0c920 RCX= RDX=0001 RSI=06d18798 RDI=8664 RBP= RSP=07f0c8d0 R8 =0001 R9 =0089 R10= R11=07f2c987 R12= R13= R14=07087901 R15= RIP=07f1d225 RFL=0246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0030 00cf9300 DPL=0 DS [-WA] CS =0038 00af9a00 DPL=0 CS64 [-R-] SS =0030 00cf9300 DPL=0 DS [-WA] DS =0030 00cf9300 DPL=0 DS [-WA] FS =0030 00cf9300 DPL=0 DS [-WA] GS =0030 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 079eea98 0047 IDT= 0758f018 0fff CR0=80010033 CR2= CR3=07c01000 CR4=0668 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=0044 CCD= CCO=EFLAGS EFER=0d00 NOTE[5]: Just to better help the investigation of the bug, I'd like to remark that the issue is NOT caused by an endless loop of triple-faults. I tried with -d cpu_reset and there is NO such loop. No triple fault whatsoever. NOTE[6]: The OVMF version used for the test has been downloaded from: https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200515.1398.g6ff7c838d0.noarch.rpm but the issue is the 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: New ** Affects: qemu (Ubuntu) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882671 Title: qemu-system-x86_64 (ver 4.2) stuck at boot with OVMF bios To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
*** 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 order to get some attention. Honestly, I didn't even thought the bug could be _that_ bad and I didn't test that simple scenario. I just assumed it worked. But, certainly, just a simple question from any maintainer about this use-case could have helped solving this bug much earlier and saving time to all the people it affected. I mean, it's not disappointing that it took one month to get a fix. If the bug affected only my scenario that would had been fine. It's disappointing that even if there was a single _small_ 100% guilty patch, in one month, bug #1846557 did not get a _single_ technical comment/question. We could have discovered this broader-scope bug much earlier. It's not about fixing any bug "right now" (bugs have priority). It's about at least talking with the reporter and don't underestimate the scope of the bug, even if it appears to be narrow. It might not be. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1848200 Title: gdb not stopping on breakpoint in a 32-bit program To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846557] Re: Unable to debug any kernel on i386 qemu machine
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/1846557 Title: Unable to debug any kernel on i386 qemu machine To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
*** 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 to Ubuntu. https://bugs.launchpad.net/bugs/1848200 Title: gdb not stopping on breakpoint in a 32-bit program To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846557] Re: Unable to debug any kernel on i386 qemu machine
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 to boot a full system, but for me it was enough to break on start_kernel and then trying to do `stepi`. Exactly like with the other project, with the gdb version `Ubuntu 8.1-0ubuntu3` it worked perfectly, while with gdb `Ubuntu 8.1-0ubuntu3.1` I got the same problem: (gdb) b start_kernel warning: Breakpoint address adjusted from 0xc17257cd to 0xc17257cd. Breakpoint 1 at 0xc17257cd (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si Therefore, as expected, the bug affects _definitively_ any kind of 32-bit code when remote debugging is used and the client is 64-bit. I also checked if the latest non-Ubuntu gdb is affected by this issue and it's not. In conclusion, I believe that the following patch introduced the regression: http://launchpadlibrarian.net/431301516/gdb_8.1-0ubuntu3_8.1-0ubuntu3.1.diff.gz And that the bug needs to get some attention. After all, people _cannot_ debug a 32-bit linux kernel running on a VM anymore, if they're using Ubuntu. @Manoj could you please comment? Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846557 Title: Unable to debug any kernel on i386 qemu machine To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846557] [NEW] Unable to debug any kernel on i386 qemu machine
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 breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , > use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. As you see, the whole QEMU VM is stuck until I quit GDB. Note: I downgraded exclusively GDB back to version 'Ubuntu 8.1-0ubuntu3' in order to check if the problem would be fixed and it is. I'm sure the problem has been introduced in this specific version 'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with the kernel that is being debugged. It's totally independent from that. Final remark: note that I'm running gdb on x86_64 machine, while I'm debugging a kernel running on a i386 (virtual) machine. I believe that the cross-arch scenario almost certainly has something to do with the bug, as it happened in the past on both sides (qemu and gdb). Thanks a lot, Vlad ** Affects: gdb (Ubuntu) Importance: Undecided Status: New ** Tags: bionic regression-update ** Description changed: 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 breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. - Which seems (and actually is a bad sign), for what comes later. [why do + Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) - at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 + at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) *
[Bug 468266] Re: the Bulgarian spell-check does not function
*** 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 seems to work pretty fine. Can this bug be fixed, please? Thanks, Vlad -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/468266 Title: the Bulgarian spell-check does not function To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/468266/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
