This fix is needed for AMD family 10h CPUs.
It prevents auto select of mwait_idle for AMD CPUs.
MWAIT does not enter C-states on family 10h and more
power saving is reached by entering C1 with
default_idle.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu
for benchmarking.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/process.c|9 +++--
arch/x86_64/kernel/setup.c |4
include/asm-x86_64/cpufeature.h |1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86_64/kernel/process.c
for benchmarking.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
arch/x86_64/kernel/process.c|9 +++--
arch/x86_64/kernel/setup.c |4
include/asm-x86_64/cpufeature.h |1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86_64/kernel/process.c b/arch
This fix is needed for AMD family 10h CPUs.
It prevents auto select of mwait_idle for AMD CPUs.
MWAIT does not enter C-states on family 10h and more
power saving is reached by entering C1 with
default_idle.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/amd.c
Actually I have also written patches to clear the MWAIT flag
for AMD CPUs.
But after re-reading of specs (also Intel's specs) I preferred
to keep the MWAIT flag but to introduce a MWAIT_NO_CSTATE flag.
I think this is the cleaner solution.
Regards,
Andreas
-
To unsubscribe from this list:
Hi,
I send this as RFC because I won't manage it to test it
before end of Easter but want to have a consensus about
how the final patch should look like.
Andi,
what do you finally prefer?
(1) Something like the attached patch or
(2) a version which keeps to the MWAIT flag for Fam10 but
On Thu, Apr 05, 2007 at 05:37:17PM +0200, Andi Kleen wrote:
>
> > > > This patch will enable default_idle for non-Intel
> > > > CPUs even if mwait is supported.
> > >
> > > It would be better to clear MONITOR/MWAIT in the AMD specific
> > > CPU initialize code than add workarounds everywhere
On Thu, Apr 05, 2007 at 04:24:45PM +0200, Andi Kleen wrote:
> On Thursday 05 April 2007 16:00:45 Andreas Herrmann wrote:
> >
> > Commit 991528d7348667924176f3e29addea0675298944
> > introduced mwait_idle which is supposed to work
> > for Intel CPUs starting with C
Commit 991528d7348667924176f3e29addea0675298944
introduced mwait_idle which is supposed to work
for Intel CPUs starting with Core Duo.
AMD Fam10 processors won't enter C1 on mwait.
This patch will enable default_idle for non-Intel
CPUs even if mwait is supported.
Signed-off-by: Andreas Herrmann
Hi,
I send this as RFC because I won't manage it to test it
before end of Easter but want to have a consensus about
how the final patch should look like.
Andi,
what do you finally prefer?
(1) Something like the attached patch or
(2) a version which keeps to the MWAIT flag for Fam10 but
Commit 991528d7348667924176f3e29addea0675298944
introduced mwait_idle which is supposed to work
for Intel CPUs starting with Core Duo.
AMD Fam10 processors won't enter C1 on mwait.
This patch will enable default_idle for non-Intel
CPUs even if mwait is supported.
Signed-off-by: Andreas Herrmann
On Thu, Apr 05, 2007 at 04:24:45PM +0200, Andi Kleen wrote:
On Thursday 05 April 2007 16:00:45 Andreas Herrmann wrote:
Commit 991528d7348667924176f3e29addea0675298944
introduced mwait_idle which is supposed to work
for Intel CPUs starting with Core Duo.
AMD Fam10 processors won't
On Thu, Apr 05, 2007 at 05:37:17PM +0200, Andi Kleen wrote:
This patch will enable default_idle for non-Intel
CPUs even if mwait is supported.
It would be better to clear MONITOR/MWAIT in the AMD specific
CPU initialize code than add workarounds everywhere else.
Why is
On Tue, Feb 06, 2007 at 10:54:23AM -0700, [EMAIL PROTECTED] wrote:
> "Andreas Herrmann" <[EMAIL PROTECTED]> writes:
> > On Mon, Feb 05, 2007 at 05:26:12PM -0700, [EMAIL PROTECTED] wrote:
> >> "Andreas Herrmann" <[EMAIL PROTECTED]> writes:
> >
On Tue, Feb 06, 2007 at 11:54:57AM +0100, Andi Kleen wrote:
> On Tuesday 06 February 2007 10:53, Jan Beulich wrote:
> > >> I don't think I remember a restriction here, at least not below 44 bits
> > >> (that's where pfn-s would need to become 64-bit wide).
> > >
> > >The i386 mm code only supports
On Tue, Feb 06, 2007 at 09:31:45AM +, Jan Beulich wrote:
> >>> Andi Kleen <[EMAIL PROTECTED]> 06.02.07 08:53 >>>
> >On Monday 05 February 2007 23:50, Siddha, Suresh B wrote:
> >> On Mon, Feb 05, 2007 at 06:19:59PM +0100, Andreas Herrmann wrote:
>
On Mon, Feb 05, 2007 at 05:26:12PM -0700, [EMAIL PROTECTED] wrote:
> "Andreas Herrmann" <[EMAIL PROTECTED]> writes:
> > mtrr: fix issues with large addresses
> >
> > Fixes some issues with /proc/mtrr interface:
> > o If physical address size cro
On Mon, Feb 05, 2007 at 05:26:12PM -0700, [EMAIL PROTECTED] wrote:
Andreas Herrmann [EMAIL PROTECTED] writes:
mtrr: fix issues with large addresses
Fixes some issues with /proc/mtrr interface:
o If physical address size crosses the 44 bit boundary
size_or_mask is evaluated wrong
o
On Tue, Feb 06, 2007 at 09:31:45AM +, Jan Beulich wrote:
Andi Kleen [EMAIL PROTECTED] 06.02.07 08:53
On Monday 05 February 2007 23:50, Siddha, Suresh B wrote:
On Mon, Feb 05, 2007 at 06:19:59PM +0100, Andreas Herrmann wrote:
o added check to restrict base address to 36 bit on i386
On Tue, Feb 06, 2007 at 11:54:57AM +0100, Andi Kleen wrote:
On Tuesday 06 February 2007 10:53, Jan Beulich wrote:
I don't think I remember a restriction here, at least not below 44 bits
(that's where pfn-s would need to become 64-bit wide).
The i386 mm code only supports 4 entries in
On Tue, Feb 06, 2007 at 10:54:23AM -0700, [EMAIL PROTECTED] wrote:
Andreas Herrmann [EMAIL PROTECTED] writes:
On Mon, Feb 05, 2007 at 05:26:12PM -0700, [EMAIL PROTECTED] wrote:
Andreas Herrmann [EMAIL PROTECTED] writes:
The limit is per cpu not per architecture. So if you run a
cpu
than 44 bit
o added check to restrict base address to 36 bit on i386
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
--
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index f77fc53..aa21d15 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arc
than 44 bit
o added check to restrict base address to 36 bit on i386
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
--
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index f77fc53..aa21d15 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arch/i386
mtrr: fix size_or_mask and size_and_mask
This fixes two bugs in /proc/mtrr interface:
o If physical address size crosses the 44 bit boundary
size_or_mask is evaluated wrong.
o size_and_mask limits width of physical base
address for an MTRR to be less than 44 bits.
Signed-off-by: Andreas
mtrr: fix size_or_mask and size_and_mask
This fixes two bugs in /proc/mtrr interface:
o If physical address size crosses the 44 bit boundary
size_or_mask is evaluated wrong.
o size_and_mask limits width of physical base
address for an MTRR to be less than 44 bits.
Signed-off-by: Andreas
On 27.08.2005 19:38 James Bottomley <[EMAIL PROTECTED]> wrote:
> > this patch fixes a severe problem with 2.6.13-rc7.
> >
> > Due to recent SCSI changes it is not possible to add any
> > LUNs to the zfcp device driver anymore. With registration
> > of remote ports this is fixed.
> >
On 27.08.2005 19:38 James Bottomley [EMAIL PROTECTED] wrote:
this patch fixes a severe problem with 2.6.13-rc7.
Due to recent SCSI changes it is not possible to add any
LUNs to the zfcp device driver anymore. With registration
of remote ports this is fixed.
Please
then please integrate it
in 2.6.13.1
Thanks a lot.
Regards,
Andreas
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
diffstat:
zfcp_aux.c | 29 +++--
zfcp_ccw.c | 10 ++
zfcp_def.h |2 +-
zfcp_erp.c | 25 ++---
zfcp
then please integrate it
in 2.6.13.1
Thanks a lot.
Regards,
Andreas
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
diffstat:
zfcp_aux.c | 29 +++--
zfcp_ccw.c | 10 ++
zfcp_def.h |2 +-
zfcp_erp.c | 25 ++---
zfcp_ext.h
Simon Derr <[EMAIL PROTECTED]> wrote:
> It is sufficient to have a few HBAs and to insmod/rmmod the driver a
few
> times.
> Since the host_no is choosen with a mere counter increment
> in scsi_host_alloc():
> shost->host_no = scsi_host_next_hn++; /* XXX(hch): still
Simon Derr [EMAIL PROTECTED] wrote:
It is sufficient to have a few HBAs and to insmod/rmmod the driver a
few
times.
Since the host_no is choosen with a mere counter increment
in scsi_host_alloc():
shost-host_no = scsi_host_next_hn++; /* XXX(hch): still racy */
will fix the problem.
Sorry, for any inconvenience.
Regards,
Andreas
zfcp: fix compile error
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
diff -bBrauN linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c
linux-2.6.x/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c
,
Andreas
zfcp: fix compile error
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
diff -bBrauN linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c
linux-2.6.x/drivers/s390/scsi/zfcp_aux.c
--- linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c 2005-04-21
12:36:44.0 +0200
+++ linux-2.6.x
301 - 333 of 333 matches
Mail list logo
