* 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 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
* 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: [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 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 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 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: 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-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: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-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: 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: [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
* 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
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.