On Sat, 02 Feb 2008 16:27:40 -0800 Harvey Harrison <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-02-02 at 16:10 -0800, Andrew Morton wrote:
> > On Thu, 17 Jan 2008 17:06:33 -0800 "Russell Leidich" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > > Here's the hopefully-final version of the patch, which I hav
On Sat, 2008-02-02 at 16:10 -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:06:33 -0800 "Russell Leidich" <[EMAIL PROTECTED]>
> wrote:
>
> > > Here's the hopefully-final version of the patch, which I have just
> > > tested on Intel and AMD.
>
> Curious. This just broke.
>
> i386 allmodcon
On Thu, 17 Jan 2008 17:06:33 -0800 "Russell Leidich" <[EMAIL PROTECTED]> wrote:
> > Here's the hopefully-final version of the patch, which I have just
> > tested on Intel and AMD.
Curious. This just broke.
i386 allmodconfig:
arch/x86/kernel/cpu/mcheck/p4.o: In function `smp_thermal_interrupt':
All,
Sorry, but the Google code review process has turned up a subtle issue
with my formerly submitted patch. It is fixed in this newer patch
(attached). Otherwise, the functional description is exactly as
explained below.
The issue is that there were 2 printk()s which printed the northbridge
P
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
/sys/devices/system/cpu/cpu(whatever)/thermal_throttle/count was not
being updated. I fixed this by (1)
On Tue, Jan 08, 2008 at 06:28:18PM -0800, Russell Leidich wrote:
> On Jan 8, 2008 3:52 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > ENTRY(thermal_interrupt)
> > > - apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
> > > + apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt(%r
On Jan 8, 2008 3:52 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > ENTRY(thermal_interrupt)
> > - apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
> > + apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt(%rip)
>
> Are you sure a * is not needed? I would have thought it would ju
> ENTRY(thermal_interrupt)
> - apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt
> + apicinterrupt THERMAL_APIC_VECTOR,smp_thermal_interrupt(%rip)
Are you sure a * is not needed? I would have thought it would jump
to the variable instead of through it. But if it works it's ok for m
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.6.24-rc5
On Jan 5, 2008 5:24 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > But if PCI locks are spinlocks, then how can one access config space
> > in an interrupt handler, as it might be locked by the foreground? (No
>
> They disable interrupts
Got it.
>
> > locks would be required at all, if everyo
>
> But if PCI locks are spinlocks, then how can one access config space
> in an interrupt handler, as it might be locked by the foreground? (No
They disable interrupts
> locks would be required at all, if everyone just saved 0xCF8 and
> 0xCFC, but I digress.)
Not sure what you mean? Since i
On Jan 4, 2008 2:26 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > There are 2 pending issues, to which I have received insufficient feedback:
> >
> > 1. Andi would like to eliminate the trampoline in mce_thermal.c, but
> > no one has responded to my proposed disgusting hack on entry_64.S in
> > ord
> As to the question of Athlon RevG, it turns out that it has the same
> thermal erratum as RevF. Therefore the fact that this code only works
> with Barcelona and up is not a defficiency.
Thanks.
>
> There are 2 pending issues, to which I have received insufficient feedback:
>
> 1. Andi would
Here's a new version of the patch. Since I didn't explain its purpose
very well in my previous submission, I'll do so here:
This patch adds thermal machine check event (MCE) support to AMD
Barcelona (and probably later, if new PCI IDs are added to
k8_northbridges[]), styled after the same in the
On Jan 2, 2008 1:54 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Thanks. My code doesn't support these CPUs because their northbridge
> > IDs are not 0x1203.
>
> Sure, but do they have the crippling erratum too?
We don't seem to have erratum documentation on this chip, so I can't
confirm one way
> Thanks. My code doesn't support these CPUs because their northbridge
> IDs are not 0x1203.
Sure, but do they have the crippling erratum too?
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
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 Leidich wrote:
> > > > likelihood, will
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 Leidich wrote:
> > > likelihood, will extend to some future CPUs). Indeed, as far as my
> > > testing has deter
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++) {
> > > > + if ((k8_northbridges[nb_num]->device) == 0x1103)
> > > >
On Wed, Jan 02, 2008 at 11:43:08AM -0800, Russell Leidich wrote:
> > > + */
> > > + for (nb_num = 0; nb_num < num_k8_northbridges; nb_num++) {
> > > + if ((k8_northbridges[nb_num]->device) == 0x1103)
> > > + goto out;
> > > + }
> >
> > AFAIK that's all K
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
had no further issues. Anyway, thanks
"Russell Leidich" <[EMAIL PROTECTED]> writes:
Not sure you have addressed any of my feedback; don't see many changes.
When you repost stuff can you please add a changelog or if you decide
to not address some review comment say why at least.
Also the patch changelog description is missing anyways
On Sat, 29 Dec 2007 03:34:34 +0100, Andi Kleen said:
> On Saturday 29 December 2007 03:30:17 [EMAIL PROTECTED] wrote:
> > On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said:
> > > On Friday 28 December 2007 21:40:28 Russell Leidich wrote:
> >
> > > + printk(KERN_CRIT "CPU 0x%x: Thermal mo
On Saturday 29 December 2007 03:30:17 [EMAIL PROTECTED] wrote:
> On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said:
> > On Friday 28 December 2007 21:40:28 Russell Leidich wrote:
>
> > + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not "
> > + "functional.\n", cpu);
On Sat, 29 Dec 2007 03:11:51 +0100, Andi Kleen said:
> On Friday 28 December 2007 21:40:28 Russell Leidich wrote:
> + printk(KERN_CRIT "CPU 0x%x: Thermal monitoring not "
> + "functional.\n", cpu);
>
> Why is that KERN_CRIT? Does not seem that critical to me.
If y
On Friday 28 December 2007 21:40:28 Russell Leidich wrote:
> 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.
>
In general you seem to have a lot (too
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
/home/rml/
On Thu, 27 Dec 2007 10:57:20 -0800 "Russell Leidich" <[EMAIL PROTECTED]> wrote:
> Thanks Andrew. I have a few questions on your comments...
>
> On Dec 25, 2007 2:04 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > + unsigned int apic_lv_therm;
> > > +
> > > + /* Set up APIC_LVTTHMR to
Thanks Andrew. I have a few questions on your comments...
On Dec 25, 2007 2:04 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > + unsigned int apic_lv_therm;
> > +
> > + /* Set up APIC_LVTTHMR to issue THERMAL_APIC_VECTOR. */
> > + apic_lv_therm = apic_read(APIC_LVTTHMR);
> > + /*
On Mon, 17 Dec 2007 10:54:53 -0800 (PST) [EMAIL PROTECTED] (Russell Leidich)
wrote:
> Hi,
>
> This patch to 2.6.24-rc5 enables AMD Barcelona CPUs to register thermal
> throttling events as machine checks, in the
> same fashion as the analogous Intel code.
>
> Changed files:
>
> arch/x86/kerne
Hi,
This patch to 2.6.24-rc5 enables AMD Barcelona CPUs to register thermal
throttling events as machine checks, in the
same fashion as the analogous Intel code.
Changed files:
arch/x86/kernel/cpu/mcheck/Makefile
arch/x86/kernel/cpu/mcheck/mce_amd_64.c
arch/x86/kernel/cpu/mcheck/mce_intel_64.c
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 implementation, thermal
> interru
This patch adds thermal interrupt logging support for AMD Barcelona to
2.6.18. In the style of the existing Intel implementation, thermal
interrupts are logged as machine checks. Interrupts are logged only
when throttling is activated, i.e. when the package gets too hot.
Files affected:
2.6.18/
33 matches
Mail list logo
