[Touch-packages] [Bug 2045621] Re: Improve power consumption on Framework systems
** Tags added: amd originate-from-2044861 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2045621 Title: Improve power consumption on Framework systems Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Committed Status in systemd-hwe package in Ubuntu: Invalid Status in systemd source package in Jammy: Confirmed Status in systemd-hwe source package in Jammy: Confirmed Status in systemd source package in Lunar: Confirmed Status in systemd-hwe source package in Lunar: Confirmed Status in systemd source package in Mantic: Confirmed Status in systemd-hwe source package in Mantic: Confirmed Status in systemd source package in Noble: Fix Committed Status in systemd-hwe source package in Noble: Invalid Bug description: [ Impact ] * Framework systems that have DP or HDMI cards connected will have increased power consumption even when nothing is connected to DP or HDMI ports since the cards don't default to autosuspend. * Backporting upstream patch that adds rules in hwdb.d/60-autosuspend.hwdb for Framework's HDMI and DP extensions. [ Test Plan ] * DUT: Framework with DP and HDMI: $ lsusb | grep Framework Bus 007 Device 002: ID 32ac:0003 Framework DisplayPort Expansion Card Bus 001 Device 002: ID 32ac:0002 Framework HDMI Expansion Card 1. Autosuspend is not enabled before patch. Set to "on" in power/control $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/power/control on $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/power/control on 2. Install patch 3. Autosuspend is enabled for both extensions. Set to "auto" in power/control $ cat power/control auto [ Where problems could occur ] * During testing verified that both DP+HDMI display show good output after hot-plug, system suspend, and reboot. There might be some differences when hibernate and hotplug. [ Other Info ] * https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2045621/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045621] Re: Improve power consumption on Framework systems
Hi Artur, We may want to use systemd-hwe to support this. ** Also affects: systemd-hwe (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: In Progress => Fix Committed ** Changed in: systemd (Ubuntu) Assignee: Artur Pak (artur-at-work) => (unassigned) ** Changed in: oem-priority Importance: Undecided => High ** Changed in: oem-priority Status: New => In Progress ** Also affects: systemd (Ubuntu Noble) Importance: High Status: Fix Committed ** Also affects: systemd-hwe (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd-hwe (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: systemd-hwe (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: systemd-hwe (Ubuntu Lunar) Importance: Undecided Status: New ** Changed in: systemd-hwe (Ubuntu Noble) Status: New => Invalid ** Changed in: systemd (Ubuntu Noble) Importance: High => Undecided ** Changed in: systemd-hwe (Ubuntu Jammy) Importance: Undecided => Wishlist ** Changed in: systemd-hwe (Ubuntu Lunar) Importance: Undecided => Wishlist ** Changed in: systemd-hwe (Ubuntu Mantic) Importance: Undecided => Wishlist ** Changed in: systemd-hwe (Ubuntu Noble) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Noble) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Mantic) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Lunar) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => Wishlist ** Tags removed: originate-from-2045516 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2045621 Title: Improve power consumption on Framework systems Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Committed Status in systemd-hwe package in Ubuntu: Invalid Status in systemd source package in Jammy: Confirmed Status in systemd-hwe source package in Jammy: Confirmed Status in systemd source package in Lunar: Confirmed Status in systemd-hwe source package in Lunar: Confirmed Status in systemd source package in Mantic: Confirmed Status in systemd-hwe source package in Mantic: Confirmed Status in systemd source package in Noble: Fix Committed Status in systemd-hwe source package in Noble: Invalid Bug description: [ Impact ] * Framework systems that have DP or HDMI cards connected will have increased power consumption even when nothing is connected to DP or HDMI ports since the cards don't default to autosuspend. * Backporting upstream patch that adds rules in hwdb.d/60-autosuspend.hwdb for Framework's HDMI and DP extensions. [ Test Plan ] * DUT: Framework with DP and HDMI: $ lsusb | grep Framework Bus 007 Device 002: ID 32ac:0003 Framework DisplayPort Expansion Card Bus 001 Device 002: ID 32ac:0002 Framework HDMI Expansion Card 1. Autosuspend is not enabled before patch. Set to "on" in power/control $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/power/control on $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/power/control on 2. Install patch 3. Autosuspend is enabled for both extensions. Set to "auto" in power/control $ cat power/control auto [ Where problems could occur ] * During testing verified that both DP+HDMI display show good output after hot-plug, system suspend, and reboot. There might be some differences when hibernate and hotplug. [ Other Info ] * https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2045621/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Description changed: [Workaround] Some workarounds have been suggested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/comments/125 [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` - Based on grub_mm_dump, we can see the memory fragment (some parts seem - likely be used because of 4K resolution?) and doesn’t have available - contiguous memory for larger file as: - - ``` - grub_real_malloc(...) + Based on grub_mm_dump, we can see the memory region starvation in <1G + addresses: + + Type StartEnd # Pages Attributes + Available -00086FFF 0087 000F + BS_Data00087000-00087FFF 0001 000F + Available 00088000-0009EFFF 0017 000F + Reserved 0009F000-0009 0001 000F + Available 0010-00FF 0F00 000F + LoaderCode 0100-01021FFF 0022 000F + Available 01022000-238A7FFF 00022886 000F + BS_Data238A8000-23927FFF 0080 000F + Available 23928000-28860FFF 4F39 000F + BS_Data28861000-2AB09FFF 22A9 000F + LoaderCode 2AB0A000-2ACF8FFF 01EF 000F + BS_Data2ACF9000-2B2FAFFF 0602 000F + Available 2B2FB000-2B611FFF 0317 000F + BS_Data2B612000-2B630FFF 001F 000F + Available 2B631000-2B632FFF 0002 000F + BS_Data2B633000-2B63CFFF 000A 000F + Available 2B63D000-2B649FFF 000D 000F + BS_Data2B64A000-2B64EFFF 0005 000F + Available 2B64F000-2B666FFF 0018 000F + BS_Data2B667000-2D8D5FFF 226F 000F + LoaderCode 2D8D6000-2D8E9FFF 0014 000F + BS_Data2D8EA000-2D925FFF 003C 000F + LoaderCode 2D926000-2D932FFF 000D 000F + BS_Data2D933000-2D969FFF 0037 000F + BS_Code2D96A000-2D973FFF 000A 000F + BS_Data2D974000-2E377FFF 0A04 000F + Available 2E378000-2E37AFFF 0003 000F ... - if (cur->size >= n + extra) - ``` + Reserved 3C08B000-4192 58A5 000F + ACPI_NVS 4193-41B2 0200 000F + ACPI_Recl 41B3-41BFEFFF 00CF 000F + BS_Data41BFF000-41BF 0001 000F + Available 0001-0002AB7F 001AB800 000F + Reserved 000A-000F 0060 + Reserved 41C0-43FF 2400 + Reserved 4400-47FF 4000 000F + Reserved 4940-495F 0200 000F + Reserved 4C00-4FFF 4000 0009 + Reserved 5000-547F 4800 + MMIO C000-CFFF 0001 800
[Touch-packages] [Bug 1950282] Re: Fibocom WWAN FM350-GL-00 (Mediatek M80 5G) support
** Tags added: originate-from-1982919 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1950282 Title: Fibocom WWAN FM350-GL-00 (Mediatek M80 5G) support Status in HWE Next: New Status in OEM Priority Project: New Status in linux package in Ubuntu: Incomplete Status in modemmanager package in Ubuntu: Confirmed Bug description: :55:00.0 Wireless controller [0d40]: MEDIATEK Corp. Device [14c3:4d75] (rev 01) Subsystem: Hewlett-Packard Company Device [103c:8914] https://lore.kernel.org/linux- wireless/20211101035635.26999-1-ricardo.marti...@linux.intel.com/ Modemmanager requires >= 1.19.1, the detail info is in lp:1962525 --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: skip Dependencies: DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-focal-amd64-20200502-85+fossa-edge-staging+X136 DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2021-07-13 (119 days ago) InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58 MachineType: Intel Corporation Alder Lake Client Platform Package: linux-firmware 1.187.20+staging.31 PackageArchitecture: all ProcFB: 0 i915 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.14.0-9007-oem root=UUID=56278c18-b6d3-4b07-b758-32f574db7ae0 ro i915.force_probe=46c0 automatic-oem-config quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.14.0-9007.7+staging.29-oem 5.14.14 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-5.14.0-9007-oem N/A linux-backports-modules-5.14.0-9007-oem N/A linux-firmware 1.187.20+staging.31 Tags: focal Uname: Linux 5.14.0-9007-oem x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A _MarkForUpload: True dmi.bios.date: 08/23/2021 dmi.bios.vendor: Intel Corporation dmi.bios.version: ADLPFWI1.R00.2347.A00.2108230957 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: AlderLake-M LP5 RVP dmi.board.vendor: Intel Corporation dmi.board.version: 1 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: Intel Corporation dmi.chassis.version: 0.1 dmi.ec.firmware.release: 1.43 dmi.modalias: dmi:bvnIntelCorporation:bvrADLPFWI1.R00.2347.A00.2108230957:bd08/23/2021:efr1.43:svnIntelCorporation:pnAlderLakeClientPlatform:pvr0.1:rvnIntelCorporation:rnAlderLake-MLP5RVP:rvr1:cvnIntelCorporation:ct9:cvr0.1:sku01010002: dmi.product.family: Alder Lake Client System dmi.product.name: Alder Lake Client Platform dmi.product.sku: 01010002 dmi.product.version: 0.1 dmi.sys.vendor: Intel Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1950282/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
Is it possible if we have an overwrite in debian/rule by using something like DEB_BUILD_ARCH to specify higher compression rate for amd64? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Triaged Status in grub2-unsigned package in Ubuntu: Triaged Status in initramfs-tools package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package, then test grubx64.efi is under “obj/monolith
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
Hi Daniel, Finally, I tried to reproduce your scenario on my side but not able to reproduce. * Environment: ubuntu 22.04 64G RAM (allocated a process to occupy 32G RAN) NVMe storage 32G micron SD card (dd /dev/random to a 29G file) * A script to reproduce: #!/bin/bash count=0 file="29G-file" while [ 1 ]; do count=$((count+1)) echo "--the $count times" rm ${HOME}/${file} sync echo 3 | sudo tee /proc/sys/vm/drop_caches ionice -c3 nice cp -a /mnt/mmc/${file} ${HOME}/${file} sync done The result is it was pass 25 times of copying file. I was monitor the system resource that in my case, the swapping was not trigger and the copy action didn't consume too many memory. Could you please help to monitor the memory usage when you try to copy file? ** Attachment added: "Screenshot from 2022-11-06 17-12-51.png" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1985887/+attachment/5629411/+files/Screenshot%20from%202022-11-06%2017-12-51.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
I don't think "MODULES=dep" is the proper workaround for this. If an user somehow met this issue, then the system is not able to boot. Users need to do many extra works to find out this workaround and do apply unless we make "MODULES=dep" as default setting in initramfs configs (but I don't think it's doable). Based on #117, we also confirm the stock ubuntu not able to boot on some machines. The fix needs to be included in the packages from ubuntu-archive as common solution. Julian, Can we go back to consider #105, #106 to try to land it in Lunar or Kinetic first? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Triaged Status in grub2-unsigned package in Ubuntu: Triaged Status in initramfs-tools package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and nev
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
If possible, I still expect we can make grub supports to boot from bigger initramfs. There will still have users to meet this issue in the future if their initramfs somehow bigger as long as we don't choose use higher compression as workaround (for ubuntu desktop / server). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Triaged Status in grub2-unsigned package in Ubuntu: Triaged Status in initramfs-tools package in Ubuntu: Won't Fix Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test sou
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
I don't have such "there is allways that machine (or bad firmware) that nobody heard of that will fail" case from my hand but it's frustrated if it becomes a blocker for fixing the bug for new devices from market. However, I understand how users feel helpless if a SRU introduces a regression especially the bootloader. I think it's worth to mention that, here are many users reported their certain real cases (as opposed to "there is allways that machine (or bad firmware) that nobody heard of that will fail") which causes there system not able to boot. As we all known, Fedora and Arch linux are using higher compression rate (for initramfs) to avoid this issue. I could try the upstream grub as soon as I can and to see if I can prepare such scheme as what the mailing thread mentioned but I afraid it'll definitely take times. Anyway, if we can have some solutions for existing impacted user, then it'll very helpful. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
It's interesting. I would like to reproduce your scenario on my side. Would you please share: 1. "ionice -c3 nice cp -a SRC DST" is mandatory? Does it reproducible through a normal "cp -a"? 2. What's the fail rate? 3. Would you please share the data type from "SRC"? a single large 29,613MB file? or a lot of small files? or 300MB * 100 files? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
Hi Julian, I didn't see the 'boot failures on older system' from comment#90. Would you please point it out more specifically? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package, then test grubx64.efi is under “obj/monolithic/grub-efi-amd64/grubx64.efi”, in my case: `/var/cache/pbuild
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
Hi Daniel, could you please share the log (e.g. apport, sosreport or journalctl when issue happens)? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Invalid Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
Hi Mauricio, From the patch set in this ticket: ``` +0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch +0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch +0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch +0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch +0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch +0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch +0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch ``` 0129-0133 are the key patches to support the >4G memory allocation which made by vathpela and I didn't see they are upstreamed. From my point of view, it won't upstream because upstream has different approach to allocate memory for kernel and initramfs. Therefore, the last time I debug this issue is based on ubuntu code base. Indeed, I should take a look to see if upstream version whether has this issue. However, I learned from Julian that upstream refactored the MM part. (says, the patches will likely be dropped after 2.12 grub) I can give it a try but it takes time because I'm a newbie in the grub. Even if there is a patch on upstream, it need to based on the refactored MM which might not easy to land in LTS version as users expected. I suggest to consider to carry these patches in ubuntu to unblock the ubuntu users first. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” bu
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
Hi renton, If you want to build it by yourself, then you should clone this: https://people.canonical.com/~jeremysu/lp1842320/ and built it locally and don't clear the build environment, you can found the efi binary on "obj/monolithic/grub-efi-amd64/grubx64.efi". I personally use pbuilder with some hooks when debugging. Alternatively, I upload the binary built by me on https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320v2 and for sure, the efi binary relates to security, then build it by yourself makes sense (but TBH it's not easy as other packages.) If you want to give it a try, then I suggest don't replace the original efi binary. Instead, you can use something like efibootmgr -c -L 'lp1842320' -d ${u-r-boot-dev} -p ${partition} -l '\EFI\ubuntu\grubx64.efi.lp1842320v2' for example: efibootmgr -c -L 'lp1842320' -d /dev/vda -p 2 -l '\EFI\ubuntu\grubx64.efi.lp1842320v2' and use something like 'efibootmgr -n ${your-boot-order-of-lp1842320}' or press F9 on HP machine or press F12 on Lenovo machine Please only do that if you know what you are doing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_la
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
Closed it first because I can not find any normal use case as what stress-ng did. Feel free to reopen and investigating if any normal use case got "being ...% > 50.00% for > 20s with reclaim activity". ** Changed in: systemd (Ubuntu) Status: New => Invalid ** Changed in: oem-priority Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Invalid Status in systemd package in Ubuntu: Invalid Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
alright, although the children are belong to same cgroup but > as a measurement of the CPU time lost due to lack of memory. it seems to me there is no a normal case from users will hit it unless memory stressors. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
yes, it same as what I understand. systemd-run and over ssh could have a session out of monitored by systemd-oomd. I'm trying to understand if any use cases will similar to this case? something like launching a lot of tabs from chrome/firefox browsers, I suppose all tabs will belong to same cgroup to see if memory will > 50% over 20 seconds. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
systemd-oomd doesn't care about the slices other than user slice, it's why the sshd won't be killed but it also use a lot of memory: /sys/fs/cgroup/user.slice/user-1001.slice/session-4.scope/memory.pressure some avg10=69.94 avg60=69.56 avg300=43.64 total=202010660 full avg10=69.07 avg60=68.73 avg300=43.07 total=199371697 Tue Aug 16 03:32:11 PM CST 2022 Dry Run: no Swap Used Limit: 90.00% Default Memory Pressure Limit: 60.00% Default Memory Pressure Duration: 20s System Context: Memory: Used: 3.5G Total: 3.5G Swap: Used: 1.9G Total: 1.9G Swap Monitored CGroups: Memory Pressure Monitored CGroups: Path: /user.slice/user-1001.slice/user@1001.service Memory Pressure Limit: 50.00% Pressure: Avg10: 25.40 Avg60: 24.64 Avg300: 12.24 Total: 1min 15s Current Memory Usage: 74.5M Memory Min: 0B Memory Low: 0B Pgscan: 24554223 Last Pgscan: 24533954 --- only user@1001.service in monitoring score. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s)
okay, I can reproduce this issue in Xorg as well. `stress-ng --stack 0 --timeout 300` and I can see Tue Aug 16 03:13:49 PM CST 2022 ./memory.pressure some avg10=64.25 avg60=28.75 avg300=7.33 total=23575913 full avg10=62.74 avg60=28.13 avg300=7.17 total=23107632 ./vte-spawn-9dbf6c12-a335-464f-b337-c3b5b6d1ac30.scope/memory.pressure some avg10=63.79 avg60=29.06 avg300=7.44 total=23418603 full avg10=62.34 avg60=28.46 avg300=7.29 total=22962690 ./gnome-terminal-server.service/memory.pressure some avg10=3.99 avg60=1.22 avg300=0.28 total=1098016 full avg10=3.99 avg60=1.22 avg300=0.28 total=1098016 already over 50% as Aug 16 15:13:49 ubuntu systemd-oomd[795]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-9dbf6c12-a335-464f-b337-c3b5b6d1ac30.scope due to memory pressure for /user.slice/user-1001.slice/user@1001.service being 70.58% > 50.00% for > 20s with reclaim activity ** Summary changed: - systemd kills gnome-shell or gnome-terminal if gnome is in Wayland mode + systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) ** Description changed: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" + or + "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd - It's because all stressors are under same cgroup. + It's because all stressors are under same cgroup belongs to terminal. - So far, it only happen in Wayland. + Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome-terminal uses much memory (50% over 20s) Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" or "stress-ng --stack 0 --timeout 300" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup belongs to terminal. Both Wayland and Xorg can reproduce. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] Re: systemd kills gnome-shell or gnome-terminal if gnome in Wayland
I did read some threads / bugs. >From what I can see so far, it doesn't relate to swap because stressors will >fill all memory / swap. Although it's a stress test, I though if user has many tabs on browser will eventually meet this issue. >From what systemd-oomd current design, it will kill the process if memory pressure over 50% (or 60 or configured percentage) over 20 seconds (or configured settings). Thus, the current behavior is by design. However, it leads bad experience. Since most of user processes will be counted into gnome, then gnome will frequently be killed if user launches heavy application. I'm think about if expect a process can not use 5.60% memory is a correct expectation. There are many reports from upstream or other distributions to complaint about it. or enhance it to have a notification before killing. We could check why it won't happen in Xorg first. ** Also affects: oem-priority Importance: Undecided Status: New ** Summary changed: - systemd kills gnome-shell or gnome-terminal if gnome in Wayland + systemd kills gnome-shell or gnome-terminal if gnome is in Wayland mode ** Tags added: oem-priority wayland ** Changed in: oem-priority Importance: Undecided => High ** Changed in: oem-priority Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome is in Wayland mode Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup. So far, it only happen in Wayland. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1985887] [NEW] systemd kills gnome-shell or gnome-terminal if gnome in Wayland
Public bug reported: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup. So far, it only happen in Wayland. over ssh and in multi-user.target work good. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1985887 Title: systemd kills gnome-shell or gnome-terminal if gnome in Wayland Status in systemd package in Ubuntu: New Bug description: [Steps to reproduce] 0. Install Jammy image 1. open gnome terminal 2. issue stress_ng or Canonical certification tool checkbox as "checkbox-cli run com.canonical.certification::memory/memory_stress_ng" 3. Terminal or Gnome-shell will be killed by systemd-oomd It's because all stressors are under same cgroup. So far, it only happen in Wayland. over ssh and in multi-user.target work good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1985887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607435/+files/0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607434/+files/0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
This patch is not from upstream or rhboot but which has been submitted as a MP to rhboot https://github.com/rhboot/grub2/pull/102 +0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch +0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch +0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch +0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch +0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch +0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch +0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch 0129-0134 are from rhboot. ** Patch added: "0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607436/+files/0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOC
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607433/+files/0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package, then test
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607432/+files/0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package, then test g
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607431/+files/0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320 * Test source code: https://github.com/os369510/grub2/tree/lp1842320 * If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
As my MP from comment#69 doesn't have response from rhboot team. Shared the debdiff here for review to consider to carry it in Ubuntu. ** Patch added: "0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607429/+files/0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Can't boot: "error: out of memory." immediately after the grub menu Status in grub: Unknown Status in OEM Priority Project: Triaged Status in grub2-signed package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * In some cases, if the users’ initramfs grow bigger, then it’ll likely not be able to be loaded by grub2. * Some real cases from OEM projects: In many built-in 4k monitor laptops with nvidia drivers, the u-d-c puts the nvidia*.ko to initramfs which grows the initramfs to ~120M. Also the gfxpayload=auto will remain to use 4K resolution since it’s what EFI POST passed. In this case, the grub isn't able to load initramfs because the grub_memalign() won't be able to get suitable memory for the larger file: ``` #0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ``` Based on grub_mm_dump, we can see the memory fragment (some parts seem likely be used because of 4K resolution?) and doesn’t have available contiguous memory for larger file as: ``` grub_real_malloc(...) ... if (cur->size >= n + extra) ``` Based on UEFI Specification Section 7.2[1] and UEFI driver writers’ guide 4.2.3[2], we can ask 32bits+ on AllocatePages(). As most X86_64 platforms should support 64 bits addressing, we should extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available memory. * When users grown the initramfs, then probably will get initramfs not found which really annoyed and impact the user experience (system not able to boot). [Test Plan] * detailed instructions how to reproduce the bug: 1. Any method to grow the initramfs, such as install nvidia-driver. 2. If developers would like to reproduce, then could dd if=/dev/random of=... bs=1M count=500, something like: ``` $ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500 ``` And then update-initramfs * After applying my patches, the issue is gone. * I did also test my test grubx64.efi in: 1. X86_64 qemu with 1.1. 60M initramfs + 5.15.0-37-generic kernel 1.2. 565M initramfs + 5.17.0-1011-oem kernel 2. Amd64 HP mobile workstation with 2.1. 65M initramfs + 5.15.0-39-generic kernel 2.2. 771M initramfs + 5.17.0-1011-oem kernel All working well. [Where problems could occur] * The changes almost in i386/efi, thus the impact will be in the i386 / x86_64 EFI system. The other change is to modify the “grub-core/kern/efi/mm.c” but I use the original addressing for “arm/arm64/ia64/riscv32/riscv64”. Thus it should not impact them. * There is a “#if defined(__x86_64__)” which intent to limit the > 32bits code in i386 system and also ``` #if defined (__code_model_large__) -#define GRUB_EFI_MAX_USABLE_ADDRESS 0x +#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__ +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff #else #define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff +#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff #endif ``` If everything works as expected, then i386 should working good. If not lucky, based on “UEFI writers’ guide”[2], the i386 will get > 4GB memory region and never be able to access. [Other Info] * Upstream grub2 bug #61058 https://savannah.gnu.org/bugs/index.php?61058 * Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320 * Test grubx64.efi: https://people.canonical.com/~jeremysu/lp
[Touch-packages] [Bug 1842320] Re: Out of Memory on boot with 5.2.0 kernel
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376 #1 0x7dd7b074 in grub_malloc (size=592214020) at ../../../grub-core/kern/mm.c:408 #2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076) at ../../../grub-core/kern/verifiers.c:150 #3 0x7dd801d4 in grub_file_open (name=0x7bc02f00 "/boot/initrd.img-5.17.0-1011-oem", type=131076) at ../../../grub-core/kern/file.c:121 #4 0x7bcd5a30 in ?? () #5 0x7fe21247 in ?? () #6 0x7bc030c8 in ?? () #7 0x00017fe21238 in ?? () #8 0x7bcd5320 in ?? () #9 0x7fe21250 in ?? () #10 0x in ?? () ... Thus, it likely same as my assumption, grub not able to read a lager file. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Out of Memory on boot with 5.2.0 kernel Status in grub: Unknown Status in OEM Priority Project: In Progress Status in grub2-signed package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Upgraded from 19.04 to current 19.10 using "do-release-upgrade -d". Can still boot using the previous 5.0.0-25-generic kernel, but the 5.2.0-15-generic fails to start. On selecting Ubuntu from Grub, the message "error: out of memory." is immediately shown. Pressing a key attempts to start boot-up but fails to mount root fs. Machine is HP Spectre X360 with 8GB RAM. Under kernel 5.0.0, free shows the following (run from Gnome terminal): totalusedfree shared buff/cache available Mem:7906564 1761196 3833240 1020216 2312128 4849224 Swap: 1003516 0 1003516 Kernel packages installed: linux-generic 5.2.0.15.16 amd64 linux-headers-5.2.0-15 5.2.0-15.16 all linux-headers-5.2.0-15-generic 5.2.0-15.16 amd64 linux-headers-generic 5.2.0.15.16 amd64 linux-image-5.0.0-25-generic 5.0.0-25.26 amd64 linux-image-5.2.0-15-generic 5.2.0-15.16+signed1 amd64 linux-image-generic5.2.0.15.16 amd64 linux-modules-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-5.2.0-15-generic 5.2.0-15.16 amd64 linux-modules-extra-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-extra-5.2.0-15-generic 5.2.0-15.16 amd64 Photo of kernel panic attached. NVMe drive partition layout (GPT): Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506242549759 1499136 732M Linux filesystem /dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem $ sudo pvs PV VGFmt Attr PSizePFree /dev/mapper/nvme0n1p3_crypt ubuntu-vg lvm2 a-- <475.71g0 $ sudo lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao 474.75g swap_1 ubuntu-vg -wi-ao 980.00m Partition 3 is LUKS encrypted. Root LV is ext4. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gmckeown 1647 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.10 InstallationDate: Installed on 2019-08-15 (18 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 04f2:b593 Chicony Electronics Co., Ltd HP Wide Vision FHD Camera Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 13-ae0xx Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 RelatedPackageVersions: linux-restricted-modules-5.0.0-25-generic N/A linux-backports-modules-5.0.0-25-generic N/A linux-firmware1.181 Tags: eoan Uname: Linux 5.0.0-25-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-09-02 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 05/17/2019 dmi.bios.vendor: AMI dmi.bios.version: F.25 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83B9 dmi.board.vendor: HP dmi.board.version: 56.43 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: C
[Touch-packages] [Bug 1842320] Re: Out of Memory on boot with 5.2.0 kernel
In my scenario, the 'out of memory' occurred in grub_memalign(). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Out of Memory on boot with 5.2.0 kernel Status in grub: Unknown Status in OEM Priority Project: In Progress Status in grub2-signed package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Upgraded from 19.04 to current 19.10 using "do-release-upgrade -d". Can still boot using the previous 5.0.0-25-generic kernel, but the 5.2.0-15-generic fails to start. On selecting Ubuntu from Grub, the message "error: out of memory." is immediately shown. Pressing a key attempts to start boot-up but fails to mount root fs. Machine is HP Spectre X360 with 8GB RAM. Under kernel 5.0.0, free shows the following (run from Gnome terminal): totalusedfree shared buff/cache available Mem:7906564 1761196 3833240 1020216 2312128 4849224 Swap: 1003516 0 1003516 Kernel packages installed: linux-generic 5.2.0.15.16 amd64 linux-headers-5.2.0-15 5.2.0-15.16 all linux-headers-5.2.0-15-generic 5.2.0-15.16 amd64 linux-headers-generic 5.2.0.15.16 amd64 linux-image-5.0.0-25-generic 5.0.0-25.26 amd64 linux-image-5.2.0-15-generic 5.2.0-15.16+signed1 amd64 linux-image-generic5.2.0.15.16 amd64 linux-modules-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-5.2.0-15-generic 5.2.0-15.16 amd64 linux-modules-extra-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-extra-5.2.0-15-generic 5.2.0-15.16 amd64 Photo of kernel panic attached. NVMe drive partition layout (GPT): Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506242549759 1499136 732M Linux filesystem /dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem $ sudo pvs PV VGFmt Attr PSizePFree /dev/mapper/nvme0n1p3_crypt ubuntu-vg lvm2 a-- <475.71g0 $ sudo lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao 474.75g swap_1 ubuntu-vg -wi-ao 980.00m Partition 3 is LUKS encrypted. Root LV is ext4. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gmckeown 1647 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.10 InstallationDate: Installed on 2019-08-15 (18 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 04f2:b593 Chicony Electronics Co., Ltd HP Wide Vision FHD Camera Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 13-ae0xx Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 RelatedPackageVersions: linux-restricted-modules-5.0.0-25-generic N/A linux-backports-modules-5.0.0-25-generic N/A linux-firmware1.181 Tags: eoan Uname: Linux 5.0.0-25-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-09-02 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 05/17/2019 dmi.bios.vendor: AMI dmi.bios.version: F.25 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83B9 dmi.board.vendor: HP dmi.board.version: 56.43 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAMI:bvrF.25:bd05/17/2019:svnHP:pnHPSpectrex360Convertible13-ae0xx:pvr:rvnHP:rn83B9:rvr56.43:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Spectre dmi.product.name: HP Spectre x360 Convertible 13-ae0xx dmi.product.sku: 2QH38EA#ABU dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/grub/+bug/1842320/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Out of Memory on boot with 5.2.0 kernel
** Tags added: jellyfish-edge-staging -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Out of Memory on boot with 5.2.0 kernel Status in grub: Unknown Status in OEM Priority Project: In Progress Status in grub2-signed package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Upgraded from 19.04 to current 19.10 using "do-release-upgrade -d". Can still boot using the previous 5.0.0-25-generic kernel, but the 5.2.0-15-generic fails to start. On selecting Ubuntu from Grub, the message "error: out of memory." is immediately shown. Pressing a key attempts to start boot-up but fails to mount root fs. Machine is HP Spectre X360 with 8GB RAM. Under kernel 5.0.0, free shows the following (run from Gnome terminal): totalusedfree shared buff/cache available Mem:7906564 1761196 3833240 1020216 2312128 4849224 Swap: 1003516 0 1003516 Kernel packages installed: linux-generic 5.2.0.15.16 amd64 linux-headers-5.2.0-15 5.2.0-15.16 all linux-headers-5.2.0-15-generic 5.2.0-15.16 amd64 linux-headers-generic 5.2.0.15.16 amd64 linux-image-5.0.0-25-generic 5.0.0-25.26 amd64 linux-image-5.2.0-15-generic 5.2.0-15.16+signed1 amd64 linux-image-generic5.2.0.15.16 amd64 linux-modules-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-5.2.0-15-generic 5.2.0-15.16 amd64 linux-modules-extra-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-extra-5.2.0-15-generic 5.2.0-15.16 amd64 Photo of kernel panic attached. NVMe drive partition layout (GPT): Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506242549759 1499136 732M Linux filesystem /dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem $ sudo pvs PV VGFmt Attr PSizePFree /dev/mapper/nvme0n1p3_crypt ubuntu-vg lvm2 a-- <475.71g0 $ sudo lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao 474.75g swap_1 ubuntu-vg -wi-ao 980.00m Partition 3 is LUKS encrypted. Root LV is ext4. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gmckeown 1647 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.10 InstallationDate: Installed on 2019-08-15 (18 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 04f2:b593 Chicony Electronics Co., Ltd HP Wide Vision FHD Camera Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 13-ae0xx Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 RelatedPackageVersions: linux-restricted-modules-5.0.0-25-generic N/A linux-backports-modules-5.0.0-25-generic N/A linux-firmware1.181 Tags: eoan Uname: Linux 5.0.0-25-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-09-02 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 05/17/2019 dmi.bios.vendor: AMI dmi.bios.version: F.25 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83B9 dmi.board.vendor: HP dmi.board.version: 56.43 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAMI:bvrF.25:bd05/17/2019:svnHP:pnHPSpectrex360Convertible13-ae0xx:pvr:rvnHP:rn83B9:rvr56.43:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Spectre dmi.product.name: HP Spectre x360 Convertible 13-ae0xx dmi.product.sku: 2QH38EA#ABU dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/grub/+bug/1842320/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1842320] Re: Out of Memory on boot with 5.2.0 kernel
** Bug watch added: GNU Savannah Bug Tracker #61058 http://savannah.gnu.org/bugs/?61058 ** Also affects: grub via http://savannah.gnu.org/bugs/?61058 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Out of Memory on boot with 5.2.0 kernel Status in grub: Unknown Status in OEM Priority Project: In Progress Status in grub2-signed package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Upgraded from 19.04 to current 19.10 using "do-release-upgrade -d". Can still boot using the previous 5.0.0-25-generic kernel, but the 5.2.0-15-generic fails to start. On selecting Ubuntu from Grub, the message "error: out of memory." is immediately shown. Pressing a key attempts to start boot-up but fails to mount root fs. Machine is HP Spectre X360 with 8GB RAM. Under kernel 5.0.0, free shows the following (run from Gnome terminal): totalusedfree shared buff/cache available Mem:7906564 1761196 3833240 1020216 2312128 4849224 Swap: 1003516 0 1003516 Kernel packages installed: linux-generic 5.2.0.15.16 amd64 linux-headers-5.2.0-15 5.2.0-15.16 all linux-headers-5.2.0-15-generic 5.2.0-15.16 amd64 linux-headers-generic 5.2.0.15.16 amd64 linux-image-5.0.0-25-generic 5.0.0-25.26 amd64 linux-image-5.2.0-15-generic 5.2.0-15.16+signed1 amd64 linux-image-generic5.2.0.15.16 amd64 linux-modules-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-5.2.0-15-generic 5.2.0-15.16 amd64 linux-modules-extra-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-extra-5.2.0-15-generic 5.2.0-15.16 amd64 Photo of kernel panic attached. NVMe drive partition layout (GPT): Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506242549759 1499136 732M Linux filesystem /dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem $ sudo pvs PV VGFmt Attr PSizePFree /dev/mapper/nvme0n1p3_crypt ubuntu-vg lvm2 a-- <475.71g0 $ sudo lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao 474.75g swap_1 ubuntu-vg -wi-ao 980.00m Partition 3 is LUKS encrypted. Root LV is ext4. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gmckeown 1647 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.10 InstallationDate: Installed on 2019-08-15 (18 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 04f2:b593 Chicony Electronics Co., Ltd HP Wide Vision FHD Camera Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 13-ae0xx Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 RelatedPackageVersions: linux-restricted-modules-5.0.0-25-generic N/A linux-backports-modules-5.0.0-25-generic N/A linux-firmware1.181 Tags: eoan Uname: Linux 5.0.0-25-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-09-02 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 05/17/2019 dmi.bios.vendor: AMI dmi.bios.version: F.25 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83B9 dmi.board.vendor: HP dmi.board.version: 56.43 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAMI:bvrF.25:bd05/17/2019:svnHP:pnHPSpectrex360Convertible13-ae0xx:pvr:rvnHP:rn83B9:rvr56.43:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Spectre dmi.product.name: HP Spectre x360 Convertible 13-ae0xx dmi.product.sku: 2QH38EA#ABU dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/grub/+bug/1842320/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : http
[Touch-packages] [Bug 1842320] Re: Out of Memory on boot with 5.2.0 kernel
the problem seems to me that memory allocation issue with higher resolution monitor. When issue happening, the grub shell not able to read some files (depends on current memory usage). For instance, I create 20M, 30M, 40M, 50M ... 80M, 90M, 100M, 101M, 102M ... 110M, 120M, 130M, etc... files and try to read them in grub shell. The "ls -al" only list the part of files. sometimes: "20M, 30M, 40M, 50M ... 80M, 90M, 100M, 101M, 102M" sometimes: "20M, 30M, 40M, 50M ... 80M, 90M" sometimes: "20M, 30M, 40M, 50M ... 80M" when force "ls -al test-130M", it will show "out-of-memory" it looks to me that depends the current memory usage. Based on my test, this issue is likely relate to EFI or grub (or initramfs config) instead of kernel. For the people be blocked by this issue, the best practice should change the initramfs compression method to reduce the file size as what ybdjkfd shared in comment#41. ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1842320 Title: Out of Memory on boot with 5.2.0 kernel Status in OEM Priority Project: In Progress Status in grub2-signed package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: Upgraded from 19.04 to current 19.10 using "do-release-upgrade -d". Can still boot using the previous 5.0.0-25-generic kernel, but the 5.2.0-15-generic fails to start. On selecting Ubuntu from Grub, the message "error: out of memory." is immediately shown. Pressing a key attempts to start boot-up but fails to mount root fs. Machine is HP Spectre X360 with 8GB RAM. Under kernel 5.0.0, free shows the following (run from Gnome terminal): totalusedfree shared buff/cache available Mem:7906564 1761196 3833240 1020216 2312128 4849224 Swap: 1003516 0 1003516 Kernel packages installed: linux-generic 5.2.0.15.16 amd64 linux-headers-5.2.0-15 5.2.0-15.16 all linux-headers-5.2.0-15-generic 5.2.0-15.16 amd64 linux-headers-generic 5.2.0.15.16 amd64 linux-image-5.0.0-25-generic 5.0.0-25.26 amd64 linux-image-5.2.0-15-generic 5.2.0-15.16+signed1 amd64 linux-image-generic5.2.0.15.16 amd64 linux-modules-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-5.2.0-15-generic 5.2.0-15.16 amd64 linux-modules-extra-5.0.0-25-generic 5.0.0-25.26 amd64 linux-modules-extra-5.2.0-15-generic 5.2.0-15.16 amd64 Photo of kernel panic attached. NVMe drive partition layout (GPT): Device StartEnd Sectors Size Type /dev/nvme0n1p120481050623 1048576 512M EFI System /dev/nvme0n1p2 10506242549759 1499136 732M Linux filesystem /dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem $ sudo pvs PV VGFmt Attr PSizePFree /dev/mapper/nvme0n1p3_crypt ubuntu-vg lvm2 a-- <475.71g0 $ sudo lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root ubuntu-vg -wi-ao 474.75g swap_1 ubuntu-vg -wi-ao 980.00m Partition 3 is LUKS encrypted. Root LV is ext4. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gmckeown 1647 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.10 InstallationDate: Installed on 2019-08-15 (18 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 04f2:b593 Chicony Electronics Co., Ltd HP Wide Vision FHD Camera Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Spectre x360 Convertible 13-ae0xx Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash ProcVersionSignature: Ubuntu 5.0.0-25.26-generic 5.0.18 RelatedPackageVersions: linux-restricted-modules-5.0.0-25-generic N/A linux-backports-modules-5.0.0-25-generic N/A linux-firmware1.181 Tags: eoan Uname: Linux 5.0.0-25-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-09-02 (0 days ago) UserGroups: adm cdrom dip lpadmin plugde
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
** Changed in: oem-priority Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
@Brian, Thanks for your attention. As comment#8 from LP#1955997: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookStudio16.0InchMobileWorkstationPC:pvr* ``` Unfortunately, ``` In the mail from HP (please see the lp1966179), HP also confirmed the previous two platforms' dmi string need to adjust. pnHPZBookFury16G9MobileWorkstationPC pnHPZBookStudio16inchG9MobileWorkstationPC ``` Sorry for I didn't explain it clearly, in the production phase, HP changed the product name of dmi table from HPZBookStudio16.0InchMobileWorkstationPC to HPZBookStudio16inchG9MobileWorkstationPC via internal mail from: Nukala, Ravi (CW) date: Mar 31, 2022, 11:23 AM subject:RE: [Stella] The airplane hotkey (F11) has no function I can forward the mail to use for reference if needed, thank you. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Incomplete Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Changed in: oem-priority Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Impish: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
Got feedback from Andy, other platforms are working good with -proposed version. ** Tags removed: verification-needed verification-needed-focal verification-needed-impish ** Tags added: verification-done verification-done-focal verification-done-impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9MobileWorkstationPC:pvr* from focal-proposed and impish-proposed are working on my Magneta-PV- SKU2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9MobileWorkstationPC:pvr* from focal-proposed and impish-proposed are working on my Vision-PV- SKU16 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
Thank you for your great support! ** Changed in: oem-priority Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Impish: In Progress Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Tags added: originate-from-1968990 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Impish: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Hi Nick and Brian, When I verified this ticket, I did upgrade systemd to proposed version on the target machines. (245.4-4ubuntu3.16 and 248.3-1ubuntu8.4) I can see the airplane mode toggled when pressing the airplane function key. I saw the targeted version now is "248.3-1ubuntu8.5". Let me give it a try. The 245.4-4ubuntu3.16 works on focal. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Fix Committed Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902464] Re: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time
** Changed in: oem-priority Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1902464 Title: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time Status in HWE Next: New Status in OEM Priority Project: Fix Released Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: Fix Released Status in alsa-ucm-conf source package in Focal: Fix Released Status in pulseaudio source package in Focal: Fix Released Bug description: == SRU Justification == [Impact] On P620, only single port can work on rear panel. For example, when the Line-Out is plugged, the Mic won't work anymore. [Fix] Use upstream version of UCM to handle port priority correctly, instead of separate ports into different profiles. [Test] Once the UCM is in place, all three ports of rear panel work correctly. [Where problems could occur] UCM is not a static thing - it's actually interpreted differently at higher level. So any change in userspace daemons other than PulseAudio may not like the change and can interpret the UCM in another way. == Original Bug Report == After backporting following patches from PA and alsa-ucm-conf and then it works. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/354 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/USB- Audio [landed by aa74f4c12eefcc98582572d2fc48982cf7478b51] Here is the test PPA: https://launchpad.net/~os369510/+archive/ubuntu/oem-package-test Since the upstream not yet accepted those patches, the regression potential may quite high. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1902464/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
HP finally confirmed the dmistring for the G9 platforms we currently have. https://drive.google.com/file/d/12HxmGeHcGDRqyay_DLf3WR7M3-T8bv0V/view?usp=sharing -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Tags removed: verification-needed verification-needed-focal verification-needed-impish ** Tags added: verification-done verification-done-focal verification-done-impish ** Changed in: oem-priority Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Impish: Fix Committed Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1966179] Re: The airplane hotkey does not work on lots of HP platforms
Patch is here https://code.launchpad.net/~os369510/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu-focal PPA is here https://launchpad.net/~os369510/+archive/ubuntu/lp1966179 Hi Andy, Would you please help to try the systemd from the PPA? ** Changed in: oem-priority Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966179 Title: The airplane hotkey does not work on lots of HP platforms Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. [Where problems could occur] If we don't have whitelist in focal and impish, then the airplane key won't work on new HP platforms. Please refer to Bug #1955997 as well. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1966179/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1965490] Re: [FFe] Create multiple profiles per verb for conflicting devices
** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Importance: Undecided => Critical ** Tags added: oem-priority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1965490 Title: [FFe] Create multiple profiles per verb for conflicting devices Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: New Bug description: Please include the following MR to make UCM's ConflictingDevice work properly under PulseAudio. Systems like Lenovo P520c and Lenovo P620 requires the change to make audio port selection logic really work. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/596 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1965490/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902464] Re: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time
Upstream seems replaced the comment#7 by https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/596 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1902464 Title: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time Status in HWE Next: New Status in OEM Priority Project: Confirmed Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: Incomplete Bug description: After backporting following patches from PA and alsa-ucm-conf and then it works. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/354 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/USB- Audio [landed by aa74f4c12eefcc98582572d2fc48982cf7478b51] Here is the test PPA: https://launchpad.net/~os369510/+archive/ubuntu/oem-package-test Since the upstream not yet accepted those patches, the regression potential may quite high. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1902464/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Hi Robie, Lukas, As I mentioned on comment#17, impish and focal are using allowing-list to add two HP new products. I don't think it will cause the regression, could we please let impish and focal get the patch? The unblock intel-hid is in Jammy and it's not yet release, we can negotiate it before Jammy release, does it makes sense? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Impish: In Progress Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Hi Robie, Thanks for sharing the changes with other flavors. Just want to clarify the comment#14-16 are talking about Jammy which shouldn't blocking Focal#5 and Impish#10 SRU. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Impish: In Progress Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good without problem, depends on how DM handles multiple rfkill events). In this case, you could check: 1. sudo evtest # You probably could see # ... # /dev/input/event8: Intel HID events # ... # /dev/input/event11: Wireless hotkeys # or "HP Wireless hotkeys" depends on your kernel version 2. try to listen these events when pressing airplane key, you will probably see these two events will send the keycode out. 3. check the components own this event $ sudo udevadm info -a /dev/input/event11 # ... # ATTRS{phys}=="hpq6001/input0" $ sudo udevadm info -a /dev/input/event8 # ... #DRIVERS=="intel-hid" 4. check your hwdb is affect. $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb # If you didn't see anything then it means your intel-hid is unmask. 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* ``` to /lib/udev/hwdb.d/60-keyboard.hwdb then $ systemd-hwdb update $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Hi Robie, I think we are talking about Jammy as comment#11. and yes, as I mentioned in "Where problems could occur": >also each DM still need to deal with multi-rfkill events because upstream >changes[2]. From what I learned from HP, there are some old platforms have both Intel-HID and HPQ6001 components but I don't have the one in my side. I have 1. HPQ6001 HP laptop 2. Intel-HID HP laptop I shared what I can imaged when problems will occur, some check points and workaround in the bug description. Hope it can cover what you concerning. ** Description changed: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. + + In some old HP platforms (contains Intel-HID and HPQ6001 in same + machine), the user will aware the airplane mode toggled very quickly + e.g. turn-on and turn-off immediately (or works good without problem, + depends on how DM handles multiple rfkill events). + + In this case, you could check: + 1. sudo evtest + # You probably could see + # ... + # /dev/input/event8: Intel HID events + # ... + # /dev/input/event11: Wireless hotkeys + # or "HP Wireless hotkeys" depends on your kernel version + + 2. try to listen these events when pressing airplane key, you will + probably see these two events will send the keycode out. + + 3. check the components own this event + $ sudo udevadm info -a /dev/input/event11 + # ... + # ATTRS{phys}=="hpq6001/input0" + + $ sudo udevadm info -a /dev/input/event8 + # ... + #DRIVERS=="intel-hid" + + 4. check your hwdb is affect. + $ grep -rn "Intel HID" /lib/udev/hwdb.d/60-keyboard.hwdb + # If you didn't see anything then it means your intel-hid is unmask. + + 5. You could report a bug to your DM for dealing with two rfkill events (same as g-s-d[3]). Before your DM solves this issue, you could mask intel-hid as workaround (but it will be overwritten in next upgrade) by adding: + ``` + evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pn*:pvr* + ``` + to /lib/udev/hwdb.d/60-keyboard.hwdb + + then + $ systemd-hwdb update + $ udevadm trigger [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Impish: In Progress Status in systemd source package in Jammy: Fix Released Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. In some old HP platforms (contains Intel-HID and HPQ6001 in same machine), the user will aware the airplane mode toggled very quickly e.g. turn-on and turn-off immediately (or works good wit
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Changed in: oem-priority Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
for jammy, and verified pass on both platforms. BTW, for jammy. The intel-hid driver doesn't load probably caused by acpi device not found or other kernel/driver related issue. FWIK, 5.13 is not final kernel for jammy. I tried this patch with 5.14.0-oem-1018 kernel and it works as expected. ** Patch added: "lp1955997-unmask-intel-hid-for-HP-machines.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955997/+attachment/5553604/+files/lp1955997-unmask-intel-hid-for-HP-machines.debdiff ** Changed in: oem-priority Status: In Progress => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Confirmed Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
This patch is for impish. Verified pass on both HP new platforms. ** Patch added: "lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-mach.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955997/+attachment/5553585/+files/lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-mach.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Based on the discussion on https://chat.canonical.com/canonical/pl/ywmmrm9d9j8cdkcwbyx6rkwqgh. We will solve this issue by 1) maintain a whitelist on focal and impish 2) backport unmast intel-hid[1] on jammy [1] https://github.com/systemd/systemd/pull/20219 ** Patch removed: "lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-machines.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955997/+attachment/5552318/+files/lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-machines.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Changed in: oem-priority Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
Hi Lukas, The jammy and impish do have this issue and will be fixed in v250[1], FWIK, we will upgrade to v250 soon? let me know if you think I should still prepare the workaround for impish and jammy. [1] https://github.com/systemd/systemd/pull/20219 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
New version which supporting for two HP new machines. Please ignore comment#1. This patch contains the platform I mentioned on comment#3. ** Patch added: "lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-mach.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955997/+attachment/5552968/+files/lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-mach.debdiff ** Changed in: oem-priority Status: In Progress => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
btw, there is the other HP platform need the to be added in this whitelist but still confirming with HP about the correct dmi string. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
btw, there is the other HP new generation platform which need this kind of patch but still waiting for HP to confirm the correct dmi for whole platform generation. ** Description changed: + [Impact] + The airplane hokey doesn't work on HP new generation machines. + + [Test Plan] + Press airplane hokey. + + Before the patch, nothing happens. + After the patch, the rfkill works as expected. + + [Where problems could occur] + In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. + + --- + In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: - ``` + ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* - KEYBOARD_KEY_8=wlan # Use hp-wireless instead + KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubs
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
for focal ** Patch added: "lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-machines.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1955997/+attachment/5552318/+files/lp1955997-add-a-whitelist-to-unblock-intel-hid-on-HP-machines.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: [Impact] The airplane hokey doesn't work on HP new generation machines. [Test Plan] Press airplane hokey. Before the patch, nothing happens. After the patch, the rfkill works as expected. [Where problems could occur] In non-gnome ubuntu, if the specific dmi contains HPQ6001, then airplane will not work but HP confirmed the new HP generation won't contain the HPQ6001 and also each DM still need to deal with multi-rfkill events because upstream changes[2]. --- In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] Re: The airplane hotkey has no function on a HP platform
** Tags added: originate-from-1955896 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955997] [NEW] The airplane hotkey has no function on a HP platform
Public bug reported: In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda ** Affects: oem-priority Importance: Critical Assignee: jeremyszu (os369510) Status: In Progress ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1955457 stella ** Tags added: oem-priority originate-from-1955457 stella ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1955997 Title: The airplane hotkey has no function on a HP platform Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: New Bug description: In the last year, HP mentions HP machines need to use hp-wireless (HPQ6001) as the rfkill source[1]. However, HP confirms the HPQ6001 has been retired in the platforms since 2022. In the platforms after 2022, there are two sources of rkfill events (intel-hid, atkbd) and HP only guarantee the intel-hid works. Therefore, the upstream already accept the patch[2] to unmask intel-hid and mention this big change in the NEWS. This change makes the pre-2022 HP platforms meet the regression since they have two rfkill events (HPQ6001 and intel-hid) be triggered if pressing function key. Thus, there is a patch[3] to make sure the GNOME could deal with this case smoothly. However, the systemd change will still cause other DEs meet the regression (xfce, KDE, lxde, etc..). Backport systemd change to make HP 2022 platforms work is not the best choice on stable version (focal in this case). We still need a solution to make airplane key works on 2022 HP platforms (intel-hid and atkbd only). The potential solution from my mind that is to maintain a whitelist to unmask intel-hid in ubuntu-patch in focal, something like: ``` evdev:name:Intel HID events:dmi:bvn*:bvr*:bd*:svnHP*:pnHPZBookFury16inchG9*:* KEYBOARD_KEY_8=wlan # Use hp-wireless instead ``` after "KEYBOARD_KEY_8=unkown". [1] https://bugs.launchpad.net/bugs/1883846 [2] https://github.com/systemd/systemd/pull/20219 [3] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/f4dbcf3d7b0f951fe44b29229206c97b625dbfda To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955566] Re: iris driver doesn't load correctly
Hi Sponsors, Would you please help to review this minor patch? thanks! ** Changed in: oem-priority Status: In Progress => Triaged ** Summary changed: - iris driver doesn't load correctly + iris driver doesn't load correctly on intel pci_id 0x4688 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1955566 Title: iris driver doesn't load correctly on intel pci_id 0x4688 Status in OEM Priority Project: Triaged Status in mesa package in Ubuntu: New Bug description: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". * Patch backported from df5b14969f9869f363bcc8b2a564c85aaa481597 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955566] Re: iris driver doesn't load correctly
Impish and Jammy all have this patch. We don't need to bother them. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1955566 Title: iris driver doesn't load correctly on intel pci_id 0x4688 Status in OEM Priority Project: Triaged Status in mesa package in Ubuntu: New Bug description: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". * Patch backported from df5b14969f9869f363bcc8b2a564c85aaa481597 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955566] Re: iris driver doesn't load correctly
for focal ** Patch added: "mesa_21.0.3-0ubuntu0.3~20.04.6.debdiff" https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1955566/+attachment/5549109/+files/mesa_21.0.3-0ubuntu0.3~20.04.6.debdiff ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1955566 Title: iris driver doesn't load correctly on intel pci_id 0x4688 Status in OEM Priority Project: Triaged Status in mesa package in Ubuntu: New Bug description: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". * Patch backported from df5b14969f9869f363bcc8b2a564c85aaa481597 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955566] Re: iris driver doesn't load correctly
** Description changed: [Impact] - * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. - we expect the Intel GPU uses iris driver. + * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. + we expect the Intel GPU uses iris driver. [Test Plan] - * $ DISPLAY=:0 glxinfo | grep -i opengl + * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 - * After applying the fix, it shows: + * After applying the fix, it shows: - * $ DISPLAY=:0 glxinfo | grep -i opengl + * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] - * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. - * If there is any issue occur then we need to fix it with iris driver. + * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. + * If there is any issue occur then we need to fix it with iris driver. [Other Info] - - * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. - * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". + + * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. + * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". + * Patch backported from df5b14969f9869f363bcc8b2a564c85aaa481597 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1955566 Title: iris driver doesn't load correctly Status in OEM Priority Project: New Status in mesa package in Ubuntu: New Bug description: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". * Patch backported from df5b14969f9869f363bcc8b2a564c85aaa481597 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1955566] [NEW] iris driver doesn't load correctly
Public bug reported: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". ** Affects: oem-priority Importance: Undecided Status: New ** Affects: mesa (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1955371 stella ** Tags added: oem-priority originate-from-1955371 stella -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1955566 Title: iris driver doesn't load correctly Status in OEM Priority Project: New Status in mesa package in Ubuntu: New Bug description: [Impact] * iris driver doesn't load with pci_id 4688. Instead, it uses llvm. we expect the Intel GPU uses iris driver. [Test Plan] * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits) ... OpenGL version string: 3.1 Mesa 21.0.3 * After applying the fix, it shows: * $ DISPLAY=:0 glxinfo | grep -i opengl OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) Graphics (ADL-S GT1) ... OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.3 (git-d4975a0dbc) [Where problems could occur] * This patch is backport the PCI ID mapping for enabling iris driver which is expected when users have a GPU. * If there is any issue occur then we need to fix it with iris driver. [Other Info] * It already in upstream and we have a platform which using ADL-HX in OEM project. Thus, we need to enable iris on it at least on focal. * The patch is simple as to add "CHIPSET(0x4688, adl_gt1, "ADL-S GT1", "Intel(R) Graphics")" in "include/pci_ids/iris_pci_ids.h". To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1955566/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1952832] Re: internal speaker not list in sound setting when external audio device is conneceted
Update from https://bugs.launchpad.net/stella/+bug/1948777: 1) --- The Speaker in general doesn't have corresponding jack, so its availability is "unknown". When it's legacy HDA, once a Headphone is plugged, PulseAudio will disable all "unknown" profiles, so the speaker is gone in this case. When it's DMIC, the disablement of "unknown" profile is skipped because it's using UCM. 2) --- The headset jack plug may or may not have ability to determine jack type (i.e. what gets plugged in), and that creates two different behaviors: - When the hardware can determine jack types like most HP and Lenovo hardwares, libgnome-volume-control checks PA status and switches to corresponding device - When the hardware _cannot_ determine jack types like most Dell hardwares, libgnome-volume-control leaves all possible option available. For instance, when something gets plugged in, the system doesn't know it's headphone, mic, or a headset, so it has to leave all options to the user and user is responsible to choose the right device. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1952832 Title: internal speaker not list in sound setting when external audio device is conneceted Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: New Bug description: [Summary] internal speaker not list in sound setting when external device is connected [Steps to reproduce] 1) check sound setting, internal speak is listed in sound setting --> output device 2) plug a headset in 3.5mm headphone jack (front port) 3) check sound setting 4) plug headset in line-out port 5) check sound setting [Expected result] internal speaker should list when external audio device is connected. [Actual result] plug a headset in 3.5mm headphone jack (front port) --> headphone and HDMI/DP audio are listed, no internal speaker plug a headset in line-out port --> Line-out and HDMI/DP audio are listed, no internal speaker plug a headset in 3.5mm headphone jack (front port) and a headset in line-out port --> headphone, Line-out and HDMI/DP audio are listed, no internal speaker --- $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ apt-cache policy pulseaudio pulseaudio: Installed: 1:13.99.1-1ubuntu3.12 Candidate: 1:13.99.1-1ubuntu3.12 Version table: *** 1:13.99.1-1ubuntu3.12 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:13.99.1-1ubuntu3.8 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 1:13.99.1-1ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1952832/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1952832] [NEW] internal speaker not list in sound setting when external audio device is conneceted
Public bug reported: [Summary] internal speaker not list in sound setting when external device is connected [Steps to reproduce] 1) check sound setting, internal speak is listed in sound setting --> output device 2) plug a headset in 3.5mm headphone jack (front port) 3) check sound setting 4) plug headset in line-out port 5) check sound setting [Expected result] internal speaker should list when external audio device is connected. [Actual result] plug a headset in 3.5mm headphone jack (front port) --> headphone and HDMI/DP audio are listed, no internal speaker plug a headset in line-out port --> Line-out and HDMI/DP audio are listed, no internal speaker plug a headset in 3.5mm headphone jack (front port) and a headset in line-out port --> headphone, Line-out and HDMI/DP audio are listed, no internal speaker --- $ lsb_release -rd Description:Ubuntu 20.04.3 LTS Release:20.04 $ apt-cache policy pulseaudio pulseaudio: Installed: 1:13.99.1-1ubuntu3.12 Candidate: 1:13.99.1-1ubuntu3.12 Version table: *** 1:13.99.1-1ubuntu3.12 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:13.99.1-1ubuntu3.8 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 1:13.99.1-1ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages ** Affects: oem-priority Importance: Undecided Status: New ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1948777 originate-from-1950565 stella ** Tags added: oem-priority originate-from-1950565 stella ** Tags added: originate-from-1948777 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1952832 Title: internal speaker not list in sound setting when external audio device is conneceted Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: New Bug description: [Summary] internal speaker not list in sound setting when external device is connected [Steps to reproduce] 1) check sound setting, internal speak is listed in sound setting --> output device 2) plug a headset in 3.5mm headphone jack (front port) 3) check sound setting 4) plug headset in line-out port 5) check sound setting [Expected result] internal speaker should list when external audio device is connected. [Actual result] plug a headset in 3.5mm headphone jack (front port) --> headphone and HDMI/DP audio are listed, no internal speaker plug a headset in line-out port --> Line-out and HDMI/DP audio are listed, no internal speaker plug a headset in 3.5mm headphone jack (front port) and a headset in line-out port --> headphone, Line-out and HDMI/DP audio are listed, no internal speaker --- $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ apt-cache policy pulseaudio pulseaudio: Installed: 1:13.99.1-1ubuntu3.12 Candidate: 1:13.99.1-1ubuntu3.12 Version table: *** 1:13.99.1-1ubuntu3.12 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:13.99.1-1ubuntu3.8 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 1:13.99.1-1ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1952832/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1945418] Re: Hibernate doesn't support as the default action in Ubuntu when critical power
@seb128, got it, I created this one for discussion. https://gitlab.freedesktop.org/upower/upower/-/issues/156 ** Bug watch added: gitlab.freedesktop.org/upower/upower/-/issues #156 https://gitlab.freedesktop.org/upower/upower/-/issues/156 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/1945418 Title: Hibernate doesn't support as the default action in Ubuntu when critical power Status in OEM Priority Project: Confirmed Status in gnome-settings-daemon package in Ubuntu: New Status in upower package in Ubuntu: New Bug description: In a stock ubuntu 20.04.3, g-s-d will notify the critical action when battery is lower than warned critical threshold. The notification is "The battery is below the critical level and this computer is about to hibernate." When hitting critical threshold, it takes "HybirdSleep" as the action. ``` 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd[1]: Reached target Sleep. 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd[1]: Starting Hybrid Suspend+Hibernate... 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC kernel: PM: Image not found (code -22) 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd-sleep[3212]: Suspending system... 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC kernel: PM: hibernation: hibernation entry ``` You could see the hibernation called by logind but it will fail to restore since either not enough SWAP or resume address is not specify to kernel. It confusing users about the critical actions. In UPower.conf: ``` $ tail etc/UPower.conf # reached for the batteries (UPS or laptop batteries) supplying the computer # # Possible values are: # PowerOff # Hibernate # HybridSleep # # If HybridSleep isn't available, Hibernate will be used # If Hibernate isn't available, PowerOff will be used CriticalPowerAction=HybridSleep ``` In g-s-d: ``` /* We don't make the difference between HybridSleep and Hibernate */ if (g_strcmp0 (action, "PowerOff") == 0) policy = GSD_POWER_ACTION_SHUTDOWN; else policy = GSD_POWER_ACTION_HIBERNATE; ... /* use different text for different actions */ if (policy == GSD_POWER_ACTION_HIBERNATE) { /* TRANSLATORS: computer will hibernate */ message = g_strdup (_("The battery is below the critical level and " "this computer is about to hibernate.")); ``` There are two approach if possible: 1) change "CriticalPowerAction" to "PowerOff" because the suspend to ram is almost useless when battery is in critical threshold and the suspend to disk is usually not working in default installed ubuntu. 2) have a new "GsdPowerActionType" type for "HybridSleep" to show the appropriate message but taking the same action (notify logind). --- $ dpkg -l | grep -i 'upower\|gnome-settings-daemon' ii gir1.2-upowerglib-1.0:amd640.99.11-1build2 amd64GObject introspection data for upower ii gnome-settings-daemon 3.36.1-0ubuntu1.1 amd64daemon handling the GNOME session settings ii gnome-settings-daemon-common 3.36.1-0ubuntu1.1 all daemon handling the GNOME session settings - common files ii libupower-glib3:amd64 0.99.11-1build2 amd64abstraction for power management - shared library ii upower 0.99.11-1build2 amd64abstraction for power managemen To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1945418/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1945418] [NEW] Hibernate doesn't support as the default action in Ubuntu when critical power
Public bug reported: In a stock ubuntu 20.04.3, g-s-d will notify the critical action when battery is lower than warned critical threshold. The notification is "The battery is below the critical level and this computer is about to hibernate." When hitting critical threshold, it takes "HybirdSleep" as the action. ``` 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd[1]: Reached target Sleep. 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd[1]: Starting Hybrid Suspend+Hibernate... 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC kernel: PM: Image not found (code -22) 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC systemd-sleep[3212]: Suspending system... 九 29 11:24:48 ubuntu-HP-ZBook-Studio-15-6-Inch-G8-Mobile-Workstation-PC kernel: PM: hibernation: hibernation entry ``` You could see the hibernation called by logind but it will fail to restore since either not enough SWAP or resume address is not specify to kernel. It confusing users about the critical actions. In UPower.conf: ``` $ tail etc/UPower.conf # reached for the batteries (UPS or laptop batteries) supplying the computer # # Possible values are: # PowerOff # Hibernate # HybridSleep # # If HybridSleep isn't available, Hibernate will be used # If Hibernate isn't available, PowerOff will be used CriticalPowerAction=HybridSleep ``` In g-s-d: ``` /* We don't make the difference between HybridSleep and Hibernate */ if (g_strcmp0 (action, "PowerOff") == 0) policy = GSD_POWER_ACTION_SHUTDOWN; else policy = GSD_POWER_ACTION_HIBERNATE; ... /* use different text for different actions */ if (policy == GSD_POWER_ACTION_HIBERNATE) { /* TRANSLATORS: computer will hibernate */ message = g_strdup (_("The battery is below the critical level and " "this computer is about to hibernate.")); ``` There are two approach if possible: 1) change "CriticalPowerAction" to "PowerOff" because the suspend to ram is almost useless when battery is in critical threshold and the suspend to disk is usually not working in default installed ubuntu. 2) have a new "GsdPowerActionType" type for "HybridSleep" to show the appropriate message but taking the same action (notify logind). --- $ dpkg -l | grep -i 'upower\|gnome-settings-daemon' ii gir1.2-upowerglib-1.0:amd640.99.11-1build2 amd64GObject introspection data for upower ii gnome-settings-daemon 3.36.1-0ubuntu1.1 amd64daemon handling the GNOME session settings ii gnome-settings-daemon-common 3.36.1-0ubuntu1.1 all daemon handling the GNOME session settings - common files ii libupower-glib3:amd64 0.99.11-1build2 amd64abstraction for power management - shared library ii upower 0.99.11-1build2 amd64abstraction for power managemen ** Affects: oem-priority Importance: High Assignee: jeremyszu (os369510) Status: Confirmed ** Affects: gnome-settings-daemon (Ubuntu) Importance: Undecided Status: New ** Affects: upower (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1911231 originate-from-1943959 stella ** Also affects: gnome-settings-daemon (Ubuntu) Importance: Undecided Status: New ** Tags added: oem-priority originate-from-1943959 stella ** Tags added: originate-from-1911231 ** Summary changed: - Hibernate is not the default action in Ubuntu when critical power + Hibernate doesn't support as the default action in Ubuntu when critical power ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => High ** Changed in: oem-priority Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/1945418 Title: Hibernate doesn't support as the default action in Ubuntu when critical power Status in OEM Priority Project: Confirmed Status in gnome-settings-daemon package in Ubuntu: New Status in upower package in Ubuntu: New Bug description: In a stock ubuntu 20.04.3, g-s-d will notify the critical
[Touch-packages] [Bug 1942208] Re: The nvidia-dkms will be installed when installing nvidia driver through "Additional Drivers"
If I installed nvidia driver during the installation by selecting "Third-Party packages". It will use pre-signed driver instead. Please consider to use `ubuntu-drivers install` which will handle the corresponding actions. (e.g. prime-select, enabling RTD3) ** Tags added: oem-priority ** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => High ** Changed in: oem-priority Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1942208 Title: The nvidia-dkms will be installed when installing nvidia driver through "Additional Drivers" Status in OEM Priority Project: Confirmed Status in software-properties package in Ubuntu: New Bug description: [steps to reproduce] 1. Install Stock ubuntu 20.04.3 on XPS 15 9510 2. Installing without using "Third-party packages" 3. After installation completed, launch "Software & Updates" -> "Additional Drivers" -> "Using NVIDIA driver 470" 4. dpkg -l | grep nvidia [Expected result] It should use pre-signed nvidia driver instead of dkms e.g. linux-modules-nvidia-470-5.11.0-27-generic linux-modules-nvidia-470-generic-hwe-20.04 linux-objects-nvidia-470-5.11.0-27-generic linux-signatures-nvidia-5.11.0-27-generic [Actual result] ii nvidia-dkms-470 470.57.02-0ubuntu0.20.04.1 amd64 NVIDIA DKMS package --- $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ apt-cache policy software-properties-* software-properties-gtk: Installed: 0.98.9.5 Candidate: 0.98.9.5 Version table: *** 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/main i386 Packages software-properties-kde: Installed: (none) Candidate: (none) Version table: software-properties-qt: Installed: (none) Candidate: 0.98.9.5 Version table: 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/universe i386 Packages 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/universe i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/universe amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/universe i386 Packages software-properties-common: Installed: 0.98.9.5 Candidate: 0.98.9.5 Version table: *** 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/main i386 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1942208/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1942208] [NEW] The nvidia-dkms will be installed when installing nvidia driver through "Additional Drivers"
Public bug reported: [steps to reproduce] 1. Install Stock ubuntu 20.04.3 on XPS 15 9510 2. Installing without using "Third-party packages" 3. After installation completed, launch "Software & Updates" -> "Additional Drivers" -> "Using NVIDIA driver 470" 4. dpkg -l | grep nvidia [Expected result] It should use pre-signed nvidia driver instead of dkms e.g. linux-modules-nvidia-470-5.11.0-27-generic linux-modules-nvidia-470-generic-hwe-20.04 linux-objects-nvidia-470-5.11.0-27-generic linux-signatures-nvidia-5.11.0-27-generic [Actual result] ii nvidia-dkms-470 470.57.02-0ubuntu0.20.04.1 amd64 NVIDIA DKMS package --- $ lsb_release -rd Description:Ubuntu 20.04.3 LTS Release:20.04 $ apt-cache policy software-properties-* software-properties-gtk: Installed: 0.98.9.5 Candidate: 0.98.9.5 Version table: *** 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/main i386 Packages software-properties-kde: Installed: (none) Candidate: (none) Version table: software-properties-qt: Installed: (none) Candidate: 0.98.9.5 Version table: 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/universe i386 Packages 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/universe i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/universe amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/universe i386 Packages software-properties-common: Installed: 0.98.9.5 Candidate: 0.98.9.5 Version table: *** 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/main i386 Packages ** Affects: oem-priority Importance: Undecided Assignee: jeremyszu (os369510) Status: New ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1942208 Title: The nvidia-dkms will be installed when installing nvidia driver through "Additional Drivers" Status in OEM Priority Project: New Status in software-properties package in Ubuntu: New Bug description: [steps to reproduce] 1. Install Stock ubuntu 20.04.3 on XPS 15 9510 2. Installing without using "Third-party packages" 3. After installation completed, launch "Software & Updates" -> "Additional Drivers" -> "Using NVIDIA driver 470" 4. dpkg -l | grep nvidia [Expected result] It should use pre-signed nvidia driver instead of dkms e.g. linux-modules-nvidia-470-5.11.0-27-generic linux-modules-nvidia-470-generic-hwe-20.04 linux-objects-nvidia-470-5.11.0-27-generic linux-signatures-nvidia-5.11.0-27-generic [Actual result] ii nvidia-dkms-470 470.57.02-0ubuntu0.20.04.1 amd64 NVIDIA DKMS package --- $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ apt-cache policy software-properties-* software-properties-gtk: Installed: 0.98.9.5 Candidate: 0.98.9.5 Version table: *** 0.98.9.5 500 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages 100 /var/lib/dpkg/status 0.98.9.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages 0.98.9 500 500 http://tw.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://tw.archive.ubuntu.com/ubuntu focal/main i386 Packages software-properties-kde: Installed: (none) Candidate:
[Touch-packages] [Bug 1918855] Re: Xorg crashed with SIGABRT when under memory pressure
** Changed in: oem-priority Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg crashed with SIGABRT when under memory pressure Status in OEM Priority Project: Fix Released Status in mesa package in Ubuntu: Fix Released Status in mesa source package in Focal: Fix Released Status in mesa source package in Hirsute: Fix Released Bug description: == SRU Justification == [Impact] When the system is under memory pressure, the entire desktop session may crash. [Fix] Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if kernel can't allocate memory") [Test] Run memory stress and the session crashed in less than 5 minutes. With the fix applied, run memory stress for 24 hours and the desktop session is still alive. [Where problems could occur] Doing a reset might make the system even more sluggish when under memory pressure. == Original bug report == I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5619f38f0995] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg (WaitForSomething+0x122) [0x5619f3a46c12] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x5619f38ebcf7] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5619f38effc4] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fae476850b3] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x5619f38d9a2e] More info: I searched the Internet and got a bug with the same stacktrace: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468 https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1918855/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1932352] Re: Fix micmute hotkeys on HP Elite Dragonfly
** Changed in: oem-priority Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1932352 Title: Fix micmute hotkeys on HP Elite Dragonfly Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] Mic mute key is no function on HP Elite Dragonfly. [Fix] After confirming with HP, there are two model names for Dragonfly: * HP Elite Dragonfly G2 Notebook PC * HP Elite Dragonfly Max Notebook PC Thus, the commit Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic mute key. [Test] After patching it, the mic mute key could functioned well on my Dragonfly laptop. [Where problems could occur] There is not old rule for Dragonfly dmi string in current hwdb. Which means the Dragonfly is using default HP key map: ``` evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:* KEYBOARD_KEY_81=fn_esc ``` This patch will change the HP machine (if product name contains pnHPEliteDragonfly*) to map 81 to mic mute key. If a machine (pnHPEliteDragonfly*) works good in the past then this patch may cause it's mic mute key become malfunction. However, this rule is confirmed/provided from HP. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1932352/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] Re: The image is distorted while use iGPU rendering and output via AMD GPU
** Summary changed: - The image is distrorted while use iGPU rendering and output via AMD GPU + The image is distorted while use iGPU rendering and output via AMD GPU -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in OEM Priority Project focal series: New Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] Re: The image is distrorted while use iGPU rendering and output via AMD GPU
@Shengyao, I meant the -dri1. I think the -dri2 is backported from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11877#. Let's discuss it on upstream thread. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distrorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] Re: The image is distrorted while use iGPU rendering and output via AMD GPU
I did submit a discussion to discuss about "Launch using Dedicated Graphic Card" design. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4509 ** Bug watch added: gitlab.gnome.org/GNOME/gnome-shell/-/issues #4509 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4509 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distrorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] Re: The image is distrorted while use iGPU rendering and output via AMD GPU
@Shengyao, We still can reproduce this issue by following: 1. boot from dGPU (AMD) 2. DRI_PRIME=1 gxlgear 3. resize the window slowly. ** Tags added: fossa-edge-staging -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distrorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] Re: The image is distrorted while use iGPU rendering and output via AMD GPU
@Shengyao, Thanks, would you please share the ppa you tested here that we could give it a try? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distrorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937988] [NEW] The image is distrorted while use iGPU rendering and output via AMD GPU
Public bug reported: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 ** Affects: oem-priority Importance: Critical Assignee: Shengyao Xue (xueshengyao) Status: In Progress ** Affects: mesa (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1904984 originate-from-1917700 originate-from-1931050 somerville sutton ** Tags added: oem-priority originate-from-1931050 sutton ** Tags added: originate-from-1917700 ** Tags added: originate-from-1904984 somerville ** Changed in: oem-priority Assignee: (unassigned) => Shengyao Xue (xueshengyao) ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1937988 Title: The image is distrorted while use iGPU rendering and output via AMD GPU Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: [Steps to reproduce] 1. Connect a monitor on the AMD GPU. 2. Power on the system and boot into OS. 3. Run below command to launch glxgear Cmd> DRI_PRIME=1 glxgears -info [Expected result] The image is not distrorted while running the glxgears [Actual result] The image is distrorted while running the glxgears --- Here is the upstream bug for tracking this issue. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11942?commit_id=505f815e5ead8c9872bbda4c1ff3aeaee7223d64 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1937988/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg xserver got signal 6 to abort
** Changed in: oem-priority Status: In Progress => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg xserver got signal 6 to abort Status in OEM Priority Project: Triaged Status in mesa package in Ubuntu: Fix Released Status in mesa source package in Focal: New Status in mesa source package in Hirsute: Fix Committed Bug description: == SRU Justification == [Impact] When the system is under memory pressure, the entire desktop session may crash. [Fix] Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if kernel can't allocate memory") [Test] Run memory stress and the session crashed in less than 5 minutes. With the fix applied, run memory stress for 24 hours and the desktop session is still alive. [Where problems could occur] Doing a reset might make the system even more sluggish when under memory pressure. == Original bug report == I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5619f38f0995] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg (WaitForSomething+0x122) [0x5619f3a46c12] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x5619f38ebcf7] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5619f38effc4] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fae476850b3] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x5619f38d9a2e] More info: I searched the Internet and got a bug with the same stacktrace: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468 https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1918855/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1932352] [NEW] Fix micmute hotkeys on HP Elite Dragonfly
Public bug reported: [Impact] Mic mute key is no function on HP Elite Dragonfly. [Fix] After confirming with HP, there are two model names for Dragonfly: * HP Elite Dragonfly G2 Notebook PC * HP Elite Dragonfly Max Notebook PC Thus, the commit Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic mute key. [Test] After patching it, the mic mute key could functioned well on my Dragonfly laptop. [Where problems could occur] There is not old rule for Dragonfly dmi string in current hwdb. Which means the Dragonfly is using default HP key map: ``` evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:* KEYBOARD_KEY_81=fn_esc ``` This patch will change the HP machine (if product name contains pnHPEliteDragonfly*) to map 81 to mic mute key. If a machine (pnHPEliteDragonfly*) works good in the past then this patch may cause it's mic mute key become malfunction. However, this rule is confirmed/provided from HP. ** Affects: oem-priority Importance: Critical Assignee: jeremyszu (os369510) Status: Triaged ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1930709 stella ** Tags added: oem-priority originate-from-1930709 stella ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => Critical ** Changed in: oem-priority Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1932352 Title: Fix micmute hotkeys on HP Elite Dragonfly Status in OEM Priority Project: Triaged Status in systemd package in Ubuntu: New Bug description: [Impact] Mic mute key is no function on HP Elite Dragonfly. [Fix] After confirming with HP, there are two model names for Dragonfly: * HP Elite Dragonfly G2 Notebook PC * HP Elite Dragonfly Max Notebook PC Thus, the commit Commit c1b8c966eccb7be1cae0a30670f5e1fcd88b47fa maps the 81 scan code to mic mute key. [Test] After patching it, the mic mute key could functioned well on my Dragonfly laptop. [Where problems could occur] There is not old rule for Dragonfly dmi string in current hwdb. Which means the Dragonfly is using default HP key map: ``` evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:* KEYBOARD_KEY_81=fn_esc ``` This patch will change the HP machine (if product name contains pnHPEliteDragonfly*) to map 81 to mic mute key. If a machine (pnHPEliteDragonfly*) works good in the past then this patch may cause it's mic mute key become malfunction. However, this rule is confirmed/provided from HP. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1932352/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg xserver got signal 6 to abort
** Tags added: originate-from-1932285 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg xserver got signal 6 to abort Status in Mesa: Unknown Status in OEM Priority Project: In Progress Status in Provider for Plainbox - Checkbox: New Status in mesa package in Ubuntu: New Bug description: == SRU Justification == [Impact] When the system is under memory pressure, the entire desktop session may crash. [Fix] Commit f9d8d9acbb6a620684fb4dac4affe25816587d92 ("iris: Avoid abort() if kernel can't allocate memory") [Test] Run memory stress and the session crashed in less than 5 minutes. With the fix applied, run memory stress for 24 hours and the desktop session is still alive. [Where problems could occur] Doing a reset might make the system even more sluggish when under memory pressure. == Original bug report == I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5619f38f0995] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg (WaitForSomething+0x122) [0x5619f3a46c12] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x5619f38ebcf7] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5619f38effc4] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fae476850b3] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x5619f38d9a2e] More info: I searched the Internet and got a bug with the same stacktrace: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468 https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859 To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1918855/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg xserver got signal 6 to abort
@Timo, I guess you could get passed if adding "--oomable" ** Also affects: plainbox-provider-checkbox Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg xserver got signal 6 to abort Status in Mesa: Unknown Status in OEM Priority Project: In Progress Status in Provider for Plainbox - Checkbox: New Status in mesa package in Ubuntu: New Bug description: I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5619f38f0995] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg (WaitForSomething+0x122) [0x5619f3a46c12] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x5619f38ebcf7] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5619f38effc4] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fae476850b3] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x5619f38d9a2e] More info: I searched the Internet and got a bug with the same stacktrace: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468 https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859 To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1918855/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1918855] Re: Xorg xserver got signal 6 to abort
``` Mar 3 18:07:02 kernel: [ 4935.420223] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 18:07:16 kernel: [ 4949.440656] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 18:08:11 kernel: [ 5004.462545] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 18:09:14 kernel: [ 5066.643244] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 18:09:34 kernel: [ 5087.214632] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:40:26 kernel: [10538.987863] gnome-terminal- invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:40:28 kernel: [10541.043501] gnome-terminal- invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:40:45 kernel: [10558.082088] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:40:49 kernel: [10562.058290] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:41:14 kernel: [10586.699020] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:41:35 kernel: [10608.175575] gnome-shell invoked oom-killer: gfp_mask=0x0(), order=0, oom_score_adj=0 Mar 3 19:41:55 kernel: [10627.942562] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:41:55 kernel: [10628.294303] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:42:12 kernel: [10645.292252] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:42:43 kernel: [10675.670335] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:43:06 gnome-shell[1691]: GNOME Shell crashed with signal 6 Mar 3 19:43:15 kernel: [10708.155220] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:43:31 kernel: [10724.420148] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:43:32 kernel: [10725.336522] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:43:36 kernel: [10729.101114] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:43:44 kernel: [10737.358855] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:44:09 kernel: [10761.733283] gnome-shell invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:44:31 kernel: [10783.687545] pool-gnome-shel invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 Mar 3 19:45:23 /usr/lib/gdm3/gdm-x-session[1425]: (EE) Caught signal 6 (Aborted). Server aborting ``` Does not make sense to me, I don't think it's DM/WM issue but tool issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg xserver got signal 6 to abort Status in Mesa: Unknown Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/dri
[Touch-packages] [Bug 1918855] Re: Xorg xserver got signal 6 to abort
** Tags added: originate-from-1929152 stella -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1918855 Title: Xorg xserver got signal 6 to abort Status in Mesa: Unknown Status in OEM Priority Project: In Progress Status in mesa package in Ubuntu: New Bug description: I run checkbox job com.canonical.certification::memory/memory_stress_ng on focal, and the xserver stops unexpectedly with the following stacktrace: /usr/lib/gdm3/gdm-x-session[1425]: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x5619f3a4d59c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7fae4786741f] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0xcb) [0x7fae476a418b] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x12b) [0x7fae47683859] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 4: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (?+0x0) [0x7fae457d7aec] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 5: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (nouveau_drm_screen_create+0x25c8ec) [0x7fae46529c9c] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 6: /usr/lib/x86_64-linux-gnu/dri/iris_dri.so (__driDriverGetExtensions_zink+0x2561d) [0x7fae4582c74d] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x150) [0x7fae47007480] /usr/lib/gdm3/gdm-x-session[1425]: (EE) unw_get_proc_name failed: no unwind info found [-10] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7fae47040a30] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 9: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5619f38f0995] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 10: /usr/lib/xorg/Xorg (WaitForSomething+0x122) [0x5619f3a46c12] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 11: /usr/lib/xorg/Xorg (SendErrorToClient+0x117) [0x5619f38ebcf7] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 12: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5619f38effc4] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7fae476850b3] /usr/lib/gdm3/gdm-x-session[1425]: (EE) 14: /usr/lib/xorg/Xorg (_start+0x2e) [0x5619f38d9a2e] More info: I searched the Internet and got a bug with the same stacktrace: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3468 https://gitlab.freedesktop.org/mesa/mesa/-/issues/2859 To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1918855/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
Hi Daniel, SRU template filled, thanks! ** Description changed: [Impact] + In Lenovo P520, which using a codec for front panel, the other codec for rear panel and both are on a same card. + + In this case, the rear Mic will present on input devices of "Sound + Settings" even if attaching nothing to rear mic jack. [Fix] + For alsa-ucm-conf part, the Mic 2 should use "Rear Mic Jack" as JackControl because of + ``` + control.18 { + iface CARD + name 'Rear Mic Jack' + value true + comment { + access read + type BOOLEAN + count 1 + } + } + ``` + After applying "Rear Mic Jack", the rear Mic will not always there anymore but it's not there as well if hot-plugging audio device on rear mic. Thus, it needs to change pulseaudio to handle if all devices are off cases. + + For pulseaudio, if there is no any audio devices attached, then + attaching an input device on rear mic jack. The port will not be + selected automatically because the profiles is off. It needs patch + pulseaudio to check off profiles (for dual codec case). [Test] + After applying these patches, the rear mic jack works good in all cases (boot without mic and then attach mic, boot with mic and then hotplug it) and other functions (line-in / line-out) work pretty well. [Where problems could occur] + This change only apply the bonus on below cases: + ``` + if ((has_input_port && found_available_input_port && !has_output_port) || + (has_output_port && found_available_output_port && !has_input_port) || + (has_input_port && found_available_input_port && has_output_port && found_available_output_port)) + ``` + and these cases have been tested. + If there are some complex codec design then it might cause problem but so far we didn't see that. ** Changed in: oem-priority Status: In Progress => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: Triaged Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: Incomplete Status in alsa-ucm-conf source package in Focal: New Status in pulseaudio source package in Focal: New Status in alsa-ucm-conf source package in Groovy: New Status in pulseaudio source package in Groovy: New Status in alsa-ucm-conf source package in Hirsute: Fix Released Status in pulseaudio source package in Hirsute: New Bug description: [Impact] In Lenovo P520, which using a codec for front panel, the other codec for rear panel and both are on a same card. In this case, the rear Mic will present on input devices of "Sound Settings" even if attaching nothing to rear mic jack. [Fix] For alsa-ucm-conf part, the Mic 2 should use "Rear Mic Jack" as JackControl because of ``` control.18 { iface CARD name 'Rear Mic Jack' value true comment { access read type BOOLEAN count 1 } } ``` After applying "Rear Mic Jack", the rear Mic will not always there anymore but it's not there as well if hot-plugging audio device on rear mic. Thus, it needs to change pulseaudio to handle if all devices are off cases. For pulseaudio, if there is no any audio devices attached, then attaching an input device on rear mic jack. The port will not be selected automatically because the profiles is off. It needs patch pulseaudio to check off profiles (for dual codec case). [Test] After applying these patches, the rear mic jack works good in all cases (boot without mic and then attach mic, boot with mic and then hotplug it) and other functions (line-in / line-out) work pretty well. [Where problems could occur] This change only apply the bonus on below cases: ``` if ((has_input_port && found_available_input_port && !has_output_port) || (has_output_port && found_available_output_port && !has_input_port) || (has_input_port && found_available_input_port && has_output_port && found_available_output_port)) ``` and these cases have been tested. If there are some complex codec design then it might cause problem but so far we didn't see that. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For focal ** Patch added: "pulseaudio_13.99.1-1ubuntu3.11.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500253/+files/pulseaudio_13.99.1-1ubuntu3.11.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For groovy ** Patch added: "pulseaudio_13.99.2-1ubuntu2.4.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500217/+files/pulseaudio_13.99.2-1ubuntu2.4.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For hirsute ** Patch added: "pulseaudio_14.2-1ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500206/+files/pulseaudio_14.2-1ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For impish ** Patch added: "pulseaudio_14.2-2ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500205/+files/pulseaudio_14.2-2ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
alsa-ucm-conf/h/i already contains this patch https://github.com/alsa- project/alsa-ucm-conf/commit/368f10bdc3dbfd4f83ab348b54b8455f08fd1a9e. Thus, skip. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For groovy ** Patch added: "alsa-ucm-conf_1.2.2-1ubuntu5.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500204/+files/alsa-ucm-conf_1.2.2-1ubuntu5.3.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
For focal ** Patch added: "alsa-ucm-conf_1.2.2-1ubuntu0.8.debdiff" https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1929371/+attachment/5500202/+files/alsa-ucm-conf_1.2.2-1ubuntu0.8.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] Re: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
** Also affects: alsa-ucm-conf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in alsa-ucm-conf package in Ubuntu: New Status in pulseaudio package in Ubuntu: Incomplete Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902464] Re: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time
@Seb, I'll work on these two patches comment#3 mentioned in the other bug. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1929371 Let's leave this ticket to track https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1902464 Title: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time Status in HWE Next: New Status in OEM Priority Project: Confirmed Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: New Bug description: After backporting following patches from PA and alsa-ucm-conf and then it works. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/354 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/USB- Audio [landed by aa74f4c12eefcc98582572d2fc48982cf7478b51] Here is the test PPA: https://launchpad.net/~os369510/+archive/ubuntu/oem-package-test Since the upstream not yet accepted those patches, the regression potential may quite high. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1902464/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929371] [NEW] [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged
Public bug reported: [Impact] [Fix] [Test] [Where problems could occur] ** Affects: oem-priority Importance: High Assignee: jeremyszu (os369510) Status: In Progress ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: oem-priority originate-from-1884497 sutton ** Summary changed: - there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged + [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged ** Tags added: oem-priority originate-from-1884497 sutton ** Changed in: oem-priority Assignee: (unassigned) => jeremyszu (os369510) ** Changed in: oem-priority Importance: Undecided => High ** Changed in: oem-priority Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1929371 Title: [SRU] there is always a "Rear Microphone - Built-in Audio" option on the input device list even if the microphone is unplugged Status in OEM Priority Project: In Progress Status in pulseaudio package in Ubuntu: New Bug description: [Impact] [Fix] [Test] [Where problems could occur] To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1929371/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902464] Re: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time
Although comment#2 is merged, this issue still needs PA corresponding (https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290). Therefore, we will deliver a special alsa-ucm-conf on our oem-archive as short-term solution and leave it be replaced after this ticket gets the merge. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1902464 Title: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time Status in HWE Next: New Status in OEM Priority Project: Confirmed Status in alsa-ucm-conf package in Ubuntu: Fix Released Status in pulseaudio package in Ubuntu: New Bug description: After backporting following patches from PA and alsa-ucm-conf and then it works. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/354 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355 https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/USB- Audio [landed by aa74f4c12eefcc98582572d2fc48982cf7478b51] Here is the test PPA: https://launchpad.net/~os369510/+archive/ubuntu/oem-package-test Since the upstream not yet accepted those patches, the regression potential may quite high. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1902464/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp