vsync problems with recent graphics stack and 945gm
Subsystems (5)
Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) from git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles without composite manager, here's output of glxgears:
$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 243 frames in 5.0 seconds = 48.124 FPS 157 frames in 5.0 seconds = 31.300 FPS 155 frames in 5.0 seconds = 30.864 FPS
But I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not smooth at all). If I move mouse cursor over glxgears window FPS goes up to 60. And main problem is that keyboard events are also jerky, i.e. I press key and system receives press event in 0.1-0.5 sec or so (tested via xev).
There's no such problem when composition manager is running (i.e. effects are enabled in KDE)
Is there any solution for this problem? It really annoys me.
Regards
Vasily
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 16 lines · On Mon, 13 Sep 2010 23:36:11 +0300 Vasily Khoruzhick <[email protected]> wrote:
Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) from git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles without composite manager, here's output of glxgears:
$ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 243 frames in 5.0 seconds = 48.124 FPS 157 frames in 5.0 seconds = 31.300 FPS 155 frames in 5.0 seconds = 30.864 FPSBut I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not smooth at all). If I move mouse cursor over glxgears window FPS goes up to 60. And main problem is that keyboard events are also jerky, i.e. I press key and system receives press event in 0.1-0.5 sec or so (tested via xev).
Quoted 4 lines
There's no such problem when composition manager is running (i.e. effects are enabled in KDE)
Is there any solution for this problem? It really annoys me.
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?
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
Quoted 6 lines
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 :)
Regards
Vasily
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Interrupt latency on some 945GM platforms
Quoted 10 lines · On Tue, 14 Sep 2010 00:10:08 +0300 Vasily Khoruzhick <[email protected]> wrote:
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
Quoted 6 lines
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,
Signature · 5 lines
Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
Quoted 27 lines
On Tue, 14 Sep 2010 00:10:08 +0300
Quoted 11 lines · Vasily Khoruzhick
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
Quoted 6 lines
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.
Quoted 3 lines
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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
Quoted 28 lines · On Tue, 14 Sep 2010 00:41:18 +0300 Vasily Khoruzhick <[email protected]> wrote:
В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал:
Quoted 27 lines
On Tue, 14 Sep 2010 00:10:08 +0300
Quoted 11 lines · Vasily Khoruzhick
В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал:
Quoted 6 lines
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.
Quoted 8 lines
Quoted 3 lines
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. :)
Signature · 5 lines
Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
Quoted 2 lines
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.
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
Quoted 6 lines · On Tue, 14 Sep 2010 00:52:31 +0300 Vasily Khoruzhick <[email protected]> wrote:
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
Quoted 2 lines
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...
Signature · 5 lines
Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
Quoted 11 lines
On Tue, 14 Sep 2010 00:52:31 +0300
Quoted 5 lines · Vasily Khoruzhick
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
Quoted 2 lines
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
Re: Interrupt latency on some 945GM platforms
Quoted 8 lines · Vasily Khoruzhick
В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал:
Quoted 7 lines
On Tue, 14 Sep 2010 00:52:31 +0300
Quoted 4 lines · Vasily Khoruzhick
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал:
Quoted 2 lines
Yes, you can set vblank_mode=0 in your environment or drirc. At least I think 0 is no vsync. :)
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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
В сообщении от 14 of September 2010 03:55:32 автор Venkatesh Pallipadi написал:
Quoted 6 lines
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..
Quoted 8 lines
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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
Quoted 15 lines · Vasily Khoruzhick
В сообщении от 14 of September 2010 03:55:32 автор Venkatesh Pallipadi написал:
Quoted 12 lines
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.
Quoted 7 lines
Quoted 2 lines
Thanks,
VenkiI 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
В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner написал:
Quoted 3 lines
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)
Quoted 4 lines
If that works, then try
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Regards
Vasily
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
Quoted 5 lines · Vasily Khoruzhick
В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner написал:
Quoted 3 lines
Can you try with NOHZ enabled and the following on the kernel command line:
processor.max_cstate=1
Quoted 8 lines
It works in this case (gears in glxgears move smoothly)
Quoted 4 lines
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?
Signature · 1 line
Sitsofe | http://sucs.org/~sits/
Re: Interrupt latency on some 945GM platforms
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 2 lines · Vasily Khoruzhick
Quoted 1 line
В сообщении от 14 of September 2010 12:52:57 автор Thomas Gleixner
написал:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Can you try with NOHZ enabled and the following on the kernel command
line:
Quoted 11 lines
Quoted 9 lines
Quoted 1 line
processor.max_cstate=1
It works in this case (gears in glxgears move smoothly)
Quoted 3 lines
If that works, then try
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Perhaps
intel_idleis 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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
In reply to Sitsofe WheelerВ сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Perhaps
intel_idleis 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?
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Thomas Gleixner
Acked-by Suresh SiddhaRe: Interrupt latency on some 945GM platforms
Vasily,
Quoted 5 lines · Vasily Khoruzhick
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Quoted 8 lines
Quoted 1 line
Perhaps
intel_idleis 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 <[email protected]> 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.
arch/x86/include/asm/hpet.h +0 -1
@@ -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 );
arch/x86/kernel/early-quirks.c +0 -18
@@ -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 }, {} };
arch/x86/kernel/hpet.c +17 -14
@@ -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
В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
Quoted 6 lines
Quoted 3 lines
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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал:
Quoted 9 lines
В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
Quoted 6 lines
Quoted 3 lines
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
Re: Interrupt latency on some 945GM platforms
Quoted 6 lines · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал:
Quoted 5 lines
В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал:
Quoted 4 lines
Quoted 3 lines
Btw, Jesse, any comments/solutions/workarounds except one with processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo bugzilla?
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
Quoted 3 lines
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
Re: Interrupt latency on some 945GM platforms
Quoted 9 lines · On Thu, 16 Sep 2010 23:06:46 +0300 Vasily Khoruzhick <[email protected]> wrote:
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
Quoted 3 lines
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
Quoted 1 line
/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,
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
Re: Interrupt latency on some 945GM platforms
Quoted 4 lines · On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Quoted 1 line · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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
Quoted 6 lines
Quoted 1 line
/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
Quoted 19 lines · On Fri, 24 Sep 2010 22:48:36 +0300 Vasily Khoruzhick <[email protected]> wrote:
Quoted 4 lines · On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Quoted 1 line · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
Quoted 13 lines
Quoted 8 lines
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
/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...
Signature · 5 lines
Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
Am 24.09.2010 21:51, schrieb Jesse Barnes:
Quoted 20 lines
Quoted 17 lines · On Fri, 24 Sep 2010 22:48:36 +0300 Vasily Khoruzhick<[email protected]> wrote:
Quoted 4 lines · On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Quoted 1 line · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
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
Quoted 9 lines
Quoted 7 lines
Quoted 6 lines
>
/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
2010/9/26 Stefan Biereigel <[email protected]>:
Quoted 41 lines
Am 24.09.2010 21:51, schrieb Jesse Barnes:
Quoted 30 lines
Quoted 26 lines · On Fri, 24 Sep 2010 22:48:36 +0300 Vasily Khoruzhick<[email protected]> wrote:
Quoted 6 lines · On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Quoted 2 lines · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
Quoted 17 lines
Quoted 10 lines
Quoted 4 lines
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
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
- 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...
Quoted 15 lines
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'?
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
2010/9/26 Shaohua Li <[email protected]>
Quoted 57 lines
2010/9/26 Stefan Biereigel <[email protected]>:
Quoted 17 lines
Am 24.09.2010 21:51, schrieb Jesse Barnes:
Quoted 16 lines
Quoted 12 lines · On Fri, 24 Sep 2010 22:48:36 +0300 Vasily Khoruzhick<[email protected]> wrote:
Quoted 6 lines · On 24 of September 2010 22:39:01 Jesse Barnes wrote:
On Thu, 16 Sep 2010 23:06:46 +0300
Quoted 2 lines · Vasily Khoruzhick
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Ok. The problematic part of HPET was not the clocksource, it was the clock event device which failed to deliver interrupts occasionally.
It
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 1 line
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 0Quoted 1 line
/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?
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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 inLKML
Quoted 1 line
some months ago targeting the same problem (but not really attacking it
at
Quoted 1 line
the Chipset driver). As I have one of those Laptops with a 945GM-Chipset
and
Quoted 3 lines
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,
Quoted 3 lines
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
Quoted 8 lines
get
Quoted 5 lines
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, Stefandoes disable msi help with 'pci=nomsi'?
Didn't help for me - besides, according to the KMS driver code, MSI is disabled on 945G
I thought that maybe *enabling* MSI might help, but it seems 945 doesn't support MSI according to the comments in the source.
Hardware: Acer Aspire One
Intel Atom N270 w/ 945GSE
Quoted 5 lines
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signature · 1 line
Alexander Lam
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
In reply to Shaohua LiHello Everyone,
Quoted 15 lines
Quoted 6 lines
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,Quoted 9 lines
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
Quoted 2 lines
does disable msi help with 'pci=nomsi'?
No, here it doesn't.
Re: Interrupt latency on some 945GM platforms
In reply to Shaohua LiQuoted 1 line · 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
In reply to Stefan BiereigelQuoted 8 lines · 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
Quoted 8 lines
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
Quoted 19 lines · Vasily Khoruzhick
Quoted 8 lines · 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 CPU1Quoted 8 lines
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
Quoted 5 lines
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.
My laptop (original acer aspire one) uses an H2O Insyde BIOS. I had never heard of Insyde until I bought the computer. Apparently, Insyde's H2O line is EFI firmware....
Signature · 1 line
Alexander Lam
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: Interrupt latency on some 945GM platforms
In reply to Jesse BarnesQuoted 2 lines · On Fri, 24 Sep 2010 12:39:01 -0700 Jesse Barnes <[email protected]>…
Vasily and Paolo, do you both have Atom CPUs with hyperthreading enabled?
model name : Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz
Signature · 2 lines
Paolo Ornati Linux 2.6.35.4 on x86_64
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
In reply to Vasily KhoruzhickQuoted 5 lines · Vasily Khoruzhick
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Quoted 8 lines
Quoted 1 line
Perhaps
intel_idleis 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?
Signature · 8 lines
Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
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,
Quoted 30 lines · Simon Farnsworth
Quoted 5 lines · Vasily Khoruzhick
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Quoted 8 lines
Quoted 1 line
Perhaps
intel_idleis 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_latencyinterface 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_qosrequest itself. Jesse, can you comment?Signature · 4 lines
Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 17 of September 2010 19:30:26 автор Jesse Barnes написал:
Quoted 8 lines
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
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
Quoted 6 lines · On Fri, 17 Sep 2010 15:50:43 +0300 Vasily Khoruzhick <[email protected]> wrote:
Quoted 4 lines
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,
Signature · 2 lines
Paolo Ornati Linux 2.6.35.4 on x86_64
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
Quoted 12 lines · On Tue, 21 Sep 2010 20:26:07 +0200 Paolo Ornati <[email protected]> wrote:
Quoted 6 lines · On Fri, 17 Sep 2010 15:50:43 +0300 Vasily Khoruzhick <[email protected]> wrote:
Quoted 4 lines
Vasily, can you try the qos workaround on your machine and see if it works too?
Thanks,
Just give me a patch :)
Me too...
Quoted 7 lines
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.
drivers/gpu/drm/i915/intel_display.c +4 -0
@@ -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 */
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
Quoted 3 lines · 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
Quoted 15 lines
(quoted diff) +0
-0b/drivers/gpu/drm/i915/intel_d index 40cc5da..26e1d23 100644
drivers/gpu/drm/i915/intel_display.c +4
-0@@ -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
In reply to Jesse BarnesQuoted 3 lines · On Tue, 21 Sep 2010 15:56:53 -0700 Jesse Barnes <[email protected]>…
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.
Signature · 2 lines
Paolo Ornati Linux 2.6.35.4 on x86_64
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
In reply to Jesse BarnesQuoted 11 lines · On Tue, 21 Sep 2010 15:56:53 -0700 Jesse Barnes <[email protected]>…
Quoted 7 lines
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,
Signature · 2 lines
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?
Quoted 9 lines · On Sat, 25 Sep 2010 12:28:20 +0200 Paolo Ornati <[email protected]> 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)
Signature · 2 lines
Paolo Ornati Linux 2.6.35.7 on x86_64
PATCH 1/1 drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
In reply to Paolo OrnatiThis is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
--- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 8 ++++++++ 2 files changed, 10 insertions(+), 0 deletions(-)
drivers/gpu/drm/i915/i915_drv.h +2 -0
@@ -35,6 +35,7 @@#include "intel_ringbuffer.h" #include <linux/io-mapping.h> #include <linux/i2c.h> +#include <linux/pm_qos_params.h> #include <drm/intel-gtt.h> /* General customization:
@@ -659,6 +660,7 @@ typedef struct drm_i915_private {int lvds_downclock;struct work_struct idle_work;struct timer_list idle_timer; +struct pm_qos_request_list pm_qos;bool busy;u16 orig_clock;int child_dev_num;
drivers/gpu/drm/i915/intel_display.c +8 -0
@@ -4765,6 +4765,8 @@ static void intel_gpu_idle_timer(unsigned long arg)return ; } +pm_qos_remove_request (&dev_priv->pm_qos); + dev_priv->busy = false;queue_work (dev_priv->wq, &dev_priv->idle_work); }
@@ -4940,6 +4942,12 @@ void intel_mark_busy(struct drm_device *dev, struct drm_i915_gem_object *obj) fw_blc_self &= ~FW_BLC_SELF_EN ;I915_WRITE (FW_BLC_SELF , fw_blc_self |FW_BLC_SELF_EN_MASK ); } + +/* Install a handle to prevent C-state starvation of the GPU */ +pm_qos_add_request (&dev_priv->pm_qos, +PM_QOS_CPU_DMA_LATENCY , +20 ); + dev_priv->busy = true; }else mod_timer(&dev_priv->idle_timer, jiffies +
Signature · 1 line
1.7.2.3
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 3 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
Sorry, but it does not. glxgears is still jerky.
Regards
Vasily
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 6 lines · Vasily Khoruzhick
Quoted 3 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
Sorry, but it does not. glxgears is still jerky.
I thought we were trying to fix the reported framerate? Try adjusting the request max latency down from 20 to 1, or even 0.
-Chris
Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 1 line · On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote:
On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <[email protected]>
Quoted 8 lines · wrote:
Quoted 6 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
Quoted 3 lines
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
Sorry, but it does not. glxgears is still jerky.
I thought we were trying to fix the reported framerate?
Yep, it reports 20-30 instead of 60
Quoted 2 lines
Try adjusting the
request max latency down from 20 to 1, or even 0.
Will try.
Regards
Vasily
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 9 lines · Vasily Khoruzhick
Quoted 1 line · On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote:
On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
Quoted 3 lines
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
Sorry, but it does not. glxgears is still jerky.
Do you have the 2.6.36.2 candidate patch that fixes pm_qos in? From the description, it looks like pm_qos doesn't work at all without it.
--Andy
Quoted 17 lines
Quoted 2 lines
I thought we were trying to fix the reported framerate?
Yep, it reports 20-30 instead of 60
Quoted 2 lines
Try adjusting the
request max latency down from 20 to 1, or even 0.Will try.
Regards
Vasily
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 1 line · On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote:
On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick <[email protected]>
Quoted 11 lines · wrote:
Quoted 11 lines · On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote:
Quoted 2 lines
On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
Quoted 4 lines
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first:
does this help?
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Sorry, but it does not. glxgears is still jerky.
Do you have the 2.6.36.2 candidate patch that fixes
pm_qosin? From the description, it looks likepm_qosdoesn't work at all without it.
Nope, where I can get this patch?
Regards
Vasily
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 14 lines · Vasily Khoruzhick
Quoted 1 line · On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote:
On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick <[email protected]>
Quoted 11 lines · wrote:
Quoted 11 lines · On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote:
Quoted 2 lines
On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <[email protected]>
Quoted 6 lines · wrote:
Quoted 6 lines · On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote:
Quoted 4 lines
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first:
does this help?
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Sorry, but it does not. glxgears is still jerky.
Do you have the 2.6.36.2 candidate patch that fixes
pm_qosin? From the description, it looks likepm_qosdoesn't work at all without it.Nope, where I can get this patch?
http://www.spinics.net/lists/kernel/msg1120988.html
I'd test but I don't think my system is affected. :)
--Andy
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 5 lines · On Wednesday 08 December 2010 20:19:19 Andrew Lutomirski wrote:
http://www.spinics.net/lists/kernel/msg1120988.html
I'd test but I don't think my system is affected. :)
--Andy
Nope, still no effect, even with latency decreased to 5, will test with lower values later.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
Quoted 9 lines · Paolo Ornati
Quoted 3 lines · On Wed, 8 Dec 2010 16:24:35 +0000 Chris Wilson <[email protected]>…
This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help?
Sorry for the very long delay... it seems I've latency problems too ;)
Quoted 8 lines
As for Andrew's comment it looks I need a recent kernel to actually test this patch:
"Do you have the 2.6.36.2 candidate patch that fixes
pm_qosin? From the description, it looks likepm_qosdoesn't work at all without it."The "problem" is that I cannot reproduce it with 2.6.37 (tested yesterday for 8+ hours), but maybe it's just hidden by some coincidence.
Check with powertop to see if anything is preventing low C-states. It would be great if it just magically fixed itself...
-Chris
Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
Re: Interrupt latency on some 945GM platforms
In reply to Vasily KhoruzhickQuoted 5 lines · On Thu, 16 Sep 2010 18:03:04 +0300 Vasily Khoruzhick <[email protected]> wrote:
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
processor.max_cstate=2
Nope, it doesn't work with max_cstate=2
Quoted 8 lines
Quoted 1 line
Perhaps
intel_idleis 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.
Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
Re: Interrupt latency on some 945GM platforms
In reply to Vasily KhoruzhickQuoted 12 lines · Vasily Khoruzhick
Quoted 12 lines
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.
Quoted 7 lines
Quoted 2 lines
Thanks,
VenkiI 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
Signature · 1 line
[email protected] -- Speaking for myself only.