: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")
Signed-off-by: David Arcari
Cc: Naveen Krishna Chatradhi
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
drivers/hwmon/amd_energy.c | 3 ++-
1 file changed, 2
Hi Len,
Thanks for the quick turn around. My apologies for not checking the tree before
sending a follow-up email.
If you decide you prefer to change intel_idle - I'd be happy to do the work if
you'd like. Just let me know.
Thanks,
-Dave
On 8/21/20 2:23 PM, Len Brown wrote:
Hi
Hi,
Just want to make sure that this doesn't get lost.
Please let me know if you feel there is a better approach.
Thanks,
-Dave
On 8/10/20 10:43 AM, David Arcari wrote:
turbostat formatting is broken with ACPI CST for enumeration. The
problem is that the CX_ACPI% is eight characters long
turbostat formatting is broken with ACPI CST for enumeration. The
problem is that the CX_ACPI% is eight characters long which does not
work with tab formatting. One simple solution is to remove the underbar
from the state name such that C1_ACPI will be displayed as C1ACPI.
Signed-off-by: David
Make pcc_cpufreq_init() return error codes when the driver cannot be
registered. Otherwise the driver can shows up loaded via lsmod even
though it failed initialization. This is confusing to the user.
Signed-off-by: David Arcari
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
---
drive
ping -- just want to make sure this doesn't get lost.
Thanks!
On 02/12/2019 09:34 AM, David Arcari wrote:
> turbostat failed to return a non-zero exit status even though the
> supplied command (turbostat ) failed. Currently when turbostat
> forks a command it returns zer
turbostat failed to return a non-zero exit status even though the
supplied command (turbostat ) failed. Currently when turbostat
forks a command it returns zero instead of the actual exit status of the
command. Modify the code to return the exit status.
Signed-off-by: David Arcari
Cc: Len
kernel, would see
an unhandled error in the APEI generic error status block and
panic again, thereby precluding any crash dump.
Signed-off-by: Lenny Szubowicz
Signed-off-by: David Arcari
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Tony Luck
Cc: Borislav Petkov
Cc: "Eric W. Biederman"
Cc:
Hi,
Can someone help me interpret this email? I was expecting this to be about a
dmesg change which is expected, but the content doesn't seem to indicate that.
For the record, the commit shouldn't really introduce any functional changes.
It merely avoids calling kcalloc with count==-EINVAL.
Hi,
Can someone help me interpret this email? I was expecting this to be about a
dmesg change which is expected, but the content doesn't seem to indicate that.
For the record, the commit shouldn't really introduce any functional changes.
It merely avoids calling kcalloc with count==-EINVAL.
: 8f8027c5f935 ("mailbox: PCC: erroneous error message when parsing ACPI
PCCT")
Signed-off-by: David Arcari
Cc: Al Stone
Cc: Jassi Brar
---
drivers/mailbox/pcc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 311e91
: 8f8027c5f935 ("mailbox: PCC: erroneous error message when parsing ACPI
PCCT")
Signed-off-by: David Arcari
Cc: Al Stone
Cc: Jassi Brar
---
drivers/mailbox/pcc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 311e91
On 06/12/2018 12:56 PM, Peter Zijlstra wrote:
>
>> Ultimately, my solution was to restore the previous behavior by reading and
>> storing the firmware setting of the bit rather than to always clear it.
>
> Ah, urgh.. what a mess. So the OS setting the bit to a known and
> consistent value is
On 06/12/2018 12:56 PM, Peter Zijlstra wrote:
>
>> Ultimately, my solution was to restore the previous behavior by reading and
>> storing the firmware setting of the bit rather than to always clear it.
>
> Ah, urgh.. what a mess. So the OS setting the bit to a known and
> consistent value is
On 06/04/2018 10:12 AM, David Arcari wrote:
> On 06/04/2018 04:24 AM, Peter Zijlstra wrote:
>> On Sun, Jun 03, 2018 at 02:23:43PM -0400, David Arcari wrote:
>>> On some systems pressing the external NMI button is now failing to inject
>>> an NMI 5-10% of the time. This
On 06/04/2018 10:12 AM, David Arcari wrote:
> On 06/04/2018 04:24 AM, Peter Zijlstra wrote:
>> On Sun, Jun 03, 2018 at 02:23:43PM -0400, David Arcari wrote:
>>> On some systems pressing the external NMI button is now failing to inject
>>> an NMI 5-10% of the time. This
On 06/04/2018 04:24 AM, Peter Zijlstra wrote:
> On Sun, Jun 03, 2018 at 02:23:43PM -0400, David Arcari wrote:
>> On some systems pressing the external NMI button is now failing to inject
>> an NMI 5-10% of the time. This causes confusion for a user that expects
>> the N
On 06/04/2018 04:24 AM, Peter Zijlstra wrote:
> On Sun, Jun 03, 2018 at 02:23:43PM -0400, David Arcari wrote:
>> On some systems pressing the external NMI button is now failing to inject
>> an NMI 5-10% of the time. This causes confusion for a user that expects
>> the N
e can be resolved by storing the default firmware
setting of FREEZE_WHILE_SMM before initializing the PMU.
Fixes: 6089327f5424 ("perf/x86: Add sysfs entry to freeze counters on SMI")
Signed-off-by: David Arcari
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@ke
e can be resolved by storing the default firmware
setting of FREEZE_WHILE_SMM before initializing the PMU.
Fixes: 6089327f5424 ("perf/x86: Add sysfs entry to freeze counters on SMI")
Signed-off-by: David Arcari
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@ke
20 matches
Mail list logo
