https://bugzilla.kernel.org/show_bug.cgi?id=220749
[email protected] ([email protected]) changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #308893|0 |1 is obsolete| | Attachment #308894|0 |1 is obsolete| | Attachment #308898|0 |1 is obsolete| | Attachment #308899|0 |1 is obsolete| | Attachment #308904|0 |1 is obsolete| | --- Comment #24 from [email protected] ([email protected]) --- Created attachment 308955 --> https://bugzilla.kernel.org/attachment.cgi?id=308955&action=edit 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. -- 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
