Interrupt latency on some 945GM platforms

Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Tue, 14 Sep 2010 00:10:08 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
> > I remember seeing a similar problem on an Eee PC I had; it seemed to be
> > timer/interrupt related somehow.  If I booted with clocksource=tsc
> > (or maybe it was pit) I got nice smooth animations, but if I used the
> > HPET things were really slow.
> > 
> > Does the same work for you?
> 
> Yeah, it works for me (will use it as temporary workaround). But it definitely 
> is not clean solution, as I can't use nohz mode with tsc clocksource :)

Thomas, does this ring any bells for you?

I think the root symptom of the issue is that we get a much reduced i915
interrupt frequency (or no interrupts) on some 945GM platforms when
using HPET as our clock source.

In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
generate interrupts at all when HPET was used.  But shaking the mouse or
generating network traffic was enough to get i915 interrupts coming in,
even though neither of those interrupts were shared with the i915
device.

Here's hoping you have some ideas to try...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 1663 bytes --]

В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
> On Tue, 14 Sep 2010 00:10:08 +0300
> 
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
> > > I remember seeing a similar problem on an Eee PC I had; it seemed to be
> > > timer/interrupt related somehow.  If I booted with clocksource=tsc
> > > (or maybe it was pit) I got nice smooth animations, but if I used the
> > > HPET things were really slow.
> > > 
> > > Does the same work for you?
> > 
> > Yeah, it works for me (will use it as temporary workaround). But it
> > definitely is not clean solution, as I can't use nohz mode with tsc
> > clocksource :)
> 
> Thomas, does this ring any bells for you?
> 
> I think the root symptom of the issue is that we get a much reduced i915
> interrupt frequency (or no interrupts) on some 945GM platforms when
> using HPET as our clock source.
> 
> In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
> generate interrupts at all when HPET was used.  But shaking the mouse or
> generating network traffic was enough to get i915 interrupts coming in,
> even though neither of those interrupts were shared with the i915
> device.
> 
> Here's hoping you have some ideas to try...
> 
> Thanks,

Jesse, is it possible to disable wait for vsync somehow? cpufreq is not 
working for me with nohz=no for some reason, as result cpu temperature and 
power usage are higher. I prefer to see tearing but with low power usage and 
without jerky keyboard :)

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Tue, 14 Sep 2010 00:41:18 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
> > On Tue, 14 Sep 2010 00:10:08 +0300
> > 
> > Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
> > > > I remember seeing a similar problem on an Eee PC I had; it seemed to be
> > > > timer/interrupt related somehow.  If I booted with clocksource=tsc
> > > > (or maybe it was pit) I got nice smooth animations, but if I used the
> > > > HPET things were really slow.
> > > > 
> > > > Does the same work for you?
> > > 
> > > Yeah, it works for me (will use it as temporary workaround). But it
> > > definitely is not clean solution, as I can't use nohz mode with tsc
> > > clocksource :)
> > 
> > Thomas, does this ring any bells for you?
> > 
> > I think the root symptom of the issue is that we get a much reduced i915
> > interrupt frequency (or no interrupts) on some 945GM platforms when
> > using HPET as our clock source.
> > 
> > In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't
> > generate interrupts at all when HPET was used.  But shaking the mouse or
> > generating network traffic was enough to get i915 interrupts coming in,
> > even though neither of those interrupts were shared with the i915
> > device.
> > 
> > Here's hoping you have some ideas to try...
> > 
> > Thanks,
> 
> Jesse, is it possible to disable wait for vsync somehow? cpufreq is not 
> working for me with nohz=no for some reason, as result cpu temperature and 
> power usage are higher. I prefer to see tearing but with low power usage and 
> without jerky keyboard :)

Yes, you can set vblank_mode=0 in your environment or drirc.  At least
I think 0 is no vsync. :)

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 270 bytes --]

В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:

> Yes, you can set vblank_mode=0 in your environment or drirc.  At least
> I think 0 is no vsync. :)

That doesn't help, glxgears shows ~1000fps, but it's output is jerky.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Tue, 14 Sep 2010 00:52:31 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
> 
> > Yes, you can set vblank_mode=0 in your environment or drirc.  At least
> > I think 0 is no vsync. :)
> 
> That doesn't help, glxgears shows ~1000fps, but it's output is jerky.

Is it smooth with clocksource=tsc?  I wonder if the GPU batch
interrupts are also getting delayed, and possibly timer ticks...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 673 bytes --]

В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
> On Tue, 14 Sep 2010 00:52:31 +0300
> 
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
> > > Yes, you can set vblank_mode=0 in your environment or drirc.  At least
> > > I think 0 is no vsync. :)
> > 
> > That doesn't help, glxgears shows ~1000fps, but it's output is jerky.
> 
> Is it smooth with clocksource=tsc?  I wonder if the GPU batch
> interrupts are also getting delayed, and possibly timer ticks...


Yes, it's smooth with clocksource=tsc nohz=off

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Venkatesh Pallipadi]

On Mon, Sep 13, 2010 at 3:03 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
>> On Tue, 14 Sep 2010 00:52:31 +0300
>>
>> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>> > В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
>> > > Yes, you can set vblank_mode=0 in your environment or drirc.  At least
>> > > I think 0 is no vsync. :)
>> >
>> > That doesn't help, glxgears shows ~1000fps, but it's output is jerky.
>>
>> Is it smooth with clocksource=tsc?  I wonder if the GPU batch
>> interrupts are also getting delayed, and possibly timer ticks...
>
>
> Yes, it's smooth with clocksource=tsc nohz=off
>

Whats the clockevent in this case ("Tick Device" section of /proc/timer_list).
clocksource= option only changes the clocksource used to maintain
timeofday. But, timer interrupt (clockevent) source will not change.
Wondering how just the clocksource change is making the diff here..

Also, if clocksource tsc has a higher rating than HPET. The reason
HPET is getting used as clocksource in the first place seems to be due
to TSC is not a dependable clocksource on this platform (may be it
stops in C3). So, I am not sure forcing it to tsc will be a good
thing. May be clocksource=acpi_pm is a better thing to try.

Thanks,
Venki

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 1065 bytes --]

В сообщении от 14 of September 2010 03:55:32 автор Venkatesh Pallipadi 
написал:

> Whats the clockevent in this case ("Tick Device" section of
> /proc/timer_list). clocksource= option only changes the clocksource used
> to maintain
> timeofday. But, timer interrupt (clockevent) source will not change.
> Wondering how just the clocksource change is making the diff here..
> 
> Also, if clocksource tsc has a higher rating than HPET. The reason
> HPET is getting used as clocksource in the first place seems to be due
> to TSC is not a dependable clocksource on this platform (may be it
> stops in C3). So, I am not sure forcing it to tsc will be a good
> thing. May be clocksource=acpi_pm is a better thing to try.
> 
> Thanks,
> Venki

I investigated it a bit and found out that single nohz=off option helps. Just 
changing clocksource doesn't help, but it works smoothly with any clocksource 
with nohz=off. So, it seems that something wrong with intel driver while 
system is in tickless mode. 

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1355 bytes --]

On Tue, 14 Sep 2010, Vasily Khoruzhick wrote:

> В сообщении от 14 of September 2010 03:55:32 автор Venkatesh Pallipadi 
> написал:
> 
> > Whats the clockevent in this case ("Tick Device" section of
> > /proc/timer_list). clocksource= option only changes the clocksource used
> > to maintain
> > timeofday. But, timer interrupt (clockevent) source will not change.
> > Wondering how just the clocksource change is making the diff here..
> > 
> > Also, if clocksource tsc has a higher rating than HPET. The reason
> > HPET is getting used as clocksource in the first place seems to be due
> > to TSC is not a dependable clocksource on this platform (may be it
> > stops in C3). So, I am not sure forcing it to tsc will be a good
> > thing. May be clocksource=acpi_pm is a better thing to try.
> > 
> > Thanks,
> > Venki
> 
> I investigated it a bit and found out that single nohz=off option helps. Just 
> changing clocksource doesn't help, but it works smoothly with any clocksource 
> with nohz=off. So, it seems that something wrong with intel driver while 
> system is in tickless mode. 

Can you try with NOHZ enabled and the following on the kernel command line:

    processor.max_cstate=1

Make sure that CONFIG_ACPI_PROCESSOR is set to "y" and not to "m"

If that works, then try

    processor.max_cstate=2

Thanks,

	tglx

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 403 bytes --]

В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner написал:
> Can you try with NOHZ enabled and the following on the kernel command line:
> 
>     processor.max_cstate=1

It works in this case (gears in glxgears move smoothly)
 
> If that works, then try
> 
>     processor.max_cstate=2
> 

Nope, it doesn't work with max_cstate=2

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Sitsofe Wheeler]

On Tue, Sep 14, 2010 at 03:29:48PM +0300, Vasily Khoruzhick wrote:
> В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner написал:
> > Can you try with NOHZ enabled and the following on the kernel command line:
> > 
> >     processor.max_cstate=1
> 
> It works in this case (gears in glxgears move smoothly)
>  
> > If that works, then try
> > 
> >     processor.max_cstate=2
> > 
> 
> Nope, it doesn't work with max_cstate=2

Perhaps intel_idle is being used? Any mention of it in dmesg?

-- 
Sitsofe | http://sucs.org/~sits/

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 834 bytes --]

В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> On Tue, Sep 14, 2010 at 03:29:48PM +0300, Vasily Khoruzhick wrote:
> > В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner 
написал:
> > > Can you try with NOHZ enabled and the following on the kernel command 
line:
> > >     processor.max_cstate=1
> > 
> > It works in this case (gears in glxgears move smoothly)
> > 
> > > If that works, then try
> > > 
> > >     processor.max_cstate=2
> > 
> > Nope, it doesn't work with max_cstate=2
> 
> Perhaps intel_idle is being used? Any mention of it in dmesg?

Nope, acpi_idle is being used, intel_idle doesn't support my CPU (it's c2d 
t5500):

[    0.653279] intel_idle: does not run on family 6 model 15

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 553 bytes --]

В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> > >     processor.max_cstate=2
> > 
> > Nope, it doesn't work with max_cstate=2
> 
> Perhaps intel_idle is being used? Any mention of it in dmesg?

Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is 
smooth, with higher values (i.e. max_cstate=2) graphics is jerky.

Btw, Jesse, any comments/solutions/workarounds except one with 
processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo 
bugzilla?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11731 bytes --]

Vasily,

On Thu, 16 Sep 2010, Vasily Khoruzhick wrote:

> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> > > >     processor.max_cstate=2
> > > 
> > > Nope, it doesn't work with max_cstate=2
> > 
> > Perhaps intel_idle is being used? Any mention of it in dmesg?
> 
> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is 
> smooth, with higher values (i.e. max_cstate=2) graphics is jerky.
> 
> Btw, Jesse, any comments/solutions/workarounds except one with 
> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo 
> bugzilla?

we fixed a HPET related bug a few days ago, which might be the cause
for your problem as well.

Thanks,

	tglx
---
commit 54ff7e595d763d894104d421b103a89f7becf47c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Sep 14 22:10:21 2010 +0200

    x86: hpet: Work around hardware stupidity
    
    This more or less reverts commits 08be979 (x86: Force HPET
    readback_cmp for all ATI chipsets) and 30a564be (x86, hpet: Restrict
    read back to affected ATI chipsets) to the status of commit 8da854c
    (x86, hpet: Erratum workaround for read after write of HPET
    comparator).
    
    The delta to commit 8da854c is mostly comments and the change from
    WARN_ONCE to printk_once as we know the call path of this function
    already.
    
    This needs really in depth explanation:
    
    First of all the HPET design is a complete failure. Having a counter
    compare register which generates an interrupt on matching values
    forces the software to do at least one superfluous readback of the
    counter register.
    
    While it is nice in theory to program "absolute" time events it is
    practically useless because the timer runs at some absurd frequency
    which can never be matched to real world units. So we are forced to
    calculate a relative delta and this forces a readout of the actual
    counter value, adding the delta and programming the compare
    register. When the delta is small enough we run into the danger that
    we program a compare value which is already in the past. Due to the
    compare for equal nature of HPET we need to read back the counter
    value after writing the compare rehgister (btw. this is necessary for
    absolute timeouts as well) to make sure that we did not miss the timer
    event. We try to work around that by setting the minimum delta to a
    value which is larger than the theoretical time which elapses between
    the counter readout and the compare register write, but that's only
    true in theory. A NMI or SMI which hits between the readout and the
    write can easily push us beyond that limit. This would result in
    waiting for the next HPET timer interrupt until the 32bit wraparound
    of the counter happens which takes about 306 seconds.
    
    So we designed the next event function to look like:
    
       match = read_cnt() + delta;
       write_compare_ref(match);
       return read_cnt() < match ? 0 : -ETIME;
    
    At some point we got into trouble with certain ATI chipsets. Even the
    above "safe" procedure failed. The reason was that the write to the
    compare register was delayed probably for performance reasons. The
    theory was that they wanted to avoid the synchronization of the write
    with the HPET clock, which is understandable. So the write does not
    hit the compare register directly instead it goes to some intermediate
    register which is copied to the real compare register in sync with the
    HPET clock. That opens another window for hitting the dreaded "wait
    for a wraparound" problem.
    
    To work around that "optimization" we added a read back of the compare
    register which either enforced the update of the just written value or
    just delayed the readout of the counter enough to avoid the issue. We
    unfortunately never got any affirmative info from ATI/AMD about this.
    
    One thing is sure, that we nuked the performance "optimization" that
    way completely and I'm pretty sure that the result is worse than
    before some HW folks came up with those.
    
    Just for paranoia reasons I added a check whether the read back
    compare register value was the same as the value we wrote right
    before. That paranoia check triggered a couple of years after it was
    added on an Intel ICH9 chipset. Venki added a workaround (commit
    8da854c) which was reading the compare register twice when the first
    check failed. We considered this to be a penalty in general and
    restricted the readback (thus the wasted CPU cycles) to the known to
    be affected ATI chipsets.
    
    This turned out to be a utterly wrong decision. 2.6.35 testers
    experienced massive problems and finally one of them bisected it down
    to commit 30a564be which spured some further investigation.
    
    Finally we got confirmation that the write to the compare register can
    be delayed by up to two HPET clock cycles which explains the problems
    nicely. All we can do about this is to go back to Venki's initial
    workaround in a slightly modified version.
    
    Just for the record I need to say, that all of this could have been
    avoided if hardware designers and of course the HPET committee would
    have thought about the consequences for a split second. It's out of my
    comprehension why designing a working timer is so hard. There are two
    ways to achieve it:
    
     1) Use a counter wrap around aware compare_reg <= counter_reg
        implementation instead of the easy compare_reg == counter_reg
    
        Downsides:
    
    	- It needs more silicon.
    
    	- It needs a readout of the counter to apply a relative
    	  timeout. This is necessary as the counter does not run in
    	  any useful (and adjustable) frequency and there is no
    	  guarantee that the counter which is used for timer events is
    	  the same which is used for reading the actual time (and
    	  therefor for calculating the delta)
    
        Upsides:
    
    	- None
    
      2) Use a simple down counter for relative timer events
    
        Downsides:
    
    	- Absolute timeouts are not possible, which is not a problem
    	  at all in the context of an OS and the expected
    	  max. latencies/jitter (also see Downsides of #1)
    
       Upsides:
    
    	- It needs less or equal silicon.
    
    	- It works ALWAYS
    
    	- It is way faster than a compare register based solution (One
    	  write versus one write plus at least one and up to four
    	  reads)
    
    I would not be so grumpy about all of this, if I would not have been
    ignored for many years when pointing out these flaws to various
    hardware folks. I really hate timers (at least those which seem to be
    designed by janitors).
    
    Though finally we got a reasonable explanation plus a solution and I
    want to thank all the folks involved in chasing it down and providing
    valuable input to this.
    
    Bisected-by: Nix <nix@esperi.org.uk>
    Reported-by: Artur Skawina <art.08.09@gmail.com>
    Reported-by: Damien Wyart <damien.wyart@free.fr>
    Reported-by: John Drescher <drescherjm@gmail.com>
    Cc: Venkatesh Pallipadi <venki@google.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
    Cc: Borislav Petkov <borislav.petkov@amd.com>
    Cc: stable@kernel.org
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 004e6e2..1d5c08a 100644
--- a/arch/x86/include/asm/hpet.h
+++ b/arch/x86/include/asm/hpet.h
@@ -68,7 +68,6 @@ extern unsigned long force_hpet_address;
 extern u8 hpet_blockid;
 extern int hpet_force_user;
 extern u8 hpet_msi_disable;
-extern u8 hpet_readback_cmp;
 extern int is_hpet_enabled(void);
 extern int hpet_enable(void);
 extern void hpet_disable(void);
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index e5cc7e8..ebdb85c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -18,7 +18,6 @@
 #include <asm/apic.h>
 #include <asm/iommu.h>
 #include <asm/gart.h>
-#include <asm/hpet.h>
 
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
@@ -192,21 +191,6 @@ static void __init ati_bugs_contd(int num, int slot, int func)
 }
 #endif
 
-/*
- * Force the read back of the CMP register in hpet_next_event()
- * to work around the problem that the CMP register write seems to be
- * delayed. See hpet_next_event() for details.
- *
- * We do this on all SMBUS incarnations for now until we have more
- * information about the affected chipsets.
- */
-static void __init ati_hpet_bugs(int num, int slot, int func)
-{
-#ifdef CONFIG_HPET_TIMER
-	hpet_readback_cmp = 1;
-#endif
-}
-
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -236,8 +220,6 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
 	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
-	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
-	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
 	{}
 };
 
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 351f9c0..410fdb3 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -35,7 +35,6 @@
 unsigned long				hpet_address;
 u8					hpet_blockid; /* OS timer block num */
 u8					hpet_msi_disable;
-u8					hpet_readback_cmp;
 
 #ifdef CONFIG_PCI_MSI
 static unsigned long			hpet_num_timers;
@@ -395,23 +394,27 @@ static int hpet_next_event(unsigned long delta,
 	 * at that point and we would wait for the next hpet interrupt
 	 * forever. We found out that reading the CMP register back
 	 * forces the transfer so we can rely on the comparison with
-	 * the counter register below.
+	 * the counter register below. If the read back from the
+	 * compare register does not match the value we programmed
+	 * then we might have a real hardware problem. We can not do
+	 * much about it here, but at least alert the user/admin with
+	 * a prominent warning.
 	 *
-	 * That works fine on those ATI chipsets, but on newer Intel
-	 * chipsets (ICH9...) this triggers due to an erratum: Reading
-	 * the comparator immediately following a write is returning
-	 * the old value.
+	 * An erratum on some chipsets (ICH9,..), results in
+	 * comparator read immediately following a write returning old
+	 * value. Workaround for this is to read this value second
+	 * time, when first read returns old value.
 	 *
-	 * We restrict the read back to the affected ATI chipsets (set
-	 * by quirks) and also run it with hpet=verbose for debugging
-	 * purposes.
+	 * In fact the write to the comparator register is delayed up
+	 * to two HPET cycles so the workaround we tried to restrict
+	 * the readback to those known to be borked ATI chipsets
+	 * failed miserably. So we give up on optimizations forever
+	 * and penalize all HPET incarnations unconditionally.
 	 */
-	if (hpet_readback_cmp || hpet_verbose) {
-		u32 cmp = hpet_readl(HPET_Tn_CMP(timer));
-
-		if (cmp != cnt)
+	if (unlikely((u32)hpet_readl(HPET_Tn_CMP(timer)) != cnt)) {
+		if (hpet_readl(HPET_Tn_CMP(timer)) != cnt)
 			printk_once(KERN_WARNING
-			    "hpet: compare register read back failed.\n");
+				"hpet: compare register read back failed.\n");
 	}
 
 	return (s32)(hpet_readl(HPET_COUNTER) - cnt) >= 0 ? -ETIME : 0;

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 416 bytes --]

В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:

> > Btw, Jesse, any comments/solutions/workarounds except one with
> > processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo
> > bugzilla?
> 
> we fixed a HPET related bug a few days ago, which might be the cause
> for your problem as well.

Nope, it doesn't help :(

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 653 bytes --]

В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал:
> В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
> > > Btw, Jesse, any comments/solutions/workarounds except one with
> > > processor.max_cstate=1 in kernel commandline? Should I file a bug on
> > > fdo bugzilla?
> > 
> > we fixed a HPET related bug a few days ago, which might be the cause
> > for your problem as well.
> 
> Nope, it doesn't help :(

Btw, I suspect hpet is not related, I disabled hpet completely in kernel 
config but issue is still here (clocksource is acpi_pm)

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 892 bytes --]

On Thu, 16 Sep 2010, Vasily Khoruzhick wrote:

> В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал:
> > В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
> > > > Btw, Jesse, any comments/solutions/workarounds except one with
> > > > processor.max_cstate=1 in kernel commandline? Should I file a bug on
> > > > fdo bugzilla?
> > > 
> > > we fixed a HPET related bug a few days ago, which might be the cause
> > > for your problem as well.
> > 
> > Nope, it doesn't help :(
> 
> Btw, I suspect hpet is not related, I disabled hpet completely in kernel 
> config but issue is still here (clocksource is acpi_pm)

Ok. The problematic part of HPET was not the clocksource, it was the
clock event device which failed to deliver interrupts occasionally. It
was worth a try at least.

Thanks,

	tglx

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 580 bytes --]

В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
> Ok. The problematic part of HPET was not the clocksource, it was the
> clock event device which failed to deliver interrupts occasionally. It
> was worth a try at least.

Hm, it seems that jerky glxgears is not related to jerky keyboard events. 
Keyboard is jerky only in konsole (kde terminal emulator), it seems something 
happened it seems that font rendering performance is much worse in latest 
xf86-video-intel than in xf86-video-intel-2.12.0.

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Thu, 16 Sep 2010 23:06:46 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
> > Ok. The problematic part of HPET was not the clocksource, it was the
> > clock event device which failed to deliver interrupts occasionally. It
> > was worth a try at least.
> 
> Hm, it seems that jerky glxgears is not related to jerky keyboard events. 
> Keyboard is jerky only in konsole (kde terminal emulator), it seems something 
> happened it seems that font rendering performance is much worse in latest 
> xf86-video-intel than in xf86-video-intel-2.12.0.

Len just had me try a few things too:
  - maxcpus=1 lets things work
  - offlining cpu1 at runtime (echo 0
    > /sys/devices/system/cpu/cpu1/online) lets things work
  - binding the i915 interrupt to cpu 0 does *not* help

Vasily and Paolo, do you both have Atom CPUs with hyperthreading
enabled?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

On 24 of September 2010 22:39:01 Jesse Barnes wrote:
> On Thu, 16 Sep 2010 23:06:46 +0300
> 
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner 
написал:
> > > Ok. The problematic part of HPET was not the clocksource, it was the
> > > clock event device which failed to deliver interrupts occasionally. It
> > > was worth a try at least.
> > 
> > Hm, it seems that jerky glxgears is not related to jerky keyboard events.
> > Keyboard is jerky only in konsole (kde terminal emulator), it seems
> > something happened it seems that font rendering performance is much
> > worse in latest xf86-video-intel than in xf86-video-intel-2.12.0.
> 
> Len just had me try a few things too:
>   - maxcpus=1 lets things work
>   - offlining cpu1 at runtime (echo 0
> 
>     > /sys/devices/system/cpu/cpu1/online) lets things work
> 
>   - binding the i915 interrupt to cpu 0 does *not* help
> 
> Vasily and Paolo, do you both have Atom CPUs with hyperthreading
> enabled?

Nope, I have Core2Duo T5500, dual-core, no hyperthreading :)

Re: Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Fri, 24 Sep 2010 22:48:36 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> On 24 of September 2010 22:39:01 Jesse Barnes wrote:
> > On Thu, 16 Sep 2010 23:06:46 +0300
> > 
> > Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner 
> написал:
> > > > Ok. The problematic part of HPET was not the clocksource, it was the
> > > > clock event device which failed to deliver interrupts occasionally. It
> > > > was worth a try at least.
> > > 
> > > Hm, it seems that jerky glxgears is not related to jerky keyboard events.
> > > Keyboard is jerky only in konsole (kde terminal emulator), it seems
> > > something happened it seems that font rendering performance is much
> > > worse in latest xf86-video-intel than in xf86-video-intel-2.12.0.
> > 
> > Len just had me try a few things too:
> >   - maxcpus=1 lets things work
> >   - offlining cpu1 at runtime (echo 0
> > 
> >     > /sys/devices/system/cpu/cpu1/online) lets things work
> > 
> >   - binding the i915 interrupt to cpu 0 does *not* help
> > 
> > Vasily and Paolo, do you both have Atom CPUs with hyperthreading
> > enabled?
> 
> Nope, I have Core2Duo T5500, dual-core, no hyperthreading :)

Hm, well there goes the theory about Atom HT...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Stefan Biereigel]

  Am 24.09.2010 21:51, schrieb Jesse Barnes:
> On Fri, 24 Sep 2010 22:48:36 +0300
> Vasily Khoruzhick<anarsoul@gmail.com>  wrote:
>
>> On 24 of September 2010 22:39:01 Jesse Barnes wrote:
>>> On Thu, 16 Sep 2010 23:06:46 +0300
>>>
>>> Vasily Khoruzhick<anarsoul@gmail.com>  wrote:
>>>> В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
>> написал:
>>>>> Ok. The problematic part of HPET was not the clocksource, it was the
>>>>> clock event device which failed to deliver interrupts occasionally. It
>>>>> was worth a try at least.
>>>> Hm, it seems that jerky glxgears is not related to jerky keyboard events.
>>>> Keyboard is jerky only in konsole (kde terminal emulator), it seems
>>>> something happened it seems that font rendering performance is much
>>>> worse in latest xf86-video-intel than in xf86-video-intel-2.12.0.
>>> Len just had me try a few things too:
>>>    - maxcpus=1 lets things work
>>>    - offlining cpu1 at runtime (echo 0
>>>
>>>      >  /sys/devices/system/cpu/cpu1/online) lets things work
>>>
>>>    - binding the i915 interrupt to cpu 0 does *not* help
>>>
>>> Vasily and Paolo, do you both have Atom CPUs with hyperthreading
>>> enabled?
>> Nope, I have Core2Duo T5500, dual-core, no hyperthreading :)
> Hm, well there goes the theory about Atom HT...
>

Hello Everyone,
just to add on to reports of this problem, there was a Thread here in 
LKML some months ago targeting the same problem (but not really 
attacking it at the Chipset driver). As I have one of those Laptops with 
a 945GM-Chipset and am stuck with the same Problem (disabled tickless 
now as a workaround and set ticks to 1000) I could maybe do some testing 
of patches.
So what I can summarize is what the others did before: Disabling CPU1 
helps, adding nohz=off helps, changing the Clocksource afterwards helps, 
binding the Interrupt does NOT help.
So here's the Link to the old Discussion with follow-ups, maybe you can 
get some furter information from there.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html
We targeted the BIOS itself as everyone in this thread happened to own 
an Phoenix BIOS with some special version string.
best, Stefan

Re: Interrupt latency on some 945GM platforms

[Shaohua Li]

2010/9/26 Stefan Biereigel <security@biereigel-wb.de>:
>  Am 24.09.2010 21:51, schrieb Jesse Barnes:
>>
>> On Fri, 24 Sep 2010 22:48:36 +0300
>> Vasily Khoruzhick<anarsoul@gmail.com>  wrote:
>>
>>> On 24 of September 2010 22:39:01 Jesse Barnes wrote:
>>>>
>>>> On Thu, 16 Sep 2010 23:06:46 +0300
>>>>
>>>> Vasily Khoruzhick<anarsoul@gmail.com>  wrote:
>>>>>
>>>>> В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
>>>
>>> написал:
>>>>>>
>>>>>> Ok. The problematic part of HPET was not the clocksource, it was the
>>>>>> clock event device which failed to deliver interrupts occasionally. It
>>>>>> was worth a try at least.
>>>>>
>>>>> Hm, it seems that jerky glxgears is not related to jerky keyboard
>>>>> events.
>>>>> Keyboard is jerky only in konsole (kde terminal emulator), it seems
>>>>> something happened it seems that font rendering performance is much
>>>>> worse in latest xf86-video-intel than in xf86-video-intel-2.12.0.
>>>>
>>>> Len just had me try a few things too:
>>>>   - maxcpus=1 lets things work
>>>>   - offlining cpu1 at runtime (echo 0
>>>>
>>>>     >  /sys/devices/system/cpu/cpu1/online) lets things work
>>>>
>>>>   - binding the i915 interrupt to cpu 0 does *not* help
>>>>
>>>> Vasily and Paolo, do you both have Atom CPUs with hyperthreading
>>>> enabled?
>>>
>>> Nope, I have Core2Duo T5500, dual-core, no hyperthreading :)
>>
>> Hm, well there goes the theory about Atom HT...
>>
>
> Hello Everyone,
> just to add on to reports of this problem, there was a Thread here in LKML
> some months ago targeting the same problem (but not really attacking it at
> the Chipset driver). As I have one of those Laptops with a 945GM-Chipset and
> am stuck with the same Problem (disabled tickless now as a workaround and
> set ticks to 1000) I could maybe do some testing of patches.
> So what I can summarize is what the others did before: Disabling CPU1 helps,
> adding nohz=off helps, changing the Clocksource afterwards helps, binding
> the Interrupt does NOT help.
> So here's the Link to the old Discussion with follow-ups, maybe you can get
> some furter information from there.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html
> We targeted the BIOS itself as everyone in this thread happened to own an
> Phoenix BIOS with some special version string.
> best, Stefan
does disable msi help with 'pci=nomsi'?

Re: Interrupt latency on some 945GM platforms

[Stefan Biereigel]

Hello Everyone,
>> just to add on to reports of this problem, there was a Thread here in LKML
>> some months ago targeting the same problem (but not really attacking it at
>> the Chipset driver). As I have one of those Laptops with a 945GM-Chipset and
>> am stuck with the same Problem (disabled tickless now as a workaround and
>> set ticks to 1000) I could maybe do some testing of patches.
>> So what I can summarize is what the others did before: Disabling CPU1 helps,
>> adding nohz=off helps, changing the Clocksource afterwards helps, binding
>> the Interrupt does NOT help.
>> So here's the Link to the old Discussion with follow-ups, maybe you can get
>> some furter information from there.
>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html
>> We targeted the BIOS itself as everyone in this thread happened to own an
>> Phoenix BIOS with some special version string.
>> best, Stefan
>>     
> does disable msi help with 'pci=nomsi'?
>   
No, here it doesn't.

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

On 27 of September 2010 03:46:23 Shaohua Li wrote:

> does disable msi help with 'pci=nomsi'?

Doesn't help on my system :(

Re: Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

On 26 of September 2010 13:53:35 Stefan Biereigel wrote:

> Hello Everyone,
> just to add on to reports of this problem, there was a Thread here in
> LKML some months ago targeting the same problem (but not really
> attacking it at the Chipset driver). As I have one of those Laptops with
> a 945GM-Chipset and am stuck with the same Problem (disabled tickless
> now as a workaround and set ticks to 1000) I could maybe do some testing
> of patches.
> So what I can summarize is what the others did before: Disabling CPU1
> helps, adding nohz=off helps, changing the Clocksource afterwards helps,
> binding the Interrupt does NOT help.
> So here's the Link to the old Discussion with follow-ups, maybe you can
> get some furter information from there.
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html
> We targeted the BIOS itself as everyone in this thread happened to own
> an Phoenix BIOS with some special version string.
> best, Stefan

Yep, my laptop has Phoenix BIOS too. Btw, this BIOS has buggy DSDT (thermal 
and battery don't work reliably without patching DSDT). But I tested with and 
without patched DSDT - so my custom DSDT is not cause of bug in my case.

Re: Interrupt latency on some 945GM platforms

[Paolo Ornati]

On Fri, 24 Sep 2010 12:39:01 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Vasily and Paolo, do you both have Atom CPUs with hyperthreading
> enabled?

model name      : Intel(R) Core(TM)2 Duo CPU     T6570  @ 2.10GHz

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Simon Farnsworth]

On Thursday 16 September 2010, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> > > >     processor.max_cstate=2
> > > 
> > > Nope, it doesn't work with max_cstate=2
> > 
> > Perhaps intel_idle is being used? Any mention of it in dmesg?
> 
> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is
> smooth, with higher values (i.e. max_cstate=2) graphics is jerky.
> 
> Btw, Jesse, any comments/solutions/workarounds except one with
> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo
> bugzilla?

This looks like a problem I've seen on some hardware.

My workaround has been to use the pm_qos /dev/cpu_dma_latency interface to 
request a maximum latency of 1ms (value chosen as definitely small enough - a 
larger value may be better, but I don't care about power saving at runtime on 
my kit).

If it's happening on other kit, perhaps the i915 driver should make a suitable 
pm_qos request itself. Jesse, can you comment?
-- 
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Jesse Barnes]

Yeah if that works we could definitely add some qos calls to the driver.  When vblanks are alive we'd need a latency less tha the refresh rate, and when commands are oustanding we'd probably want it even lower.

Vasily, can you try the qos workaround on your machine and see if it works too?

Thanks,

"Simon Farnsworth" <simon.farnsworth@onelan.co.uk> wrote:

>On Thursday 16 September 2010, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
>> > > >     processor.max_cstate=2
>> > > 
>> > > Nope, it doesn't work with max_cstate=2
>> > 
>> > Perhaps intel_idle is being used? Any mention of it in dmesg?
>> 
>> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is
>> smooth, with higher values (i.e. max_cstate=2) graphics is jerky.
>> 
>> Btw, Jesse, any comments/solutions/workarounds except one with
>> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo
>> bugzilla?
>
>This looks like a problem I've seen on some hardware.
>
>My workaround has been to use the pm_qos /dev/cpu_dma_latency interface to 
>request a maximum latency of 1ms (value chosen as definitely small enough - a 
>larger value may be better, but I don't care about power saving at runtime on 
>my kit).
>
>If it's happening on other kit, perhaps the i915 driver should make a suitable 
>pm_qos request itself. Jesse, can you comment?
>-- 
>Simon Farnsworth
>Software Engineer
>ONELAN Limited
>http://www.onelan.com/
>

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

[-- Attachment #1: Type: Text/Plain, Size: 469 bytes --]

В сообщении от 17 of September 2010 19:30:26 автор Jesse Barnes написал:
> Yeah if that works we could definitely add some qos calls to the driver. 
> When vblanks are alive we'd need a latency less tha the refresh rate, and
> when commands are oustanding we'd probably want it even lower.
> 
> Vasily, can you try the qos workaround on your machine and see if it works
> too?
> 
> Thanks,

Just give me a patch :)

Regards
Vasily

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Paolo Ornati]

On Fri, 17 Sep 2010 15:50:43 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> > Vasily, can you try the qos workaround on your machine and see if it works
> > too?
> > 
> > Thanks,  
> 
> Just give me a patch :)

Me too...

I've a laptop with 945GM (Asus x5dij) and with 2.6.32+ kernels I'm
having random, but not frequent, screen flickering problems (for some
reasons 2.6.31 works fine).

Problem goes away with "nohz=off".

I'll try with "processor.max_cstate=?" and see if that works too.

Bye,

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Tue, 21 Sep 2010 20:26:07 +0200
Paolo Ornati <ornati@gmail.com> wrote:

> On Fri, 17 Sep 2010 15:50:43 +0300
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> 
> > > Vasily, can you try the qos workaround on your machine and see if it works
> > > too?
> > > 
> > > Thanks,  
> > 
> > Just give me a patch :)
> 
> Me too...
> 
> I've a laptop with 945GM (Asus x5dij) and with 2.6.32+ kernels I'm
> having random, but not frequent, screen flickering problems (for some
> reasons 2.6.31 works fine).
> 
> Problem goes away with "nohz=off".
> 
> I'll try with "processor.max_cstate=?" and see if that works too.

Can you guys try something like this?  My theory is that 945GM has some
power management behavior we're failing to configure correctly.  If
disabling it works, then it's likely related.

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 40cc5da..26e1d23 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5786,6 +5786,10 @@ void intel_init_clock_gating(struct drm_device *dev)
                                   I915_READ(MCHBAR_RENDER_STANDBY) & ~RCX_SW_EX
                }
        }
+
+
+       /* Disable power management on 945GM */
+       I915_WRITE(0x10f10, 0);
 }
 
 /* Set up chip specific display functions */


-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Vasily Khoruzhick]

On 22 of September 2010 01:56:53 Jesse Barnes wrote:
 
> Can you guys try something like this?  My theory is that 945GM has some
> power management behavior we're failing to configure correctly.  If
> disabling it works, then it's likely related.

Nope, it doesn't help, sorry

> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_d index 40cc5da..26e1d23 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5786,6 +5786,10 @@ void intel_init_clock_gating(struct drm_device *dev)
>                                    I915_READ(MCHBAR_RENDER_STANDBY) &
> ~RCX_SW_EX }
>         }
> +
> +
> +       /* Disable power management on 945GM */
> +       I915_WRITE(0x10f10, 0);
>  }
> 
>  /* Set up chip specific display functions */

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Paolo Ornati]

On Tue, 21 Sep 2010 15:56:53 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Can you guys try something like this?  My theory is that 945GM has some
> power management behavior we're failing to configure correctly.  If
> disabling it works, then it's likely related.

"processor.max_cstate=1" solves the problem too, tomorrow (it takes time
to be sure the problem is gone) I'll run with "processor.max_cstate=2"
and then I'll try with the patch alone.

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: [Intel-gfx] Interrupt latency on some 945GM platforms

[Paolo Ornati]

On Tue, 21 Sep 2010 15:56:53 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> > I've a laptop with 945GM (Asus x5dij) and with 2.6.32+ kernels I'm
> > having random, but not frequent, screen flickering problems (for some
> > reasons 2.6.31 works fine).
> > 
> > Problem goes away with "nohz=off".
> > 
> > I'll try with "processor.max_cstate=?" and see if that works too.  
> 
> Can you guys try something like this?  My theory is that 945GM has some
> power management behavior we're failing to configure correctly.  If
> disabling it works, then it's likely related.

UPDATE: "processor.max_cstate=2" doesn't solve the sporadic flicker
problem.

The patch, applied on top of 2.6.35.4, freezes the laptop on boot.

Summary:
	nohz=off		good
	processor.max_cstate=1	good
	processor.max_cstate=2	bad

Bye,

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: [Intel-gfx] Interrupt latency on some 945GM platforms -- and TCP/IP silent data corruption?

[Paolo Ornati]

On Sat, 25 Sep 2010 12:28:20 +0200
Paolo Ornati <ornati@gmail.com> wrote:

> UPDATE: "processor.max_cstate=2" doesn't solve the sporadic flicker
> problem.
> 
> The patch, applied on top of 2.6.35.4, freezes the laptop on boot.
> 
> Summary:
> 	nohz=off		good
> 	processor.max_cstate=1	good
> 	processor.max_cstate=2	bad

Maybe it's not related but who knows...

on this laptop (Asus x5dij / Core(TM)2 Duo CPU T6570) I've another
problem: sporadic silent data corruption over TCP/IP!

The problem is not easy to reproduce, maybe it's something like this?
	http://www.zdnet.com/blog/ou/realtek-silent-data-corruption-caused-by-firmware/663

I've first noticed it in two ways:
	- I download an ISO and sometimes it has wrong MD5, looking
	closer I find that only a few bytes (in one place) are wrong
	- ssh detects HMAC corruption

When I've tried to reproduce it doing a lot of automated fast tranfers
over a gigabit LAN it all worked fine... ;)

The intersesting thing is that "processor.max_cstate=1" seems to have
cured this problem too!

Network controller is this:

03:00.0 Ethernet controller: Atheros Communications Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)

Full lspci:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
03:00.0 Ethernet controller: Atheros Communications Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)

-- 
	Paolo Ornati
	Linux 2.6.35.7 on x86_64

Re: Interrupt latency on some 945GM platforms

[Jesse Barnes]

On Thu, 16 Sep 2010 18:03:04 +0300
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> > > >     processor.max_cstate=2
> > > 
> > > Nope, it doesn't work with max_cstate=2
> > 
> > Perhaps intel_idle is being used? Any mention of it in dmesg?
> 
> Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is 
> smooth, with higher values (i.e. max_cstate=2) graphics is jerky.
> 
> Btw, Jesse, any comments/solutions/workarounds except one with 
> processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo 
> bugzilla?

FDO bug for this is https://bugs.freedesktop.org/show_bug.cgi?id=30364.

I still don't have a root cause, but at least we have a workaround.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Interrupt latency on some 945GM platforms

[Andi Kleen]

Vasily Khoruzhick <anarsoul@gmail.com> writes:

>> Whats the clockevent in this case ("Tick Device" section of
>> /proc/timer_list). clocksource= option only changes the clocksource used
>> to maintain
>> timeofday. But, timer interrupt (clockevent) source will not change.
>> Wondering how just the clocksource change is making the diff here..
>> 
>> Also, if clocksource tsc has a higher rating than HPET. The reason
>> HPET is getting used as clocksource in the first place seems to be due
>> to TSC is not a dependable clocksource on this platform (may be it
>> stops in C3). So, I am not sure forcing it to tsc will be a good
>> thing. May be clocksource=acpi_pm is a better thing to try.
>> 
>> Thanks,
>> Venki
>
> I investigated it a bit and found out that single nohz=off option helps. Just 
> changing clocksource doesn't help, but it works smoothly with any clocksource 
> with nohz=off. So, it seems that something wrong with intel driver while 
> system is in tickless mode. 

It could be simply that nohz=off prevents the system from
going into lower idle states and it is related to that.

You could test this theory by running with processor.max_cstate=1

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.