family 10h and 11h CPU's northbridges
to
k8topology discovery.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/mm/k8topology_64.c b/arch/x86/mm/k8t
family 10h and 11h CPU's northbridges
to
k8topology discovery.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Acked-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/mm/k8topology_64.c b/arch/x86/mm/k8topology_64.c
index a96006f
On Thursday 17 January 2008, Joachim Deguara wrote:
> On Tuesday 15 January 2008, H. Peter Anvin wrote:
> > Joachim Deguara wrote:
> > > Hello,
> > > I am trying to access the x86 git tree behind a proxy and therefore
> > > over the http address. This works
On Thursday 17 January 2008, Joachim Deguara wrote:
On Tuesday 15 January 2008, H. Peter Anvin wrote:
Joachim Deguara wrote:
Hello,
I am trying to access the x86 git tree behind a proxy and therefore
over the http address. This works for Linus' tree but not for the x86
tree
On Tuesday 15 January 2008, H. Peter Anvin wrote:
> Joachim Deguara wrote:
> > Hello,
> > I am trying to access the x86 git tree behind a proxy and therefore
> > over the http address. This works for Linus' tree but not for the x86
> > tree. Please follow these guide
On Tuesday 15 January 2008, H. Peter Anvin wrote:
Joachim Deguara wrote:
Hello,
I am trying to access the x86 git tree behind a proxy and therefore
over the http address. This works for Linus' tree but not for the x86
tree. Please follow these guidelines to enable http access
Hello,
I am trying to access the x86 git tree behind a proxy and therefore over the
http address. This works for Linus' tree but not for the x86 tree. Please
follow these guidelines to enable http access.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
Hello,
I am trying to access the x86 git tree behind a proxy and therefore over the
http address. This works for Linus' tree but not for the x86 tree. Please
follow these guidelines to enable http access.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
use eax
> AK: moved change to extended space probing to different patch
> AK: reworked with inlines according to Linus' requirements.
> AK: improve comments.
>
> Signed-off-by: dean gaudet <[EMAIL PROTECTED]>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
ACKED-by: Joach
space probing to different patch
AK: reworked with inlines according to Linus' requirements.
AK: improve comments.
Signed-off-by: dean gaudet [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
ACKED-by: Joachim Deguara [EMAIL PROTECTED]
---
arch/i386/pci/mmconfig.c | 14
On Thursday 09 August 2007 01:52:37 Frank Hale wrote:
> I have the latest BIOS update for my laptop which is buggy I suppose.
> There has been only one update this year if my memory serves me
> correctly. Is there any hope to fix this or am I at the mercy of the
> hardware vendor which apparenlty
On Thursday 09 August 2007 01:52:37 Frank Hale wrote:
I have the latest BIOS update for my laptop which is buggy I suppose.
There has been only one update this year if my memory serves me
correctly. Is there any hope to fix this or am I at the mercy of the
hardware vendor which apparenlty
On Tuesday 07 August 2007 22:19:35 Yinghai Lu wrote:
> [PATCH] x86_64: clear IO_APIC before enabing apic error vector.
>
> some apic id lifting system: 4 socket quad core, 8 socket quad core will do
> apic id lifting for BSP.
>
> but io-apic regs for ExtINT still use 0 as dest.
good catch!
>
On Wednesday 08 August 2007 02:06:31 Andi Kleen wrote:
> On Tue, Aug 07, 2007 at 06:15:37PM -0400, Cal Peake wrote:
> > On Fri, 3 Aug 2007, Linus Torvalds wrote:
> > > > MSR_K8_ENABLE_C1E lo == 0x04c14015
> > > > MSR_K8_ENABLE_C1E hi == 0x
> > > > lo & ENABLE_C1E_MASK == 0
> > >
> > > And
On Wednesday 08 August 2007 02:06:31 Andi Kleen wrote:
On Tue, Aug 07, 2007 at 06:15:37PM -0400, Cal Peake wrote:
On Fri, 3 Aug 2007, Linus Torvalds wrote:
MSR_K8_ENABLE_C1E lo == 0x04c14015
MSR_K8_ENABLE_C1E hi == 0x
lo ENABLE_C1E_MASK == 0
And yeah, that claims that
On Tuesday 07 August 2007 22:19:35 Yinghai Lu wrote:
[PATCH] x86_64: clear IO_APIC before enabing apic error vector.
some apic id lifting system: 4 socket quad core, 8 socket quad core will do
apic id lifting for BSP.
but io-apic regs for ExtINT still use 0 as dest.
good catch!
diff --git
On Thursday 02 August 2007 21:10:29 Michael Chan wrote:
> Alternatively, we can also fix it by calling pci_enable_device() again
> in tg3_open(). But I think it is better to just always save and restore
> in suspend/resume. bnx2.c will also require the same fix.
>
> Thanks Joachim for helping to
On Thursday 02 August 2007 21:10:29 Michael Chan wrote:
Alternatively, we can also fix it by calling pci_enable_device() again
in tg3_open(). But I think it is better to just always save and restore
in suspend/resume. bnx2.c will also require the same fix.
Thanks Joachim for helping to
On Thursday 02 August 2007 10:05:44 Joachim Deguara wrote:
> On Wednesday 01 August 2007 23:00:23 Michael Chan wrote:
> > On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote:
> > The problem is that memory enable and bus master were not set in PCI
> > register 4 after resume
On Wednesday 01 August 2007 23:00:23 Michael Chan wrote:
> On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote:
> > You have 2 Broadcom devices in your system. 07:00.0 is a wireless
> > device, I think. 8:4.0 is the tg3 device.
> >
> > It's clear that the tg3 device is still in D3 state after
On Wednesday 01 August 2007 23:00:23 Michael Chan wrote:
On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote:
You have 2 Broadcom devices in your system. 07:00.0 is a wireless
device, I think. 8:4.0 is the tg3 device.
It's clear that the tg3 device is still in D3 state after resume
On Thursday 02 August 2007 10:05:44 Joachim Deguara wrote:
On Wednesday 01 August 2007 23:00:23 Michael Chan wrote:
On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote:
The problem is that memory enable and bus master were not set in PCI
register 4 after resume. This also explains
On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a
suspend to ram with the latet 2.6.23-rc1-git9. The tg3 works fine with s2ram
in 2.6.22.1. The tell tail signs that is dead is this message from the
kernel log:
[6.754133] tg3: eth0: No firmware running.
[
On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a
suspend to ram with the latet 2.6.23-rc1-git9. The tg3 works fine with s2ram
in 2.6.22.1. The tell tail signs that is dead is this message from the
kernel log:
[6.754133] tg3: eth0: No firmware running.
[
On Wednesday 25 July 2007 09:56:38 Henri Hunnekens wrote:
> Some more information, the problems occurs on a SMP machine. I've
> added the system logging which displays the CPU speed. The last line
> shows an inaccurate processor speed! I'll try an update, but I expect
> this has something to do
On Wednesday 25 July 2007 09:56:38 Henri Hunnekens wrote:
Some more information, the problems occurs on a SMP machine. I've
added the system logging which displays the CPU speed. The last line
shows an inaccurate processor speed! I'll try an update, but I expect
this has something to do with
On Friday 20 July 2007 09:25:22 Nick Piggin wrote:
> On Wed, Jul 18, 2007 at 11:11:30AM +0200, Joachim Deguara wrote:
> > While learning about schedstats I found that the documentation in the
> > tree is old. I updated it and found some interesting stuff like
> > schedstats v
On Friday 20 July 2007 09:25:22 Nick Piggin wrote:
On Wed, Jul 18, 2007 at 11:11:30AM +0200, Joachim Deguara wrote:
While learning about schedstats I found that the documentation in the
tree is old. I updated it and found some interesting stuff like
schedstats version 14 is the same
On Wednesday 18 July 2007 11:42:20 Andi Kleen wrote:
> On Wednesday 18 July 2007 11:30:01 Joachim Deguara wrote:
> > The problem with NUMA distances in the SLIT is that they are often wrong,
> > oh wait they aren't there at all because the BIOS didn't create a SLIT
> > since
Most x86 NUMA systems do not have a SLIT provided by them from the BIOS. We
want to fake this by either creating one or copying the original. The reason
to do this is so to later be able to alter it.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
--
Index: kernel/drivers/acpi/
The problem with NUMA distances in the SLIT is that they are often wrong, oh
wait they aren't there at all because the BIOS didn't create a SLIT since
Windows does not use it. If Linux does not find a slit it just says the
distance to local=10 and remote=20 according to ACPI spec. The problem
systems but
wrong for 4P and larger.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
--
Index: kernel/drivers/base/node.c
===
--- kernel.orig/drivers/base/node.c
+++ kernel/drivers/base/node.c
@@ -129,7 +129,30 @@ static s
anymore. Nick
had made them irrelevant in commit 476d139c218e44e045e4bc6d4cc02b010b343939
but never removed them.
Thanks to Rick's perl script who I borrowed some of the updated descriptions
from.
-Joachim
--
Updating schedstats documentation from version 10 to 14.
Signed-off-by: Joachim
anymore. Nick
had made them irrelevant in commit 476d139c218e44e045e4bc6d4cc02b010b343939
but never removed them.
Thanks to Rick's perl script who I borrowed some of the updated descriptions
from.
-Joachim
--
Updating schedstats documentation from version 10 to 14.
Signed-off-by: Joachim
The problem with NUMA distances in the SLIT is that they are often wrong, oh
wait they aren't there at all because the BIOS didn't create a SLIT since
Windows does not use it. If Linux does not find a slit it just says the
distance to local=10 and remote=20 according to ACPI spec. The problem
systems but
wrong for 4P and larger.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
--
Index: kernel/drivers/base/node.c
===
--- kernel.orig/drivers/base/node.c
+++ kernel/drivers/base/node.c
@@ -129,7 +129,30 @@ static ssize_t
Most x86 NUMA systems do not have a SLIT provided by them from the BIOS. We
want to fake this by either creating one or copying the original. The reason
to do this is so to later be able to alter it.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
--
Index: kernel/drivers/acpi/numa.c
On Wednesday 18 July 2007 11:42:20 Andi Kleen wrote:
On Wednesday 18 July 2007 11:30:01 Joachim Deguara wrote:
The problem with NUMA distances in the SLIT is that they are often wrong,
oh wait they aren't there at all because the BIOS didn't create a SLIT
since Windows does not use
On Monday 16 July 2007 15:23:58 [EMAIL PROTECTED] wrote:
> --
> Hey,
>
> Are there functions to read the BIOS given the address? Does ioremap() work
> in this case too?
I can't answer that but take a look how flashrom [1] does it.
-Joachim
[1] http://linuxbios.org/Flashrom
-
To unsubscribe
On Monday 16 July 2007 15:23:58 [EMAIL PROTECTED] wrote:
--
Hey,
Are there functions to read the BIOS given the address? Does ioremap() work
in this case too?
I can't answer that but take a look how flashrom [1] does it.
-Joachim
[1] http://linuxbios.org/Flashrom
-
To unsubscribe from
On Saturday 16 June 2007 22:40:53 Mr. James W. Laferriere wrote:
> Hello All , Does anoyone know howto identify a cause for these(*) ?
> Or of any tools to help in the identification of the cause ?
> So far the Machine checks only happen when I am running bonnie++ against
>
On Saturday 16 June 2007 22:40:53 Mr. James W. Laferriere wrote:
Hello All , Does anoyone know howto identify a cause for these(*) ?
Or of any tools to help in the identification of the cause ?
So far the Machine checks only happen when I am running bonnie++ against
my
On Friday 01 June 2007 18:11:11 Matt Mackall wrote:
> On Thu, May 31, 2007 at 10:01:09PM +0200, Ingo Molnar wrote:
> > * K.R. Foley <[EMAIL PROTECTED]> wrote:
> > > Ingo Molnar wrote:
> > > > * K.R. Foley <[EMAIL PROTECTED]> wrote:
> > > >> Ingo,
> > > >>
> > > >> I believe that patch-2.6.21.3-rt9
On Friday 01 June 2007 18:11:11 Matt Mackall wrote:
On Thu, May 31, 2007 at 10:01:09PM +0200, Ingo Molnar wrote:
* K.R. Foley [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* K.R. Foley [EMAIL PROTECTED] wrote:
Ingo,
I believe that patch-2.6.21.3-rt9 is misnamed. It applies
as the HPET does. I
also rearranged the math to make the femtoseconds and kHz clearer but it does
loose a negligible amount of precision.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
Index: 2.6-rt/arch/x86_64/kernel
as the HPET does. I
also rearranged the math to make the femtoseconds and kHz clearer but it does
loose a negligible amount of precision.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
Index: 2.6-rt/arch/x86_64/kernel/tsc.c
On Friday 18 May 2007 01:38:13 [EMAIL PROTECTED] wrote:
> Andi Kleen wrote:
> > Hmpf.
> >
> > We cold either use rdmsr_safe or add a family check again or clear it
> > in k6 setup. I think clearing it in setup is cleanest.
> >
> > Does this patch work?
> >
> > -Andi
> >
> > Clear MCE flag on AMD
On Friday 18 May 2007 01:38:13 [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
Hmpf.
We cold either use rdmsr_safe or add a family check again or clear it
in k6 setup. I think clearing it in setup is cleanest.
Does this patch work?
-Andi
Clear MCE flag on AMD K6
It reports
On Monday 23 April 2007 11:32, Andi Kleen wrote:
> On Monday 23 April 2007 11:14:10 Joachim Deguara wrote:
> > This patches fixes the silent data corruption problems being seen using
> > the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia
> > CK804 syst
.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
---
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 2bac8c6..0bae862 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -519,7 +519,11 @@ static __init int init_k8_gatt(str
.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
---
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 2bac8c6..0bae862 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -519,7 +519,11 @@ static __init int init_k8_gatt(struct ag
On Monday 23 April 2007 11:32, Andi Kleen wrote:
On Monday 23 April 2007 11:14:10 Joachim Deguara wrote:
This patches fixes the silent data corruption problems being seen using
the GART iommu where 4kB of data where incorrect (seen mostly on Nvidia
CK804 systems).
Performance numbers? How
On Saturday 14 April 2007 17:39:28 Robert Hancock wrote:
> Espen Fjellvær Olsen wrote:
> > As far as we know there wasnt any unuasal activity on the server at the
> > time.
> > We updated glibc yesterday, but that shouldnt really cause such a
> > problem. So now we wonder if this might be an MCE
On Saturday 14 April 2007 17:39:28 Robert Hancock wrote:
Espen Fjellvær Olsen wrote:
As far as we know there wasnt any unuasal activity on the server at the
time.
We updated glibc yesterday, but that shouldnt really cause such a
problem. So now we wonder if this might be an MCE bug, or
in CPUID.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
Index: 2.6-linus-git/arch/i386/kernel/cpu/mcheck/mce.c
===
--- 2.6-linus-git.orig/arch/i386/kernel/cpu/mcheck/mce.c
+++ 2.6-linus-git/arch/i386/kernel/cpu/mcheck/mce.c
@@
in CPUID.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
Index: 2.6-linus-git/arch/i386/kernel/cpu/mcheck/mce.c
===
--- 2.6-linus-git.orig/arch/i386/kernel/cpu/mcheck/mce.c
+++ 2.6-linus-git/arch/i386/kernel/cpu/mcheck/mce.c
@@ -38,8
56 matches
Mail list logo
