https://bugzilla.kernel.org/show_bug.cgi?id=221866
--- Comment #19 from David Del Sol ([email protected]) --- Important update: the slow-charge bug no longer reproduces on the current kernel, and I can now show it was never OSI-related. Kernel linux-cachyos was auto-updated 7.1.6 -> 7.1.8 in the middle of my test series today, which is the key variable: - 7.1.6, after 30s EC reset, stock cmdline, AC present at power-on: ~0.2-2.5 W (bug reproduces) - 7.1.8, same 30s EC reset procedure (identical - the hold also resets the BIOS in all cases, verified), stock cmdline, AC present at power-on: charges normally (~20 W, high-SoC taper; battery 85-88%) - 7.1.8, same reset, workaround cmdline: 28.8 W at 79% All three 30s holds behaved identically (including the BIOS reset / re-enabling Secure Boot), so the BIOS state was constant - the only variable that changed between the 2.5 W and normal-charging results is the kernel release. Consistent with this, the OSI claim machinery observably changed between the two kernels (requesting _OSI("Windows 2022") logs an Add on 7.1.8, which it never did on 7.1.6 - default list and/or logging behavior). Upstream 7.1.6->7.1.8 contains no battery/EC/charging commits visible in the changelog (only max17040/macsmc/bq25890, none relevant here), so the exact mechanism is still unidentified - I'll dig into the CachyOS fork patches. The acpi_osi workaround was a correlation artifact on 7.1.6 (Linux default-claimed the string; no firmware code checks it). Withdrawing the patch stands; this report documents a firmware-level slow-charge state that kernels <=7.1.6 failed to clear and 7.1.8 handles correctly. -- 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
