https://bugzilla.kernel.org/show_bug.cgi?id=221866
--- Comment #17 from David Del Sol ([email protected]) --- Quick update on the acpidump and the _DSM theory: 1) The acpidump was not corrupted - the uploaded acpidump.dat.gz is byte-identical to the local file (md5 verified) and passes gzip integrity. Uploaded it again as plain text (attachment 310632, "raw stdout output") in the format you asked for. 2) Regarding a Windows-specific _DSM gate: the controlled tests rule it out. The OS environment is bit-identical between the two cases - same kernel, same config, nothing differs except the hardware power-on state: - after a 30s power-button EC reset, a cold power-on WITH the adapter connected: ~0.2-2.5 W (bug reproduces) - after that same reset, a cold power-on WITHOUT the adapter, plugging it in after the OS is running: sustained 31.7 W No driver or ACPI call differs between the two; the EC's charging mode is decided at EC power-on from AC presence and does not respond to any runtime OSI/_DSM interaction (mid-session re-plug from the slow state gives only a transient spike). 3) New data point from today: once fast, the state survives even a FULL shutdown + power-on with the adapter connected (28.0-28.4 W sustained) - so it persists across power cycles and only the 30s hard EC reset returns it to slow. That also explains why every clean Linux install showed the bug: all installs ran from the factory-default (slow) EC state, and nothing during an install changes the latch. So this is EC firmware behavior determined at power-on, with no OS involvement. Happy to provide any further dumps or a _DSM trace if useful, but the OSI/_DSM angle looks closed to me. I've withdrawn the kernel patch and retitled this report accordingly. -- 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
