Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could you provide more details for reproduction on other Dells? #1

Open
csdvrx opened this issue Jun 2, 2022 · 0 comments
Open

Could you provide more details for reproduction on other Dells? #1

csdvrx opened this issue Jun 2, 2022 · 0 comments

Comments

@csdvrx
Copy link

csdvrx commented Jun 2, 2022

On older Dells I have found the exact same issues happen. The main problem seem to be the PCH not getting in SLP-S0.

Given how frequent the problem is, especially on Dells, and for how long it has existed (since at least the 7275), I believe they have misconfigured a few things from the beginning: they must have simply been copy/pasting their broken configuration since then, while remaining oblivious to the root cause of the problem.

Maybe they don't care, but I find such issues very interesting, and I happen to have a few spare Dells (identical model, CPU, Bios, NVMe...) I could use to study the situation better. If you also want to have a look, I would be happy to share a dump of the ACPI tables or even full BIOS images!

You mention "What you see below are UEFI variables for MY Dell Precision 5750, with Intel Core i7-10750h CPU, NVIDIA RTX 3000 GPU, two KIOXIA (Ex-Toshiba) KXG60ZNV1T02 drives, UEFI FW v1.7.2, etc."

Would it be possible to:

  • document your configuration in greater detail? (maybe sharing the SN by email? my email is my nickname at outlook.com)
  • upload the binary and decoded UEFI IFRs tables as they were in your UEFI FW v1.7.2 before the patch? (to better understand which resources the poke addresses represent, and what were the original values)
  • give the preparation steps? ("TBD" but that may take you a lot of time and I should be able to do with just the tables)

I plan to follow your approach on the different Dell line I have on hand, then after getting good power savings, do the equivalent of a git bisect to impute the power drain on each of the variables: for other models, this could help focus the patching on what matters the most. You could then focus on that for your TBD preparation steps :)

BTW on your README, it would be nice if you could share the power draw of a sleep session, first of a night "with" then a night "without" wake timers ("disconnected standby").

You can do that with either of:

 powercfg -setdcvalueindex scheme_current sub_none connectivityinstandby 0
 powercfg /setdcvalueindex scheme_current sub_none F15576E8-98B7-4186-B944-EAFA664402D9 0

If you then do a powercfg sleepstudy after a normal night when draining the battery in standby mode, the slope is interesting: on a 10th gen I would expect a battery drain between 1%/h to 0.5%/h.

Measurements in mW/h would be more precise but the system battery is generally sized for the CPU/GPU/display combo so a drain %/h is a good enough proxy.

Also, most people will not bother with Intel Power Gadget or VTune, while a sleepstudy is often done in routine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant