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]
Date: Sun, 12 May 2024 20:47:53 +0200
From: Armin Wolf <W_Armin@....de>
To: "Limonciello, Mario" <mario.limonciello@....com>,
 "Shen, Yijun" <Yijun.Shen@...l.com>, Lyndon Sanche <lsanche@...deno.ca>
Cc: "pali@...nel.org" <pali@...nel.org>,
 "srinivas.pandruvada@...ux.intel.com" <srinivas.pandruvada@...ux.intel.com>,
 "ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
 "lkp@...el.com" <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>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Dell Client Kernel <Dell.Client.Kernel@...l.com>
Subject: Re: [PATCH v5] platform/x86: dell-laptop: Implement platform_profile

Am 12.05.24 um 19:58 schrieb Limonciello, Mario:

>
>
> On 5/12/2024 12:53 PM, Armin Wolf wrote:
>> Am 11.05.24 um 17:56 schrieb Shen, Yijun:
>>
>>> Internal Use - Confidential
>>>> -----Original Message-----
>>>> From: Limonciello, Mario <mario.limonciello@....com>
>>>> Sent: Saturday, May 11, 2024 11:13 PM
>>>> To: Shen, Yijun <Yijun_Shen@...l.com>; Lyndon Sanche
>>>> <lsanche@...deno.ca>
>>>> Cc: pali@...nel.org; W_Armin@....de;
>>>> srinivas.pandruvada@...ux.intel.com; ilpo.jarvinen@...ux.intel.com;
>>>> 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; 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 5/11/2024 10:05 AM, Shen, Yijun wrote:
>>>>> Internal Use - Confidential
>>>>>> -----Original Message-----
>>>>>> From: Mario Limonciello <mario.limonciello@....com>
>>>>>> Sent: Wednesday, May 8, 2024 11:53 PM
>>>>>> To: Shen, Yijun <Yijun_Shen@...l.com>; Lyndon Sanche
>>>>>> <lsanche@...deno.ca>
>>>>>> Cc: pali@...nel.org; W_Armin@....de;
>>>>>> srinivas.pandruvada@...ux.intel.com; ilpo.jarvinen@...ux.intel.com;
>>>>>> 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;
>>>>>> linux-kernel@...r.kernel.org; Dell Client Kernel
>>>>>> <Dell.Client.Kernel@...l.com>
>>>>>> Subject: Re: RE: [PATCH v5] platform/x86: dell-laptop: Implement
>>>>>> platform_profile
>>>>>>
>>>>>>
>>>>>> [EXTERNAL EMAIL]
>>>>>>
>>>>>> On 5/8/2024 09:24, 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.
>>>>>>
>>>>>> Hi Alex!
>>>>>>
>>>>>> Have you had a check both on both your AMD laptops and workstations
>>>>>> too, or just the Intel ones?  I think it would be good to make sure
>>>>>> it's getting the correct experience in both cases.
>>>>>>
>>>>> Hi Mario,
>>>>>
>>>>>    I've a check for this, for both laptop and workstation, the
>>>>> dell_laptop
>>>> module will not be loaded. So, AMD platform will not be impacted by
>>>> this
>>>> patch series.
>>>>> Follow is one example output with workstation.
>>>>>    #lsmod | grep dell
>>>>>      dell_wmi               28672  0
>>>>>      dell_smbios            32768  1 dell_wmi
>>>>>      dcdbas                 20480  1 dell_smbios
>>>>>      dell_wmi_descriptor    20480  2 dell_wmi,dell_smbios
>>>>>      sparse_keymap          12288  1 dell_wmi
>>>>>      ledtrig_audio          12288  3
>>>>> snd_ctl_led,snd_hda_codec_generic,dell_wmi
>>>>>      video                  73728  2 dell_wmi,nvidia_modeset
>>>>>      wmi                    40960  5
>>>> video,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>> Ah; right that makes sense.  In that case, is dell-laptop even the
>>>> right place for
>>>> this patch series?  I would think the same policies for the
>>>> platform profile
>>>> should be able to apply to desktop/workstation.
>>>>
>>>> The v6 of this series would block smbios-thermal-ctl from working on a
>>>> workstation too.
>>>>
>>>>>>>      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".
>>>>>> I agree, this sounds like the initial profile needs to be read from
>>>>>> the BIOS settings too.
>>>>>>
>>>>>> Furthermore I wanted to ask is there also a WMI setting that
>>>>>> corresponds to this that dell-wmi-sysman offers?
>>>>>    Yes, Mario, you're right. This thermal setting could also be
>>>>> toggled by dell-
>>>> wmi-sysman.
>>>>> But, for the Dell consumer AMD laptops, like Alienware, the BIOS
>>>>> is another
>>>> variant which is different with the workstation one.
>>>>> With this variant BIOS, there is no USTT and also no
>>>>> dell_wmi/dell-wmi-
>>>> sysman.
>>>>>> I'm wondering if both should be probed in case the SMBIOS one goes
>>>> away one day.
>>>>>    Yep, I think this is a good suggestion.
>>>>>
>>>> Great! Although something I wonder is if the policy when changed
>>>> with dell-
>>>> wmi-sysman is immediate or requires a reboot.  A lot of the
>>>> settings in there
>>>> aren't effective until after a reboot.
>>>>
>>>> If this is one of them then it might not be a good idea to make it
>>>> work for
>>>> both.
>>> Hi Mario,
>>>
>>>   Just have a check, the check steps are:
>>> 1. stop the thermald
>>> 2. run the stress test
>>> 3. Toggle the thermal setting between UltraPerformance and Quiet via
>>> dell-wmi-sysman
>>> 4. Check the CPU FAN speed
>>>   The system reboot is not needed, the CPU fan speed changes
>>> immediately.
>>>   A screen recorder here:
>>> https://dell.box.com/s/p2bhd2b6cv8z5buk9eao3bosgrrp1lf9
>>>
>>> Thanks
>>>
>> Hi,
>>
>> i believe it should be the responsibility of the manufacturer (in
>> this case Dell) that
>> the thermal state remains consistent across both interfaces.
>>
>> I think that the official Windows utility only checks the thermal
>> state reported by
>> the USTT interface, so we should match this behavior.
>>
>> Thanks,
>> Armin Wolf
>>
>
> Why?  Windows also does ACPI-WMI differently than Linux.  It's not as
> easy to check both from a Windows utility due to that.

Actually, it is quite easy to check both interfaces from a Windows utility Both ACPI-WMI objects can be accessed by
Windows applications, the utility just has to interact with an additional WMI object, but they decided to not do it.

Also the original smbios-thermal-ctl utility was created by Dell itself (i think?), so they likely would have implemented this
if it really was necessary.

As Dell likely only tests their machines with Windows (if at all), i propose that we try to match the Windows behavior.

Thanks,
Armin Wolf


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ