lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: 
 <BY5PR19MB39223A0977CE393BA6833DB29AE02@BY5PR19MB3922.namprd19.prod.outlook.com>
Date: Sat, 11 May 2024 15:22:23 +0000
From: "Shen, Yijun" <Yijun.Shen@...l.com>
To: Lyndon Sanche <lsanche@...deno.ca>
CC: Mario Limonciello <mario.limonciello@....com>,
        Pali Rohár <pali@...nel.org>,
        Armin Wolf
	<W_Armin@....de>,
        "srinivas.pandruvada@...ux.intel.com"
	<srinivas.pandruvada@...ux.intel.com>,
        Ilpo Järvinen
	<ilpo.jarvinen@...ux.intel.com>,
        kernel test robot <lkp@...el.com>,
        Hans de
 Goede <hdegoede@...hat.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Jonathan
 Corbet <corbet@....net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Vegard
 Nossum <vegard.nossum@...cle.com>,
        "platform-driver-x86@...r.kernel.org"
	<platform-driver-x86@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dell Client Kernel <Dell.Client.Kernel@...l.com>
Subject: RE: [PATCH v5] platform/x86: dell-laptop: Implement platform_profile




Internal Use - Confidential
> -----Original Message-----
> From: Lyndon Sanche <lsanche@...deno.ca>
> Sent: Saturday, May 11, 2024 9:49 AM
> To: Shen, Yijun <Yijun_Shen@...l.com>
> Cc: Mario Limonciello <mario.limonciello@....com>; Pali Rohár
> <pali@...nel.org>; Armin Wolf <W_Armin@....de>;
> srinivas.pandruvada@...ux.intel.com; Ilpo Järvinen
> <ilpo.jarvinen@...ux.intel.com>; kernel test robot <lkp@...el.com>; Hans de
> Goede <hdegoede@...hat.com>; Matthew Garrett <mjg59@...f.ucam.org>;
> Jonathan Corbet <corbet@....net>; Heiner Kallweit
> <hkallweit1@...il.com>; Vegard Nossum <vegard.nossum@...cle.com>;
> platform-driver-x86@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>;
> Dell Client Kernel <Dell.Client.Kernel@...l.com>
> Subject: Re: [PATCH v5] platform/x86: dell-laptop: Implement platform_profile
>
>
> [EXTERNAL EMAIL]
>
>
>
> On Thu, May 9 2024 at 09:10:51 AM -06:00:00, Lyndon Sanche
> <lsanche@...deno.ca> wrote:
> > On Wed, May 8, 2024, at 8:24 AM, Shen, Yijun wrote:
> >>  Hi Lyndon,
> >>
> >>   Thanks for working on this patch.
> >>
> >>
> >>   Dell side has an initial testing with this patch on some laptops,
> >> it  looks good. While changing the platform profile:
> >>  1. The corresponding USTT option in BIOS will be changed.
> >>  2. thermald will not be impacted. The related PSVT and ITMT will be
> >> loaded.
> >>   Some Dell DTs does not have the USTT, Dell'll have a check if
> >> nothing  is broken.
> >>
> >>    Additional, with this patch, follow behavior is found:
> >>   1. For example, the platform profile is quiet.
> >>   2. Reboot the system and change the USTT to performance.
> >>   3. Boot to desktop, the platform profile is "quiet", the USTT will
> >> be  changed back to "quiet".
> >>   This looks like not a proper user experience. The platform profile
> >> should honor the BIOS setting, aka, the platform profile should be
> >> switched to "performance".
> >
> > Hello:
> >
> > Thank you for your email. This is definitely undesirable behaviour, I
> > will have a look at the code to see why this is happening. Does it
> > always revert to quiet on boot, or always the mode that you had
> > switched to prior to reboot?
> >
> > Do you happen to have power-profiles-daemon or something similar
> > running? My understanding is it remembers profiles across reboots,
> > this could potentially also revert the profile back to what it was.
> > See this release for details:
> > https://urldefense.com/v3/__https://gitlab.freedesktop.org/upower/powe
> > r-profiles-daemon/-/releases/0.9.0__;!!LpKI!jUAEHb-9foumkcmPlEKD6tnQrZ
> > sqjB1sXdPDsYvH2fJ-gPV6G35MUtDW4q3xhlJ4IeLcIgmVpb3ztXqaOg8$
> > [gitlab[.]freedesktop[.]org]
> >
> > I will assume there is a bug in my code at this point. I will test
> > with and without ppd running on my system to see if it changes across
> > reboots.
> >
> > Are USTT settings exposed in your BIOS configuration menu? On my
> > laptop they are not and I have to use smbios-thermal-ctl.
> >
> > Thank you,
> >
> > Lyndon
>
> Hi Yijun:
>
> I tested this on my computer (XPS 9560). I do not have access to the USTT
> settings in the BIOS screen so to substitute that, I booted without the patch
> and set the USTT manually using smbios-thermal-ctl.
> Here are my findings:
>
> Scenario #1: Without power-profiles-daemon (ppd) running
>
> 1. Boot with patch, set platform_profile to quiet 2. Boot without patch applied
> (no platform_profile)
>  - smbios-thermal-ctl confirms USTT is set to quiet
>  - use smbios-thermal-ctl to set USTT to performance
>  - confirm set to performance
> 3. Boot with patch again
>  - platform_profile is set to performance
>
> Scenario #2: With ppd running
> 1. Boot with patch, set platform_profile to performance with ppd
>  - Confirm platform_profile is performance 2. Boot without patch applied (no
> platform_profile)
>  - smbios-thermal-ctl confirms USTT is set to performance
>  - ppd reverts to balanced (only controlling intel_pstate in this case)
>  - use smbios-thermal-ctl to set USTT to quiet
>  - confirm set to quiet
> 3. Boot with patch again
>  - platform_profile and ppd is set to performance
>
> In my case, the setting in the smbios is honored if it was switched with
> another method. When using a userspace program that manipulates the
> platform_profile, the program seems to remember the previous state and
> switch to that.
>
> So I do not think there is a bug in this patch related to this issue, at least in my
> case. Please let me know if you have any questions.
>
> Thanks,
>
> Lyndon
>
>
>
Hi Lyndon,

 I've made a video recorder of the issue: https://dell.box.com/s/3f3znz1z8c6htbcll9juj6tyyu0zvvut
 My test environment is that I freshly installed the Fedora 40 and will not do any online updates. Then install the kernel with the v5 patch applied.

 XPS 9560 is a pretty old system which is RTS with 2017. No USTT setting in the BIOS is expected.
 I've a check that the Dell system, at least shipped from 2022, the USTT setting will be valid in the BIOS. The system used in above link, it is Latitude 7350 which is shipped by 2024 April.

 I think the key point to duplicate of this issue that, the USTT needs to be changed under BIOS but not under the Linux OS.

Thanks



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ