Work is in progress in Mutter here: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5247 ** Changed in: mutter (Ubuntu) Status: Opinion => In Progress ** Changed in: mutter (Ubuntu) Milestone: None => later -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2101816 Title: [amdgpu] Crash with SIGABRT in amdgpu_ctx_set_sw_reset_status() from amdgpu_cs_submit_ib() from util_queue_thread_func() from impl_thrd_routine() from start_thread() Status in Mesa: New Status in Mutter: New Status in linux package in Ubuntu: Confirmed Status in linux-oem-6.17 package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Status in mutter package in Ubuntu: In Progress Status in xorg-server package in Ubuntu: Opinion Status in xwayland package in Ubuntu: Opinion Status in gnome-shell package in Fedora: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 48~beta-3ubuntu1, the problem page at https://errors.ubuntu.com/problem/fb85627cf28fc2fa707952f5c3c1a887e8f2b5fb contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/2101816/+subscriptions
[РЕШЕНО] Ошибка № ...
Ошибки в Программах и Способы их Исправления
воскресенье
[Bug 2163214] Re: WWAN modem unresponsive after freeze on Dell systems with DW5826e
** Changed in: linux-oem-7.0 (Ubuntu Resolute) Status: In Progress => Fix Committed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2163214 Title: WWAN modem unresponsive after freeze on Dell systems with DW5826e Status in HWE Next: New Status in linux package in Ubuntu: Invalid Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Invalid Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux-oem-7.0 source package in Resolute: Fix Committed Bug description: [Impact] On Dell systems with a DW5826e WWAN module, the modem can enter a frozen state where it no longer responds to USB commands. The system has no way to reset just the modem, so the user must reboot the whole machine to recover it. There is no kernel error log from this failure because the modem simply stops answering on USB; the symptom is a dead wwan0 interface that does not come back after toggling the modem. [Fix] Add a reset driver for the DW5826e that exposes a sysfs file, wwan_reset, under the PALC0001 platform device. Writing to it triggers an ACPI Platform Level Device Reset (PLDR) of the modem via _DSM, recovering a frozen module without a reboot: echo 1 > /sys/bus/platform/devices/PALC0001\:00/wwan_reset Include the follow-up fix so the reset actually reaches the right ACPI function: the original driver passed a bitmask to acpi_evaluate_dsm(), which needs a 0-based function index, so it evaluated Function 2 instead of Function 1. Both are upstream. Patches: - Add reset driver, upstream in v7.2-rc1: https://lore.kernel.org/all/20260526-dell-reset-v8-v8-1-d3a29cb4cf2f@compal.com/ 1ab843135a77 platform/x86: dell-dw5826e: Add reset driver for DW5826e - Fix _DSM function index and bitmask usage, upstream in v7.2-rc6: https://patch.msgid.link/20260724125533.74751-1-kr494167@gmail.com 39490ec6063d platform/x86: dell-dw5826e: fix ACPI _DSM function index and bitmask usage [Test Plan] Freeze the DW5826e modem (or reproduce with a modem stuck after a failed power cycle), then reset it: $ echo 1 > /sys/bus/platform/devices/PALC0001\:00/wwan_reset Without the driver: no wwan_reset file exists and there is no way to reset the modem short of rebooting. With the driver (and the _DSM fix): writing 1 to wwan_reset returns success and the modem re-enumerates and responds to USB commands again. [Where problems could occur] Could affect the WWAN/USB stack on Dell systems with this modem. If the _DSM function index were still wrong, the reset would hit the wrong function and the modem would not recover, or the reset could misbehave. If the driver probes on a system where the modem is healthy, writing wwan_reset resets an in-use modem and briefly drops its wwan0 interface, which would interrupt an active data connection. The driver only binds to the PALC0001 ACPI ID and checks _DSM support before activating, so non-Dell or unsupported systems are unaffected. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2163214/+subscriptions
[Bug 2164504] Re: Speakers not detected on HP systems with TI TAS2783 SoundWire amps
** Changed in: linux-oem-7.0 (Ubuntu Resolute) Status: In Progress => Fix Committed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2164504 Title: Speakers not detected on HP systems with TI TAS2783 SoundWire amps Status in HWE Next: New Status in linux package in Ubuntu: Invalid Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: Invalid Status in linux-oem-6.17 source package in Noble: Fix Committed Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux-oem-7.0 source package in Resolute: Fix Committed Bug description: [Impact] Speakers do not show up on HP systems (CID: 202512-38250) with four TAS2783 SoundWire speaker amplifiers. The audio detect_sources test fails. Error log from the test: media.class:[Audio/Source] couldn't find The machine driver's card->components string never includes "spk:tas2783" because the TAS2783 entry in sdw_utils is missing .component_name. WirePlumber/PipeWire cannot match the speaker codec, so only a Dummy Output is shown and no Speaker sink or audio source is exposed. Happens with updated BIOS that already fixes the SDCA function type. [Fix] Add the missing component_name string to the TAS2783 entry in codec_info_list in sound/soc/sdw_utils/soc_sdw_utils.c: .component_name = "tas2783", With this, card->components includes "spk:tas2783" so WirePlumber/UCM can match the codec and build the Speaker device. Upstream commit: 79bec46381942 ASoC: sdw_utils: Add missed component_name strings for TI amps Merged in Linus' tree and linux-next for v7.1 (no released tag yet). Patch: https://patch.msgid.link/20260611125359.19839-1-baojun.xu@ti.com This is one of three pieces of the full fix. The BIOS update adds the missing mipi-sdca-control-dc-value for SDCA function type. This kernel patch exposes the codec name. A separate userspace patch (alsa-ucm- conf tas2783.conf, TI PR #812) provides the UCM profile. This SRU is for the kernel piece only. [Test Plan] On a HP system with 4x TAS2783 amps, BIOS Y90 99.15.23 or newer: 1. Check the speaker codec is matched: $ wpctl status Without patch: no Speaker device, only Dummy Output. With patch: a Speaker sink appears under Audio. 2. Run the failing test: $ sudo checkbox-cli run com.canonical.certification::audio/detect_sources Without patch: fails with "media.class:[Audio/Source] couldn't find". With patch: passes. Note: full speaker playback also needs the tas2783.conf UCM profile installed. [Where problems could occur] Could break ASoC SoundWire machine setup. The change only adds a string to one codec entry, so the risk is small. If the component_name does not match the UCM profile name, the Speaker still will not be created and the test keeps failing (no worse than today). If the component matching picks up the codec with a wrong UCM profile, there could be no speaker output or wrong default audio routing after boot. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2164504/+subscriptions
[Bug 2166622] Re: Yoga Slim 7 14AKP10: ~38 s s2idle resume stall, NVMe IO_PAGE_FAULT, fixed by iommu=pt
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166622 Title: Yoga Slim 7 14AKP10: ~38 s s2idle resume stall, NVMe IO_PAGE_FAULT, fixed by iommu=pt Status in linux package in Ubuntu: New Bug description: Yoga Slim 7 14AKP10 (Krackan Point): ~38.6 s s2idle resume stall ending in NVMe IO_PAGE_FAULT, fixed by iommu=pt System Lenovo Yoga Slim 7 14AKP10, AMD Ryzen AI 5 330 (Krackan Point), Radeon 820M, 16 GB NVMe: Micron 2400 MTFDKCD512TGW-1BP1AABLA, firmware 1002VALN (DRAM-less, uses HMB) Kubuntu 26.04.1 LTS, kernel 7.0.0-31-generic BIOS QTCN33WW (2026-04-24), Pluton disabled in BIOS; no newer firmware on LVFS /sys/power/mem_sleep = [s2idle] (no deep/S3 available) Symptom After s2idle suspend (lid or systemctl suspend), affected resumes take ~38 to 40 s before the login screen appears. The delay is almost constant (38.57 s / 38.61 s / 38.61 s over three cycles). Some resumes are immediate, so the issue is intermittent but easily reproducible. What was measured amd_pmc s0ix_stats: S0i3 entry succeeds, ~151 ms to resume from S0i3, so the SoC/SMU side is fine. pm_print_times: endpoint callbacks are fast (amdgpu ~185 ms, USB max ~266 ms, nvme pci_pm_resume 2 µs since it only schedules an async reset). In dmesg the stall sits between ACPI: EC: interrupt unblocked and the following line, which is logged exactly at the end of the ~38.6 s gap: nvme 0000:bf:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0x77e54000 flags=0x0000] immediately followed by amdgpu ... SMU is resuming, nvme nvme0: 8/0/0 default/read/poll queues and PM: suspend exit. The firmware also repeatedly logs, at suspend entry and/or exit: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OSFG], AE_NOT_FOUND ACPI Error: Aborting method \_SB.PEP._DSM due to previous error (AE_NOT_FOUND) so the LPS0 (Modern Standby) entry/exit notification to the platform aborts. Workaround (verified) Booting with iommu=pt completely removes the stall and the IO_PAGE_FAULT over repeated systemctl suspend cycles (20–30 s sleep). Nothing else was changed. The ACPI OSFG / PEP._DSM error is still logged with the workaround. Parameters deliberately not used: amd_iommu=off, nvme.noacpi=1, iommu=soft, pcie_aspm=off. Interpretation The IO_PAGE_FAULT is the marker of the end of the stall, not its cause: after leaving D3cold the NVMe controller issues DMA with a stale address, the IOMMU rejects it in the default translated mode, and the controller stays in a bad state until a ~38.6 s timeout expires, after which resume completes normally. With identity mapping (iommu=pt) the stale address stays valid and the device answers immediately. This looks like a platform + NVMe (Micron 2400 / HMB / D3cold) resume-ordering issue rather than a userspace, GPU or SMU delay. The aborted PEP._DSM may contribute to the intermittency (the EC may not be told the OS left standby); that part needs a DSDT review. Requests Kernel/AMD: consider a quirk for this platform/SSD combination (e.g. IOMMU passthrough by default for this DMI, or HMB/D3cold handling on resume) so it works out of the box. Lenovo: fix the firmware ACPI tables so that \_SB.PCI0.LPC0.EC0.OSFG, referenced by \_SB.PEP._DSM, exists. Reproduction Boot Kubuntu without iommu=pt; check /sys/power/mem_sleep shows [s2idle]. systemctl suspend, wait 20–30 s, wake. On an affected cycle, observe ~38 s before the login screen; in dmesg the gap is between ACPI: EC: interrupt unblocked and nvme ... AMD-Vi: Event logged [IO_PAGE_FAULT ...]. Reboot with iommu=pt, repeat 2–3: no stall, no fault. Full report (French, with logs and s0ix_stats) and amd-s2idle output attached ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Sep 6 21:18:48 2026 InstallationDate: Installed on 2026-09-06 (0 days ago) InstallationMedia: Kubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826.1) MachineType: LENOVO 83JY ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=764762f1-5e87-46be-869b-a6869d0d88f0 ro quiet splash iommu=pt PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/24/2026 dmi.bios.release: 1.33 dmi.bios.vendor: LENOVO dmi.bios.version: QTCN33WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76573 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 14AKP10 dmi.ec.firmware.release: 1.33 dmi.modalias: dmi:bvnLENOVO:bvrQTCN33WW:bd04/24/2026:br1.33:efr1.33:svnLENOVO:pn83JY:pvrYogaSlim714AKP10:rvnLENOVO:rnLNVNB161216:rvrSDK0T76573WIN:cvnLENOVO:ct10:cvrYogaSlim714AKP10:skuLENOVO_MT_83JY_BU_idea_FM_YogaSlim714AKP10:pfaYogaSlim714AKP10: dmi.product.family: Yoga Slim 7 14AKP10 dmi.product.name: 83JY dmi.product.sku: LENOVO_MT_83JY_BU_idea_FM_Yoga Slim 7 14AKP10 dmi.product.version: Yoga Slim 7 14AKP10 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166622/+subscriptions
[Bug 2141741] Re: 55-initrd.install silently exits 0 when initrd missing causing undetectable kernel panic on NVMe systems
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: grub2 (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2141741 Title: 55-initrd.install silently exits 0 when initrd missing causing undetectable kernel panic on NVMe systems Status in grub2 package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Bug description: ENVIRONMENT: - Ubuntu 24.04 Noble (HWE kernel) - systemd version: 255 (255.4-1ubuntu8.10) - Kernel: 6.17.0-14-generic - Storage: NVMe SSD - File: /usr/lib/kernel/install.d/55-initrd.install - Package owner: systemd (confirmed via dpkg -S) BUG: When initrd generation fails or is skipped during kernel installation, 55-initrd.install detects the missing initrd but exits 0 (success) instead of exit 1 (failure). Relevant code in 55-initrd.install (line 26): if [ -e "$INITRD_SRC" ]; then ln -fs "$INITRD_SRC" "$KERNEL_INSTALL_STAGING_AREA" else echo "$INITRD_SRC does not exist, not installing an initrd" fi exit 0 ← BUG IS HERE This silent success causes GRUB to write a boot entry for a kernel with no initrd, with zero warning to the user. HOW THIS CAUSES KERNEL PANIC: Ubuntu's kernel config has CONFIG_BLK_DEV_NVME=m meaning the NVMe storage driver exists ONLY as a module inside initramfs. Without initramfs: - NVMe driver never loads - Kernel cannot see any storage device - Results in: VFS: Unable to mount root fs on unknown-block(0,0) - KERNEL PANIC on every boot — silent, no warning given HOW I TRIGGERED THIS: virtualbox-dkms 7.0.16 (dfsg) fails to build for kernel 6.17 due to missing VBox/cdefs.h header. DKMS exits code 11. run-parts stops alphabetically — 'd' (dkms) runs before 'i' (initramfs-tools) — so initramfs is never generated. 55-initrd.install then silently exits 0 → GRUB creates unbootable boot entry → KERNEL PANIC on reboot. This failed silently 3 days in a row (Feb 11, 12, 13 2026) confirmed in /var/log/dpkg.log and /var/log/apt/term.log. PROPOSED FIX: Change line 26 of 55-initrd.install from: exit 0 to: exit 1 When initrd is missing, this should be a HARD FAILURE not a silent warning. This would cause apt to report the error visibly and prevent GRUB from creating an unbootable boot entry. RELATED BUG: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/2136499 (virtualbox-dkms FTBFS triggers this silent failure) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/2141741/+subscriptions
[Bug 2142384] Re: ELAN2514:00 (04F3:4428) stylus report rate extremely low (~10–25 Hz) on Ubuntu 24.04 kernel 6.17
@mrmoe12 I let the people in the thread (https://bugzilla.kernel.org/show_bug.cgi?id=220854) know. One of them -- username is BitSlice -- tried your fix. He only needed to had his pen model to the source code and per his reply, it seems to be working fine. He has forked your Github project: https://github.com/BitSlice32/hp-elan2514-pen-fix-cachy-k7.2 Thanks for solving this one. My HP Omnibook works perfectly fine, only the pen is causing issues. Haven't tried your fix yet but I am 100% positive that it will resolve the issue on my end, too. I believe it only needs standardisation (so that other MPP 2 pens are supported without having to add the pen model to the source code). -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2142384 Title: ELAN2514:00 (04F3:4428) stylus report rate extremely low (~10–25 Hz) on Ubuntu 24.04 kernel 6.17 Status in linux package in Ubuntu: Fix Released Bug description: The active stylus on my HP OmniBook x Flip Ultra 14 reports at extremely low frequency (~10–25 Hz) under Ubuntu 24.04.4 LTS with kernel 6.17.0-14-generic. The pen input is choppy and unusable, while touch input works normally. The pen is a HP MPP tilt pen 2.0 Steps to Reproduce: Boot Ubuntu 24.04.4 LTS on HP OmniBook x Flip Ultra 14. Ensure kernel 6.17.0-14-generic is in use. Run: sudo libinput debug-events And then i move the pen and compare the input events with touch on my screen. The timestamps of the pen are 40-100 ms apart, which makes it unusable. I think this is the stylus in libinput: Device: ELAN2514:00 04F3:4428 Stylus Kernel: /dev/input/event7 Group: 5 Seat: seat0, default Size: 300x188mm Capabilities: tablet Accel profiles: none Other relevant info: lsmod | grep hid hid_sensor_prox 20480 0 hid_sensor_trigger 20480 3 hid_sensor_prox hid_sensor_iio_common 24576 2 hid_sensor_trigger,hid_sensor_prox industrialio 139264 4 industrialio_triggered_buffer,hid_sensor_trigger,hid_sensor_prox,kfifo_buf intel_hid 32768 0 sparse_keymap 12288 2 hp_wmi,intel_hid mac_hid 12288 0 hid_sensor_hub 28672 3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_prox usbhid 77824 0 hid_multitouch 36864 0 hid_generic 12288 0 i2c_hid_acpi 12288 0 i2c_hid 40960 1 i2c_hid_acpi hid 262144 6 i2c_hid,usbhid,hid_multitouch,hid_sensor_hub,snd_soc_sdca,hid_generic cat /sys/bus/i2c/devices/i2c-ELAN2514:00/power/control on Ubuntu 24.04.4 LTS Kernel: 6.17.0-14-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2142384/+subscriptions
Re: [Bug 2162367] Re: [i915] Dell Precision M4800 screen wont wake from sleep
The bug seems to be fixed now. Thank you! Daryl On 8/17/26 1:43 AM, Daniel van Vugt wrote: > It looks like the i915 kernel driver is flooding the log with problems > regarding the backlight and suspending. So it's probably a kernel bug. > > ** Summary changed: > > - laptop screen wont wake from sleep > + [i915] Dell Precision M4800 screen wont wake from sleep > > ** Package changed: ubuntu => linux (Ubuntu) > > ** Changed in: linux (Ubuntu) > Status: Incomplete => New > > ** Tags added: i915 suspend-resume > -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162367 Title: [i915] Dell Precision M4800 screen wont wake from sleep Status in linux package in Ubuntu: New Bug description: This happend on my last update befor upgrading to Ubuntu 26.04. When opening the lid to wake from sleep the keys light up, the hard drive flickers but the screen stays black and I can't login. Have to reboot to use the computer. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: xorg (not installed) ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 30 12:57:33 2026 InstallationDate: Installed on 2026-04-14 (107 days ago) InstallationMedia: Ubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash XDG_RUNTIME_DIR=<set> SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to resolute on 2026-07-30 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162367/+subscriptions
[Bug 2166592] Re: Lid switch stopped working under kernel 7.0.x — laptop never suspends on lid close
** Changed in: linux (Ubuntu) Status: Confirmed => New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166592 Title: Lid switch stopped working under kernel 7.0.x — laptop never suspends on lid close Status in linux package in Ubuntu: New Bug description: Bug report: Lid switch stopped working under kernel 7.0.x — laptop never suspends on lid close Affects: linux package (Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic) Hardware: Dell Inspiron 5558 (2015), ACPI lid switch PNP0C0D @ input0 -> /dev/input/event0 Steps to reproduce: 1. Fresh Ubuntu 26.04.1 LTS with stock kernel 7.0.0-31-generic, GNOME on Wayland. 2. systemd-logind default config (HandleLidSwitch=suspend), GNOME power lid-close action = suspend on both AC and battery. 3. Close the laptop lid. Expected result: The system suspends (like on previous Ubuntu releases / kernel 6.8). Actual result: The system never suspends. The lid event is never delivered to userspace: - The ACPI driver DOES receive the event: /proc/acpi/button/lid/LID0/state reliably toggles "open" -> "closed" when the lid is closed. - But NO EV_SW / SW_LID input event is emitted on /dev/input/event0 ("Lid Switch"). Verified with a python-evdev monitor (device grab succeeds, so no other reader is stealing events): closing the lid changes the /proc state but produces zero SW_LID events. - systemd-logind therefore logs nothing beyond boot time "Watching system buttons on /dev/input/event0 (Lid Switch)" — no "Lid closed.", and journalctl shows no PM suspend/resume entries at all for the lid action. - `systemctl suspend` from the terminal works fine, so suspend itself is functional. Analysis: This looks like a regression in the ACPI button driver (drivers/acpi/button.c): the lid state (btn->lid_state) is updated but the matching input_event(EV_SW, SW_LID, ...) is not delivered on this hardware under kernel 7.0.x. On many other Dell models the event IS delivered, which suggests model-specific ACPI/EC interaction. Workaround (in use): A systemd service polling /proc/acpi/button/lid/LID0/state every 1s that runs "systemctl suspend" when the state flips to "closed". Suggested fix: Ensure drivers/acpi/button.c always forwards the SW_LID input event together with updating the ACPI state, or investigate why the event is dropped specifically on this Dell ACPI implementation under 7.0.x. Files: full apport data collected at /tmp/opencode/lid-bug.apport ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: anurag 1854 F.... wireplumber /dev/snd/controlC0: anurag 1854 F.... wireplumber /dev/snd/seq: anurag 1836 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Sep 6 11:05:05 2026 InstallationDate: Installed on 2026-03-28 (162 days ago) InstallationMedia: Ubuntu 24.04.4 LTS "Noble Numbat" - Release amd64 (20260210) MachineType: Dell Inc. Inspiron 5558 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=05134500-1438-4844-8dd7-2b9cf214e29b ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/30/2019 dmi.bios.release: 65.18 dmi.bios.vendor: Dell Inc. dmi.bios.version: A18 dmi.board.name: 0DPP8C dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA18:bd12/30/2019:br65.18:svnDellInc.:pnInspiron5558:pvr:rvnDellInc.:rn0DPP8C:rvrA00:cvnDellInc.:ct9:cvr:sku06AE:pfa: dmi.product.name: Inspiron 5558 dmi.product.sku: 06AE dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166592/+subscriptions
[Bug 2166622] [NEW] Yoga Slim 7 14AKP10: ~38 s s2idle resume stall, NVMe IO_PAGE_FAULT, fixed by iommu=pt
Public bug reported: Yoga Slim 7 14AKP10 (Krackan Point): ~38.6 s s2idle resume stall ending in NVMe IO_PAGE_FAULT, fixed by iommu=pt System Lenovo Yoga Slim 7 14AKP10, AMD Ryzen AI 5 330 (Krackan Point), Radeon 820M, 16 GB NVMe: Micron 2400 MTFDKCD512TGW-1BP1AABLA, firmware 1002VALN (DRAM-less, uses HMB) Kubuntu 26.04.1 LTS, kernel 7.0.0-31-generic BIOS QTCN33WW (2026-04-24), Pluton disabled in BIOS; no newer firmware on LVFS /sys/power/mem_sleep = [s2idle] (no deep/S3 available) Symptom After s2idle suspend (lid or systemctl suspend), affected resumes take ~38 to 40 s before the login screen appears. The delay is almost constant (38.57 s / 38.61 s / 38.61 s over three cycles). Some resumes are immediate, so the issue is intermittent but easily reproducible. What was measured amd_pmc s0ix_stats: S0i3 entry succeeds, ~151 ms to resume from S0i3, so the SoC/SMU side is fine. pm_print_times: endpoint callbacks are fast (amdgpu ~185 ms, USB max ~266 ms, nvme pci_pm_resume 2 µs since it only schedules an async reset). In dmesg the stall sits between ACPI: EC: interrupt unblocked and the following line, which is logged exactly at the end of the ~38.6 s gap: nvme 0000:bf:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0x77e54000 flags=0x0000] immediately followed by amdgpu ... SMU is resuming, nvme nvme0: 8/0/0 default/read/poll queues and PM: suspend exit. The firmware also repeatedly logs, at suspend entry and/or exit: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OSFG], AE_NOT_FOUND ACPI Error: Aborting method \_SB.PEP._DSM due to previous error (AE_NOT_FOUND) so the LPS0 (Modern Standby) entry/exit notification to the platform aborts. Workaround (verified) Booting with iommu=pt completely removes the stall and the IO_PAGE_FAULT over repeated systemctl suspend cycles (20–30 s sleep). Nothing else was changed. The ACPI OSFG / PEP._DSM error is still logged with the workaround. Parameters deliberately not used: amd_iommu=off, nvme.noacpi=1, iommu=soft, pcie_aspm=off. Interpretation The IO_PAGE_FAULT is the marker of the end of the stall, not its cause: after leaving D3cold the NVMe controller issues DMA with a stale address, the IOMMU rejects it in the default translated mode, and the controller stays in a bad state until a ~38.6 s timeout expires, after which resume completes normally. With identity mapping (iommu=pt) the stale address stays valid and the device answers immediately. This looks like a platform + NVMe (Micron 2400 / HMB / D3cold) resume-ordering issue rather than a userspace, GPU or SMU delay. The aborted PEP._DSM may contribute to the intermittency (the EC may not be told the OS left standby); that part needs a DSDT review. Requests Kernel/AMD: consider a quirk for this platform/SSD combination (e.g. IOMMU passthrough by default for this DMI, or HMB/D3cold handling on resume) so it works out of the box. Lenovo: fix the firmware ACPI tables so that \_SB.PCI0.LPC0.EC0.OSFG, referenced by \_SB.PEP._DSM, exists. Reproduction Boot Kubuntu without iommu=pt; check /sys/power/mem_sleep shows [s2idle]. systemctl suspend, wait 20–30 s, wake. On an affected cycle, observe ~38 s before the login screen; in dmesg the gap is between ACPI: EC: interrupt unblocked and nvme ... AMD-Vi: Event logged [IO_PAGE_FAULT ...]. Reboot with iommu=pt, repeat 2–3: no stall, no fault. Full report (French, with logs and s0ix_stats) and amd-s2idle output attached ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Sep 6 21:18:48 2026 InstallationDate: Installed on 2026-09-06 (0 days ago) InstallationMedia: Kubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826.1) MachineType: LENOVO 83JY ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=764762f1-5e87-46be-869b-a6869d0d88f0 ro quiet splash iommu=pt PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/24/2026 dmi.bios.release: 1.33 dmi.bios.vendor: LENOVO dmi.bios.version: QTCN33WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76573 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 14AKP10 dmi.ec.firmware.release: 1.33 dmi.modalias: dmi:bvnLENOVO:bvrQTCN33WW:bd04/24/2026:br1.33:efr1.33:svnLENOVO:pn83JY:pvrYogaSlim714AKP10:rvnLENOVO:rnLNVNB161216:rvrSDK0T76573WIN:cvnLENOVO:ct10:cvrYogaSlim714AKP10:skuLENOVO_MT_83JY_BU_idea_FM_YogaSlim714AKP10:pfaYogaSlim714AKP10: dmi.product.family: Yoga Slim 7 14AKP10 dmi.product.name: 83JY dmi.product.sku: LENOVO_MT_83JY_BU_idea_FM_Yoga Slim 7 14AKP10 dmi.product.version: Yoga Slim 7 14AKP10 dmi.sys.vendor: LENOVO ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session ** Attachment added: "rapport_bug_resume_suspend_lenovo_yoga_slim_7_14AKP10_v2.docx" https://bugs.launchpad.net/bugs/2166622/+attachment/5998010/+files/rapport_bug_resume_suspend_lenovo_yoga_slim_7_14AKP10_v2.docx -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166622 Title: Yoga Slim 7 14AKP10: ~38 s s2idle resume stall, NVMe IO_PAGE_FAULT, fixed by iommu=pt Status in linux package in Ubuntu: New Bug description: Yoga Slim 7 14AKP10 (Krackan Point): ~38.6 s s2idle resume stall ending in NVMe IO_PAGE_FAULT, fixed by iommu=pt System Lenovo Yoga Slim 7 14AKP10, AMD Ryzen AI 5 330 (Krackan Point), Radeon 820M, 16 GB NVMe: Micron 2400 MTFDKCD512TGW-1BP1AABLA, firmware 1002VALN (DRAM-less, uses HMB) Kubuntu 26.04.1 LTS, kernel 7.0.0-31-generic BIOS QTCN33WW (2026-04-24), Pluton disabled in BIOS; no newer firmware on LVFS /sys/power/mem_sleep = [s2idle] (no deep/S3 available) Symptom After s2idle suspend (lid or systemctl suspend), affected resumes take ~38 to 40 s before the login screen appears. The delay is almost constant (38.57 s / 38.61 s / 38.61 s over three cycles). Some resumes are immediate, so the issue is intermittent but easily reproducible. What was measured amd_pmc s0ix_stats: S0i3 entry succeeds, ~151 ms to resume from S0i3, so the SoC/SMU side is fine. pm_print_times: endpoint callbacks are fast (amdgpu ~185 ms, USB max ~266 ms, nvme pci_pm_resume 2 µs since it only schedules an async reset). In dmesg the stall sits between ACPI: EC: interrupt unblocked and the following line, which is logged exactly at the end of the ~38.6 s gap: nvme 0000:bf:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0x77e54000 flags=0x0000] immediately followed by amdgpu ... SMU is resuming, nvme nvme0: 8/0/0 default/read/poll queues and PM: suspend exit. The firmware also repeatedly logs, at suspend entry and/or exit: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OSFG], AE_NOT_FOUND ACPI Error: Aborting method \_SB.PEP._DSM due to previous error (AE_NOT_FOUND) so the LPS0 (Modern Standby) entry/exit notification to the platform aborts. Workaround (verified) Booting with iommu=pt completely removes the stall and the IO_PAGE_FAULT over repeated systemctl suspend cycles (20–30 s sleep). Nothing else was changed. The ACPI OSFG / PEP._DSM error is still logged with the workaround. Parameters deliberately not used: amd_iommu=off, nvme.noacpi=1, iommu=soft, pcie_aspm=off. Interpretation The IO_PAGE_FAULT is the marker of the end of the stall, not its cause: after leaving D3cold the NVMe controller issues DMA with a stale address, the IOMMU rejects it in the default translated mode, and the controller stays in a bad state until a ~38.6 s timeout expires, after which resume completes normally. With identity mapping (iommu=pt) the stale address stays valid and the device answers immediately. This looks like a platform + NVMe (Micron 2400 / HMB / D3cold) resume-ordering issue rather than a userspace, GPU or SMU delay. The aborted PEP._DSM may contribute to the intermittency (the EC may not be told the OS left standby); that part needs a DSDT review. Requests Kernel/AMD: consider a quirk for this platform/SSD combination (e.g. IOMMU passthrough by default for this DMI, or HMB/D3cold handling on resume) so it works out of the box. Lenovo: fix the firmware ACPI tables so that \_SB.PCI0.LPC0.EC0.OSFG, referenced by \_SB.PEP._DSM, exists. Reproduction Boot Kubuntu without iommu=pt; check /sys/power/mem_sleep shows [s2idle]. systemctl suspend, wait 20–30 s, wake. On an affected cycle, observe ~38 s before the login screen; in dmesg the gap is between ACPI: EC: interrupt unblocked and nvme ... AMD-Vi: Event logged [IO_PAGE_FAULT ...]. Reboot with iommu=pt, repeat 2–3: no stall, no fault. Full report (French, with logs and s0ix_stats) and amd-s2idle output attached ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Sep 6 21:18:48 2026 InstallationDate: Installed on 2026-09-06 (0 days ago) InstallationMedia: Kubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826.1) MachineType: LENOVO 83JY ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=764762f1-5e87-46be-869b-a6869d0d88f0 ro quiet splash iommu=pt PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/24/2026 dmi.bios.release: 1.33 dmi.bios.vendor: LENOVO dmi.bios.version: QTCN33WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76573 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Slim 7 14AKP10 dmi.ec.firmware.release: 1.33 dmi.modalias: dmi:bvnLENOVO:bvrQTCN33WW:bd04/24/2026:br1.33:efr1.33:svnLENOVO:pn83JY:pvrYogaSlim714AKP10:rvnLENOVO:rnLNVNB161216:rvrSDK0T76573WIN:cvnLENOVO:ct10:cvrYogaSlim714AKP10:skuLENOVO_MT_83JY_BU_idea_FM_YogaSlim714AKP10:pfaYogaSlim714AKP10: dmi.product.family: Yoga Slim 7 14AKP10 dmi.product.name: 83JY dmi.product.sku: LENOVO_MT_83JY_BU_idea_FM_Yoga Slim 7 14AKP10 dmi.product.version: Yoga Slim 7 14AKP10 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166622/+subscriptions
суббота
[Bug 2162722] Re: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg)
Two more recurrences on 2026-09-06 on 7.0.0-31-generic (MGLRU still disabled: /sys/kernel/mm/lru_gen/enabled -> 0x0000). **#8 — 2026-09-06 08:53 JST** - Oops: page fault (not-present page) at lru_activate+0x91/0x3e0 - Comm: kworker/15:0 (Workqueue: events mmput_async_fn), UID 0 - Path: mmput_async_fn -> exit_mmap -> folio_mark_accessed -> lru_activate - Same RIP as my 2026-08-23 report (lru_activate) but triggered from async mm teardown, not a read syscall. **#9 — 2026-09-06 08:59 JST** (kdump reboot ~6 min after #8) - Oops: general protection fault at __page_cache_release.part.0+0xac/0x240 - Comm: V8Worker (PID 8551, UID 1000) — Cursor/Electron V8 worker - Path: do_madvise -> __page_cache_release -> folios_put_refs - Same class as 2026-08-30 (Comm: cursor, madvise path). Hardware unchanged: ASUS PRIME Z690M-PLUS D4, 64GB RAM, RTX 5060 Ti, nvidia OE. Not OOM. Full kdump dmesg archived locally; excerpt attached. Recurrence table update: | Date (JST) | Kernel | RIP | Comm | |-------------------|----------|-----------------------------|-----------------| | 2026-09-06 08:53 | 7.0.0-31 | lru_activate | kworker/15:0 | | 2026-09-06 08:59 | 7.0.0-31 | __page_cache_release | V8Worker | Still awaiting 7.0.0-32+ with upstream MGLRU fixes. ** Attachment added: "kdump dmesg excerpt 2026-09-06 (#8 and #9)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162722/+attachment/5997821/+files/launchpad_2162722_kdump_dmesg_20260906.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2162722 Title: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg) Status in linux package in Ubuntu: New Bug description: DistroRelease: Ubuntu 26.04 LTS (resolute) Package: linux-image-7.0.0-28-generic 7.0.0-28.28 Kernel: Linux 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC x86_64 Hardware: ASUS PRIME Z690M-PLUS D4, BIOS 3811 GPU: NVIDIA GeForce RTX 5060 Ti (driver 610.43.02, tainted OE) Impact of the bug: The entire system rebooted unexpectedly (kdump). Work in progress was lost. What I expected to happen: The desktop session should remain stable under normal application load. What actually happened: On 2026-08-03 ~17:25 JST, during heavy Electron/Chromium workload (Cursor IDE agent/plan build), the kernel hit an Oops and kdump triggered an automatic reboot. kdump artifacts: /var/crash/202608031725/ (dmesg + vmcore) Apport ticket: cb836c7a-8f1f-11f1-8811-9953c338e1ca Kernel Oops (from kdump dmesg): Oops: general protection fault, probably for non-canonical address 0xffff7127d16b6d48: 0000 [#1] SMP NOPTI CPU: 6 PID: 80704 Comm: ThreadPoolForeg Tainted: G OE (nvidia out-of-tree modules loaded) RIP: lru_gen_del_folio.constprop.0+0x19a/0x380 Call Trace: lru_gen_del_folio __page_cache_release.part.0 folios_put_refs free_pages_and_swap_cache zap_pte_range exit_mmap do_exit get_signal Not OOM: 64 GB RAM, swap unused at time of crash. Correlating load (not proven causal): - GNOME localsearch indexing CIFS/rclone/SSHFS mounts under ~/drive and ~/mnt - CIFS automount retries to unreachable //192.168.1.152/ (return code -113/-4) Host mitigations already applied locally: - localsearch ignored-directories: drive, mnt - Disabled unreachable .152 CIFS fstab automount Regression notes: Similar sudden reboots were rare on Ubuntu 24.04 (6.8 kernel). This is the first kdump on 26.04 / 7.0.0-28-generic on this machine. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-28-generic 7.0.0-28.28 ProcVersionSignature: Ubuntu 7.0.0-28.28-generic 7.0.12 Uname: Linux 7.0.0-28-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC1: ytsubame 2780 F.... wireplumber /dev/snd/controlC0: ytsubame 2780 F.... wireplumber /dev/snd/seq: ytsubame 2696 F.... pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Aug 3 18:39:40 2026 InstallationDate: Installed on 2026-07-13 (21 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) MachineType: ASUS System Product Name PackageArchitecture: amd64 ProcEnviron: LANG=ja_JP.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=dumb XDG_RUNTIME_DIR=<set> ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-28-generic root=UUID=9061133c-3778-49ec-85ba-ecb208384534 ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M RfKill: 0: hci0: Bluetooth Soft blocked: no Hard blocked: no SourcePackage: linux Title: general protection fault in lru_gen_del_folio during exit_mmap (ThreadPoolForeg) UpgradeStatus: No upgrade log present (probably fresh install) _MarkForUpload: True dmi.bios.date: 10/22/2025 dmi.bios.release: 38.11 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3811 dmi.board.asset.tag: Default string dmi.board.name: PRIME Z690M-PLUS D4 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3811:bd10/22/2025:br38.11:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEZ690M-PLUSD4:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162722/+subscriptions
[Bug 2166509] Re: NULL pointer dereference in btmtk_usb_hci_wmt_sync kills MT7925 Bluetooth in 6.8.0-139 (regression from 6.8.0-138)
Hi, thought I'd chime in, also affected. Knocked out the BT chip of my Framework 16. Attaching more information to the ticket in case it helps. Similar disclosure as OP, the comment below comes from Claude Code/Opus 4.8. --- Independent reproduction on MediaTek MT7922 (Framework "RZ616"), confirming this is not MT7925-specific. HARDWARE - Framework Laptop 16 (AMD Ryzen 7040 Series) - Bluetooth: MT7922 USB 0e8d:e616 (btusb + btmtk). Wi-Fi side is mt7921e (PCIe) and is unaffected. - Ubuntu noble SAME REGRESSION BOUNDARY AS REPORTED (from my journal, 10 boots): - 6.8.0-138.138 -- Bluetooth initializes normally. Aug 21 - Sep 2, 7 boots, no oops, valid BD address. - 6.8.0-139.139 -- crashes on every boot. Sep 5, 3 boots. Controller left DOWN INIT with address 00:00:00:00:00:00. BT firmware is identical on both kernels (Build Time: 20250523103438); only the kernel differs. OOPS ON 6.8.0-139 (matches the reported __pm_runtime_resume(NULL) mechanism): BUG: kernel NULL pointer dereference, address: 0000000000000219 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:__pm_runtime_resume+0x1b/0x80 Call Trace: btmtk_usb_hci_wmt_sync+0xa9/0x2e0 [btmtk] btmtk_setup_firmware_79xx+0x1c7/0x360 [btmtk] btusb_mtk_setup+0x453/0x610 [btusb] hci_dev_setup_sync+0x6c/0x430 [bluetooth] hci_dev_init_sync+0x3e/0x1c0 [bluetooth] hci_dev_open_sync+0xb1/0x350 [bluetooth] hci_dev_do_open+0x28/0x70 [bluetooth] hci_power_on+0x50/0x210 [bluetooth] WORKAROUND CONFIRMED: booting 6.8.0-138 restores internal Bluetooth. (A USB CSR dongle also works, since it doesn't go through btusb_mtk_setup().) This confirms the report's "MT7921/MT7922/MT7925 all affected" statement on real MT7922 hardware and a second platform (Framework Laptop 16, vs. the original MSI desktop). Full 6.8.0-139 dmesg attached. ** Attachment added: "lp2166509-mt7922-dmesg-6.8.0-139.sanitized.txt" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166509/+attachment/5997817/+files/lp2166509-mt7922-dmesg-6.8.0-139.sanitized.txt -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166509 Title: NULL pointer dereference in btmtk_usb_hci_wmt_sync kills MT7925 Bluetooth in 6.8.0-139 (regression from 6.8.0-138) Status in linux package in Ubuntu: Confirmed Bug description: The following report is filled by AI upon my request. However, I had the issue, I read about the fix that AI proposed, I applied it and the fix worked. So I can say that it was not a hallucination, at least for my computer. Would it work on others computers? Is it a good patch? I have no idea... [Impact] MediaTek MT7925/MT7921 USB Bluetooth controllers are completely non-functional on linux-image-6.8.0-139-generic. The controller oopses during firmware setup, the hci0 kworker exits with irqs disabled, and the adapter is left DOWN INIT with BD_ADDR 00:00:00:00:00:00. bluetoothctl reports no controller at all, so the machine has no usable Bluetooth: no pairing, and every previously paired device stops working. This is a regression introduced by 6.8.0-139.139. 6.8.0-138.138 is unaffected on identical hardware. MediaTek MT7925/MT7921 is the Bluetooth companion of the mt7921e Wi-Fi chip and is very common on recent AMD desktop boards and laptops, so the affected population is not small. [Fix] Two consecutive upstream commits from the same July 2024 MediaTek series, both first released in v6.11: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Moves the WMT handshake into btmtk.c. struct btusb_data is out of scope there, so the moved code reads the USB interface, device and control anchor out of the btmtk private area of hci_dev instead: struct btmtk_data *data = hci_get_priv(hdev); ... err = usb_autopm_get_interface(data->intf); 5c5e8c52e3ca ("Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c") Rewrites btusb_mtk_setup() to populate exactly those three fields before delegating to btmtk_usb_setup(). noble applied the first in 6.8.0-139.139, via LP: #2160250 ("Noble update: upstream stable patchset 2026-07-09"), but not the second. The consumer landed without its producer. btusb_mtk_setup() in noble therefore still has its pre-6.11 shape and sets only ->dev_id and ->reset_sync, leaving ->intf, ->udev and ->ctrl_anchor NULL. btmtk_usb_hci_wmt_sync() then calls usb_autopm_get_interface(NULL). Upstream is not affected: v6.11 and later carry both commits, v6.10 and earlier carry neither. Only a tree holding one without the other is broken. Backporting 5c5e8c52e3ca in full is not appropriate here: it moves btusb_mtk_setup()/btusb_mtk_shutdown() wholesale into btmtk.c and depends on the rest of the 6.11 MediaTek restructuring (btmtk_usb_setup(), btmtk_usb_shutdown(), the ISO data transmission series). The attached patch instead seeds the three fields the moved WMT code requires, which is what 5c5e8c52e3ca does for them upstream: mediatek = hci_get_priv(hdev); mediatek->dev_id = dev_id; mediatek->reset_sync = btusb_mtk_reset; + mediatek->intf = data->intf; + mediatek->udev = data->udev; + mediatek->ctrl_anchor = &data->ctrl_anchor; [Test Case] On an MT7925 USB adapter (0e8d:0616) running 6.8.0-139-generic, no Bluetooth adapter is usable: hci0 never leaves DOWN INIT, it carries no BD address, and bluetoothctl lists no controller. The kernel log shows why, at boot: BUG: kernel NULL pointer dereference, address: 0000000000000219 #PF: supervisor read access in kernel mode Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 225 Comm: kworker/u51:0 Tainted: P OE 6.8.0-139-generic #139-Ubuntu Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:__pm_runtime_resume+0x1b/0x80 Call Trace: usb_autopm_get_interface+0x1d/0x60 btmtk_usb_hci_wmt_sync+0xa9/0x2e0 [btmtk] btmtk_setup_firmware_79xx+0x1c7/0x360 [btmtk] btusb_mtk_setup+0x453/0x610 [btusb] hci_dev_setup_sync+0x6c/0x430 [bluetooth] hci_dev_init_sync+0x3e/0x1c0 [bluetooth] hci_dev_open_sync+0xb1/0x350 [bluetooth] hci_dev_do_open+0x28/0x70 [bluetooth] hci_power_on+0x50/0x210 [bluetooth] process_one_work+0x181/0x3a0 worker_thread+0x18b/0x330 kthread+0xef/0x120 note: kworker/u51:0[225] exited with irqs disabled Booting 6.8.0-138-generic on the same machine: no oops, Bluetooth works. With btusb.ko rebuilt from 6.8.0-139 sources plus the attached patch, the same machine boots to: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20250523103438 Bluetooth: hci0: Device setup in 159295 usecs Bluetooth: hci0: AOSP extensions version v1.00 $ hciconfig -a | head -3 hci0: Type: Primary Bus: USB BD Address: A8:3B:76:XX:XX:XX ACL MTU: 1021:6 SCO MTU: 240:8 UP RUNNING PSCAN and audio devices pair and stream normally. [Regression Potential] Very low. Three assignments of already-available values, confined to the MediaTek USB setup path, restoring parity with upstream btusb_mtk_setup(). Non-MediaTek controllers never execute this code. Without the assignments the fields are NULL and every consumer of them oopses, so there is no existing behaviour to preserve. Any risk would be confined to MediaTek USB Bluetooth, which is currently 100% broken on this kernel. [Other Info] Broken: linux-image-6.8.0-139-generic 6.8.0-139.139 Last good: linux-image-6.8.0-138-generic 6.8.0-138.138 Release: Ubuntu 24.04.4 LTS (noble) Adapter: MediaTek MT7925, USB 0e8d:0616 (companion to mt7921e Wi-Fi) Board: Micro-Star MSI MAG X670E TOMAHAWK WIFI (MS-7E12), BIOS 1.80 02/06/2024 Any MT7921/MT7922/MT7925 USB controller going through btusb_mtk_setup() should reproduce this identically. Patch, build scripts and full kernel logs for the broken, good and patched boots: https://github.com/LouisJULIEN/btusb-mtk-fix ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Sep 4 17:08:27 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2024-03-20 (898 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) MachineType: Micro-Star International Co., Ltd. MS-7E12 ProcFB: 0 simpledrmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_hve01w@/vmlinuz-6.8.0-139-generic root=ZFS=rpool/ROOT/ubuntu_hve01w ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2024-11-30 (643 days ago) dmi.bios.date: 02/06/2024 dmi.bios.release: 5.32 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 1.80 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: MAG X670E TOMAHAWK WIFI (MS-7E12) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.80:bd02/06/2024:br5.32:svnMicro-StarInternationalCo.,Ltd.:pnMS-7E12:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMAGX670ETOMAHAWKWIFI(MS-7E12):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7E12 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166509/+subscriptions
[Bug 2166509] Re: NULL pointer dereference in btmtk_usb_hci_wmt_sync kills MT7925 Bluetooth in 6.8.0-139 (regression from 6.8.0-138)
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166509 Title: NULL pointer dereference in btmtk_usb_hci_wmt_sync kills MT7925 Bluetooth in 6.8.0-139 (regression from 6.8.0-138) Status in linux package in Ubuntu: Confirmed Bug description: The following report is filled by AI upon my request. However, I had the issue, I read about the fix that AI proposed, I applied it and the fix worked. So I can say that it was not a hallucination, at least for my computer. Would it work on others computers? Is it a good patch? I have no idea... [Impact] MediaTek MT7925/MT7921 USB Bluetooth controllers are completely non-functional on linux-image-6.8.0-139-generic. The controller oopses during firmware setup, the hci0 kworker exits with irqs disabled, and the adapter is left DOWN INIT with BD_ADDR 00:00:00:00:00:00. bluetoothctl reports no controller at all, so the machine has no usable Bluetooth: no pairing, and every previously paired device stops working. This is a regression introduced by 6.8.0-139.139. 6.8.0-138.138 is unaffected on identical hardware. MediaTek MT7925/MT7921 is the Bluetooth companion of the mt7921e Wi-Fi chip and is very common on recent AMD desktop boards and laptops, so the affected population is not small. [Fix] Two consecutive upstream commits from the same July 2024 MediaTek series, both first released in v6.11: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Moves the WMT handshake into btmtk.c. struct btusb_data is out of scope there, so the moved code reads the USB interface, device and control anchor out of the btmtk private area of hci_dev instead: struct btmtk_data *data = hci_get_priv(hdev); ... err = usb_autopm_get_interface(data->intf); 5c5e8c52e3ca ("Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c") Rewrites btusb_mtk_setup() to populate exactly those three fields before delegating to btmtk_usb_setup(). noble applied the first in 6.8.0-139.139, via LP: #2160250 ("Noble update: upstream stable patchset 2026-07-09"), but not the second. The consumer landed without its producer. btusb_mtk_setup() in noble therefore still has its pre-6.11 shape and sets only ->dev_id and ->reset_sync, leaving ->intf, ->udev and ->ctrl_anchor NULL. btmtk_usb_hci_wmt_sync() then calls usb_autopm_get_interface(NULL). Upstream is not affected: v6.11 and later carry both commits, v6.10 and earlier carry neither. Only a tree holding one without the other is broken. Backporting 5c5e8c52e3ca in full is not appropriate here: it moves btusb_mtk_setup()/btusb_mtk_shutdown() wholesale into btmtk.c and depends on the rest of the 6.11 MediaTek restructuring (btmtk_usb_setup(), btmtk_usb_shutdown(), the ISO data transmission series). The attached patch instead seeds the three fields the moved WMT code requires, which is what 5c5e8c52e3ca does for them upstream: mediatek = hci_get_priv(hdev); mediatek->dev_id = dev_id; mediatek->reset_sync = btusb_mtk_reset; + mediatek->intf = data->intf; + mediatek->udev = data->udev; + mediatek->ctrl_anchor = &data->ctrl_anchor; [Test Case] On an MT7925 USB adapter (0e8d:0616) running 6.8.0-139-generic, no Bluetooth adapter is usable: hci0 never leaves DOWN INIT, it carries no BD address, and bluetoothctl lists no controller. The kernel log shows why, at boot: BUG: kernel NULL pointer dereference, address: 0000000000000219 #PF: supervisor read access in kernel mode Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 225 Comm: kworker/u51:0 Tainted: P OE 6.8.0-139-generic #139-Ubuntu Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:__pm_runtime_resume+0x1b/0x80 Call Trace: usb_autopm_get_interface+0x1d/0x60 btmtk_usb_hci_wmt_sync+0xa9/0x2e0 [btmtk] btmtk_setup_firmware_79xx+0x1c7/0x360 [btmtk] btusb_mtk_setup+0x453/0x610 [btusb] hci_dev_setup_sync+0x6c/0x430 [bluetooth] hci_dev_init_sync+0x3e/0x1c0 [bluetooth] hci_dev_open_sync+0xb1/0x350 [bluetooth] hci_dev_do_open+0x28/0x70 [bluetooth] hci_power_on+0x50/0x210 [bluetooth] process_one_work+0x181/0x3a0 worker_thread+0x18b/0x330 kthread+0xef/0x120 note: kworker/u51:0[225] exited with irqs disabled Booting 6.8.0-138-generic on the same machine: no oops, Bluetooth works. With btusb.ko rebuilt from 6.8.0-139 sources plus the attached patch, the same machine boots to: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20250523103438 Bluetooth: hci0: Device setup in 159295 usecs Bluetooth: hci0: AOSP extensions version v1.00 $ hciconfig -a | head -3 hci0: Type: Primary Bus: USB BD Address: A8:3B:76:XX:XX:XX ACL MTU: 1021:6 SCO MTU: 240:8 UP RUNNING PSCAN and audio devices pair and stream normally. [Regression Potential] Very low. Three assignments of already-available values, confined to the MediaTek USB setup path, restoring parity with upstream btusb_mtk_setup(). Non-MediaTek controllers never execute this code. Without the assignments the fields are NULL and every consumer of them oopses, so there is no existing behaviour to preserve. Any risk would be confined to MediaTek USB Bluetooth, which is currently 100% broken on this kernel. [Other Info] Broken: linux-image-6.8.0-139-generic 6.8.0-139.139 Last good: linux-image-6.8.0-138-generic 6.8.0-138.138 Release: Ubuntu 24.04.4 LTS (noble) Adapter: MediaTek MT7925, USB 0e8d:0616 (companion to mt7921e Wi-Fi) Board: Micro-Star MSI MAG X670E TOMAHAWK WIFI (MS-7E12), BIOS 1.80 02/06/2024 Any MT7921/MT7922/MT7925 USB controller going through btusb_mtk_setup() should reproduce this identically. Patch, build scripts and full kernel logs for the broken, good and patched boots: https://github.com/LouisJULIEN/btusb-mtk-fix ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139 ProcVersionSignature: Ubuntu 6.8.0-139.139-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs ApportVersion: 2.28.3-0ubuntu0.1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Sep 4 17:08:27 2026 HibernationDevice: RESUME=none InstallationDate: Installed on 2024-03-20 (898 days ago) InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 (20240220) MachineType: Micro-Star International Co., Ltd. MS-7E12 ProcFB: 0 simpledrmdrmfb ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_hve01w@/vmlinuz-6.8.0-139-generic root=ZFS=rpool/ROOT/ubuntu_hve01w ro quiet splash vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-6.8.0-139-generic N/A linux-backports-modules-6.8.0-139-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.29 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2024-11-30 (643 days ago) dmi.bios.date: 02/06/2024 dmi.bios.release: 5.32 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 1.80 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: MAG X670E TOMAHAWK WIFI (MS-7E12) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.80:bd02/06/2024:br5.32:svnMicro-StarInternationalCo.,Ltd.:pnMS-7E12:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMAGX670ETOMAHAWKWIFI(MS-7E12):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7E12 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166509/+subscriptions
[Bug 2166579] Re: System hangs on shutdown/restart via KDE Start Menu on ASUS ROG Crosshair VIII Hero (X570)
** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166579 Title: System hangs on shutdown/restart via KDE Start Menu on ASUS ROG Crosshair VIII Hero (X570) Status in linux package in Ubuntu: New Bug description: When attempting to shut down or restart the system using the KDE Plasma Start Menu / Session Manager on an ASUS ROG Crosshair VIII Hero (AMD X570) motherboard, the graphical session exits, but the system hangs indefinitely on a black screen with case fans and LEDs still powered on. Description: Ubuntu 26.04.1 LTS Release: 26.04 linux-image-generic: Installed: 7.0.0-31.31 Candidate: 7.0.0-31.31 Version table: *** 7.0.0-31.31 500 500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages 100 /var/lib/dpkg/status 7.0.0-14.14 500 500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages timothy@littlebullet:~$ Key Observations & Diagnostics: Direct Commands Work: Issuing direct kernel power commands (e.g., via custom desktop shortcuts or systemctl poweroff -i) powers down and restarts the motherboard and PSU cleanly every time, ruling out a physical motherboard ACPI or hardware power failure. Session Tear-Down Deadlock: The hang only occurs during the graphical session cleanup phase when initiated via the KDE Plasma UI, likely caused by an ACPI power-state transition deadlock or a driver failing to unhook during standard systemd user session shutdown. Hardware Context: Motherboard: ASUS ROG Crosshair VIII Hero (AMD X570) OS: Kubuntu (KDE Plasma) System configuration includes newly mounted local ext4 data drives under /mnt. New PSU has been installed Expected Behavior: Selecting "Shut Down" or "Restart" from the KDE Start Menu should cleanly terminate background processes, unmount filesystems, and pass power-off control to the Linux kernel/systemd without hanging. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-31-generic 7.0.0-31.31 ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 Uname: Linux 7.0.0-31-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sat Sep 5 18:27:36 2026 InstallationDate: Installed on 2026-08-31 (5 days ago) InstallationMedia: Kubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423) MachineType: ASUS System Product Name ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic root=UUID=a6c2c797-ae1a-43cf-9e4c-b5e66c81bbfd ro quiet splash reboot=pci amdgpu.runpm=0 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/18/2026 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 5601 dmi.board.asset.tag: Default string dmi.board.name: ROG CROSSHAIR VIII HERO dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr5601:bd08/18/2026:br5.17:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnROGCROSSHAIRVIIIHERO:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166579/+subscriptions