Created attachment 308893 [details] Boot log (dmesg) from successful boot with acpi=off nomodeset Summary: Across multiple Linux distributions, the HP M02-0310 fails to boot unless both GRUB flags acpi=off nomodeset are used. Without these flags, the kernel halts during early initialization with repeated ACPI table errors: ACPI BIOS Error (bug): Failure creating named object \_SB.PCI0.LPCB.EC0 ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog ACPI: EC: EC device not found When these flags are applied, the system boots, but all ACPI-dependent functions (sleep, thermal, CPU scaling, etc.) are disabled. Hardware Configuration: -Model: HP M02-0310 -CPU: AMD Ryzen 5 8500G -GPU: Radeon 740M (integrated) -Memory: 16 GB DDR5 -Storage: 512 GB NVMe SSD -BIOS Version: F.08 Distributions Tested: -Debian 13.1 “Trixie” — kernels 6.6 → 6.18 -Fedora 43 (beta) — kernel 6.8 -Fedora 41 — kernel 6.8 -Ubuntu 24.04 LTS — kernel 6.8 -Linux Mint “Zara” -Arch Linux (rolling) -openSUSE Leap All fail to boot normally. Only Debian 13.1 with a manually updated kernel (6.18) and the flags acpi=off nomodeset allows successful initialization. Windows 11 boots normally on the same hardware, indicating an ACPI table implementation issue (DSDT/SSDT namespace conflict) within the BIOS firmware. The behavior occurs before OS initialization, suggesting a non-compliant ACPI namespace or EC device definition during early table parsing. Request: Please review the DSDT/SSDT ACPI implementation for the HP M02-0310 (BIOS F.08). A corrected firmware release would restore ACPI compatibility with mainline Linux kernels.
Additional context for maintainers: - The issue occurs prior to OS initialization — ACPI table parsing fails during early kernel handoff. - Tested across multiple distributions (Debian 13.1 → openSUSE Leap) and kernel versions (6.6 → 6.18). - Windows 11 boots normally on the same hardware, suggesting a DSDT/SSDT namespace issue or non-compliant ACPI EC definition in BIOS F.08. This bug is reproducible on HP M02-0310 (AMD Ryzen 5 8500G, Radeon 740M iGPU). Please advise if additional ACPI dumps (acpidump, dmidecode, etc.) would assist in analysis — I can provide them on request.
Created attachment 308894 [details] Terminal output showing acpidump failure (ACPI tables missing with acpi=off) Attached screenshot showing acpidump failure. ACPI tables are unavailable when booted with acpi=off, confirming that the kernel cannot access firmware ACPI data without those flags.
Are you using the latest BIOS? If not, please update. Also would be great if you reset BIOS settings.
1. Also please try to boot with either of these options: acpi_osi=! acpi_osi="Windows 2022" or acpi_osi=! acpi_osi="Windows 2015" 2. Please provide acpidump output and 3. The kernel output for "loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4" when _not_ using any additional options.
You're indeed on the latest BIOS release :-( https://support.hp.com/us-en/drivers/hp-omnidesk-desktop-pc-m02-0000a/model/2102686293?sku=B5RQ9AA
Mario, you must know the stuff, could you take a look please?
IMO - we can't use acpi=off on a modern system like this. There are just too many areas that rely upon ACPI. With 6.18-rc4, can you please provide the dmesg with no additional parameters added? Or are you saying that hangs? If that hangs can you please provide the output of dmesg with just nomodeset?
Yes — system is already running the latest BIOS / UEFI firmware available from the vendor. BIOS was also reset to defaults to rule out configuration-side issues. The behavior is the same with: - Default BIOS settings - Reset NVRAM - CSM disabled - Secure Boot on and off Additionally, the issue is reproducible across multiple kernel versions (6.6 LTS, 6.8, and 6.18-rc builds), and occurs regardless of kernel command-line parameters unless ACPI is fully disabled (`acpi=off`), which suggests the hang occurs during early ACPI/APIC initialization before PCI/USB/NVMe enumeration. This points to an ACPI or IOMMU initialization path that is failing silently rather than a firmware misconfiguration. If helpful, I can provide: - Full `dmesg` boot log (normal vs `acpi=off`) - `acpidump` table set - `journalctl -b -1` traces (from successful acpi=off boot) Just let me know which format you prefer. Sent from Proton Mail for Android. -------- Original Message -------- On Tuesday, 11/04/25 at 22:57 bugzilla-daemon@kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=220749 --- Comment #3 from Artem S. Tashkinov (aros@gmx.com) --- Are you using the latest BIOS? If not, please update. Also would be great if you reset BIOS settings. -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
Thanks, understood. 1. I will test both of the following OSI configurations and report back: - acpi_osi=! acpi_osi="Windows 2022" - acpi_osi=! acpi_osi="Windows 2015" 2. I will provide a full `acpidump` output: acpidump > acpidump.txt and also `acpixtract` output if needed. 3. I will capture a boot log with: loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4 This will be done *without* `acpi=off` or other workarounds, so the boot will freeze. I will retrieve the trace from `journalctl -b -1` after rebooting with `acpi=off`. I'll attach all three sets of data in the next update. Sent from Proton Mail for Android. -------- Original Message -------- On Wednesday, 11/05/25 at 00:47 bugzilla-daemon@kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=220749 Artem S. Tashkinov (aros@gmx.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Component|BIOS |EC Assignee|acpi_bios@kernel-bugs.osdl. |acpi_ec@kernel-bugs.osdl.or |org |g --- Comment #4 from Artem S. Tashkinov (aros@gmx.com) --- 1. Also please try to boot with either of these options: acpi_osi=! acpi_osi="Windows 2022" or acpi_osi=! acpi_osi="Windows 2015" 2. Please provide acpidump output and 3. The kernel output for "loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4" when _not_ using any additional options. -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
Thanks for the guidance, Artem. BIOS version is current (F.22, 2024-09 release), and the BIOS settings have now been reset to defaults before testing. I have tested both recommended ACPI OSI override variants: 1) acpi_osi=! acpi_osi="Windows 2022" 2) acpi_osi=! acpi_osi="Windows 2015" Unfortunately, neither configuration allows the system to proceed past "Loading initial ramdisk" — same behavior as with no flags. Regarding acpidump: The system freezes when ACPI is enabled, so I cannot collect acpidump directly in a normal boot. I *can* run acpidump when booting with `acpi=off`, and I can also use the UEFI shell method (acpidump.efi). Please confirm whether a dump generated in `acpi=off` mode is still useful, or if the UEFI shell dump is preferred. I am prepared to provide whichever format is needed. For the debug log request: I will capture output using: loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4 and will attach /var/log/dmesg (or serial console capture) on next reboot attempt without any additional boot parameters. Expected attachments next: - acpidump output (UEFI shell if preferred) - full dmesg log with debug flags enabled Sent from Proton Mail for Android. -------- Original Message -------- On Wednesday, 11/05/25 at 00:48 bugzilla-daemon@kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=220749 Artem S. Tashkinov (aros@gmx.com) changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://h30434.www3.hp.com/ | |t5/Desktop-Hardware-and-Upg | |rade-Questions/Linux-ACPI-b | |ug-HP-OmniDesk-M02-0310-req | |uires-acpi-off-to/td-p/9526 | |974 -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
Thanks, Mario. Confirmed: booting with no parameters on 6.18-rc4 hangs consistently at “Loading initial ramdisk…” when ACPI is enabled. The hang occurs before a usable tty appears, so I’m not able to obtain dmesg in that state. Booting with `nomodeset` (without disabling ACPI) also hangs at the same point. No output progresses past the initramfs handoff. The only configuration that currently boots to a stable userspace environment is: acpi=off pci=noacpi nomodeset which I understand is not viable long-term or appropriate for debugging. To proceed with your request, I will capture: • dmesg from a boot using: `loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4` • and a raw ACPI table dump via UEFI shell (`acpidump`), so you can inspect the DSDT/EC region directly. I’ll attach both artifacts shortly. . Sent from Proton Mail for Android. -------- Original Message -------- On Wednesday, 11/05/25 at 08:17 bugzilla-daemon@kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=220749 --- Comment #7 from Mario Limonciello (AMD) (mario.limonciello@amd.com) --- IMO - we can't use acpi=off on a modern system like this. There are just too many areas that rely upon ACPI. With 6.18-rc4, can you please provide the dmesg with no additional parameters added? Or are you saying that hangs? If that hangs can you please provide the output of dmesg with just nomodeset? -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
Created attachment 308898 [details] Full ACPI table dump extracted via UEFI Shell (not using acpi=off). Includes DSDT, all SSDTs, RSDP, and EC tables. Thanks for the guidance. I’ve attached a full ACPI table dump extracted via UEFI environment (not using acpi=off). System details: - HP OmniDesk M02-0310 - BIOS version: F.08 (latest, been reflashed) - Kernel tested: 6.18-rc4 (also tested stable 6.7 and 6.6 LTS) - The system consistently hangs at “Loading initial ramdisk…” when ACPI is enabled. Behavior: - System only boots fully with: acpi=off nomodeset - Any configuration where ACPI remains enabled results in freeze at early initramfs. - The same behavior is seen with or without amdgpu, with or without EFI shell overrides. Requested Data: - Full ACPI dump (attached: acpi_dump.tar.gz) Next Step: Tell me how you’d like the dmesg collected with `loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4`. System hangs immediately with ACPI enabled, so I can attempt capture through earlyprintk or UART if needed. Let me know what method you prefer for capturing boot logs.
Comment on attachment 308898 [details] Full ACPI table dump extracted via UEFI Shell (not using acpi=off). Includes DSDT, all SSDTs, RSDP, and EC tables. Thanks for the guidance. I’ve attached a full ACPI table dump extracted via UEFI environment (not using acpi=off). System details: - HP OmniDesk M02-0310 - BIOS version: F.08 (latest, reflashed) - Kernel tested: 6.18-rc4 (also tested stable 6.7 and 6.6 LTS) - The system consistently hangs at “Loading initial ramdisk…” when ACPI is enabled. Behavior: - System only boots fully with: acpi=off nomodeset - Any configuration where ACPI remains enabled results in freeze at early initramfs. - The same behavior is seen with or without amdgpu, with or without EFI shell overrides. Requested Data: - Full ACPI dump (attached: acpi_dump.tar.gz) Next Step: Tell me how you’d like the dmesg collected with `loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4`. System hangs immediately with ACPI enabled, so I can attempt capture through earlyprintk or UART if needed. Let me know what method you prefer for capturing boot logs.
Comment on attachment 308898 [details] Full ACPI table dump extracted via UEFI Shell (not using acpi=off). Includes DSDT, all SSDTs, RSDP, and EC tables. Thanks for the guidance. Attached is the full ACPI table dump extracted via UEFI shell (not using acpi=off). It includes DSDT, all SSDTs, RSDP, EC tables, and supporting firmware metadata. System: HP OmniDesk M02-0310 BIOS: F.08 (latest, reflashed) CPU: AMD Ryzen 5 8500G w/ Radeon 740M Graphics Kernel tested: 6.18-rc4, also 6.7 stable Behavior: System hangs at “Loading initial ramdisk…” when ACPI is enabled. Requires acpi=off to boot. Let me know your preferred method to capture early boot logs with: loglevel=8 acpi.debug_layer=0x2 acpi.debug_level=0x4 I can use earlyprintk=efi if needed.
Sorry for the duplicate comments earlier — the system was running without ACPI and the browser became unstable during submission. The important data is in the attached ACPI dump. I'll wait for guidance on preferred logging method for collecting early boot/kernel hang output when ACPI is enabled.
Created attachment 308899 [details] Boot log (dmesg) from successful boot with acpi=off nomodeset As requested, here is the dmesg output from a successful boot using `acpi=off nomodeset`. System locks at "Loading initial ramdisk..." when ACPI is enabled. Let me know how you'd like me to capture early boot output for the failing case (earlyprintk, UART, or camera capture).
I haven't looked at these logs yet; but I would say that if you have the ability to set up a UART with early printk output this would definitely be the way to go.
Created attachment 308904 [details] Attachment: early printk buffer capture (no UART yet) Hey Mario — wanted to follow up after testing. I booted with: log_buf_len=32M ignore_loglevel earlyprintk=efi,keep no_console_suspend The shutdown hang behavior is unchanged, and the resulting dmesg capture was still only ~68KB. This suggests the stall is occurring before the kernel gets a chance to emit early printk messages, which points to the firmware ACPI transition rather than the kernel shutdown path. I’ll capture a UART trace next. I need to hook up a USB-TTL adapter to the board’s debug UART header. Once I have that connected I’ll boot with: earlyprintk=uart,ttyS0,115200 console=ttyS0,115200 no_console_suspend and grab the full early shutdown trace for you. Just wanted to keep you in the loop while I get the adapter. Will update as soon as I have the UART output. (attaching the ~68KB early printk capture here for reference)
What bootloader are you using? Would it be possible to try to remove all bootloaders from the picture and try to boot with just the kernel EFI stub? +Ard for any ideas
Currently using GRUB 2. Yes, I can test kernel EFI stub boot. I will prepare a direct EFI entry for vmlinuz + initrd and boot without GRUB. Will report results.
Update: I tested a direct kernel EFI stub boot to remove GRUB from the equation. Booted using: vmlinuz-6.18.0-rc3 with initrd.img-6.18.0-rc3 via an efibootmgr-created EFI entry (no bootloader involved). Result: The system freezes before any visible console output. Screen goes black immediately and keyboard power drops as soon as the firmware attempts to start the kernel. There is no kernel early printk output at all. This indicates the hang is occurring during the EFI → kernel handoff, before the kernel logging is initialized. So the issue appears to be in the firmware/ACPI transition path rather than GRUB or userspace. UART adapter is on the way; I will capture early printk UART trace next and share it here.
Hi all, Quick status update from the user side, now that I’ve spent more time living on this machine and trying different approaches. Hardware / setup (recap) ---------------- - Machine: HP OmniDesk (desktop), AMD Ryzen 5 8500G w/ Radeon 740M - BIOS: F.08 (latest available from HP at the time of writing) - OS: Debian 13 “trixie” (amd64) - Kernels tested: multiple, including 6.12.x (Debian), 6.16.x and 6.18.0-rc3 - GPU: integrated AMD GPU only (no discrete card) Baseline symptom ---------------- With *no* special kernel parameters (i.e., normal ACPI enabled), the system: - Shows ACPI-related error messages during boot (details are in the dmesg logs I’ve already attached), - Then hard-freezes consistently during the “Loading initial ramdisk” stage. When it freezes: - Keyboard LEDs go dark, - USB is dead, - Only a hard power-off works. This is fully reproducible across all tested kernels. It doesn’t look like a version-to-version regression; it behaves more like “ACPI + this firmware + this platform” is fundamentally misbehaving very early in boot. What I tried so far ------------------- To narrow this down, I’ve gone through a number of kernel options and experiments. 1. Early workaround (very degraded) - Boot flags: `acpi=noacpi nomodeset` - Result: - System boots, - But ACPI and GPU are effectively crippled, no proper graphics stack, and overall poor usability. - Clearly not acceptable as a long-term configuration. 2. Current “best” workaround (still a hack) - Boot flags: `pci=noacpi iommu=pt mem_encrypt=off` - Result: - System now boots reliably. - Poweroff and reboot work correctly. - The iGPU appears to be at least partially used (much better than with `nomodeset`). - However: - This still relies on disabling/working around ACPI on PCI in a non-standard way. - It’s a workaround, not a fix; the goal is to run with normal ACPI and no special flags. 3. Early printk / early logging attempts - As requested, I attempted to enable early logging (e.g. `earlyprintk`, higher `loglevel`, etc.) to capture more useful output before the freeze. - The issue is that the hard-freeze occurs *so early* that I do not get any additional output beyond what is already visible in the existing boot logs: - By the time the system locks up, there is no new earlyprintk output to capture, and no way to sync anything to disk. - So, to be explicit: I have tried to provide the early logs that were requested, but the failure happens before those mechanisms can really help. There is simply nothing more emitted for me to save. 4. UART / serial debugging attempt - Following the suggestion to go “earlier than earlyprintk,” I purchased a UART/serial debug adapter with the intention of capturing very early firmware/kernel output. - However, on this HP OEM motherboard there is no documented serial/UART header exposed: - There is no obvious UART header on the board, - The HP documentation for this system does not describe any usable serial debug pins, - I was not able to identify a safe, supported way to hook the adapter up. - In practice, this means I cannot obtain a pre-boot UART trace from this machine, even though I did get the hardware specifically to try. 5. ACPI / DSDT override experiments - I captured and attached `acpidump` output earlier in this bug. - I built custom `DSDT.aml` files and attempted to override via the usual ACPI override mechanism in initramfs (cpio archive in `/boot` with the `acpi_override` hook). - However, because the freeze happens extremely early (around or just after “Loading initial ramdisk”), I cannot reliably confirm: - Whether the override is being applied at all before the system dies, or - Whether any change in behavior is due to the override versus the underlying firmware issue. - In other words, I can’t say “the patched DSDT doesn’t work” with confidence — it’s entirely possible that the failure is occurring before the override has a chance to take effect. From the outside, all I see is “same hard-freeze, same point in boot.” Where things stand now ---------------------- - The machine is only usable day-to-day with: `pci=noacpi iommu=pt mem_encrypt=off` - Without those flags (or similarly heavy-handed ACPI-disabling options), the system very reliably hard-freezes during boot. - This strongly suggests a platform/firmware ACPI problem that the kernel is tripping over very early, rather than a simple user configuration issue. - I have already provided: - `dmesg` logs from successful boots (with workarounds), - `acpidump` output, - Other requested debugging information in earlier comments. What I’m hoping for ------------------- From the kernel / ACPI side: - Guidance on **what additional data is realistically obtainable**, given that: - The failure happens before earlyprintk/earlycon is able to give new information, and - The motherboard does not expose a usable UART header for pre-boot serial capture. - An assessment of whether this resembles: - A known broken ACPI pattern on similar HP / Ryzen platforms that might be handled via a quirk, or - A new type of ACPI table bug specific to this machine that needs a targeted kernel-side workaround. - If possible, a **test patch** or suggested quirk, for example: - Something that safely ignores/deduplicates the problematic ACPI object(s) the kernel is choking on, rather than failing in a way that bricks the boot path. - I’m fully willing to build and test custom kernels, apply patches, and report back with whatever logs I can get from working boots. From the HP / firmware side (if that’s where this ultimately lands): - If the conclusion is “this is a broken firmware,” a clear statement and any specific ACPI violations or suspicious constructs you can point to would be extremely helpful. - That would give me something concrete to take back to HP support (instead of just “Linux doesn’t boot”). Goal ---- The goal is straightforward: > Get this HP OmniDesk / Ryzen 5 8500G system to boot **reliably, with full > ACPI and iGPU support**, using *no special kernel flags*. Right now, the kernel only works for me with `pci=noacpi iommu=pt mem_encrypt=off`, which is better than `acpi=noacpi nomodeset` but still a non-standard and degraded configuration. I’m happy to continue being the test system for experiments and patches. If you can outline the next concrete steps or any specific tests that are realistically possible given the very-early hard-freeze and lack of UART access, I’ll run them and report back. Thanks again for the time and effort spent on this so far.
If it's not obvious where the UART header is, another option - do you have a PCIe slot? You can potentially put a PCIe serial card in place and we might be able to get output from the serial port of that. > pci=noacpi iommu=pt mem_encrypt=off Regarding these options, are you sure you need all 3? What happens with just pci=noacpi and mem_encrypt=off? Can you check in BIOS if there is a TSME option? Can you please try turning it off. Do you have updated logs from this combination you used? Is the GPU acceleration working in your combination?
Created attachment 308955 [details] HP M02-0310 logs for 6.16.8 with pci=noacpi iommu=pt Hi Mario, Thanks for following up and for digging into this. (1) UART header / PCIe serial I haven’t been able to identify any clearly documented UART header on this HP board from the silkscreen or the service docs I’ve found. There is a free PCIe slot, but I don’t currently have a PCIe serial card available. If serial console output would still be useful after this round of testing, I can pick up a PCIe serial card and try to capture logs that way. For now, the information below is from dmesg/journalctl on successful boots. (2) Boot parameters By default (no extra kernel parameters), the machine consistently freezes a few seconds after: Loading initial ramdisk ... The keyboard LEDs go out and it requires a hard poweroff; it never reaches userspace, so I can’t collect logs from that configuration. To get a stable system that completes boot, I had previously been using: pci=noacpi iommu=pt mem_encrypt=off but after more testing I’ve confirmed that `mem_encrypt=off` is not required. My current “safe” combination is: pci=noacpi iommu=pt With these two parameters the system boots reliably into a graphical desktop. If I drop `iommu=pt` (for example using): pci=noacpi mem_encrypt=off or just pci=noacpi the system also fails to reach userspace, but in this case it drops to the initramfs prompt with an error that it cannot find the root filesystem and offers a rescue shell. This behavior is consistent whenever `iommu=pt` is removed, and has occurred on each Debian kernel I’ve tested on this machine (e.g. 6.12.x, 6.16.8, and previously 6.18.x before I removed it). I’ve attached hp-m02-0310-logs-6.16.8-pci-noacpi-iommu-pt.tar.xz, which contains: * cmdline-6.16.8-pci-noacpi-iommu-pt.txt * dmesg-6.16.8-pci-noacpi-iommu-pt.txt * journal-6.16.8-pci-noacpi-iommu-pt.txt * lspci-vvnn-6.16.8-pci-noacpi-iommu-pt.txt * acpidump-6.16.8-pci-noacpi-iommu-pt.bin * glxinfo-6.16.8-pci-noacpi-iommu-pt.txt (3) TSME in BIOS I’ve double-checked the firmware setup utility on this HP OmniDesk M02-0310. There is no TSME / SME / “Memory Guard” / “Transparent Secure Memory Encryption” option exposed anywhere in the BIOS (I checked under Security, Advanced, and CPU-related menus). So there is nothing I can toggle for TSME on this system. (4) GPU acceleration status Under the working combination (`pci=noacpi iommu=pt`), GPU acceleration appears to be working correctly: * The kernel is using `amdgpu` for the integrated GPU and KMS is active. * `glxinfo -B` reports the AMD GPU as the renderer rather than llvmpipe (details are in glxinfo-6.16.8-pci-noacpi-iommu-pt.txt). * Desktop performance is smooth and I’m not seeing GPU-related errors in dmesg for this configuration. If you’d like me to try a specific test kernel or additional kernel parameters (e.g. extra ACPI or IOMMU debug options), I’m happy to rerun these combinations and provide more logs.
> If serial console output would still be useful after this round of testing, I > can pick up a PCIe serial card and try to capture logs that way. For now, the > information below is from dmesg/journalctl on successful boots. At this point we're still looking for a needle in a haystack and guessing. No promises of course; but a serial console might get us a better hint at where things are going awry. > the system also fails to reach userspace, but in this case it drops to the > initramfs prompt with an error that it cannot find the root filesystem and > offers a rescue shell. This behavior is consistent whenever `iommu=pt` is > removed, and has occurred on each Debian kernel I’ve tested on this machine > (e.g. 6.12.x, 6.16.8, and previously 6.18.x before I removed it). OK this is really helpful to know actually. It points at an IOMMU issue that it would be helpful to look at the logs for. You should be able to get a working network stack at the initramfs prompt and use something like netconsole or ssh (where you'll have to include these in your initramfs) to be able to send the full kernel log in this configuration to another machine. Instead of iommu=pt can you please try amd_iommu=off both with and with and without pci=noacpi? > I’ve double-checked the firmware setup utility on this HP OmniDesk M02-0310. > There is no TSME / SME / “Memory Guard” / “Transparent Secure Memory > Encryption” option exposed anywhere in the BIOS (I checked under Security, > Advanced, and CPU-related menus). So there is nothing I can toggle for TSME > on this system. As your previous testing with memory encryption was pointless (where did this come from?) then TSME will also be pointless. > Under the working combination (`pci=noacpi iommu=pt`), GPU acceleration > appears to be working correctly: OK, this is a much more usable system at least then. > [ 0.033598] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0 > [ 0.033600] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0 > [ 0.033603] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0 > [ 0.033604] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0xa0 > [ 0.033605] AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10 > [ 0.033646] AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found > [ 0.033650] AMD-Vi: Disabling interrupt remapping > [ 0.033655] clocksource: tsc-early: mask: 0xfffffff From your logs I noticed this while IOMMU is in pass through. You can see there is definitely a firmware bug in the IVRS table entries that the kernel tells you about. https://github.com/torvalds/linux/blob/23cb64fb76257309e396ea4cec8396d4a1dbae68/drivers/iommu/amd/init.c#L3103 If you look at commit history you can see this message was added in place to turn off interrupt remapping and try to work around the BIOS bug. https://github.com/torvalds/linux/commit/c2ff5cf5294bcbd7fa50f7d860e90a66db7e5059 This is probably enough to /start/ your conversation with HP support about fixing the firmware as it's tangible and definitely not a Linux problem.
Hi Mario, Quick follow-up on the two points you raised — why I tested mem_encrypt=off, and what happens with amd_iommu=off in the different combinations. 1. Why I originally used mem_encrypt=off The only reason I experimented with mem_encrypt=off was that some of the early boot failures looked similar to what I’ve seen documented when SME/TSME is involved on unsupported or misconfigured systems. Since this HP firmware exposes no explicit SME/TSME/“Memory Guard” toggle anywhere in the setup utility, I tried mem_encrypt=off as a way to rule out any latent memory-encryption interaction contributing to the hangs. As you pointed out, on this platform it doesn’t actually change behavior in a meaningful way, so I’ve dropped it from my current tests. It was purely a diagnostic attempt to eliminate one possible class of problems. When I originally sent you the update that included that flag, it was at the end of a long day of repeated initramfs drops, and I was just relieved to reach userspace with something other than acpi=off and nomodeset, so I carried it forward out of caution. After re-testing without it and comparing logs with a clearer head, I realized it wasn’t actually contributing anything, so I’ve removed it from further testing. 2. Results with amd_iommu=off Per your suggestion I tried the two combinations: amd_iommu=off (by itself) This reproduces the (unfortunately) familar freeze, occruing a few seconds after “loading initial ramdisk” on the splash screen. No initramfs prompt or rescue shell appears; the keyboard LEDs go out and I have to hard power-off. pci=noacpi amd_iommu=off This one actually boots successfully into Debian and reaches userspace. Root filesystem is found and the system seems stable under normal use. So at this point I have two “working” configurations: this one, and the earlier pci=noacpi iommu=pt setup. Next step on my side is to get a serial console set up so I can capture early boot logs for the failing amd_iommu=off case (and the non-pt IOMMU path more generally) and send those along. Thanks again for sticking with this — I appreciate the help. Sent with Proton Mail secure email. On Thursday, November 20th, 2025 at 7:44 AM, bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=220749 > > --- Comment #25 from Mario Limonciello (AMD) (mario.limonciello@amd.com) --- > > > If serial console output would still be useful after this round of testing, > I > > can pick up a PCIe serial card and try to capture logs that way. For now, > the > > information below is from dmesg/journalctl on successful boots. > > > At this point we're still looking for a needle in a haystack and guessing. No > promises of course; but a serial console might get us a better hint at where > things are going awry. > > > the system also fails to reach userspace, but in this case it drops to the > > initramfs prompt with an error that it cannot find the root filesystem and > > offers a rescue shell. This behavior is consistent whenever `iommu=pt` is > > removed, and has occurred on each Debian kernel I’ve tested on this machine > > (e.g. 6.12.x, 6.16.8, and previously 6.18.x before I removed it). > > > OK this is really helpful to know actually. It points at an IOMMU issue that > it would be helpful to look at the logs for. You should be able to get a > working network stack at the initramfs prompt and use something like > netconsole > or ssh (where you'll have to include these in your initramfs) to be able to > send the full kernel log in this configuration to another machine. > > Instead of iommu=pt can you please try amd_iommu=off both with and with and > without pci=noacpi? > > > I’ve double-checked the firmware setup utility on this HP OmniDesk > M02-0310. > > There is no TSME / SME / “Memory Guard” / “Transparent Secure Memory > > Encryption” option exposed anywhere in the BIOS (I checked under Security, > > Advanced, and CPU-related menus). So there is nothing I can toggle for TSME > > on this system. > > > As your previous testing with memory encryption was pointless (where did this > come from?) then TSME will also be pointless. > > > Under the working combination (`pci=noacpi iommu=pt`), GPU acceleration > > appears to be working correctly: > > > OK, this is a much more usable system at least then. > > > [ 0.033598] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0 > > [ 0.033600] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0 > > [ 0.033603] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0 > > [ 0.033604] AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0xa0 > > [ 0.033605] AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10 > > [ 0.033646] AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found > > [ 0.033650] AMD-Vi: Disabling interrupt remapping > > [ 0.033655] clocksource: tsc-early: mask: 0xfffffff > > > From your logs I noticed this while IOMMU is in pass through. You can see > there is definitely a firmware bug in the IVRS table entries that the kernel > tells you about. > > > https://github.com/torvalds/linux/blob/23cb64fb76257309e396ea4cec8396d4a1dbae68/drivers/iommu/amd/init.c#L3103 > > If you look at commit history you can see this message was added in place to > turn off interrupt remapping and try to work around the BIOS bug. > > > https://github.com/torvalds/linux/commit/c2ff5cf5294bcbd7fa50f7d860e90a66db7e5059 > > This is probably enough to /start/ your conversation with HP support about > fixing the firmware as it's tangible and definitely not a Linux problem. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.