AMD 7502P and restore a fully
functional turbostat.
model : AMD EPYC 7502P 32-Core Processor
Vendor: 23 (0x17)
Model : 49 (0x31)
Signed-off-by: Erwan Velu
---
tools/power/x86/turbostat/turbostat.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/power/x86/turbostat/turbosta
Jean, I don't see my patches in the 5.7-rc series.
Is there anything wrong with them ?
Le mar. 11 févr. 2020 à 14:31, Erwan Velu a écrit :
>
> No issue with that.
>
> Thanks for applying.
>
> Erwan,
>
> On 11/02/2020 14:21, Jean Delvare wrote:
> > On Fri, 7
virtual/dmi/id/fw_release_minor
75
[root@t1700 ~]#
Signed-off-by: Erwan Velu
---
drivers/firmware/dmi-id.c | 10 --
drivers/firmware/dmi_scan.c | 2 ++
include/linux/mod_devicetable.h | 2 ++
scripts/mod/file2alias.c| 2 ++
4 files changed, 14 insertions(+
virtual/dmi/id/bios_release_minor
27
[root@t1700 ~]#
Signed-off-by: Erwan Velu
---
drivers/firmware/dmi-id.c | 6 ++
drivers/firmware/dmi_scan.c | 2 ++
include/linux/mod_devicetable.h | 2 ++
scripts/mod/file2alias.c| 2 ++
4 files changed, 12 insertions(+)
diff -
In DMI type 0, there is several fields that encodes a release.
The dmi_save_release() function have the logic to check if the field is valid.
If so, it reports the actual value.
Signed-off-by: Erwan Velu
---
drivers/firmware/dmi_scan.c | 26 ++
1 file changed, 26
This commit is about report all registers from MSR_PLATFORM_INFO.
This helps understand the actual state of the processor.
This patch also reports the min efficiency frequency.
Signed-off-by: Erwan Velu
---
tools/power/x86/turbostat/turbostat.c | 42 +--
1 file changed
Signed-off-by: Erwan Velu
---
arch/x86/include/asm/msr-index.h | 1 +
tools/power/x86/turbostat/turbostat.c | 23 ++-
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 271d837d69a
As per Intel's documentation, those 2 registers are starting from offset 47 and
not 48.
As a result, the reported values were incorrect.
Signed-off-by: Erwan Velu
---
tools/power/x86/turbostat/turbostat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/powe
Le 01/04/2019 à 17:03, Borislav Petkov a écrit :
> From: Borislav Petkov
>
> This driver is Intel-only so loading on anything which is not Intel is
> pointless. Prevent it from doing so.
>
> While at it, correct the "not supported" print statement to say CPU
> "model" which is what that test does
> index ea62e3f02d56..19854f01e2fa 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -2608,7 +2608,9 @@ static int __init intel_pstate_init(void)
> } else {
> id = x86_match_cpu(intel_pstate_cpu_ids);
> if (!id) {
> -
Le 08/03/2019 à 11:26, Greg KH a écrit :
> On Thu, Feb 21, 2019 at 01:25:23PM +0100, Borislav Petkov wrote:
>> On Thu, Feb 21, 2019 at 12:52:30PM +0100, Greg KH wrote:
>>> I would, but I do not see this patch in Linus's tree yet :)
>> You will soon :)
> I see it now, so it's now queued up, thanks.
part of the code makes clear this is because driver received a
HARDWARE_ERROR/0x3e/0x1 which is a 'logical unit failure'.
This patch is just about reporting the reason behind the offlining to ease the
analyse.
Signed-off-by: Erwan Velu
---
drivers/scsi/smartpqi/smartpqi_init.c | 6
Le 01/03/2019 à 16:56, James Bottomley a écrit :
> [...]
> I was thinking just
>
> if (printk_ratelimit())
> scmd_printk(KERN_ERR, scmd, "received 'logical unit failure' from
> controller for scsi %d:%d:%d:%d\n", ...
>
> That will give all the necessary information
I'm pretty new to this a
Le 01/03/2019 à 16:26, James Bottomley a écrit :
> [...]
> Shouldn't this be a variant of sdev/scmd_printk? Otherwise it tells
> you what disk in the array terms is the problem but not what device in
> your actual system is affected.
Hey James,
My initial take on that was that pqi_take_device_o
[...]
> Be careful printing errors per-IO; you could get thousands of them if things
> go bad.
> The block layer print_req_error() uses printk_ratelimited(KERN_ERR) for that
> reason,
> and the SCSI layer scsi_io_completion_action() maintains a ratelimit on its
> own.
>
> The dev_err_ratelimited
part of the code makes clear this is because driver received a
HARDWARE_ERROR/0x3e/0x1 which is a 'logical unit failure'.
This patch is just about reporting the reason behind the offlining to ease the
analyse.
Signed-off-by: Erwan Velu
---
drivers/scsi/smartpqi/smartpqi_init.c | 6
Hey,
That makes me wonder why the 0x3e / 0x2 isn't handled here aka
3E/02 DZTPROMAEBKVF TIMEOUT ON LOGICAL UNIT Is it possible the
controller send to the kernel this kind of message, if so shouldn't we
handle it here ? Erwan,
Le 27/02/2019 à 17:31, Erwan Velu a écrit :
&
code makes clear this is because driver received a
HARDWARE_ERROR/0x3e/0x1 which is a 'logical unit failure'.
This patch is just about reporting that fact to help admins making a
relationship between this event and the offlining.
Signed-off-by: Erwan Velu
---
drivers/scsi/smartpqi/
I tried to put the message in a way to stay neutral, not saying if its
a real error or not.
Just reporting we were not able to find any boost cap on it.
Erwan,
Le mer. 20 févr. 2019 à 12:16, Rafael J. Wysocki a écrit :
>
> On Wed, Feb 20, 2019 at 11:52 AM Erwan Velu wrote:
> >
>
Le 20/02/2019 à 11:41, Rafael J. Wysocki a écrit :
> On Wed, Feb 20, 2019 at 11:11 AM Erwan Velu wrote:
>> There is some rare cases where CPB (and possibly IDA) are missing on
>> processors.
>> This is the case fixed by commit f7f3dc00f612 ("x86/cpu/AMD: Fix erratu
This commit is about printing a message reporting the CPU doesn't expose the
boost capabilities.
This message could help debugging platforms hit by this phenomena.
Signed-off-by: Erwan Velu
---
drivers/cpufreq/acpi-cpufreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --g
Le 14/02/2019 à 11:22, Rafael J. Wysocki a écrit :
> I've queued it up with some manual changes. No need to update.
As this could help troubleshooting platforms and as some commits like
the PSS one on Proliant servers were backported to stable, I would
surely make sense to backport it to the o
Le 14/02/2019 à 11:22, Rafael J. Wysocki a écrit :
> On Thu, Feb 14, 2019 at 10:28 AM Erwan Velu wrote:
>> Hey rafael,
>>
>> Does the V6 looks good to you ?
> I've queued it up with some manual changes. No need to update.
Ok, cool. What kind of changes ?
I'
Hey rafael,
Does the V6 looks good to you ?
Thanks,
Erwan,
Le 13/02/2019 à 13:21, Erwan Velu a écrit :
> The init code path has several exceptions where the module can decide not to
> load.
> As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is not
> reac
situation where its difficult for a user to determine,
on a given platform, why the driver didn't load properly.
This patch is about reporting to the user the reason/context of why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
Le 13/02/2019 à 11:34, Rafael J. Wysocki a écrit :
> So a single "no PCCH" message for this whole function should be sufficient.
Let's do that.
[...]
> And what did turn out to be the problem?
>
> Anyway, pr_info() should be sufficient IMO.
You should be pretty aware of 95d6c0857e54b78898274607
Le 13/02/2019 à 00:01, Rafael J. Wysocki a écrit :
[...]
> Newline characters are missing in all of your messages.
oops. Fixing this.
> "ACPI _PSS not found\n"
Done.
>> return true;
>> }
>>
>> @@ -2484,10 +2485,15 @@ static bool __init intel_pstate_no_acpi_pcch(void)
>> ac
situation where its difficult for a user to determine,
on a given platform, why the driver didn't load properly.
This patch is about reporting to the user the reason/context of why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
Le 12/02/2019 à 00:17, Srinivas Pandruvada a écrit :
> [...]
> To know if the intel_pstate in control, you can look at:
> #cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver
>
> So if it is not loaded and Intel intend to support a processor model
> with intel_pstate, then OEM's platform_po
situation where its difficult for a user to determine,
on a given platform, why the driver didn't load properly.
This patch is about reporting to the user the reason/context of why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
ts (kernel, bios, fw update).
Would you agree if I update the patch this way ?
Thx !
Erwan,
Le lun. 11 févr. 2019 à 22:25, Srinivas Pandruvada
a écrit :
>
> On Mon, 2019-02-11 at 10:31 +0100, Erwan Velu wrote:
> > The init code path have several execeptions where the module ca
situation where its difficult for a user to determine,
on a given platform, why the driver didn't loaded properly.
This patch is about reporting to the user the reason/context why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
situation where its difficult for a user to determine,
on a given platform, why the driver didn't loaded properly.
This patch is about reporting to the user the reason/context why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
situation where its difficult for a user to determine,
on a given platform, why the driver didn't loaded properly.
This patch is about reporting to the user the reason/context why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
dr
On 24/01/2014 16:51, Jens Axboe wrote:
Hi,
Just a heads-up that any email to jax...@fusionio.com does no longer
work, please use ax...@kernel.dk or ax...@fb.com going forward.
I have decided to leave Fusion-io, after about 3.5 years there. It's
been an interesting ride and I would not have been
Hi fellows,
I'm been facing some lseek() troubles on a very light hardware (Atom E660)
under heavy load (network + cpu + disk IOs). I'm using 3.2.32 on a 32bit Os
with a local SSD as mass storage.
If a do open a block device like sdb1 and lseek SEEK_SET in it, some unexpected
latencies occurs
36 matches
Mail list logo
