right-by-3 to compute PCI device numbers.
This patch assumes that it is being applied _after_ my previous patch
has already been integrated. I mailed out that patch on 1/17/2008
with subject "Re: [PATCH] AMD Thermal Interrupt Support".
--
Russell Leidich
Signed-off-by: Russell Leidi
P.S. This patch also moves the responsibility for enabling hardware
thermal control from the OS to the BIOS.
On Feb 3, 2008 10:13 PM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> All,
>
> You can imagine my dismay when I recently learned that, after all our
> collective effort
On Feb 3, 2008 11:20 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 03, 2008 at 10:13:53PM -0800, Russell Leidich wrote:
> > All,
> >
> > You can imagine my dismay when I recently learned that, after all our
> > collective effort, hardware thermal throttl
All,
Sorry this took so long. I have attached the Kconfig changes
requested by Andi, appended to the original patch.
On Feb 4, 2008 11:22 AM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> On Feb 3, 2008 11:20 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > On Sun, Feb 03, 200
> > +/*
> > + * Currently trivial. Write the real->protected mode
> > + * bootstrap into the page concerned. The caller
> > + * has made sure it's suitably aligned.
> > + */
> > +
> > +unsigned long setup_trampoline(void)
> > +{
> > + void *tramp = __va(TRAMPOLINE_BASE);
> > + memcpy(tramp, trampoline_data, trampoline_end - trampoline_data);
> > + return virt_to_phys(tramp);
> > +}
> > +#endif /* CONFIG_X86_TRAMPOLINE */
> > Index: linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/sleep.c
> > ===
> > --- linux-2.6.25-rc2-mm1.orig/arch/x86/kernel/acpi/sleep.c
> > +++ linux-2.6.25-rc2-mm1/arch/x86/kernel/acpi/sleep.c
> > @@ -10,7 +10,6 @@
> > #include
> > #include
> >
> > -#include
> > #include "realmode/wakeup.h"
> > #include "sleep.h"
> >
> > Index: linux-2.6.25-rc2-mm1/include/asm-x86/trampoline.h
> > ===
> > --- /dev/null
> > +++ linux-2.6.25-rc2-mm1/include/asm-x86/trampoline.h
> > @@ -0,0 +1,18 @@
> > +#ifndef __TRAMPOLINE_HEADER
> > +#define __TRAMPOLINE_HEADER
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#define TRAMPOLINE_BASE 0x6000
> > +
> > +/*
> > + * Trampoline 80x86 program as an array.
> > + */
> > +extern const unsigned char trampoline_data[];
> > +extern const unsigned char trampoline_end[];
> > +
> > +extern unsigned long setup_trampoline(void);
> > +
> > +#endif /* __ASSEMBLY__ */
> > +
> > +#endif /* __TRAMPOLINE_HEADER */
>
--
Russell Leidich
--
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/
hermal.c
/home/rml/linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/mce_thermal.c
--- linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/mce_thermal.c
1969-12-31 16:00:00.0 -0800
+++ /home/rml/linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/mce_thermal.c
2008-01-04 11:43:06.750303000 -0800
@@ -0,0 +1,37 @
ll function correctly, hence my
reliance on the whitelist. In my view, anyone who adds an ID to a
whitelist (or just a list, for that matter) is obligated to perform a
static analysis (i.e. grep for "k8_northbridges") of the implications
of such act; therefore, I'm not too concerned abou
iance on the whitelist.
>
> ? but you don't have a whitelist, you have a black list.
I'm using k8_northbridges[] as my de-facto whitelist, because I
believe that future CPUs will probably function properly. (It's hard
to imagine AMD removing or breaking a perfectly functional
OK all, I fixed the comments about accessing PCI config space in an
interrupt context.
Can someone please give me a thumbs up or down about checking this in?
If it's thumbs up, I will do a final retest and mail back a
Signed-off-by patch.
--
Russell Leidich
diff -uprN /home/rml/linux-2
a final test and submit the official patch this week.
>
> -Andi
>
>
--
Russell Leidich
--
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/
/arch/x86-64/kernel/Makefile
2.6.18/arch/x86-64/kernel/mce_amd.c
2.6.18/arch/x86-64/kernel/mce_intel.c
2.6.18/arch/x86-64/kernel/mce_thermal.c (new)
2.6.18/include/asm-x86-64/kernel/mce.h
Signed-off-by: Russell Leidich <[EMAIL PROTECTED]>
--
Russell Leidich
patch
Description: Binary data
I am reapplying this patch to 2.6.24. I will send an update when it's done.
On Dec 11, 2007 10:44 AM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> This patch adds thermal interrupt logging support for AMD Barcelona to
> 2.6.18. In the style of the existing Intel implem
er from assembly language to either Intel or AMD C code. Trouble
is, at compiletime, we might have both Intel and AMD support
installed, but only one of them should actually receive the interrupt
at runtime. So I think I need to do runtime binding, unless I want to
do CPUID inside the ISR. What do yo
OK, given our discussion, perhaps the attached revised patch will be
more to your liking.
If so, let me know and I'll give it one last paranoid test, then mail
you a Signed-off-by patch.
--
Russell Leidich
diff -uprN /home/rml/linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/Makefile
/hom
On Dec 30, 2007 10:39 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> "Russell Leidich" <[EMAIL PROTECTED]> writes:
>
> Not sure you have addressed any of my feedback; don't see many changes.
I emailed you on 12/7/2007 and never heard back, so I assumed that you
ha
On Jan 2, 2008 12:00 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 11:43:08AM -0800, Russell Leidich wrote:
> > > > + */
> > > > + for (nb_num = 0; nb_num < num_k8_northbridges; nb_num++) {
> > > > +
On Jan 2, 2008 1:33 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 2, 2008 10:12 PM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> > On Jan 2, 2008 12:00 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 02, 2008 at 11:43:08AM -0800, Russell Lei
this chip, so I can't
confirm one way or another. In any event, I have no way to test this
CPU. I think it's a small sacrifice to assume that it doesn't work.
Someone could always add support later.
>
> -Andi
>
--
Russell Leidich
--
To unsubscribe from this list: send th
, AMD and Intel use radically different architectures
for the purpose of reporting throttling events.) At that point, an
MCE is logged if and only if the temperature has made a low-to-high
transition. Rate limiting is employed so as not to spam the log.
--
Russell Leidich
Signed-off-by: Russell Leidic
Jan 10, 2008 6:21 PM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> All,
>
> Here's the hopefully-final version of the patch, which I have just
> tested on Intel and AMD.
>
> In my AMD test, I happened to discover that although MCEs were being
> logged, the MCE counter at
>
include/asm-x86/mce.h
New files:
arch/x86/kernel/cpu/mcheck/mce_thermal.c
Signed-off-by Russell Leidich <[EMAIL PROTECTED]>
--
Russell Leidich
diff -uprN linux-2.6.24-rc5.orig/arch/x86/kernel/cpu/mcheck/Makefile
linux-2.6.24-rc5/arch/x86/kernel/cpu/mcheck/Makefile
--- linux-2.6.24-rc
21 matches
Mail list logo
