https://bugzilla.kernel.org/show_bug.cgi?id=220749
--- Comment #22 from [email protected] ([email protected]) --- 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. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
