Borislav Petkov writes:
> On Mon, Dec 14, 2020 at 10:27:09PM +0900, Punit Agrawal wrote:
>> IIUC, this suggests that Linux booting on anything prior to Zen3 is down
>> to pure luck - I hope that wasn't the case.
>
> WTF does this have to do with linux booting?!
I guess I misunderstood the
On Mon, Dec 14, 2020 at 10:27:09PM +0900, Punit Agrawal wrote:
> IIUC, this suggests that Linux booting on anything prior to Zen3 is down
> to pure luck - I hope that wasn't the case.
WTF does this have to do with linux booting?!
> At the moment acpi thermals is bust on this and other affected
Borislav Petkov writes:
> On Sat, Dec 12, 2020 at 08:36:48AM +0900, Punit Agrawal wrote:
>> To me it suggests, that there are likely more systems from the family
>> that show the characteristic described below.
>
> Until we find a *single* system with a broken BIOS which has those
> objects
On Sat, Dec 12, 2020 at 08:36:48AM +0900, Punit Agrawal wrote:
> To me it suggests, that there are likely more systems from the family
> that show the characteristic described below.
Until we find a *single* system with a broken BIOS which has those
objects kaputt and then this heuristic would
Borislav Petkov writes:
> On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
>> According to the commit log, acd316248205 seems to be only targeted at
>> powernow-K8 -
>
> No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
> on AMD hw. He means to make
On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
> According to the commit log, acd316248205 seems to be only targeted at
> powernow-K8 -
No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
on AMD hw. He means to make acpi-cpufreq's behavior consistent with
Borislav Petkov writes:
> On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
>> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
>> there are two approaches:
>>
>> * Keep override_acpi_psd()
>> Let us keep the original quirk and override_acpi_psd() function. Over
>>
On 12/7/20 4:30 PM, Borislav Petkov wrote:
> On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
>> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
>> there are two approaches:
>>
>> * Keep override_acpi_psd()
>> Let us keep the original quirk and
On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
> there are two approaches:
>
> * Keep override_acpi_psd()
> Let us keep the original quirk and override_acpi_psd() function. Over
> the time, people may want to add
On 12/7/20 2:26 PM, Borislav Petkov wrote:
> On Mon, Dec 07, 2020 at 02:20:55PM -0600, Wei Huang wrote:
>> In summary, this patch is fine if Punit already verified it. My only
>> concern is the list can potentially increase over the time, and we will
>> keep coming back to fix
On Mon, Dec 07, 2020 at 02:20:55PM -0600, Wei Huang wrote:
> In summary, this patch is fine if Punit already verified it. My only
> concern is the list can potentially increase over the time, and we will
> keep coming back to fix override_acpi_psd() function.
Can the detection be done by looking
On 11/25/20 8:48 AM, Punit Agrawal wrote:
> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
> stepping: 0x1) shows the following message in the logs -
>
> acpi_cpufreq: overriding BIOS provided _PSD data
>
> Although commit 5368512abe08 ("acpi-cpufreq: Honor _PSD table
Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
stepping: 0x1) shows the following message in the logs -
acpi_cpufreq: overriding BIOS provided _PSD data
Although commit 5368512abe08 ("acpi-cpufreq: Honor _PSD table setting
on new AMD CPUs") indicates that the override is
13 matches
Mail list logo
