* vsync problems with recent graphics stack and 945gm @ 2010-09-13 20:36 Vasily Khoruzhick 2010-09-13 20:44 ` Jesse Barnes 0 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 20:36 UTC (permalink / raw) To: intel-gfx [-- Attachment #1.1: Type: Text/Plain, Size: 960 bytes --] 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 [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: vsync problems with recent graphics stack and 945gm 2010-09-13 20:36 vsync problems with recent graphics stack and 945gm Vasily Khoruzhick @ 2010-09-13 20:44 ` Jesse Barnes 2010-09-13 21:10 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 20:44 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx On Mon, 13 Sep 2010 23:36:11 +0300 Vasily Khoruzhick <anarsoul@gmail.com> 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 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. 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? -- Jesse Barnes, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: vsync problems with recent graphics stack and 945gm 2010-09-13 20:44 ` Jesse Barnes @ 2010-09-13 21:10 ` Vasily Khoruzhick 2010-09-13 21:19 ` Jesse Barnes 0 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 21:10 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx [-- Attachment #1.1: Type: Text/Plain, Size: 559 bytes --] В сообщении от 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 :) Regards Vasily [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Interrupt latency on some 945GM platforms 2010-09-13 21:10 ` Vasily Khoruzhick @ 2010-09-13 21:19 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:19 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Interrupt latency on some 945GM platforms @ 2010-09-13 21:19 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:19 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 21:19 ` Jesse Barnes @ 2010-09-13 21:41 ` Vasily Khoruzhick -1 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 21:41 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-13 21:41 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 21:41 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 21:41 ` Vasily Khoruzhick @ 2010-09-13 21:46 ` Jesse Barnes -1 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:46 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-13 21:46 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:46 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 21:46 ` Jesse Barnes @ 2010-09-13 21:52 ` Vasily Khoruzhick -1 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 21:52 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-13 21:52 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 21:52 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 21:52 ` Vasily Khoruzhick @ 2010-09-13 21:59 ` Jesse Barnes -1 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:59 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-13 21:59 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-13 21:59 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Thomas Gleixner, linux-kernel 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 21:59 ` Jesse Barnes (?) @ 2010-09-13 22:03 ` Vasily Khoruzhick 2010-09-14 0:55 ` Venkatesh Pallipadi -1 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-13 22:03 UTC (permalink / raw) To: Jesse Barnes; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-13 22:03 ` Vasily Khoruzhick @ 2010-09-14 0:55 ` Venkatesh Pallipadi 2010-09-14 8:09 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Venkatesh Pallipadi @ 2010-09-14 0:55 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: Jesse Barnes, intel-gfx, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 0:55 ` Venkatesh Pallipadi @ 2010-09-14 8:09 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-14 8:09 UTC (permalink / raw) To: Venkatesh Pallipadi Cc: Jesse Barnes, intel-gfx, Thomas Gleixner, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-14 8:09 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-14 8:09 UTC (permalink / raw) To: Venkatesh Pallipadi; +Cc: intel-gfx, Thomas Gleixner, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 8:09 ` Vasily Khoruzhick (?) @ 2010-09-14 9:52 ` Thomas Gleixner 2010-09-14 12:29 ` Vasily Khoruzhick -1 siblings, 1 reply; 69+ messages in thread From: Thomas Gleixner @ 2010-09-14 9:52 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 9:52 ` Thomas Gleixner @ 2010-09-14 12:29 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-14 12:29 UTC (permalink / raw) To: Thomas Gleixner Cc: Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-14 12:29 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-14 12:29 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 12:29 ` Vasily Khoruzhick (?) @ 2010-09-14 22:41 ` Sitsofe Wheeler 2010-09-15 7:07 ` Vasily Khoruzhick 2010-09-16 15:03 ` Vasily Khoruzhick -1 siblings, 2 replies; 69+ messages in thread From: Sitsofe Wheeler @ 2010-09-14 22:41 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Thomas Gleixner, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel 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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 22:41 ` Sitsofe Wheeler @ 2010-09-15 7:07 ` Vasily Khoruzhick 2010-09-16 15:03 ` Vasily Khoruzhick 1 sibling, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-15 7:07 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Thomas Gleixner, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-15 7:07 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-15 7:07 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Venkatesh Pallipadi, Thomas Gleixner, intel-gfx, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 22:41 ` Sitsofe Wheeler @ 2010-09-16 15:03 ` Vasily Khoruzhick 2010-09-16 15:03 ` Vasily Khoruzhick 1 sibling, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 15:03 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Thomas Gleixner, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-16 15:03 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 15:03 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Venkatesh Pallipadi, Thomas Gleixner, intel-gfx, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 15:03 ` Vasily Khoruzhick (?) @ 2010-09-16 18:07 ` Thomas Gleixner 2010-09-16 18:30 ` Vasily Khoruzhick -1 siblings, 1 reply; 69+ messages in thread From: Thomas Gleixner @ 2010-09-16 18:07 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Sitsofe Wheeler, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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; ^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 18:07 ` Thomas Gleixner @ 2010-09-16 18:30 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 18:30 UTC (permalink / raw) To: Thomas Gleixner Cc: Sitsofe Wheeler, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-16 18:30 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 18:30 UTC (permalink / raw) To: Thomas Gleixner Cc: Venkatesh Pallipadi, intel-gfx, Sitsofe Wheeler, linux-kernel [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 18:30 ` Vasily Khoruzhick (?) @ 2010-09-16 18:42 ` Vasily Khoruzhick 2010-09-16 18:50 ` Thomas Gleixner -1 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 18:42 UTC (permalink / raw) To: Thomas Gleixner Cc: Sitsofe Wheeler, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 18:42 ` Vasily Khoruzhick @ 2010-09-16 18:50 ` Thomas Gleixner 2010-09-16 20:06 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Thomas Gleixner @ 2010-09-16 18:50 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Sitsofe Wheeler, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 18:50 ` Thomas Gleixner @ 2010-09-16 20:06 ` Vasily Khoruzhick 2010-09-24 19:39 ` Jesse Barnes 0 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-16 20:06 UTC (permalink / raw) To: Thomas Gleixner Cc: Sitsofe Wheeler, Venkatesh Pallipadi, Jesse Barnes, intel-gfx, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 20:06 ` Vasily Khoruzhick @ 2010-09-24 19:39 ` Jesse Barnes 2010-09-24 19:48 ` Vasily Khoruzhick 2010-09-25 10:25 ` Paolo Ornati 0 siblings, 2 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-24 19:39 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, linux-kernel, Len Brown 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-24 19:39 ` Jesse Barnes @ 2010-09-24 19:48 ` Vasily Khoruzhick 2010-09-24 19:51 ` Jesse Barnes 2010-09-25 10:25 ` Paolo Ornati 1 sibling, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-24 19:48 UTC (permalink / raw) To: Jesse Barnes Cc: Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, linux-kernel, Len Brown 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 :) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-24 19:48 ` Vasily Khoruzhick @ 2010-09-24 19:51 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-24 19:51 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, linux-kernel, Len Brown 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-24 19:51 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-24 19:51 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Venkatesh Pallipadi, intel-gfx, Sitsofe Wheeler, linux-kernel, Thomas Gleixner, Len Brown 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-24 19:51 ` Jesse Barnes (?) @ 2010-09-26 10:53 ` Stefan Biereigel 2010-09-27 0:46 ` Shaohua Li 2010-09-27 21:18 ` Vasily Khoruzhick -1 siblings, 2 replies; 69+ messages in thread From: Stefan Biereigel @ 2010-09-26 10:53 UTC (permalink / raw) To: linux-kernel Cc: Vasily Khoruzhick, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, Len Brown, Jesse Barnes 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-26 10:53 ` Stefan Biereigel @ 2010-09-27 0:46 ` Shaohua Li 2010-09-27 21:18 ` Vasily Khoruzhick 1 sibling, 0 replies; 69+ messages in thread From: Shaohua Li @ 2010-09-27 0:46 UTC (permalink / raw) To: Stefan Biereigel Cc: linux-kernel, Vasily Khoruzhick, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, Len Brown, Jesse Barnes 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'? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-27 0:46 ` Shaohua Li 0 siblings, 0 replies; 69+ messages in thread From: Shaohua Li @ 2010-09-27 0:46 UTC (permalink / raw) To: Stefan Biereigel Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel, Sitsofe Wheeler, Thomas Gleixner, Len Brown 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'? _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-27 0:46 ` Shaohua Li (?) @ 2010-09-27 2:52 ` Alexander Lam -1 siblings, 0 replies; 69+ messages in thread From: Alexander Lam @ 2010-09-27 2:52 UTC (permalink / raw) To: Shaohua Li Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel, Sitsofe Wheeler, Thomas Gleixner, Len Brown, Stefan Biereigel [-- Attachment #1.1: Type: text/plain, Size: 3099 bytes --] 2010/9/26 Shaohua Li <shaohua.li@intel.com> > 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'? > 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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Alexander Lam [-- Attachment #1.2: Type: text/html, Size: 4640 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-27 0:46 ` Shaohua Li (?) (?) @ 2010-09-27 5:45 ` Stefan Biereigel -1 siblings, 0 replies; 69+ messages in thread From: Stefan Biereigel @ 2010-09-27 5:45 UTC (permalink / raw) To: Shaohua Li Cc: linux-kernel, Vasily Khoruzhick, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, Len Brown, Jesse Barnes 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-27 0:46 ` Shaohua Li @ 2010-09-27 11:41 ` Vasily Khoruzhick -1 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-27 11:41 UTC (permalink / raw) To: Shaohua Li Cc: Stefan Biereigel, linux-kernel, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, Len Brown, Jesse Barnes On 27 of September 2010 03:46:23 Shaohua Li wrote: > does disable msi help with 'pci=nomsi'? Doesn't help on my system :( ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-27 11:41 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-27 11:41 UTC (permalink / raw) To: Shaohua Li Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel, Sitsofe Wheeler, Thomas Gleixner, Len Brown, Stefan Biereigel On 27 of September 2010 03:46:23 Shaohua Li wrote: > does disable msi help with 'pci=nomsi'? Doesn't help on my system :( ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-26 10:53 ` Stefan Biereigel @ 2010-09-27 21:18 ` Vasily Khoruzhick 2010-09-27 21:18 ` Vasily Khoruzhick 1 sibling, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-27 21:18 UTC (permalink / raw) To: Stefan Biereigel Cc: linux-kernel, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, Len Brown, Jesse Barnes 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-27 21:18 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-27 21:18 UTC (permalink / raw) To: Stefan Biereigel Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel, Sitsofe Wheeler, Thomas Gleixner, Len Brown 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-27 21:18 ` Vasily Khoruzhick (?) @ 2010-09-30 20:23 ` Alexander Lam -1 siblings, 0 replies; 69+ messages in thread From: Alexander Lam @ 2010-09-30 20:23 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Venkatesh Pallipadi, intel-gfx, linux-kernel, Sitsofe Wheeler, Thomas Gleixner, Len Brown, Stefan Biereigel [-- Attachment #1.1: Type: text/plain, Size: 1505 bytes --] On Mon, Sep 27, 2010 at 5:18 PM, Vasily Khoruzhick <anarsoul@gmail.com>wrote: > 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. > 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.... -- Alexander Lam [-- Attachment #1.2: Type: text/html, Size: 2050 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-24 19:39 ` Jesse Barnes 2010-09-24 19:48 ` Vasily Khoruzhick @ 2010-09-25 10:25 ` Paolo Ornati 1 sibling, 0 replies; 69+ messages in thread From: Paolo Ornati @ 2010-09-25 10:25 UTC (permalink / raw) To: Jesse Barnes Cc: Vasily Khoruzhick, Thomas Gleixner, Sitsofe Wheeler, Venkatesh Pallipadi, intel-gfx, linux-kernel, Len Brown 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-16 15:03 ` Vasily Khoruzhick @ 2010-09-17 9:02 ` Simon Farnsworth -1 siblings, 0 replies; 69+ messages in thread From: Simon Farnsworth @ 2010-09-17 9:02 UTC (permalink / raw) To: intel-gfx Cc: Vasily Khoruzhick, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel, Jesse Barnes 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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-17 9:02 ` Simon Farnsworth 0 siblings, 0 replies; 69+ messages in thread From: Simon Farnsworth @ 2010-09-17 9:02 UTC (permalink / raw) To: intel-gfx Cc: Venkatesh Pallipadi, Sitsofe Wheeler, linux-kernel, Thomas Gleixner 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/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-17 9:02 ` Simon Farnsworth (?) @ 2010-09-17 16:30 ` Jesse Barnes 2010-09-17 12:50 ` Vasily Khoruzhick -1 siblings, 1 reply; 69+ messages in thread From: Jesse Barnes @ 2010-09-17 16:30 UTC (permalink / raw) To: Simon Farnsworth, intel-gfx Cc: Vasily Khoruzhick, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-17 16:30 ` [Intel-gfx] " Jesse Barnes @ 2010-09-17 12:50 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-17 12:50 UTC (permalink / raw) To: Jesse Barnes Cc: Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-17 12:50 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-17 12:50 UTC (permalink / raw) To: Jesse Barnes Cc: Venkatesh Pallipadi, intel-gfx, Sitsofe Wheeler, linux-kernel, Thomas Gleixner [-- Attachment #1.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 #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-17 12:50 ` Vasily Khoruzhick (?) @ 2010-09-21 18:26 ` Paolo Ornati 2010-09-21 22:56 ` Jesse Barnes 2010-12-08 16:24 ` [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU Chris Wilson -1 siblings, 2 replies; 69+ messages in thread From: Paolo Ornati @ 2010-09-21 18:26 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Jesse Barnes, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-21 18:26 ` [Intel-gfx] " Paolo Ornati @ 2010-09-21 22:56 ` Jesse Barnes 2010-12-08 16:24 ` [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU Chris Wilson 1 sibling, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-21 22:56 UTC (permalink / raw) To: Paolo Ornati Cc: Vasily Khoruzhick, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms @ 2010-09-21 22:56 ` Jesse Barnes 0 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-21 22:56 UTC (permalink / raw) To: Paolo Ornati Cc: Thomas, Venkatesh Pallipadi, intel-gfx, Wheeler, linux-kernel, Sitsofe, Gleixner 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 ^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-21 22:56 ` Jesse Barnes (?) @ 2010-09-22 5:57 ` Vasily Khoruzhick -1 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-09-22 5:57 UTC (permalink / raw) To: Jesse Barnes Cc: Paolo Ornati, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 */ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-21 22:56 ` Jesse Barnes (?) (?) @ 2010-09-23 18:21 ` Paolo Ornati -1 siblings, 0 replies; 69+ messages in thread From: Paolo Ornati @ 2010-09-23 18:21 UTC (permalink / raw) To: Jesse Barnes Cc: Vasily Khoruzhick, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms 2010-09-21 22:56 ` Jesse Barnes ` (2 preceding siblings ...) (?) @ 2010-09-25 10:28 ` Paolo Ornati 2010-10-16 15:54 ` [Intel-gfx] Interrupt latency on some 945GM platforms -- and TCP/IP silent data corruption? Paolo Ornati -1 siblings, 1 reply; 69+ messages in thread From: Paolo Ornati @ 2010-09-25 10:28 UTC (permalink / raw) To: Jesse Barnes Cc: Vasily Khoruzhick, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Intel-gfx] Interrupt latency on some 945GM platforms -- and TCP/IP silent data corruption? 2010-09-25 10:28 ` Paolo Ornati @ 2010-10-16 15:54 ` Paolo Ornati 0 siblings, 0 replies; 69+ messages in thread From: Paolo Ornati @ 2010-10-16 15:54 UTC (permalink / raw) To: Paolo Ornati Cc: Jesse Barnes, Vasily Khoruzhick, Simon Farnsworth, intel-gfx, Sitsofe Wheeler, Venkatesh Pallipadi, Thomas Gleixner, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-09-21 18:26 ` [Intel-gfx] " Paolo Ornati 2010-09-21 22:56 ` Jesse Barnes @ 2010-12-08 16:24 ` Chris Wilson 2010-12-08 16:44 ` Vasily Khoruzhick [not found] ` <20110115113431.0e42f037@gmail.com> 1 sibling, 2 replies; 69+ messages in thread From: Chris Wilson @ 2010-12-08 16:24 UTC (permalink / raw) To: intel-gfx; +Cc: Paolo Ornati 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? --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 8 ++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d9b54a2..4675f6d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -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; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e213529..128020a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -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 + -- 1.7.2.3 ^ permalink raw reply related [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 16:24 ` [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU Chris Wilson @ 2010-12-08 16:44 ` Vasily Khoruzhick 2010-12-08 16:54 ` Chris Wilson [not found] ` <20110115113431.0e42f037@gmail.com> 1 sibling, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-12-08 16:44 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Paolo Ornati 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 16:44 ` Vasily Khoruzhick @ 2010-12-08 16:54 ` Chris Wilson 2010-12-08 17:00 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Chris Wilson @ 2010-12-08 16:54 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Paolo Ornati On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > 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 -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 16:54 ` Chris Wilson @ 2010-12-08 17:00 ` Vasily Khoruzhick 2010-12-08 17:54 ` Andrew Lutomirski 0 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-12-08 17:00 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx, Paolo Ornati On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: > On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > > 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? Yep, it reports 20-30 instead of 60 > Try adjusting the > request max latency down from 20 to 1, or even 0. Will try. Regards Vasily ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 17:00 ` Vasily Khoruzhick @ 2010-12-08 17:54 ` Andrew Lutomirski 2010-12-08 18:14 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Andrew Lutomirski @ 2010-12-08 17:54 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Paolo Ornati On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: >> On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick <anarsoul@gmail.com> > wrote: >> > 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. 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 >> >> I thought we were trying to fix the reported framerate? > > Yep, it reports 20-30 instead of 60 > >> Try adjusting the >> request max latency down from 20 to 1, or even 0. > > Will try. > > Regards > Vasily > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 17:54 ` Andrew Lutomirski @ 2010-12-08 18:14 ` Vasily Khoruzhick 2010-12-08 18:19 ` Andrew Lutomirski 0 siblings, 1 reply; 69+ messages in thread From: Vasily Khoruzhick @ 2010-12-08 18:14 UTC (permalink / raw) To: Andrew Lutomirski; +Cc: intel-gfx, Paolo Ornati On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote: > On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > > On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: > >> On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick > >> <anarsoul@gmail.com> > > > > wrote: > >> > 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. > > 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. Nope, where I can get this patch? Regards Vasily ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 18:14 ` Vasily Khoruzhick @ 2010-12-08 18:19 ` Andrew Lutomirski 2010-12-08 18:55 ` Vasily Khoruzhick 0 siblings, 1 reply; 69+ messages in thread From: Andrew Lutomirski @ 2010-12-08 18:19 UTC (permalink / raw) To: Vasily Khoruzhick; +Cc: intel-gfx, Paolo Ornati On Wed, Dec 8, 2010 at 1:14 PM, Vasily Khoruzhick <anarsoul@gmail.com> wrote: > On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote: >> On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick <anarsoul@gmail.com> > wrote: >> > On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: >> >> On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick >> >> <anarsoul@gmail.com> >> > >> > wrote: >> >> > 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. >> >> 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. > > 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU 2010-12-08 18:19 ` Andrew Lutomirski @ 2010-12-08 18:55 ` Vasily Khoruzhick 0 siblings, 0 replies; 69+ messages in thread From: Vasily Khoruzhick @ 2010-12-08 18:55 UTC (permalink / raw) To: Andrew Lutomirski; +Cc: intel-gfx, Paolo Ornati 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
[parent not found: <20110115113431.0e42f037@gmail.com>]
* Re: [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU [not found] ` <20110115113431.0e42f037@gmail.com> @ 2011-01-15 11:13 ` Chris Wilson 0 siblings, 0 replies; 69+ messages in thread From: Chris Wilson @ 2011-01-15 11:13 UTC (permalink / raw) To: Paolo Ornati; +Cc: intel-gfx On Sat, 15 Jan 2011 11:34:31 +0100, Paolo Ornati <ornati@gmail.com> wrote: > On Wed, 8 Dec 2010 16:24:35 +0000 > Chris Wilson <chris@chris-wilson.co.uk> 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 for the very long delay... it seems I've latency problems too ;) > > 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_qos in? From > the description, it looks like pm_qos doesn'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 -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-16 15:03 ` Vasily Khoruzhick ` (2 preceding siblings ...) (?) @ 2010-09-24 18:41 ` Jesse Barnes -1 siblings, 0 replies; 69+ messages in thread From: Jesse Barnes @ 2010-09-24 18:41 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Sitsofe Wheeler, Thomas Gleixner, Venkatesh Pallipadi, intel-gfx, linux-kernel 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Interrupt latency on some 945GM platforms 2010-09-14 8:09 ` Vasily Khoruzhick (?) (?) @ 2010-09-14 9:55 ` Andi Kleen -1 siblings, 0 replies; 69+ messages in thread From: Andi Kleen @ 2010-09-14 9:55 UTC (permalink / raw) To: Vasily Khoruzhick Cc: Venkatesh Pallipadi, intel-gfx, Thomas Gleixner, linux-kernel 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2011-01-15 11:13 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-09-13 20:36 vsync problems with recent graphics stack and 945gm Vasily Khoruzhick 2010-09-13 20:44 ` Jesse Barnes 2010-09-13 21:10 ` Vasily Khoruzhick 2010-09-13 21:19 ` Interrupt latency on some 945GM platforms Jesse Barnes 2010-09-13 21:19 ` Jesse Barnes 2010-09-13 21:41 ` Vasily Khoruzhick 2010-09-13 21:41 ` Vasily Khoruzhick 2010-09-13 21:46 ` Jesse Barnes 2010-09-13 21:46 ` Jesse Barnes 2010-09-13 21:52 ` Vasily Khoruzhick 2010-09-13 21:52 ` Vasily Khoruzhick 2010-09-13 21:59 ` Jesse Barnes 2010-09-13 21:59 ` Jesse Barnes 2010-09-13 22:03 ` Vasily Khoruzhick 2010-09-14 0:55 ` Venkatesh Pallipadi 2010-09-14 8:09 ` Vasily Khoruzhick 2010-09-14 8:09 ` Vasily Khoruzhick 2010-09-14 9:52 ` Thomas Gleixner 2010-09-14 12:29 ` Vasily Khoruzhick 2010-09-14 12:29 ` Vasily Khoruzhick 2010-09-14 22:41 ` Sitsofe Wheeler 2010-09-15 7:07 ` Vasily Khoruzhick 2010-09-15 7:07 ` Vasily Khoruzhick 2010-09-16 15:03 ` Vasily Khoruzhick 2010-09-16 15:03 ` Vasily Khoruzhick 2010-09-16 18:07 ` Thomas Gleixner 2010-09-16 18:30 ` Vasily Khoruzhick 2010-09-16 18:30 ` Vasily Khoruzhick 2010-09-16 18:42 ` Vasily Khoruzhick 2010-09-16 18:50 ` Thomas Gleixner 2010-09-16 20:06 ` Vasily Khoruzhick 2010-09-24 19:39 ` Jesse Barnes 2010-09-24 19:48 ` Vasily Khoruzhick 2010-09-24 19:51 ` Jesse Barnes 2010-09-24 19:51 ` Jesse Barnes 2010-09-26 10:53 ` Stefan Biereigel 2010-09-27 0:46 ` Shaohua Li 2010-09-27 0:46 ` Shaohua Li 2010-09-27 2:52 ` Alexander Lam 2010-09-27 5:45 ` Stefan Biereigel 2010-09-27 11:41 ` Vasily Khoruzhick 2010-09-27 11:41 ` Vasily Khoruzhick 2010-09-27 21:18 ` Vasily Khoruzhick 2010-09-27 21:18 ` Vasily Khoruzhick 2010-09-30 20:23 ` Alexander Lam 2010-09-25 10:25 ` Paolo Ornati 2010-09-17 9:02 ` [Intel-gfx] " Simon Farnsworth 2010-09-17 9:02 ` Simon Farnsworth 2010-09-17 16:30 ` [Intel-gfx] " Jesse Barnes 2010-09-17 12:50 ` Vasily Khoruzhick 2010-09-17 12:50 ` Vasily Khoruzhick 2010-09-21 18:26 ` [Intel-gfx] " Paolo Ornati 2010-09-21 22:56 ` Jesse Barnes 2010-09-21 22:56 ` Jesse Barnes 2010-09-22 5:57 ` [Intel-gfx] " Vasily Khoruzhick 2010-09-23 18:21 ` Paolo Ornati 2010-09-25 10:28 ` Paolo Ornati 2010-10-16 15:54 ` [Intel-gfx] Interrupt latency on some 945GM platforms -- and TCP/IP silent data corruption? Paolo Ornati 2010-12-08 16:24 ` [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU Chris Wilson 2010-12-08 16:44 ` Vasily Khoruzhick 2010-12-08 16:54 ` Chris Wilson 2010-12-08 17:00 ` Vasily Khoruzhick 2010-12-08 17:54 ` Andrew Lutomirski 2010-12-08 18:14 ` Vasily Khoruzhick 2010-12-08 18:19 ` Andrew Lutomirski 2010-12-08 18:55 ` Vasily Khoruzhick [not found] ` <20110115113431.0e42f037@gmail.com> 2011-01-15 11:13 ` Chris Wilson 2010-09-24 18:41 ` Interrupt latency on some 945GM platforms Jesse Barnes 2010-09-14 9:55 ` Andi Kleen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.