[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 --- Comment #5 from Sam Edwards (cfswo...@gmail.com) --- The improper device poweroff DOES happen with 7e4fdeafa61f, but NOT with 4b9ee772eaa8 (7e4fdea's parent commit). So it's a regression with 7e4fdeafa61f, although the resource_in_use=0 is not new. -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 Bjorn Helgaas (bj...@helgaas.com) changed: What|Removed |Added Regression|No |Yes -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 --- Comment #4 from Sam Edwards (cfswo...@gmail.com) --- I do know that this worked fine on a 5.12.x kernel and the issue appeared when I attempted to boot 5.13.0. I can see if 7e4fdeafa61f itself introduced the problem (by trying a boot with 7e4fdeafa61f and 7e4fdeafa61f^) if desired. I'll spend some time configuring a more minimalist kernel that I can kexec to test patches and do any additional debug steps. -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 --- Comment #3 from Sam Edwards (cfswo...@gmail.com) --- Created attachment 298281 --> https://bugzilla.kernel.org/attachment.cgi?id=298281=edit dmesg output up to when NVMe driver is running (with acpi_turn_off_unused_power_resources disabled) -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 --- Comment #2 from Sam Edwards (cfswo...@gmail.com) --- Created attachment 298279 --> https://bugzilla.kernel.org/attachment.cgi?id=298279=edit acpidump -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035
Bjorn Helgaas (bj...@helgaas.com) changed:
What|Removed |Added
CC||bj...@helgaas.com,
||r...@rjwysocki.net
--- Comment #1 from Bjorn Helgaas (bj...@helgaas.com) ---
https://git.kernel.org/linus/7e4fdeafa61f ("ACPI: power: Turn off unused power
resources unconditionally")
Is this a regression caused by 7e4fdeafa61f, i.e., did this device work
correctly in v5.12 and broke in v5.13? If so, this is a much higher priority
problem.
Could you attach the complete dmesg log and the output of acpidump?
--
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
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 214035] New: acpi_turn_off_unused_power_resources() may take down necessary hardware
https://bugzilla.kernel.org/show_bug.cgi?id=214035 Bug ID: 214035 Summary: acpi_turn_off_unused_power_resources() may take down necessary hardware Product: ACPI Version: 2.5 Kernel Version: 5.13.9 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Power-Other Assignee: acpi_power-ot...@kernel-bugs.osdl.org Reporter: cfswo...@gmail.com Regression: No The commit 7e4fdea changes the ACPI power system's initialization to turn off any unused power resources, even ones in an unknown state. This essentially has the effect of ensuring that all unused power resources are turned off, which is great in theory. I have recently encountered an issue on 5.13.0+ where this behavior is taking down the NVMe SSD before the driver can initialize, resulting in the following in the kernel log: acpi LNXPOWER:02: Turning OFF ... pci :02:00.0: CLS mismatch (64 != 1020), using 64 bytes ... nvme :02:00.0: can't change power state from D3hot to D0 (config space inaccessible) (See bug 214025 for a discussion about making this error message more clear) What is happening is that the LNXPOWER:02 resource is controlling the power to the PCIe port where the NVMe SSD is attached, but no other ACPI object is claiming this in power_resources_D*, and so: $ cat /sys/bus/acpi/devices/LNXPOWER:02/resource_in_use 0 This causes the acpi_turn_off_unused_power_resources() function to believe that the resource is fair game and turn off the PCIe port, between the time that the PCIe device is discovered and the time that the driver gets a chance to probe the device. I'm currently working around this by bypassing acpi_turn_off_unused_power_resources() entirely, but a proper fix will require flagging the power resource as "in use." I don't know whether this is a problem with the device's ACPI or if Linux should be claiming all LNXPOWER:* resources under each PCI bridge's firmware_node. Happy to do any additional debugging steps. -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
[Bug 213031] MEDION notebook internal keyboard not recognized / not working correctly
https://bugzilla.kernel.org/show_bug.cgi?id=213031 --- Comment #79 from Manuel Krause (manuelkra...@netscape.net) --- (In reply to beng from comment #78) > I am using the Medion notebook too. It is not such a good machine, it is > for Windows only with official support from the company. > > But it can work with Linux!! > > You must add to the kernel configuration the options > > i8042.nomux=1 i8042.reset > > This is from the article at > > https://unix.stackexchange.com/questions/28736/what-does-the-i8042-nomux-1- > kernel-option-do-during-booting-of-ubuntu > > The keyboard it works for the kernel I build from all 5.12x & 5.13x versions. What hardware are you using? E.g. post a "dmesg | grep DMI:" output, please. On my "MEDION P15651/M15T, BIOS 209 11/24/2020" your proposed kernel parameter addon doesn't have any effect. Just re-tested it without this patch @kernel v5.13.9. The models MEDION S15450/M15T and MEDION S15449/M15T are affected in the same way. We affected users stumbled about that hint you posted too, but it never worked on our hardware. I've done a comprehensive series of testing upon the available i8042 kernel parameters, no combo worked. See the attachment on top. So, we still depend on an in-kernel solution, that fits all needs. -- 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 acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
