Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

[Calvin Walton]

On Tue, 2021-04-20 at 22:37 +0800, Chen Yu wrote:
> On Tue, Apr 20, 2021 at 09:28:06AM -0400, Calvin Walton wrote:
> > This patch has the same issue I noticed with the initial revision
> > of
> > Terry's patch - the idx_to_offset function returns type int (32-bit
> > signed), but MSR_PKG_ENERGY_STAT is greater than INT_MAX (or
> > rather,
> > would be interpreted as a negative number)
> > 
> > The end result is, as far as I can tell, that it hits the if
> > (offset <
> > 0) check in update_msr_sum() resulting in the timer callback for
> > updating the stat in the background when long durations are used to
> > not
> > happen.
> > 
> > For short durations it still works fine since the background update
> > isn't used.
> > 
> Ah, got it, nice catch. How about an incremental patch based on Bas'
> one
> to fix this 'overflow' issue? Would converting offset_to_idx(),
> idx_to_offset() and
> update_msr_sum() to use off_t instead of int be enough? Do you or
> Terry have interest
> to cook that patch? For Terry's version, I'm not sure if spliting
> the code into different CPU vendor would benefit in the future,
> except
> that we would have plenty of new MSRs to be introduced in the future.

Yes, I believe updating the offset_to_idx(), idx_to_offset(), and
update_msr_sum() functions is sufficient. I can do the incremental
patch for that this evening if nobody beats me to it :)

-- 
Calvin Walton 

Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

[Calvin Walton]

On Mon, 2021-04-19 at 14:58 -0500, Terry Bowman wrote:
> Turbostat fails to correctly collect and display RAPL summary
> information
> on Family 17h and 19h AMD processors. Running turbostat on these
> processors
> returns immediately. If turbostat is working correctly then RAPL
> summary
> data is displayed until the user provided command completes. If a
> command
> is not provided by the user then turbostat is designed to
> continuously
> display RAPL information until interrupted.
> 
> The issue is due to offset_to_idx() and idx_to_offset() missing
> support for
> AMD MSR addresses/offsets. offset_to_idx()'s switch statement is
> missing
> cases for AMD MSRs and idx_to_offset() does not include a path to
> return
> AMD MSR(s) for any idx.

Ah, when I was looking at Boris's patch, it lead me to one more spot
that was missed with the off_t type - inside the function
update_msr_sum(), the offset is also stored in a variable of type int,
and as a result the background update for AMD's MSR when turbostat is
used with long durations won't work. (It's skipped because of the
offset < 0 check).

-- 
Calvin Walton 

Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

[Calvin Walton]

On Tue, 2021-04-20 at 21:15 +0800, Chen Yu wrote:
> 
> Okay. I would vote for the the patch from Bas as it was a combined
> work from two
> authors and tested by several AMD users. But let me paste it here too
> for Artem to
> see if this also works for him:
> 
> 
> From 00e0622b1b693a5c7dc343aeb3aa51614a9e125e Mon Sep 17 00:00:00
> 2001
> From: Bas Nieuwenhuizen 
> Date: Fri, 12 Mar 2021 21:27:40 +0800
> Subject: [PATCH] tools/power/turbostat: Fix turbostat for AMD Zen
> CPUs
> 
> 
> @@ -297,7 +297,10 @@ int idx_to_offset(int idx)
>  
> switch (idx) {
> case IDX_PKG_ENERGY:
> -   offset = MSR_PKG_ENERGY_STATUS;
> +   if (do_rapl & RAPL_AMD_F17H)
> +   offset = MSR_PKG_ENERGY_STAT;
> +   else
> +   offset = MSR_PKG_ENERGY_STATUS;
> break;
> case IDX_DRAM_ENERGY:
> offset = MSR_DRAM_ENERGY_STATUS;

This patch has the same issue I noticed with the initial revision of
Terry's patch - the idx_to_offset function returns type int (32-bit
signed), but MSR_PKG_ENERGY_STAT is greater than INT_MAX (or rather,
would be interpreted as a negative number)

The end result is, as far as I can tell, that it hits the if (offset <
0) check in update_msr_sum() resulting in the timer callback for
updating the stat in the background when long durations are used to not
happen.

For short durations it still works fine since the background update
isn't used.


-- 
Calvin Walton 

Re: [PATCH v2] tools/power turbostat: Fix RAPL summary collection on AMD processors

[calvin . walton]

On Mon, 2021-04-19 at 14:58 -0500, Terry Bowman wrote:

@@ -3281,7 +3326,7 @@ static int update_msr_sum(struct thread_data *t, struct 
core_data *c, struct pkg
continue;
ret = get_msr(cpu, offset, _cur);
if (ret) {
-   fprintf(outf, "Can not update msr(0x%x)\n", offset);
+   fprintf(outf, "Can not update msr(0x%lx)\n", offset);

This gives a warning when compiled on 32-bit, since turbostat is
compiled with -D_FILE_OFFSET_BITS=64:

turbostat.c: In function 'update_msr_sum':
turbostat.c:3329:42: warning: format '%lx' expects argument of type
'long unsigned int', but argument 3 has type 'off_t' {aka 'long long
int'} [-Wformat=]
 3329 |fprintf(outf, "Can not update msr(0x%lx)\n", offset);
  |~~^  ~~
  |  |  |
  |  |  off_t {aka long long 
int}
  |  long unsigned int
  |%llx

Easiest fix is probably to cast to (long long int) and use the %llx
format specifier. That should be valid with i686, x32, and amd64
userspace.

Everything else looks fine as far as I can tell, so feel free to add a

Reviewed-by: Calvin Walton 

once you've fixed that warning.


-- 
 

Re: [PATCH v4] tools/power turbostat: Fix RAPL summary collection on AMD processors

[Calvin Walton]

On Fri, 2021-04-16 at 06:42 -0500, Terry Bowman wrote:
> 
> Hi Calvin,
> 
> Thanks for the feedback. I'll begin making the change and testing.
> I'll 
> respond with V2 patch in this thread.
> 
> Regards,
> Terry

It looks like there might already be a patch in the pipeline for this
issue; see Chen Yu's response to my patch here:
https://lkml.org/lkml/2021/4/14/1322
I'm hoping we get some clarification of the status soon.

While you're respinning your patch, there's one other issue that I
noticed - all the idx/offset-related functions pass the offset value in
a variable of type "int" (32bit signed integer), but the offset of the
AMD MSR_CORE_ENERGY_STAT MSR is 0xC001029A, which exceeds INT_MAX. The
offsets should all use "off_t" to get a 64bit type and avoid wrapping
or sign extension issues.

-- 
Calvin Walton 

Re: [PATCH] Fix turbostat exiting with an error when run on AMD CPUs

[Calvin Walton]

On Thu, 2021-04-15 at 10:26 +0800, Chen Yu wrote:
> Hi Calvin,
> On Wed, Apr 14, 2021 at 10:08:07PM -0400, Calvin Walton wrote:
> > On Wed, 2021-04-14 at 22:05 -0400, Calvin Walton wrote:
> > > The current version of turbostat exits immediately upon entering
> > > the
> > > main loop, with error code -13. This is a regression that was
> > > introducted
> > > in these commits:
> > > 
> > > 9972d5d84d76 tools/power turbostat: Enable accumulate RAPL
> > > display
> > > 87e15da95775 tools/power turbostat: Introduce functions to
> > > accumulate
> > > RAPL consumption
> > 
> > Ah, I failed to check the mailing list before sending this patch!
> > Terry
> > Bowman's fix here should probably be preferred:
> > https://patchwork.kernel.org/project/linux-pm/patch/20210331155807.3838-1-terry.bow...@amd.com/
> > 
> > My patch was simply the minimum necessary to get turbostat working
> > again.
> Thanks for reporting this. We had a fix for this previously at
> https://lkml.org/lkml/2021/3/12/682
> 
> I'll check with Len if this patch has been merged.

Thanks for checking.

I notice that the linked patch doesn't include the other part of the
fix - correcting the type used for the MSR offsets to off_t (the AMD
MSRs at 0xc0010299 exceed the range of a signed 32-bit int), so if that
patch is in the queue to be merged, I can submit the off_t patch
separately.

-- 
Calvin Walton 

Re: [PATCH v4] tools/power turbostat: Fix RAPL summary collection on AMD processors

[Calvin Walton]

On Tue, 2021-03-30 at 21:38 +, Terry Bowman wrote:
> 
> +int idx_valid_amd(int idx)
> +{
> +   switch (idx) {
> +   case IDX_PKG_ENERGY:
> +   return do_rapl & MSR_PKG_ENERGY_STAT;

This isn't correct - MSR_PKG_ENERGY_STAT is the MSR offset, not a bit
mask for the do_rapl bit field.

The presence of MSR_PKG_ENERGY_STAT (along with MSR_RAPL_PWR_UNIT and
MSR_CORE_ENERGY_STAT) is indicated by the RAPL_AMD_F17H bit in do_rapl,
and can be checked with:
do_rapl & RAPL_AMD_F17H


-- 
Calvin Walton 

Re: [PATCH] Fix turbostat exiting with an error when run on AMD CPUs

[Calvin Walton]

On Wed, 2021-04-14 at 22:05 -0400, Calvin Walton wrote:
> The current version of turbostat exits immediately upon entering the
> main loop, with error code -13. This is a regression that was
> introducted
> in these commits:
> 
> 9972d5d84d76 tools/power turbostat: Enable accumulate RAPL display
> 87e15da95775 tools/power turbostat: Introduce functions to accumulate
> RAPL consumption

Ah, I failed to check the mailing list before sending this patch! Terry
Bowman's fix here should probably be preferred:
https://patchwork.kernel.org/project/linux-pm/patch/20210331155807.3838-1-terry.bow...@amd.com/

My patch was simply the minimum necessary to get turbostat working
again.
-- 
Calvin Walton 

[PATCH] Fix turbostat exiting with an error when run on AMD CPUs

[Calvin Walton]

The current version of turbostat exits immediately upon entering the
main loop, with error code -13. This is a regression that was introducted
in these commits:

9972d5d84d76 tools/power turbostat: Enable accumulate RAPL display
87e15da95775 tools/power turbostat: Introduce functions to accumulate RAPL 
consumption

Which introduced a method to accumulate MSR values over long sampling
durations.

The commits failed to account for the fact that AMD CPUs use a different
(but confusingly similarly named) MSR for reading the package energy.
I've added the AMD version of the MSR to the methods so that turbostat
can be run again.

(If you run on a system with mixed Intel and AMD cpus, you might have
problems, but I have been assured that this isn't likely in practice.)

The MSR offsets in the conversion functions have been switched to use
type off_t, since the offsets of the AMD MSRs exceed the range of a
signed 32-bit int.

Note that since the framework introduced only handles per-cpu MSRs but not
per-core MSRs, AMD "Core" energy is not currently accumulated over long
sampling periods.

Fixes: 9972d5d84d76982606806b2ce887f70c2f8ba60a
Signed-off-by: Calvin Walton 
---
 tools/power/x86/turbostat/turbostat.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index a7c4f0772e53..576e03d373c4 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -291,13 +291,16 @@ struct msr_sum_array {
 /* The percpu MSR sum array.*/
 struct msr_sum_array *per_cpu_msr_sum;
 
-int idx_to_offset(int idx)
+off_t idx_to_offset(int idx)
 {
-   int offset;
+   off_t offset;
 
switch (idx) {
case IDX_PKG_ENERGY:
-   offset = MSR_PKG_ENERGY_STATUS;
+   if (do_rapl & RAPL_AMD_F17H)
+   offset = MSR_PKG_ENERGY_STAT;
+   else
+   offset = MSR_PKG_ENERGY_STATUS;
break;
case IDX_DRAM_ENERGY:
offset = MSR_DRAM_ENERGY_STATUS;
@@ -320,11 +323,12 @@ int idx_to_offset(int idx)
return offset;
 }
 
-int offset_to_idx(int offset)
+int offset_to_idx(off_t offset)
 {
int idx;
 
switch (offset) {
+   case MSR_PKG_ENERGY_STAT:
case MSR_PKG_ENERGY_STATUS:
idx = IDX_PKG_ENERGY;
break;
@@ -353,7 +357,7 @@ int idx_valid(int idx)
 {
switch (idx) {
case IDX_PKG_ENERGY:
-   return do_rapl & RAPL_PKG;
+   return do_rapl & (RAPL_PKG | RAPL_AMD_F17H);
case IDX_DRAM_ENERGY:
return do_rapl & RAPL_DRAM;
case IDX_PP0_ENERGY:
-- 
2.31.1

Re: [RFC PATCH] tools/power turbostat: Fix caller parameter of get_tdp_amd()

[Calvin Walton]

On Fri, 2019-08-30 at 17:22 +0800, Pu Wen wrote:
> Commit 9392bd98bba760be96ee ("tools/power turbostat: Add support for
> AMD
> Fam 17h (Zen) RAPL") add a function get_tdp_amd(), the parameter is
> CPU
> family. But the rapl_probe_amd() function use wrong model parameter.
> Fix the wrong caller parameter of get_tdp_amd() to use family.

Whoops, good catch. Before, this code was only working because the
switch statement in get_tdp_amd() has a default case.

That said, this patch is effectively a no-op, since the get_tdp_amd()
function returns the value "250" no matter what argument is passed. The
only reason the function exists in the first place is that I thought
there might be a way to read the configured TDP from the CPU, but I
couldn't find any documentation on how to do that at the time.

Reviewed-by: Calvin Walton 

-- 
Calvin Walton 

Re: [RFC PATCH] tools/power turbostat: Add support for Hygon Fam 18h (Dhyana) RAPL

[Calvin Walton]

On Fri, 2019-08-30 at 17:23 +0800, Pu Wen wrote:
> Commit 9392bd98bba760be96ee ("tools/power turbostat: Add support for
> AMD
> Fam 17h (Zen) RAPL") and the commit 3316f99a9f1b68c578c5
> ("tools/power
> turbostat: Also read package power on AMD F17h (Zen)") add AMD Fam
> 17h
> RAPL support.
> 
> Hygon Family 18h(Dhyana) support RAPL in bit 14 of CPUID 0x8007
> EDX,
> and has MSRs RAPL_PWR_UNIT/CORE_ENERGY_STAT/PKG_ENERGY_STAT. So add
> Hygon
> Dhyana Family 18h support for RAPL.
> 
> Already tested on Hygon multi-node systems and it shows correct per-
> core
> energy usage and the total package power.

I was a bit worried about these two chunks, since as far as I know AMD
has not yet released any processor with family 0x18, so there might be
future conflicts:

> @@ -3803,6 +3804,7 @@ double get_tdp_amd(unsigned int family)
>  {
>   switch (family) {
>   case 0x17:
> + case 0x18:
>   default:
> 

> @@ -3982,6 +3984,7 @@ void rapl_probe_amd(unsigned int family,
> unsigned int model)
>  
>   switch (family) {
>   case 0x17: /* Zen, Zen+ */
> + case 0x18:
>   do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
>   if (rapl_joules) {
>   BIC_PRESENT(BIC_Pkg_J);

But the second switch is already guarded by the CPUID check for the
rapl support, so it will either "just work" if AMD's family 0x18 chip
uses the same RAPL registers - or cleanly skip the CPU if they changed
it.

Please add a comment on the 0x18 case in the rapl_probe_amd function,
something like:
case 0x18: /* Hygon Dhyana */

Feel free to add a
Reviewed-by: Calvin Walton 

-- 
Calvin Walton 

Re: [PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)

[Calvin Walton]

(Whoops, resending this message. Forgot that Gmail defaulted to
HTML...)

On Wed, 2019-03-20 at 19:36 -0400, Len Brown wrote:
> Hi Calvin,
> I'm inclined to apply this -- because it will not break anything,
> and it would at least enable testing by people, who have this
> hardware.

Hi Len,

By all means go ahead and apply the package power patch as well. I've
tested it on both Summit (single-die desktop) and Raven (desktop/laptop
apu) with good results. The worst case as it stands is that if the
multi-die packages (EPYC/TR) don't aggregate the value per package,
then package power will be under-reported.

(I previously wrote that this would be easier to test with the patch
applied, because the package power is reported with the -Dump option,
but I'm not sure that's actually the case - the value might still only
be collected once per package?)

Calvin.

> 
> On Fri, Aug 17, 2018 at 12:35 PM Calvin Walton <
> calvin.wal...@kepstin.ca> wrote:
> > The package power can also be read from an MSR. It's not clear
> > exactly
> > what is included, and whether it's aggregated over all nodes or
> > reported separately.
> > 
> > It does look like this is reported separately per CCX (I get a
> > single
> > value on the Ryzen R7 1700), but it might be reported separately
> > per-
> > die (node?) on larger processors. If that's the case, it would have
> > to
> > be recorded per node and aggregated for the socket.
> > 
> > Note that although Zen has these MSRs reporting power, it looks
> > like
> > the actual RAPL configuration (power limits, configured TDP) is
> > done
> > through PCI configuration space. I have not yet found any public
> > documentation for this.
> > 
> > Signed-off-by: Calvin Walton 
> > ---
> >  tools/power/x86/turbostat/turbostat.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/power/x86/turbostat/turbostat.c
> > b/tools/power/x86/turbostat/turbostat.c
> > index 89d4e2e75774..675c894b8595 100644
> > --- a/tools/power/x86/turbostat/turbostat.c
> > +++ b/tools/power/x86/turbostat/turbostat.c
> > @@ -1973,6 +1973,11 @@ int get_counters(struct thread_data *t,
> > struct core_data *c, struct pkg_data *p)
> > return -16;
> > p->rapl_dram_perf_status = msr & 0x;
> > }
> > +   if (do_rapl & RAPL_AMD_F17H) {
> > +   if (get_msr(cpu, MSR_PKG_ENERGY_STAT, ))
> > +   return -13;
> > +   p->energy_pkg = msr & 0x;
> > +   }
> > if (DO_BIC(BIC_PkgTmp)) {
> > if (get_msr(cpu, MSR_IA32_PACKAGE_THERM_STATUS,
> > ))
> > return -17;
> > @@ -3986,10 +3991,13 @@ void rapl_probe_amd(unsigned int family,
> > unsigned int model)
> > switch (family) {
> > case 0x17: /* Zen, Zen+ */
> > do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
> > -   if (rapl_joules)
> > +   if (rapl_joules) {
> > +   BIC_PRESENT(BIC_Pkg_J);
> > BIC_PRESENT(BIC_Cor_J);
> > -   else
> > +   } else {
> > +   BIC_PRESENT(BIC_PkgWatt);
> > BIC_PRESENT(BIC_CorWatt);
> > +   }
> > break;
> > default:
> > return;
> > --
> > 2.18.0
> > 
> 
> 

[PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)

[Calvin Walton]

The package power can also be read from an MSR. It's not clear exactly
what is included, and whether it's aggregated over all nodes or
reported separately.

It does look like this is reported separately per CCX (I get a single
value on the Ryzen R7 1700), but it might be reported separately per-
die (node?) on larger processors. If that's the case, it would have to
be recorded per node and aggregated for the socket.

Note that although Zen has these MSRs reporting power, it looks like
the actual RAPL configuration (power limits, configured TDP) is done
through PCI configuration space. I have not yet found any public
documentation for this.

Signed-off-by: Calvin Walton 
---
 tools/power/x86/turbostat/turbostat.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 89d4e2e75774..675c894b8595 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1973,6 +1973,11 @@ int get_counters(struct thread_data *t, struct core_data 
*c, struct pkg_data *p)
return -16;
p->rapl_dram_perf_status = msr & 0x;
}
+   if (do_rapl & RAPL_AMD_F17H) {
+   if (get_msr(cpu, MSR_PKG_ENERGY_STAT, ))
+   return -13;
+   p->energy_pkg = msr & 0x;
+   }
if (DO_BIC(BIC_PkgTmp)) {
if (get_msr(cpu, MSR_IA32_PACKAGE_THERM_STATUS, ))
return -17;
@@ -3986,10 +3991,13 @@ void rapl_probe_amd(unsigned int family, unsigned int 
model)
switch (family) {
case 0x17: /* Zen, Zen+ */
do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
-   if (rapl_joules)
+   if (rapl_joules) {
+   BIC_PRESENT(BIC_Pkg_J);
BIC_PRESENT(BIC_Cor_J);
-   else
+   } else {
+   BIC_PRESENT(BIC_PkgWatt);
BIC_PRESENT(BIC_CorWatt);
+   }
break;
default:
return;
-- 
2.18.0

[PATCH v3 0/2] tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

This is an updated version of my RAPL patchset for Zen CPUs, rebased on
top of the current state of kernel/git/lenb/linux.get turbostat branch.
(In particular, this fixes conflicts with the AMD APIC-id patch)

I've split it into two patches now. The first patch only adds Cores
power reporting, since I'm fairly confident that this'll work on all of
the Zen chips. I think this part is ready to apply now.

The second part is still a work in progress until I'm able to (or I'm
able to find someone else to) test the package power reporting on a
multi-die Zen chip.

Calvin Walton (2):
  tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL
  [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)

 tools/power/x86/turbostat/turbostat.c | 167 +-
 1 file changed, 138 insertions(+), 29 deletions(-)

-- 
2.18.0

[PATCH v3 2/2] [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)

[Calvin Walton]

The package power can also be read from an MSR. It's not clear exactly
what is included, and whether it's aggregated over all nodes or
reported separately.

It does look like this is reported separately per CCX (I get a single
value on the Ryzen R7 1700), but it might be reported separately per-
die (node?) on larger processors. If that's the case, it would have to
be recorded per node and aggregated for the socket.

Note that although Zen has these MSRs reporting power, it looks like
the actual RAPL configuration (power limits, configured TDP) is done
through PCI configuration space. I have not yet found any public
documentation for this.

Signed-off-by: Calvin Walton 
---
 tools/power/x86/turbostat/turbostat.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 89d4e2e75774..675c894b8595 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1973,6 +1973,11 @@ int get_counters(struct thread_data *t, struct core_data 
*c, struct pkg_data *p)
return -16;
p->rapl_dram_perf_status = msr & 0x;
}
+   if (do_rapl & RAPL_AMD_F17H) {
+   if (get_msr(cpu, MSR_PKG_ENERGY_STAT, ))
+   return -13;
+   p->energy_pkg = msr & 0x;
+   }
if (DO_BIC(BIC_PkgTmp)) {
if (get_msr(cpu, MSR_IA32_PACKAGE_THERM_STATUS, ))
return -17;
@@ -3986,10 +3991,13 @@ void rapl_probe_amd(unsigned int family, unsigned int 
model)
switch (family) {
case 0x17: /* Zen, Zen+ */
do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
-   if (rapl_joules)
+   if (rapl_joules) {
+   BIC_PRESENT(BIC_Pkg_J);
BIC_PRESENT(BIC_Cor_J);
-   else
+   } else {
+   BIC_PRESENT(BIC_PkgWatt);
BIC_PRESENT(BIC_CorWatt);
+   }
break;
default:
return;
-- 
2.18.0

[PATCH v3 0/2] tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

This is an updated version of my RAPL patchset for Zen CPUs, rebased on
top of the current state of kernel/git/lenb/linux.get turbostat branch.
(In particular, this fixes conflicts with the AMD APIC-id patch)

I've split it into two patches now. The first patch only adds Cores
power reporting, since I'm fairly confident that this'll work on all of
the Zen chips. I think this part is ready to apply now.

The second part is still a work in progress until I'm able to (or I'm
able to find someone else to) test the package power reporting on a
multi-die Zen chip.

Calvin Walton (2):
  tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL
  [WIP] tools/power turbostat: Also read package power on AMD F17h (Zen)

 tools/power/x86/turbostat/turbostat.c | 167 +-
 1 file changed, 138 insertions(+), 29 deletions(-)

-- 
2.18.0

[PATCH v3 1/2] tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.

I haven't yet enabled collection of package power, due to being unable
to test it on multi-node systems (TR, EPYC).

Signed-off-by: Calvin Walton 
---
 tools/power/x86/turbostat/turbostat.c | 159 +-
 1 file changed, 130 insertions(+), 29 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 6837a65409ba..89d4e2e75774 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -141,9 +142,21 @@ unsigned int first_counter_read = 1;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -187,6 +200,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -680,6 +694,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -734,7 +756,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -747,7 +769,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -808,6 +830,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX

[PATCH v3 1/2] tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.

I haven't yet enabled collection of package power, due to being unable
to test it on multi-node systems (TR, EPYC).

Signed-off-by: Calvin Walton 
---
 tools/power/x86/turbostat/turbostat.c | 159 +-
 1 file changed, 130 insertions(+), 29 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 6837a65409ba..89d4e2e75774 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -141,9 +142,21 @@ unsigned int first_counter_read = 1;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -187,6 +200,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -680,6 +694,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -734,7 +756,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -747,7 +769,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -808,6 +830,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX

[PATCH v3] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.

This matches the code in arch/x86/lib/cpu.c

Signed-off-by: Calvin Walton 
---

v3: Having just looked at the arch/x86/lib/cpu.c code again, I realized
that it *didn't* actually match - the kernel code uses family >= 6 for
applying the extended model number, while I was applying it only to
 family == 6 or family >= 0xf. Change that to match for consistency.

v2: I'm still working on updating the RAPL patch on top of the changes for
v4.18, but this CPUID fix doesn't have to wait.

 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..ed024deed36f 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += (fms >> 20) & 0xff;
+   if (family >= 6)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH v3] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.

This matches the code in arch/x86/lib/cpu.c

Signed-off-by: Calvin Walton 
---

v3: Having just looked at the arch/x86/lib/cpu.c code again, I realized
that it *didn't* actually match - the kernel code uses family >= 6 for
applying the extended model number, while I was applying it only to
 family == 6 or family >= 0xf. Change that to match for consistency.

v2: I'm still working on updating the RAPL patch on top of the changes for
v4.18, but this CPUID fix doesn't have to wait.

 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..ed024deed36f 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += (fms >> 20) & 0xff;
+   if (family >= 6)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH v2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.

This matches the code in arch/x86/lib/cpu.c

Signed-off-by: Calvin Walton 
---

I'm still working on updating the RAPL patch on top of the changes for
v4.18, but this CPUID fix doesn't have to wait.

 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..8452ace384b3 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += (fms >> 20) & 0xff;
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH v2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.

This matches the code in arch/x86/lib/cpu.c

Signed-off-by: Calvin Walton 
---

I'm still working on updating the RAPL patch on top of the changes for
v4.18, but this CPUID fix doesn't have to wait.

 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..8452ace384b3 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += (fms >> 20) & 0xff;
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

Re: [PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

On Thu, 2018-07-26 at 15:10 -0400, Len Brown wrote:
> Hi Calvin,
> I'll assume you are waiting for this to be tested by somebody who has
> the HW (sorry, I don't have AMD HW to test this)
> and will re-send a checkpatch.pl clean version when you have that
> result.
> 
> thanks,
> -Len

I need to rebase this on top of the 4.18-rc code at a minimum, I
suspect there will be some conflicts due to the changes for system
"Nodes". (This patch was based off 4.17)

I'll resubmit the CPUID fix shortly, and continue working on the RAPL
patch.

Thanks,
Calvin.

Re: [PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

On Thu, 2018-07-26 at 15:10 -0400, Len Brown wrote:
> Hi Calvin,
> I'll assume you are waiting for this to be tested by somebody who has
> the HW (sorry, I don't have AMD HW to test this)
> and will re-send a checkpatch.pl clean version when you have that
> result.
> 
> thanks,
> -Len

I need to rebase this on top of the 4.18-rc code at a minimum, I
suspect there will be some conflicts due to the changes for system
"Nodes". (This patch was based off 4.17)

I'll resubmit the CPUID fix shortly, and continue working on the RAPL
patch.

Thanks,
Calvin.

Re: [PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID) (Resend)

[Calvin Walton]

On Wed, 2018-07-18 at 18:26 -0400, Calvin Walton wrote:
> Based on the documentation provided in AMD's Open-Source
> Register Reference For AMD Family 17h Processors:
> https://support.amd.com/TechDocs/56255_OSRR.pdf
> 
> I've added support for reading Cores and Package energy usage from
> AMD's
> "RAPL" MSRs. In order to correctly detect the AMD processor
> generation,
> I've also had to update the CPUID code to handle AMD's extended
> family
> field.

Having now had the chance to look at recent changes to the turbostat
tool (these patches were based on the version from the 4.17 kernel), it
looks like I'm going to have to update the second patch in this set
because of the changes to handle processor "Nodes".

One thing I'm not sure about is whether the "Package" power reporting
on multi-node AMD systems is reported per node - I suspect it is, but
don't have hardware to confirm. If someone has a processor where this
applies (I'm guessing this is Threadripper and EPYC?) I'd appreciate
seeing the output of

turbostat --Dump --add msr0xc001029b,u32,raw

to know which is the case.

-- 
Calvin Walton 

Re: [PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID) (Resend)

[Calvin Walton]

On Wed, 2018-07-18 at 18:26 -0400, Calvin Walton wrote:
> Based on the documentation provided in AMD's Open-Source
> Register Reference For AMD Family 17h Processors:
> https://support.amd.com/TechDocs/56255_OSRR.pdf
> 
> I've added support for reading Cores and Package energy usage from
> AMD's
> "RAPL" MSRs. In order to correctly detect the AMD processor
> generation,
> I've also had to update the CPUID code to handle AMD's extended
> family
> field.

Having now had the chance to look at recent changes to the turbostat
tool (these patches were based on the version from the 4.17 kernel), it
looks like I'm going to have to update the second patch in this set
because of the changes to handle processor "Nodes".

One thing I'm not sure about is whether the "Package" power reporting
on multi-node AMD systems is reported per node - I suspect it is, but
don't have hardware to confirm. If someone has a processor where this
applies (I'm guessing this is Threadripper and EPYC?) I'd appreciate
seeing the output of

turbostat --Dump --add msr0xc001029b,u32,raw

to know which is the case.

-- 
Calvin Walton 

[PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.
---
 tools/power/x86/turbostat/turbostat.c | 171 ++
 1 file changed, 145 insertions(+), 26 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index f404d67fda92..1ab351512044 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -64,6 +65,7 @@ unsigned int has_epb;
 unsigned int do_irtl_snb;
 unsigned int do_irtl_hsw;
 unsigned int units = 100;  /* MHz etc */
+unsigned int authentic_amd;
 unsigned int genuine_intel;
 unsigned int has_invariant_tsc;
 unsigned int do_nhm_platform_info;
@@ -129,9 +131,21 @@ unsigned int has_misc_feature_control;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -171,6 +185,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -589,6 +604,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -639,7 +662,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -652,7 +675,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -713,6 +736,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX\n", c->c7);
outp += sprintf(outp, "DTS: %dC\n", c->core_temp_c);
+   outp += sprintf(outp, "Joules: %0X\n", c->core_energy);
 
for (i = 0, mp = sys.cp; mp; i++, mp = 

[PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.
---
 tools/power/x86/turbostat/turbostat.c | 171 ++
 1 file changed, 145 insertions(+), 26 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index f404d67fda92..1ab351512044 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -64,6 +65,7 @@ unsigned int has_epb;
 unsigned int do_irtl_snb;
 unsigned int do_irtl_hsw;
 unsigned int units = 100;  /* MHz etc */
+unsigned int authentic_amd;
 unsigned int genuine_intel;
 unsigned int has_invariant_tsc;
 unsigned int do_nhm_platform_info;
@@ -129,9 +131,21 @@ unsigned int has_misc_feature_control;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -171,6 +185,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -589,6 +604,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -639,7 +662,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -652,7 +675,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -713,6 +736,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX\n", c->c7);
outp += sprintf(outp, "DTS: %dC\n", c->core_temp_c);
+   outp += sprintf(outp, "Joules: %0X\n", c->core_energy);
 
for (i = 0, mp = sys.cp; mp; i++, mp = 

[PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID) (Resend)

[Calvin Walton]

Based on the documentation provided in AMD's Open-Source
Register Reference For AMD Family 17h Processors:
https://support.amd.com/TechDocs/56255_OSRR.pdf

I've added support for reading Cores and Package energy usage from AMD's
"RAPL" MSRs. In order to correctly detect the AMD processor generation,
I've also had to update the CPUID code to handle AMD's extended family
field.

I've resent this including the linux-pm mailing list per Rafael's
suggestion (I wasn't sure who to send this to initially - maybe the
MAINTAINERS file should be updated so get_maintainer.pl gives better
results). The patches are unchanged from my previous submission.

Here's some example output from my (idle) Ryzen 3 2200G test system:

turbostat version 17.06.23 - Len Brown 
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0x17:11:0 
(23:17:0)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, 
No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
RAPL: 364 sec. Joule Counter Range, at 180 Watts
cpu2: POLL: CPUIDLE CORE POLL IDLE
cpu2: C1: ACPI FFH INTEL MWAIT 0x0
cpu2: C2: ACPI IOPORT 0x414
cpu2: cpufreq driver: acpi-cpufreq
cpu2: cpufreq governor: schedutil
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1003 (0.125000 Watts, 0.15 Joules, 0.000977 
sec.)
CoreCPU Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ C1  C2  C1% 
C2% CorWatt PkgWatt
-   -   33  2.20148535005073126336942.75
95.12   0.033.29
0   0   33  2.20148335001213354 886 2.96
94.89   0.013.29
1   1   25  1.6714743500907 197 682 1.55
96.80   0.01
2   2   33  2.24147835001674450 11754.16
93.70   0.01
3   3   40  2.67150135001279262 951 2.33
95.07   0.01


Calvin Walton (2):
  turbostat: Read extended processor family from CPUID
  turbostat: Add support for AMD Fam 17h (Zen) RAPL

 tools/power/x86/turbostat/turbostat.c | 184 ++
 1 file changed, 156 insertions(+), 28 deletions(-)

-- 
2.18.0

[PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID) (Resend)

[Calvin Walton]

Based on the documentation provided in AMD's Open-Source
Register Reference For AMD Family 17h Processors:
https://support.amd.com/TechDocs/56255_OSRR.pdf

I've added support for reading Cores and Package energy usage from AMD's
"RAPL" MSRs. In order to correctly detect the AMD processor generation,
I've also had to update the CPUID code to handle AMD's extended family
field.

I've resent this including the linux-pm mailing list per Rafael's
suggestion (I wasn't sure who to send this to initially - maybe the
MAINTAINERS file should be updated so get_maintainer.pl gives better
results). The patches are unchanged from my previous submission.

Here's some example output from my (idle) Ryzen 3 2200G test system:

turbostat version 17.06.23 - Len Brown 
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0x17:11:0 
(23:17:0)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, 
No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
RAPL: 364 sec. Joule Counter Range, at 180 Watts
cpu2: POLL: CPUIDLE CORE POLL IDLE
cpu2: C1: ACPI FFH INTEL MWAIT 0x0
cpu2: C2: ACPI IOPORT 0x414
cpu2: cpufreq driver: acpi-cpufreq
cpu2: cpufreq governor: schedutil
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1003 (0.125000 Watts, 0.15 Joules, 0.000977 
sec.)
CoreCPU Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ C1  C2  C1% 
C2% CorWatt PkgWatt
-   -   33  2.20148535005073126336942.75
95.12   0.033.29
0   0   33  2.20148335001213354 886 2.96
94.89   0.013.29
1   1   25  1.6714743500907 197 682 1.55
96.80   0.01
2   2   33  2.24147835001674450 11754.16
93.70   0.01
3   3   40  2.67150135001279262 951 2.33
95.07   0.01


Calvin Walton (2):
  turbostat: Read extended processor family from CPUID
  turbostat: Add support for AMD Fam 17h (Zen) RAPL

 tools/power/x86/turbostat/turbostat.c | 184 ++
 1 file changed, 156 insertions(+), 28 deletions(-)

-- 
2.18.0

[PATCH 1/2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.
---
 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..f404d67fda92 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += ((fms >> 20) & 0xff);
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH 1/2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.
---
 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..f404d67fda92 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += ((fms >> 20) & 0xff);
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.
---
 tools/power/x86/turbostat/turbostat.c | 171 ++
 1 file changed, 145 insertions(+), 26 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index f404d67fda92..1ab351512044 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -64,6 +65,7 @@ unsigned int has_epb;
 unsigned int do_irtl_snb;
 unsigned int do_irtl_hsw;
 unsigned int units = 100;  /* MHz etc */
+unsigned int authentic_amd;
 unsigned int genuine_intel;
 unsigned int has_invariant_tsc;
 unsigned int do_nhm_platform_info;
@@ -129,9 +131,21 @@ unsigned int has_misc_feature_control;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -171,6 +185,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -589,6 +604,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -639,7 +662,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -652,7 +675,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -713,6 +736,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX\n", c->c7);
outp += sprintf(outp, "DTS: %dC\n", c->core_temp_c);
+   outp += sprintf(outp, "Joules: %0X\n", c->core_energy);
 
for (i = 0, mp = sys.cp; mp; i++, mp = 

[PATCH 1/2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.
---
 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..f404d67fda92 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += ((fms >> 20) & 0xff);
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID)

[Calvin Walton]

Based on the documentation provided in AMD's Open-Source
Register Reference For AMD Family 17h Processors:
https://support.amd.com/TechDocs/56255_OSRR.pdf

I've added support for reading Cores and Package energy usage from AMD's
"RAPL" MSRs. In order to correctly detect the AMD processor generation,
I've also had to update the CPUID code to handle AMD's extended family
field.

Here's some example output from my (idle) Ryzen 3 2200G test system:

turbostat version 17.06.23 - Len Brown 
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0x17:11:0 
(23:17:0)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, 
No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
RAPL: 364 sec. Joule Counter Range, at 180 Watts
cpu2: POLL: CPUIDLE CORE POLL IDLE
cpu2: C1: ACPI FFH INTEL MWAIT 0x0
cpu2: C2: ACPI IOPORT 0x414
cpu2: cpufreq driver: acpi-cpufreq
cpu2: cpufreq governor: schedutil
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1003 (0.125000 Watts, 0.15 Joules, 0.000977 
sec.)
CoreCPU Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ C1  C2  C1% 
C2% CorWatt PkgWatt
-   -   33  2.20148535005073126336942.75
95.12   0.033.29
0   0   33  2.20148335001213354 886 2.96
94.89   0.013.29
1   1   25  1.6714743500907 197 682 1.55
96.80   0.01
2   2   33  2.24147835001674450 11754.16
93.70   0.01
3   3   40  2.67150135001279262 951 2.33
95.07   0.01


Calvin Walton (2):
  turbostat: Read extended processor family from CPUID
  turbostat: Add support for AMD Fam 17h (Zen) RAPL

 tools/power/x86/turbostat/turbostat.c | 184 ++
 1 file changed, 156 insertions(+), 28 deletions(-)

-- 
2.18.0

[PATCH 2/2] turbostat: Add support for AMD Fam 17h (Zen) RAPL

[Calvin Walton]

Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf

These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_UNIT
0xc001029a (CORE_ENERGY_STAT), kind of like Intel's PP0_ENERGY_STATUS
0xc001029b (PKG_ENERGY_STAT), like Intel's PKG_ENERGY_STATUS

A notable difference from the Intel implementation is that AMD reports
the "Cores" energy usage separately for each core, rather than a
per-package total. The code has been adjusted to handle either case in a
generic way.
---
 tools/power/x86/turbostat/turbostat.c | 171 ++
 1 file changed, 145 insertions(+), 26 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index f404d67fda92..1ab351512044 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -64,6 +65,7 @@ unsigned int has_epb;
 unsigned int do_irtl_snb;
 unsigned int do_irtl_hsw;
 unsigned int units = 100;  /* MHz etc */
+unsigned int authentic_amd;
 unsigned int genuine_intel;
 unsigned int has_invariant_tsc;
 unsigned int do_nhm_platform_info;
@@ -129,9 +131,21 @@ unsigned int has_misc_feature_control;
 
 #define RAPL_CORES_ENERGY_STATUS   (1 << 9)
/* 0x639 MSR_PP0_ENERGY_STATUS */
+#define RAPL_PER_CORE_ENERGY   (1 << 10)
+   /* Indicates cores energy collection is 
per-core,
+* not per-package. */
+#define RAPL_AMD_F17H  (1 << 11)
+   /* 0xc0010299 MSR_RAPL_PWR_UNIT */
+   /* 0xc001029a MSR_CORE_ENERGY_STAT */
+   /* 0xc001029b MSR_PKG_ENERGY_STAT */
 #define RAPL_CORES (RAPL_CORES_ENERGY_STATUS | RAPL_CORES_POWER_LIMIT)
 #defineTJMAX_DEFAULT   100
 
+/* MSRs that are not yet in the kernel-provided header. */
+#define MSR_RAPL_PWR_UNIT  0xc0010299
+#define MSR_CORE_ENERGY_STAT   0xc001029a
+#define MSR_PKG_ENERGY_STAT0xc001029b
+
 #define MAX(a, b) ((a) > (b) ? (a) : (b))
 
 /*
@@ -171,6 +185,7 @@ struct core_data {
unsigned long long c7;
unsigned long long mc6_us;  /* duplicate as per-core for now, even 
though per module */
unsigned int core_temp_c;
+   unsigned int core_energy;   /* MSR_CORE_ENERGY_STAT */
unsigned int core_id;
unsigned long long counter[MAX_ADDED_COUNTERS];
 } *core_even, *core_odd;
@@ -589,6 +604,14 @@ void print_header(char *delim)
if (DO_BIC(BIC_CoreTmp))
outp += sprintf(outp, "%sCoreTmp", (printed++ ? delim : ""));
 
+   if (do_rapl && !rapl_joules) {
+   if (DO_BIC(BIC_CorWatt) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
+   } else if (do_rapl && rapl_joules) {
+   if (DO_BIC(BIC_Cor_J) && (do_rapl & RAPL_PER_CORE_ENERGY))
+   outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
+   }
+
for (mp = sys.cp; mp; mp = mp->next) {
if (mp->format == FORMAT_RAW) {
if (mp->width == 64)
@@ -639,7 +662,7 @@ void print_header(char *delim)
if (do_rapl && !rapl_joules) {
if (DO_BIC(BIC_PkgWatt))
outp += sprintf(outp, "%sPkgWatt", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_CorWatt))
+   if (DO_BIC(BIC_CorWatt) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCorWatt", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFXWatt))
outp += sprintf(outp, "%sGFXWatt", (printed++ ? delim : 
""));
@@ -652,7 +675,7 @@ void print_header(char *delim)
} else if (do_rapl && rapl_joules) {
if (DO_BIC(BIC_Pkg_J))
outp += sprintf(outp, "%sPkg_J", (printed++ ? delim : 
""));
-   if (DO_BIC(BIC_Cor_J))
+   if (DO_BIC(BIC_Cor_J) && !(do_rapl & RAPL_PER_CORE_ENERGY))
outp += sprintf(outp, "%sCor_J", (printed++ ? delim : 
""));
if (DO_BIC(BIC_GFX_J))
outp += sprintf(outp, "%sGFX_J", (printed++ ? delim : 
""));
@@ -713,6 +736,7 @@ int dump_counters(struct thread_data *t, struct core_data 
*c,
outp += sprintf(outp, "c6: %016llX\n", c->c6);
outp += sprintf(outp, "c7: %016llX\n", c->c7);
outp += sprintf(outp, "DTS: %dC\n", c->core_temp_c);
+   outp += sprintf(outp, "Joules: %0X\n", c->core_energy);
 
for (i = 0, mp = sys.cp; mp; i++, mp = 

[PATCH 1/2] turbostat: Read extended processor family from CPUID

[Calvin Walton]

This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.

See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and ExtFamily values.
---
 tools/power/x86/turbostat/turbostat.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..f404d67fda92 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -4031,7 +4031,9 @@ void process_cpuid()
family = (fms >> 8) & 0xf;
model = (fms >> 4) & 0xf;
stepping = fms & 0xf;
-   if (family == 6 || family == 0xf)
+   if (family == 0xf)
+   family += ((fms >> 20) & 0xff);
+   if (family == 6 || family >= 0xf)
model += ((fms >> 16) & 0xf) << 4;
 
if (!quiet) {
-- 
2.18.0

[PATCH 0/2] turbostat: Improve support for AMD Zen CPUs (RAPL, CPUID)

[Calvin Walton]

Based on the documentation provided in AMD's Open-Source
Register Reference For AMD Family 17h Processors:
https://support.amd.com/TechDocs/56255_OSRR.pdf

I've added support for reading Cores and Package energy usage from AMD's
"RAPL" MSRs. In order to correctly detect the AMD processor generation,
I've also had to update the CPUID code to handle AMD's extended family
field.

Here's some example output from my (idle) Ryzen 3 2200G test system:

turbostat version 17.06.23 - Len Brown 
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0x17:11:0 
(23:17:0)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, 
No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
RAPL: 364 sec. Joule Counter Range, at 180 Watts
cpu2: POLL: CPUIDLE CORE POLL IDLE
cpu2: C1: ACPI FFH INTEL MWAIT 0x0
cpu2: C2: ACPI IOPORT 0x414
cpu2: cpufreq driver: acpi-cpufreq
cpu2: cpufreq governor: schedutil
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1003 (0.125000 Watts, 0.15 Joules, 0.000977 
sec.)
CoreCPU Avg_MHz Busy%   Bzy_MHz TSC_MHz IRQ C1  C2  C1% 
C2% CorWatt PkgWatt
-   -   33  2.20148535005073126336942.75
95.12   0.033.29
0   0   33  2.20148335001213354 886 2.96
94.89   0.013.29
1   1   25  1.6714743500907 197 682 1.55
96.80   0.01
2   2   33  2.24147835001674450 11754.16
93.70   0.01
3   3   40  2.67150135001279262 951 2.33
95.07   0.01


Calvin Walton (2):
  turbostat: Read extended processor family from CPUID
  turbostat: Add support for AMD Fam 17h (Zen) RAPL

 tools/power/x86/turbostat/turbostat.c | 184 ++
 1 file changed, 156 insertions(+), 28 deletions(-)

-- 
2.18.0

Re: [PATCH v3 0/3] Bind RMI4 over SMBus from PS/2

[Calvin Walton]

Hi,

On Wed, 2017-03-08 at 16:24 +0100, Benjamin Tissoires wrote:
> Hi Dmitry,
> 
> This is mostly a resend of the PS/2-SMBus binding (last 3 patches of
> now 3 years
> of trial and errors).
> I integrated both warnings raised by Coccinelle, and squashed 4/3
> into 3/3.

Just want to provide you some quick feedback from the user's
perspective...

I tested this patch set on my somewhat hacked together laptop - I have
a Lenovo T440p with the touchpad replaced with a "top button pad" from
a T450 or similar.

With this patch set (and using the psmouse.synaptics_intertouch=1
option), the touchpad is found and used via RMI4/SMBUS, and the PS2
passthrough to the trackpoint does work. Passing the buttons presses
from the top buttons to the trackpoint device doesn't work - my
understanding is the code for this isn't included here?

The touchpad cursor movement (and scrolling, etc.) is so much smoother
than with the PS2 interface of this touchpad model... I'm glad these
patches are getting closer to complete!

Calvin.

[   17.665070] psmouse serio1: synaptics: queried max coordinates: x [..5676], 
y [..4758]
[   17.698107] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1096..]
[   17.760612] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 
0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x1, board id: 3053, fw id: 2560
[   17.763619] psmouse serio1: synaptics: serio: Synaptics pass-through port at 
isa0060/serio1/input0
[   17.766577] psmouse serio1: synaptics: device also supported by an other bus.
[   17.807548] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio1/input/input9
[   18.435205] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   18.630809] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/serio2/input/input18
[   19.064659] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: 
Synaptics, product: TM3053-003, fw id: 1741108
[   19.131839] input: Synaptics TM3053-003 as /devices/rmi4-00/input/input19
[   19.152671] rmi4_smbus 9-002c: registered rmi smb driver at 0x2c.
[   20.425233] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   20.482937] input: TPPS/2 IBM TrackPoint as 
/devices/rmi4-00/rmi4-00.fn03/serio3/input/input21
-- 
Calvin Walton <calvin.wal...@kepstin.ca>

Re: [PATCH v3 0/3] Bind RMI4 over SMBus from PS/2

[Calvin Walton]

Hi,

On Wed, 2017-03-08 at 16:24 +0100, Benjamin Tissoires wrote:
> Hi Dmitry,
> 
> This is mostly a resend of the PS/2-SMBus binding (last 3 patches of
> now 3 years
> of trial and errors).
> I integrated both warnings raised by Coccinelle, and squashed 4/3
> into 3/3.

Just want to provide you some quick feedback from the user's
perspective...

I tested this patch set on my somewhat hacked together laptop - I have
a Lenovo T440p with the touchpad replaced with a "top button pad" from
a T450 or similar.

With this patch set (and using the psmouse.synaptics_intertouch=1
option), the touchpad is found and used via RMI4/SMBUS, and the PS2
passthrough to the trackpoint does work. Passing the buttons presses
from the top buttons to the trackpoint device doesn't work - my
understanding is the code for this isn't included here?

The touchpad cursor movement (and scrolling, etc.) is so much smoother
than with the PS2 interface of this touchpad model... I'm glad these
patches are getting closer to complete!

Calvin.

[   17.665070] psmouse serio1: synaptics: queried max coordinates: x [..5676], 
y [..4758]
[   17.698107] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1096..]
[   17.760612] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 
0x1e2b1, caps: 0xf003a3/0x943300/0x12e800/0x1, board id: 3053, fw id: 2560
[   17.763619] psmouse serio1: synaptics: serio: Synaptics pass-through port at 
isa0060/serio1/input0
[   17.766577] psmouse serio1: synaptics: device also supported by an other bus.
[   17.807548] input: SynPS/2 Synaptics TouchPad as 
/devices/platform/i8042/serio1/input/input9
[   18.435205] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   18.630809] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/serio2/input/input18
[   19.064659] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: 
Synaptics, product: TM3053-003, fw id: 1741108
[   19.131839] input: Synaptics TM3053-003 as /devices/rmi4-00/input/input19
[   19.152671] rmi4_smbus 9-002c: registered rmi smb driver at 0x2c.
[   20.425233] psmouse serio3: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[   20.482937] input: TPPS/2 IBM TrackPoint as 
/devices/rmi4-00/rmi4-00.fn03/serio3/input/input21
-- 
Calvin Walton 

Re: [bisected, regression] 3.17-rc2 kernel doesn't load initramfs with EFI stub boot

[Calvin Walton]

On Mon, 2014-09-01 at 19:42 +0100, Matt Fleming wrote:
> On Wed, 27 Aug, at 12:02:37PM, Calvin Walton wrote:
> >  Hi all,
> > 
> >  When I tried booting the 3.17-rc2 kernel on my Lenovo ThinkPad 
> > T440p
> >  (16gb ram) via Gummiboot/EFI stub, it failed with an error saying 
> > that
> >  it could not mount root. A little investigation revealed that the
> >  initramfs did not load, so mounting by filesystem UUID failed.
> >  I've bisected the change, and it has led me to:
> > 
> >  4bf7111f50167133a71c23530ca852a41355e739 is the first bad commit
> >  commit 4bf7111f50167133a71c23530ca852a41355e739
> >  Author: Yinghai Lu 
> >  Date:   Sat Jun 14 12:23:41 2014 -0700
> > 
> >  x86/efi: Support initrd loaded above 4G
> 
> Thanks for reporting this. Could you try the below commit and see
> whether it fixes things for you?
> 
>   http://article.gmane.org/gmane.linux.kernel.efi/4524

With Yinghai Lu's patch from the linked message, my ThinkPad is now 
booting correctly. (Admittedly using a rather "small" 7MB intramfs - I 
don't have any >2GB ones handy).

Feel free to take a
Tested-by: Calvin Walton 

Thanks!


-- 
Calvin Walton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [bisected, regression] 3.17-rc2 kernel doesn't load initramfs with EFI stub boot

[Calvin Walton]

On Mon, 2014-09-01 at 19:42 +0100, Matt Fleming wrote:
 On Wed, 27 Aug, at 12:02:37PM, Calvin Walton wrote:
   Hi all,
  
   When I tried booting the 3.17-rc2 kernel on my Lenovo ThinkPad 
  T440p
   (16gb ram) via Gummiboot/EFI stub, it failed with an error saying 
  that
   it could not mount root. A little investigation revealed that the
   initramfs did not load, so mounting by filesystem UUID failed.
   I've bisected the change, and it has led me to:
  
   4bf7111f50167133a71c23530ca852a41355e739 is the first bad commit
   commit 4bf7111f50167133a71c23530ca852a41355e739
   Author: Yinghai Lu ying...@kernel.org
   Date:   Sat Jun 14 12:23:41 2014 -0700
  
   x86/efi: Support initrd loaded above 4G
 
 Thanks for reporting this. Could you try the below commit and see
 whether it fixes things for you?
 
   http://article.gmane.org/gmane.linux.kernel.efi/4524

With Yinghai Lu's patch from the linked message, my ThinkPad is now 
booting correctly. (Admittedly using a rather small 7MB intramfs - I 
don't have any 2GB ones handy).

Feel free to take a
Tested-by: Calvin Walton calvin.wal...@kepstin.ca

Thanks!


-- 
Calvin Walton calvin.wal...@kepstin.ca
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[bisected, regression] 3.17-rc2 kernel doesn't load initramfs with EFI stub boot

[Calvin Walton]

Hi all,

When I tried booting the 3.17-rc2 kernel on my Lenovo ThinkPad T440p 
(16gb ram) via Gummiboot/EFI stub, it failed with an error saying that 
it could not mount root. A little investigation revealed that the 
initramfs did not load, so mounting by filesystem UUID failed.

A video of the failed boot is available here, if you're curious:
https://www.youtube.com/watch?v=wOHTvg8Tico

I've bisected the change, and it has led me to:

4bf7111f50167133a71c23530ca852a41355e739 is the first bad commit
commit 4bf7111f50167133a71c23530ca852a41355e739
Author: Yinghai Lu 
Date:   Sat Jun 14 12:23:41 2014 -0700

x86/efi: Support initrd loaded above 4G

For boot efi kernel directly without bootloader.
If the kernel support XLF_CAN_BE_LOADED_ABOVE_4G, we should
not limit initrd under hdr->initrd_add_max.

Signed-off-by: Yinghai Lu 
Signed-off-by: Matt Fleming 

This commit reverts cleanly on top of 3.17-rc2, and the resulting 
kernel boots correctly.

Note that testing was done during bisect with the EFI PE/COFF 
alignment fix by Michael Brown on top for kernels where it was not 
already included (this laptop requires that fix).


Full bisect log:
git bisect start
# bad: [52addcf9d6669fa439387610bc65c92fa0980cef] 
Linux 3.17-rc2
git bisect bad 52addcf9d6669fa439387610bc65c92fa0980cef
# 
good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16
git bisect 
good 19583ca584d6f574384e17fe7613dfaeadcdc4a6
# bad: 
[ae045e2455429c418a418a3376301a9e5753a0a8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect 
bad ae045e2455429c418a418a3376301a9e5753a0a8
# bad: 
[53ee983378ff23e8f3ff95ecf99dea7c6c221900] Merge tag 
'staging-3.17-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect 
bad 53ee983378ff23e8f3ff95ecf99dea7c6c221900
# good: 
[2042088cd67d0064d18c52c13c69af2499907bb1] staging: comedi: ni_labpc: 
tidy up labpc_ai_scan_mode()
git bisect good 
2042088cd67d0064d18c52c13c69af2499907bb1
# good: 
[98959948a7ba33cf8c708626e0d2a1456397e1c6] Merge branch 
'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 
98959948a7ba33cf8c708626e0d2a1456397e1c6
# good: 
[6f929b4e5a022c3ca806c1675ccb833c42086853] staging: comedi: 
amplc_pc236: move static board data
git bisect good 
6f929b4e5a022c3ca806c1675ccb833c42086853
# bad: 
[2521129a6d2fd8a81f99cf95055eddea3df914ff] Merge tag 
'char-misc-3.17-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git 
bisect bad 2521129a6d2fd8a81f99cf95055eddea3df914ff
# good: 
[7b9d1f0b7a18b86db0ac1de628fa91c0994fefbe] misc: bh1780: Introduce the 
use of devm_kzalloc
git bisect good 
7b9d1f0b7a18b86db0ac1de628fa91c0994fefbe
# bad: 
[ce4747963252a30613ebf1c1df3d83b9526a342e] Merge branch 
'x86-mm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 
ce4747963252a30613ebf1c1df3d83b9526a342e
# bad: 
[fb86b2440de0ec10fe0272eb19d262ae7a01adb8] x86/efi: Add better error 
logging to EFI boot stub
git bisect bad 
fb86b2440de0ec10fe0272eb19d262ae7a01adb8
# bad: 
[0c5ed61adbdbf2ca5de934642d5be1e971c498c1] efi/reboot: Allow powering 
off machines using EFI
git bisect bad 
0c5ed61adbdbf2ca5de934642d5be1e971c498c1
# bad: 
[e15dd4949a937d8e8482f37f8fe493357417f203] efi/arm64: Preserve FP/SIMD 
registers on UEFI runtime services calls
git bisect bad 
e15dd4949a937d8e8482f37f8fe493357417f203
# bad: 
[4bf7111f50167133a71c23530ca852a41355e739] x86/efi: Support initrd 
loaded above 4G
git bisect bad 4bf7111f50167133a71c23530ca852a41355e739

# good: [98a716b66cab993e15001c7ec06f637ca6f1079b] x86/efi: Use 
early_memunmap() to squelch sparse errors
git bisect good 
98a716b66cab993e15001c7ec06f637ca6f1079b
# first bad commit: 
[4bf7111f50167133a71c23530ca852a41355e739] x86/efi: Support initrd 
loaded above 4G


-- 
Calvin Walton 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[bisected, regression] 3.17-rc2 kernel doesn't load initramfs with EFI stub boot

[Calvin Walton]

Hi all,

When I tried booting the 3.17-rc2 kernel on my Lenovo ThinkPad T440p 
(16gb ram) via Gummiboot/EFI stub, it failed with an error saying that 
it could not mount root. A little investigation revealed that the 
initramfs did not load, so mounting by filesystem UUID failed.

A video of the failed boot is available here, if you're curious:
https://www.youtube.com/watch?v=wOHTvg8Tico

I've bisected the change, and it has led me to:

4bf7111f50167133a71c23530ca852a41355e739 is the first bad commit
commit 4bf7111f50167133a71c23530ca852a41355e739
Author: Yinghai Lu ying...@kernel.org
Date:   Sat Jun 14 12:23:41 2014 -0700

x86/efi: Support initrd loaded above 4G

For boot efi kernel directly without bootloader.
If the kernel support XLF_CAN_BE_LOADED_ABOVE_4G, we should
not limit initrd under hdr-initrd_add_max.

Signed-off-by: Yinghai Lu ying...@kernel.org
Signed-off-by: Matt Fleming matt.flem...@intel.com

This commit reverts cleanly on top of 3.17-rc2, and the resulting 
kernel boots correctly.

Note that testing was done during bisect with the EFI PE/COFF 
alignment fix by Michael Brown on top for kernels where it was not 
already included (this laptop requires that fix).


Full bisect log:
git bisect start
# bad: [52addcf9d6669fa439387610bc65c92fa0980cef] 
Linux 3.17-rc2
git bisect bad 52addcf9d6669fa439387610bc65c92fa0980cef
# 
good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16
git bisect 
good 19583ca584d6f574384e17fe7613dfaeadcdc4a6
# bad: 
[ae045e2455429c418a418a3376301a9e5753a0a8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect 
bad ae045e2455429c418a418a3376301a9e5753a0a8
# bad: 
[53ee983378ff23e8f3ff95ecf99dea7c6c221900] Merge tag 
'staging-3.17-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect 
bad 53ee983378ff23e8f3ff95ecf99dea7c6c221900
# good: 
[2042088cd67d0064d18c52c13c69af2499907bb1] staging: comedi: ni_labpc: 
tidy up labpc_ai_scan_mode()
git bisect good 
2042088cd67d0064d18c52c13c69af2499907bb1
# good: 
[98959948a7ba33cf8c708626e0d2a1456397e1c6] Merge branch 
'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 
98959948a7ba33cf8c708626e0d2a1456397e1c6
# good: 
[6f929b4e5a022c3ca806c1675ccb833c42086853] staging: comedi: 
amplc_pc236: move static board data
git bisect good 
6f929b4e5a022c3ca806c1675ccb833c42086853
# bad: 
[2521129a6d2fd8a81f99cf95055eddea3df914ff] Merge tag 
'char-misc-3.17-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git 
bisect bad 2521129a6d2fd8a81f99cf95055eddea3df914ff
# good: 
[7b9d1f0b7a18b86db0ac1de628fa91c0994fefbe] misc: bh1780: Introduce the 
use of devm_kzalloc
git bisect good 
7b9d1f0b7a18b86db0ac1de628fa91c0994fefbe
# bad: 
[ce4747963252a30613ebf1c1df3d83b9526a342e] Merge branch 
'x86-mm-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 
ce4747963252a30613ebf1c1df3d83b9526a342e
# bad: 
[fb86b2440de0ec10fe0272eb19d262ae7a01adb8] x86/efi: Add better error 
logging to EFI boot stub
git bisect bad 
fb86b2440de0ec10fe0272eb19d262ae7a01adb8
# bad: 
[0c5ed61adbdbf2ca5de934642d5be1e971c498c1] efi/reboot: Allow powering 
off machines using EFI
git bisect bad 
0c5ed61adbdbf2ca5de934642d5be1e971c498c1
# bad: 
[e15dd4949a937d8e8482f37f8fe493357417f203] efi/arm64: Preserve FP/SIMD 
registers on UEFI runtime services calls
git bisect bad 
e15dd4949a937d8e8482f37f8fe493357417f203
# bad: 
[4bf7111f50167133a71c23530ca852a41355e739] x86/efi: Support initrd 
loaded above 4G
git bisect bad 4bf7111f50167133a71c23530ca852a41355e739

# good: [98a716b66cab993e15001c7ec06f637ca6f1079b] x86/efi: Use 
early_memunmap() to squelch sparse errors
git bisect good 
98a716b66cab993e15001c7ec06f637ca6f1079b
# first bad commit: 
[4bf7111f50167133a71c23530ca852a41355e739] x86/efi: Support initrd 
loaded above 4G


-- 
Calvin Walton calvin.wal...@kepstin.ca
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 24/27] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Calvin Walton]

Sorry, dropped the CCs when I replied... I don't normally use the
Gmail web interface :)

On Thu, Dec 6, 2012 at 7:59 PM, Greg Kroah-Hartman
 wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Calvin Walton 
>
> commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.
>
> This board is incorrectly detected as having an LVDS connector,

$ git describe --contains a51d4ed01e5bb39d2cf36a12f9976ab08872c192
v3.6-rc4~5^2~3^2

This patch was already included in Linus's 3.6 upstream release, so it
doesn't need to be (re-)applied to the 3.6.x stable tree. I'm
surprised it applied at all, it must need some fuzz to add the
duplicate entry...?

Anyways, it should only be applied to the 3.0 and 3.4 trees.

Calvin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 24/27] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Calvin Walton]

Sorry, dropped the CCs when I replied... I don't normally use the
Gmail web interface :)

On Thu, Dec 6, 2012 at 7:59 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 3.6-stable review patch.  If anyone has any objections, please let me know.

 --

 From: Calvin Walton calvin.wal...@kepstin.ca

 commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.

 This board is incorrectly detected as having an LVDS connector,

$ git describe --contains a51d4ed01e5bb39d2cf36a12f9976ab08872c192
v3.6-rc4~5^2~3^2

This patch was already included in Linus's 3.6 upstream release, so it
doesn't need to be (re-)applied to the 3.6.x stable tree. I'm
surprised it applied at all, it must need some fuzz to add the
duplicate entry...?

Anyways, it should only be applied to the 3.0 and 3.4 trees.

Calvin.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] zram: select ZSMALLOC when ZRAM is configured

[Calvin Walton]

On Wed, 2012-09-26 at 09:15 -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 26, 2012 at 05:50:19PM +0900, Minchan Kim wrote:
> > At the monent, we can configure zram in driver/block once zsmalloc
> > in /lib menu is configured firstly. It's not convenient.
> > 
> > User can configure zram in driver/block regardless of zsmalloc enabling
> > by this patch.
> > 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/block/zram/Kconfig |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> > index be5abe8..ee23a86 100644
> > --- a/drivers/block/zram/Kconfig
> > +++ b/drivers/block/zram/Kconfig
> > @@ -1,6 +1,7 @@
> >  config ZRAM
> > tristate "Compressed RAM block device support"
> > -   depends on BLOCK && SYSFS && ZSMALLOC
> > +   depends on BLOCK && SYSFS
> > +   select ZSMALLOC
> 
> As ZSMALLOC is dependant on CONFIG_STAGING, this isn't going to work at
> all, sorry.

Perhaps you missed [PATCH 1/3] zsmalloc: promote to lib/ ? The first
patch in this series moves zsmalloc out of the staging directory, and
removes the dependency on CONFIG_STAGING.

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] zram: select ZSMALLOC when ZRAM is configured

[Calvin Walton]

On Wed, 2012-09-26 at 09:15 -0700, Greg Kroah-Hartman wrote:
 On Wed, Sep 26, 2012 at 05:50:19PM +0900, Minchan Kim wrote:
  At the monent, we can configure zram in driver/block once zsmalloc
  in /lib menu is configured firstly. It's not convenient.
  
  User can configure zram in driver/block regardless of zsmalloc enabling
  by this patch.
  
  Signed-off-by: Minchan Kim minc...@kernel.org
  ---
   drivers/block/zram/Kconfig |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
  index be5abe8..ee23a86 100644
  --- a/drivers/block/zram/Kconfig
  +++ b/drivers/block/zram/Kconfig
  @@ -1,6 +1,7 @@
   config ZRAM
  tristate Compressed RAM block device support
  -   depends on BLOCK  SYSFS  ZSMALLOC
  +   depends on BLOCK  SYSFS
  +   select ZSMALLOC
 
 As ZSMALLOC is dependant on CONFIG_STAGING, this isn't going to work at
 all, sorry.

Perhaps you missed [PATCH 1/3] zsmalloc: promote to lib/ ? The first
patch in this series moves zsmalloc out of the staging directory, and
removes the dependency on CONFIG_STAGING.

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: "Trapping" hard drive errors ( "ata***** failed command: READ FPDMA QUEUED")

[Calvin Walton]

On Thu, 2012-08-23 at 23:26 -0500, Mouse Dresden wrote:
> Hello I hope that this question is not to mundane.
> 
> A while ago I encountered this error message on a hard drive of mine.
> I managed to clean up the problem and run smartctl and the disk is
> clean, but such errors can be very problematic. I think one of the
> reasons is that the hard drive gets "bogs down" on the particular
> command and communication between the kernel and drive, other system
> calls time out. This generates a lot of spurious errors you have to
> eliminate.
> 
> I would like to create some basic tools to aid in diagnosing and
> repairing such problems. The main difficulty is "trapping" the error
> message. By this I mean terminating the call that is causing the
> error, causing the drive to abandon this particular command, and
> sending some sort of signal ( figurative and or literal ) to the
> process making the particular command, so I can trace it.
> 
> Can someone either describe the process, or if it is too long,
> recommend some reading describing it?
> 
> If it helps to know the detailed message, it can be found at:
> http://unix.stackexchange.com/questions/43681/kde-causes-read-fpdma-queued-error

This error has nothing to do with software (kde) configuration or
filesystem corruption. It is a hardware error. First of all, this:

sd 2:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sda, sector 326677146

means that your hard drive has a pending relocated sector (if you could
share the smartctl output, it would confirm this). Assuming that your
drive has spare area remaining (which it does, if smartctl says it's
happy), then simply overwriting the sector in question will cause the
drive to reallocate the sector and fix the error.

You can use the 'hdparm --write-sector' command to do this - but read
all the warnings and backup important data first.

The reason for the delay/timeouts that you're seeing is that typical
consumer drives will attempt to retry reads many times for up to 10
seconds (or longer!) before returning an error to the operating system.
In the mean time, there is no way for the linux kernel to cancel the
command. It can only wait it out.

Often times, errors like this are signs that your drive is close to
failing - not /always/, but often. If manually overwriting the sector in
question doesn't help, you should probably look into replacing the
drive.

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Calvin Walton]

This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.

It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
chipset.

I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.

Signed-off-by: Calvin Walton 
---

This board:
http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp

If you want any additional debug output from this machine, let me know
what you would like and how to find it.

I think this patch would probably be a reasonable candidate for -stable?

 drivers/gpu/drm/i915/intel_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 08eb04c..2c58310 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Gigabyte GA-D525TUD",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., 
Ltd."),
+   DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
1.7.12

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

[Calvin Walton]

This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.

It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
chipset.

I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.

Signed-off-by: Calvin Walton calvin.wal...@kepstin.ca
---

This board:
http://www.gigabyte.us/products/product-page.aspx?pid=3549#sp

If you want any additional debug output from this machine, let me know
what you would like and how to find it.

I think this patch would probably be a reasonable candidate for -stable?

 drivers/gpu/drm/i915/intel_lvds.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 08eb04c..2c58310 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -777,6 +777,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, MS-7469),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = Gigabyte GA-D525TUD,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, Gigabyte Technology Co., 
Ltd.),
+   DMI_MATCH(DMI_BOARD_NAME, D525TUD),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
1.7.12

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Trapping hard drive errors ( ata***** failed command: READ FPDMA QUEUED)

[Calvin Walton]

On Thu, 2012-08-23 at 23:26 -0500, Mouse Dresden wrote:
 Hello I hope that this question is not to mundane.
 
 A while ago I encountered this error message on a hard drive of mine.
 I managed to clean up the problem and run smartctl and the disk is
 clean, but such errors can be very problematic. I think one of the
 reasons is that the hard drive gets bogs down on the particular
 command and communication between the kernel and drive, other system
 calls time out. This generates a lot of spurious errors you have to
 eliminate.
 
 I would like to create some basic tools to aid in diagnosing and
 repairing such problems. The main difficulty is trapping the error
 message. By this I mean terminating the call that is causing the
 error, causing the drive to abandon this particular command, and
 sending some sort of signal ( figurative and or literal ) to the
 process making the particular command, so I can trace it.
 
 Can someone either describe the process, or if it is too long,
 recommend some reading describing it?
 
 If it helps to know the detailed message, it can be found at:
 http://unix.stackexchange.com/questions/43681/kde-causes-read-fpdma-queued-error

This error has nothing to do with software (kde) configuration or
filesystem corruption. It is a hardware error. First of all, this:

sd 2:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sda, sector 326677146

means that your hard drive has a pending relocated sector (if you could
share the smartctl output, it would confirm this). Assuming that your
drive has spare area remaining (which it does, if smartctl says it's
happy), then simply overwriting the sector in question will cause the
drive to reallocate the sector and fix the error.

You can use the 'hdparm --write-sector' command to do this - but read
all the warnings and backup important data first.

The reason for the delay/timeouts that you're seeing is that typical
consumer drives will attempt to retry reads many times for up to 10
seconds (or longer!) before returning an error to the operating system.
In the mean time, there is no way for the linux kernel to cancel the
command. It can only wait it out.

Often times, errors like this are signs that your drive is close to
failing - not /always/, but often. If manually overwriting the sector in
question doesn't help, you should probably look into replacing the
drive.

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch: Thermostat doesn't cool Harddrives (12 inch Powerbooks, Ibooks G4)

[Calvin Walton]

On Sat, 2012-08-18 at 11:57 +0200, Thomas Haschka wrote:
> Hello everybody!

Hi Thomas,
Unfortunately, there are quite a few things wrong with your patch that
will likely prevent any kernel developers from picking it up as-is.
Please read through the file Documentation/SubmittingPatches, it has a
lot of helpful hints.

I've added a few more comments inline...

> It was quite hot here in Austria in the recent days and I found out
> that the fan in my 12 inch powerbook only kicked in on CPU, GPU usage,
> while on Mac OS X sides the fan ran nearly all the time (hot as it
> was)... 
> 
> I looked into the therm_adt746 driver and found out that the
> temperature sensor at the harddrive's bottom in the powerbook was not
> taken into account, but it should as one of the air inlets is just
> besides the harddrive, and it is thus also cooled by the fan, ( on can
> verfy that by spinning up the fans an reading out the hdd temp ) .. 
> 
> I created a patch to fix the situation, and I guess that it is pretty
> urgent as I imagine lot's of powerbooks running with their disk
> uncooled.. 
> 
> Here goes the patch
> 
> Thanks for making it accessible.. 
> 
> Thomas

You're missing the Signed-off-by line here. (It's described in the
SubmittingPatches file). Your patch description is pretty good - it
explains clearly why someone would want the patch.

> diff -uprN linux/drivers/macintosh/therm_adt746x.c
> linux-mod/drivers/macintosh/therm_adt746x.c ---
> linux/drivers/macintosh/therm_adt746x.c   2012-08-10
> 12:42:38.0 +0200 +++
> linux-mod/drivers/macintosh/therm_adt746x.c   2012-08-18
> 11:29:41.0 +0200 @@ -2,6 +2,7 @@

This patch has been word-wrapped and mangled by your email client, and
cannot be applied. The file Documentation/email-clients.txt in the
kernel source has some hints on how to set up your email client to avoid
this problem. (If you're using the Gmail web interface for this, you'll
have to use another client: the Gmail web interface cannot be fixed.)
 
> -static u8 TEMP_REG[3]= {0x26, 0x25, 0x27}; /* local, sensor1,
> sensor2 */ -static u8 LIMIT_REG[3]   = {0x6b, 0x6a, 0x6c}; /* local,
> sensor1, sensor2 */ -static u8 MANUAL_MODE[2] = {0x5c, 0x5d};   
> -static u8 REM_CONTROL[2] = {0x00, 0x40};
> -static u8 FAN_SPEED[2]   = {0x28, 0x2a};
> -static u8 FAN_SPD_SET[2] = {0x30, 0x31};
> -
> -static u8 default_limits_local[3] = {70, 50, 70};/* local,
> sensor1, sensor2 */ -static u8 default_limits_chip[3] = {80, 65,
> 80};/* local, sensor1, sensor2 */ -static const char
> *sensor_location[3] = { "?", "?", "?" }; +static u8 TEMP_REG[3] =
> { 0x26, 0x25, 0x27 }; /* local, sensor1, sensor2 */ +static u8
> LIMIT_REG[3] = { 0x6b, 0x6a, 0x6c };  /* local, sensor1, sensor2
> */ +static u8 MANUAL_MODE[2] = { 0x5c, 0x5d }; +static u8
> REM_CONTROL[2] = { 0x00, 0x40 }; +static u8 FAN_SPEED[2] = { 0x28,
> 0x2a }; +static u8 FAN_SPD_SET[2] = { 0x30, 0x31 };
> +
> +static u8 default_limits_local[3] = { 45, 50, 70 };  /* local,
> sensor1, sensor2 */ +static u8 default_limits_chip[3] = { 70, 65,
> 80 }; /* local, sensor1, sensor2 */ +
> +static const char *sensor_location[3];
>  
>  static int limit_adjust;
>  static int fan_speed = -1;
> -static bool verbose;
> +static int verbose;

You've scattered around quite a few code changes that do things like
change types, indentation, or variable names. You even re-order a couple
functions later on in the code! Your patch says that it's adding support
for reading the hard driver temperature sensor - these formatting
changes don't seem to be related to that goal. (And if they are, you
should mention them in the commit message.)

If you want to clean up the formatting of the source code, feel free to
do so; but it should be done as a separate patch from this one, so that
the individual feature changes and formatting changes can be reviewed
separately. Right now I can't even tell which parts of the patch are
functional changes, related to the goal of cooling your hard drive.

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Patch: Thermostat doesn't cool Harddrives (12 inch Powerbooks, Ibooks G4)

[Calvin Walton]

On Sat, 2012-08-18 at 11:57 +0200, Thomas Haschka wrote:
 Hello everybody!

Hi Thomas,
Unfortunately, there are quite a few things wrong with your patch that
will likely prevent any kernel developers from picking it up as-is.
Please read through the file Documentation/SubmittingPatches, it has a
lot of helpful hints.

I've added a few more comments inline...

 It was quite hot here in Austria in the recent days and I found out
 that the fan in my 12 inch powerbook only kicked in on CPU, GPU usage,
 while on Mac OS X sides the fan ran nearly all the time (hot as it
 was)... 
 
 I looked into the therm_adt746 driver and found out that the
 temperature sensor at the harddrive's bottom in the powerbook was not
 taken into account, but it should as one of the air inlets is just
 besides the harddrive, and it is thus also cooled by the fan, ( on can
 verfy that by spinning up the fans an reading out the hdd temp ) .. 
 
 I created a patch to fix the situation, and I guess that it is pretty
 urgent as I imagine lot's of powerbooks running with their disk
 uncooled.. 
 
 Here goes the patch
 
 Thanks for making it accessible.. 
 
 Thomas

You're missing the Signed-off-by line here. (It's described in the
SubmittingPatches file). Your patch description is pretty good - it
explains clearly why someone would want the patch.

 diff -uprN linux/drivers/macintosh/therm_adt746x.c
 linux-mod/drivers/macintosh/therm_adt746x.c ---
 linux/drivers/macintosh/therm_adt746x.c   2012-08-10
 12:42:38.0 +0200 +++
 linux-mod/drivers/macintosh/therm_adt746x.c   2012-08-18
 11:29:41.0 +0200 @@ -2,6 +2,7 @@

This patch has been word-wrapped and mangled by your email client, and
cannot be applied. The file Documentation/email-clients.txt in the
kernel source has some hints on how to set up your email client to avoid
this problem. (If you're using the Gmail web interface for this, you'll
have to use another client: the Gmail web interface cannot be fixed.)
 
 -static u8 TEMP_REG[3]= {0x26, 0x25, 0x27}; /* local, sensor1,
 sensor2 */ -static u8 LIMIT_REG[3]   = {0x6b, 0x6a, 0x6c}; /* local,
 sensor1, sensor2 */ -static u8 MANUAL_MODE[2] = {0x5c, 0x5d};   
 -static u8 REM_CONTROL[2] = {0x00, 0x40};
 -static u8 FAN_SPEED[2]   = {0x28, 0x2a};
 -static u8 FAN_SPD_SET[2] = {0x30, 0x31};
 -
 -static u8 default_limits_local[3] = {70, 50, 70};/* local,
 sensor1, sensor2 */ -static u8 default_limits_chip[3] = {80, 65,
 80};/* local, sensor1, sensor2 */ -static const char
 *sensor_location[3] = { ?, ?, ? }; +static u8 TEMP_REG[3] =
 { 0x26, 0x25, 0x27 }; /* local, sensor1, sensor2 */ +static u8
 LIMIT_REG[3] = { 0x6b, 0x6a, 0x6c };  /* local, sensor1, sensor2
 */ +static u8 MANUAL_MODE[2] = { 0x5c, 0x5d }; +static u8
 REM_CONTROL[2] = { 0x00, 0x40 }; +static u8 FAN_SPEED[2] = { 0x28,
 0x2a }; +static u8 FAN_SPD_SET[2] = { 0x30, 0x31 };
 +
 +static u8 default_limits_local[3] = { 45, 50, 70 };  /* local,
 sensor1, sensor2 */ +static u8 default_limits_chip[3] = { 70, 65,
 80 }; /* local, sensor1, sensor2 */ +
 +static const char *sensor_location[3];
  
  static int limit_adjust;
  static int fan_speed = -1;
 -static bool verbose;
 +static int verbose;

You've scattered around quite a few code changes that do things like
change types, indentation, or variable names. You even re-order a couple
functions later on in the code! Your patch says that it's adding support
for reading the hard driver temperature sensor - these formatting
changes don't seem to be related to that goal. (And if they are, you
should mention them in the commit message.)

If you want to clean up the formatting of the source code, feel free to
do so; but it should be done as a separate patch from this one, so that
the individual feature changes and formatting changes can be reviewed
separately. Right now I can't even tell which parts of the patch are
functional changes, related to the goal of cooling your hard drive.

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is there no nouveau driver maintainer listed in MAINTAINERS?

[Calvin Walton]

On Sat, 2012-08-04 at 17:49 +0200, richard -rw- weinberger wrote:
> On Sat, Aug 4, 2012 at 5:36 PM, Miles Lane  wrote:
> > I would like to report an issue in the nouveau driver, but don't know
> > who to report it to.
> 
> We have a script for this.
> 
> rw@raccoon:/media/data1/linux-2.6 (master)>
> ./scripts/get_maintainer.pl -f ./drivers/gpu/drm/nouveau
> Ben Skeggs  (commit_signer:399/442=90%)
> Dave Airlie  (commit_signer:40/442=9%)
> Martin Peres  (commit_signer:35/442=8%)
> linux-kernel@vger.kernel.org (open list)

In addition, the nouveau driver has its own mailing list, at
nouv...@lists.freedesktop.org - and they respond to issues on the
http://bugs.freedesktop.org/ bugzilla.

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is there no nouveau driver maintainer listed in MAINTAINERS?

[Calvin Walton]

On Sat, 2012-08-04 at 17:49 +0200, richard -rw- weinberger wrote:
 On Sat, Aug 4, 2012 at 5:36 PM, Miles Lane miles.l...@gmail.com wrote:
  I would like to report an issue in the nouveau driver, but don't know
  who to report it to.
 
 We have a script for this.
 
 rw@raccoon:/media/data1/linux-2.6 (master)
 ./scripts/get_maintainer.pl -f ./drivers/gpu/drm/nouveau
 Ben Skeggs bske...@redhat.com (commit_signer:399/442=90%)
 Dave Airlie airl...@redhat.com (commit_signer:40/442=9%)
 Martin Peres martin.pe...@labri.fr (commit_signer:35/442=8%)
 linux-kernel@vger.kernel.org (open list)

In addition, the nouveau driver has its own mailing list, at
nouv...@lists.freedesktop.org - and they respond to issues on the
http://bugs.freedesktop.org/ bugzilla.

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] NTFS code doesn't sanitize folder names sufficiently

[Calvin Walton]

On Thu, 2012-07-26 at 20:18 +0200, Marian Beermann wrote:
> Hello everyone,
> 
> today I noticed some very odd behaviour, which could lead people to 
> believe a loss of data, because it is possible to create directories 
> with backslashes in them.
> 
> I am currently running kernel 3.5.
> 
> To completly reproduce the problem to the full extend you'll need a 
> Windows computer, but to see whats wrong Linux completly suffices :-)
> 
> On a Linux computer
> 1. Create a directory named TestA on an NTFS partition
> 2. Create a subdirectory of TestA named TestB
> 3. Create a third directory alongside TestA named TestA\TestB (the 
> fundamental problem is this: backslashes in directory names)

If you're writing new directories to an NTFS partition, it's very
probable that you're not actually using the in-kernel NTFS driver at
all. It's more likely that you have the userspace (FUSE) NTFS driver
instead:
http://www.tuxera.com/community/ntfs-3g-download/

In fact, they have a FAQ about it the issue that you're seeing:
http://www.tuxera.com/community/ntfs-3g-faq/#posixfilenames2
You use the 'windows_names' mount option to disable creating file and
directory names that confuse windows.

Linux itself (and most native Linux programs) has no issues with
directory names containing the '\' character, of course; the only
characters that you cannot use are '/' and ASCII NUL, 0x00.

-- 
Calvin Walton 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] NTFS code doesn't sanitize folder names sufficiently

[Calvin Walton]

On Thu, 2012-07-26 at 20:18 +0200, Marian Beermann wrote:
 Hello everyone,
 
 today I noticed some very odd behaviour, which could lead people to 
 believe a loss of data, because it is possible to create directories 
 with backslashes in them.
 
 I am currently running kernel 3.5.
 
 To completly reproduce the problem to the full extend you'll need a 
 Windows computer, but to see whats wrong Linux completly suffices :-)
 
 On a Linux computer
 1. Create a directory named TestA on an NTFS partition
 2. Create a subdirectory of TestA named TestB
 3. Create a third directory alongside TestA named TestA\TestB (the 
 fundamental problem is this: backslashes in directory names)

If you're writing new directories to an NTFS partition, it's very
probable that you're not actually using the in-kernel NTFS driver at
all. It's more likely that you have the userspace (FUSE) NTFS driver
instead:
http://www.tuxera.com/community/ntfs-3g-download/

In fact, they have a FAQ about it the issue that you're seeing:
http://www.tuxera.com/community/ntfs-3g-faq/#posixfilenames2
You use the 'windows_names' mount option to disable creating file and
directory names that confuse windows.

Linux itself (and most native Linux programs) has no issues with
directory names containing the '\' character, of course; the only
characters that you cannot use are '/' and ASCII NUL, 0x00.

-- 
Calvin Walton calvin.wal...@kepstin.ca

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO_DELAY documentation

[Calvin Walton]

On Sun, 2008-02-17 at 20:21 -0500, George Spelvin wrote:
> "make oldconfig" doesn't know how to display the per-item help, so
> something like this is needed.  It was a squeeze to make all the help
> text, plus option prompt, fit into 24 lines.  If you think that's not
> a concern, some of the wording could be improved.

It's not really well documented (I found it by accident), but you can
see the individual item help; you just need to type the choice number
followed by a question mark, like so:

Choose SLAB allocator
  1. SLAB (SLAB)
> 2. SLUB (Unqueued Allocator) (SLUB)
choice[1-2?]: 1?

The regular slab allocator that is established and known to work
well in all environments. It organizes cache hot objects in
per cpu and per node queues. SLAB is the default choice for
a slab allocator.

-- 
Calvin Walton <[EMAIL PROTECTED]>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO_DELAY documentation

[Calvin Walton]

On Sun, 2008-02-17 at 20:21 -0500, George Spelvin wrote:
 make oldconfig doesn't know how to display the per-item help, so
 something like this is needed.  It was a squeeze to make all the help
 text, plus option prompt, fit into 24 lines.  If you think that's not
 a concern, some of the wording could be improved.

It's not really well documented (I found it by accident), but you can
see the individual item help; you just need to type the choice number
followed by a question mark, like so:

Choose SLAB allocator
  1. SLAB (SLAB)
 2. SLUB (Unqueued Allocator) (SLUB)
choice[1-2?]: 1?

The regular slab allocator that is established and known to work
well in all environments. It organizes cache hot objects in
per cpu and per node queues. SLAB is the default choice for
a slab allocator.

-- 
Calvin Walton [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Spurious completions during NCQ

[Calvin Walton]

On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote:
> I'm getting these on my Dell Latitude D830:
> 
> Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0 
> action 0x2 frozen
> Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ 
> issue=0x0 SAct=0x4 FIS=004040a1:0002

>In some cases, there are several cmd/res lines listed. It's
> happening about once an hour or so (not correlated with any other
> event that I can see). It doesn't seem to be affecting operation of
> the machine, but it's making me nervous.
> 
>Can anyone set my mind at rest? (Or suggest a fix?)

You didn't mention which SATA chipset your laptop has, but some quick
googling says that it's AHCI. Until 2.6.24, the AHCI driver has a
problem where it'll report superious NCQ completions due to a bug in the
driver logic.

> uname -a reports:
> Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux

The fix is simple, upgrade your kernel to 2.6.24 :)

>It's a kernel.org kernel with the patch for tickless operation on
> amd64.

Handily, the 2.6.24 kernel.org kernel includes amd64 tickless support
already.

-- 
Calvin Walton <[EMAIL PROTECTED]>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Spurious completions during NCQ

[Calvin Walton]

On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote:
 I'm getting these on my Dell Latitude D830:
 
 Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0 
 action 0x2 frozen
 Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ 
 issue=0x0 SAct=0x4 FIS=004040a1:0002

In some cases, there are several cmd/res lines listed. It's
 happening about once an hour or so (not correlated with any other
 event that I can see). It doesn't seem to be affecting operation of
 the machine, but it's making me nervous.
 
Can anyone set my mind at rest? (Or suggest a fix?)

You didn't mention which SATA chipset your laptop has, but some quick
googling says that it's AHCI. Until 2.6.24, the AHCI driver has a
problem where it'll report superious NCQ completions due to a bug in the
driver logic.

 uname -a reports:
 Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux

The fix is simple, upgrade your kernel to 2.6.24 :)

It's a kernel.org kernel with the patch for tickless operation on
 amd64.

Handily, the 2.6.24 kernel.org kernel includes amd64 tickless support
already.

-- 
Calvin Walton [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)

[Calvin Walton]

On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: 
> Hi,
> 
> I want to report that suspend to RAM stopped working on my Sony Vaio 
> VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down
> to:
> 
> commit bc71bec91f9875ef825d12104acf3bf4ca215fa4
> Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date:   Thu Jan 31 17:35:04 2008 -0800
> 
> ACPI: enable MWAIT for C1 idle

I normally hate to throw in a 'me-too', but I'm also seeing a
suspend-to-ram regression on my Thinkpad R61i that I've managed to
bisect down to the same patch series.

You beat me emailing the issue to the list by a few minutes :)

> The problem with suspend to RAM is that right after typing (from inside X)
> 'echo mem > /sys/power/state' the screen becomes black and the laptop 
> freezes. I have to use SysRq+b to reboot.

My symptoms in this case are slightly different - the suspend appears to
work correctly, and is fast. However, when I resume, the screen lights
up quickly, but the system hangs for nearly a minute with the suspend
light still on solid before it actually resumes. No delay is visible in
dmesg; this apparently happens before the "return to C".

> I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but
> the compilation fails. It turns out that I have to revert also 9a0b8415 and
> 9b12e18c to be able to compile without errors. 
> 
> After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel
> can suspend to RAM again (and I must say that it is better that 2.6.24, 
> because
> now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 
> to
> go back to X as I used to do before).

I just tried reverting the above-mentioned 3 commits, doing so fixes the
delay. 

> The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit 
> mode, with the
> following graphics card:
> VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated 
> Graphics Controller (rev 0c) (prog-if 00 [VGA])

Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo,
and a GM965 chip (using uvesafb)

> 
> If there is anything else I can do to help please let me know.
> 
> Carlos R. Mafra

-- 
Calvin Walton <[EMAIL PROTECTED]>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)

[Calvin Walton]

On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: 
 Hi,
 
 I want to report that suspend to RAM stopped working on my Sony Vaio 
 VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down
 to:
 
 commit bc71bec91f9875ef825d12104acf3bf4ca215fa4
 Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Date:   Thu Jan 31 17:35:04 2008 -0800
 
 ACPI: enable MWAIT for C1 idle

I normally hate to throw in a 'me-too', but I'm also seeing a
suspend-to-ram regression on my Thinkpad R61i that I've managed to
bisect down to the same patch series.

You beat me emailing the issue to the list by a few minutes :)

 The problem with suspend to RAM is that right after typing (from inside X)
 'echo mem  /sys/power/state' the screen becomes black and the laptop 
 freezes. I have to use SysRq+b to reboot.

My symptoms in this case are slightly different - the suspend appears to
work correctly, and is fast. However, when I resume, the screen lights
up quickly, but the system hangs for nearly a minute with the suspend
light still on solid before it actually resumes. No delay is visible in
dmesg; this apparently happens before the return to C.

 I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but
 the compilation fails. It turns out that I have to revert also 9a0b8415 and
 9b12e18c to be able to compile without errors. 
 
 After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel
 can suspend to RAM again (and I must say that it is better that 2.6.24, 
 because
 now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 
 to
 go back to X as I used to do before).

I just tried reverting the above-mentioned 3 commits, doing so fixes the
delay. 

 The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit 
 mode, with the
 following graphics card:
 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated 
 Graphics Controller (rev 0c) (prog-if 00 [VGA])

Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo,
and a GM965 chip (using uvesafb)

 
 If there is anything else I can do to help please let me know.
 
 Carlos R. Mafra

-- 
Calvin Walton [EMAIL PROTECTED]


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with ata layer in 2.6.24

[Calvin Walton]

On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote:
> On Monday 28 January 2008, Mikael Pettersson wrote:
> >Unfortunately we also see:
> > > [   48.285456] nvidia: module license 'NVIDIA' taints kernel.
> > > [   48.549725] ACPI: PCI Interrupt :02:00.0[A] -> Link [APC4] -> GSI
> > > 19 (level, high) -> IRQ 20 [   48.550149] NVRM: loading NVIDIA UNIX x86
> > > Kernel Module  169.07  Thu Dec 13 18:42:56 PST 2007
> >
> >We have no way of debugging that module, so please try 2.6.24 without it.
> 
> Sorry, I can't do this and have a working machine.  The nv driver has 
> suffered 
> bit rot or something since the FC2 days when it COULD run a 19" crt at 
> 1600x1200, and will not drive this 20" wide screen lcd 1680x1050 monitor at 
> more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg 
> compressed to 10%.  The system is not usable on a day to basis without the 
> nvidia driver.

You should probably give the nouveau[1] driver a try, if only for
testing purposes; if you are running an NV4x (G6x or G7x) card in
particular, it works a lot better than the nv driver for 2d support.

1. http://nouveau.freedesktop.org/wiki/InstallNouveau

-- 
Calvin Walton <[EMAIL PROTECTED]>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with ata layer in 2.6.24

[Calvin Walton]

On Mon, 2008-01-28 at 11:35 -0500, Gene Heskett wrote:
 On Monday 28 January 2008, Mikael Pettersson wrote:
 Unfortunately we also see:
   [   48.285456] nvidia: module license 'NVIDIA' taints kernel.
   [   48.549725] ACPI: PCI Interrupt :02:00.0[A] - Link [APC4] - GSI
   19 (level, high) - IRQ 20 [   48.550149] NVRM: loading NVIDIA UNIX x86
   Kernel Module  169.07  Thu Dec 13 18:42:56 PST 2007
 
 We have no way of debugging that module, so please try 2.6.24 without it.
 
 Sorry, I can't do this and have a working machine.  The nv driver has 
 suffered 
 bit rot or something since the FC2 days when it COULD run a 19 crt at 
 1600x1200, and will not drive this 20 wide screen lcd 1680x1050 monitor at 
 more than 800x600, which is absolutely butt ugly fuzzy, looking like a jpg 
 compressed to 10%.  The system is not usable on a day to basis without the 
 nvidia driver.

You should probably give the nouveau[1] driver a try, if only for
testing purposes; if you are running an NV4x (G6x or G7x) card in
particular, it works a lot better than the nv driver for 2d support.

1. http://nouveau.freedesktop.org/wiki/InstallNouveau

-- 
Calvin Walton [EMAIL PROTECTED]

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/