Hi,
With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu 10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC 900 with an i915.
Attempts to bisect the issue are not successful - most kernels in between rc1 and rc2 just make the system come up with a black screen which takes minutes between showing messages (rather than finishing in two seconds). bc584c5107bfd97e2aa41c798e3b213bcdd4eae7 seems to be good but 45d7f32c7a43cbb9592886d38190e379e2eb2226 is not.
Warnings like:
[ 64.227046] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 31. [ 82.953011] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
appear frequently in the dmesg and the stalls are most visible when playing fullscreen video. The first warning message (Insufficient FIFO...) is present in 2.6.36-rc1 but not 2.6.35.
One additional quirk is that a more recent X userspace (xserver-xorg-video-intel 2:2.12.0+git20100810.19c48d3b-0ubuntu0sarvatt2~lucid, libdrm-intel1 2.4.21+git20100804.431f7f00-0ubuntu0sarvatt~lucid, xorg 1:7.5+6ubuntu1) now has major tearing (when watching video) and refresh (in general at least when using compiz) issues which were not seen with 2.6.36-rc1.
On Tue, 24 Aug 2010 00:35:51 +0100, Sitsofe Wheeler sitsofe@yahoo.com wrote:
Hi,
With 2.6.36-rc2 I see periodic stalls when running with a stock Ubuntu 10.04 userspace. These stalls were not present in 2.6.36-rc1 on an EeePC 900 with an i915.
From the error message, I'd suggest we'd tackle hangcheck - it simply
shouldn't be firing at all under normal circumstances. (Looking at it we don't handle the introduction of the BSD ring correctly, but that is irrelevant on the EeePC 900.)
Do the stalls and tearing go away with:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index e4d42a7..dc5fb4f 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1305,8 +1305,7 @@ void i915_hangcheck_elapsed(unsigned long data) dev_priv->hangcheck_count = 0;
/* Issue a wake-up to catch stuck h/w. */ - if (dev_priv->render_ring.waiting_gem_seqno | - dev_priv->bsd_ring.waiting_gem_seqno) { + if (0) { DRM_ERROR("Hangcheck timer elapsed... GPU idle, missed IRQ.\n"); if (dev_priv->render_ring.waiting_gem_seqno) DRM_WAKEUP(&dev_priv->render_ring.irq_queue);
On Tue, Aug 24, 2010 at 01:12:22AM +0100, Chris Wilson wrote:
From the error message, I'd suggest we'd tackle hangcheck - it simply shouldn't be firing at all under normal circumstances. (Looking at it we don't handle the introduction of the BSD ring correctly, but that is irrelevant on the EeePC 900.)
Do the stalls and tearing go away with:
The stalls became a bit better with the patch but there were still very small pauses but the tearing with more recent X bits is definitely still there. Additionally videos in totem would play as a tiny one pixel high row about a quarter of the screen across at the top left of the screen. It also seems that X has started having trouble refreshing itself so sometimes new windows are invisible (especially with compiz).
I've also noticed a couple of other things. Sometimes (but without any pattern) an extra display is detected even though no external display is plugged in. Here's an example of the xrandr output: Screen 0: minimum 320 x 200, current 2384 x 768, maximum 4096 x 4096 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x600 59.5*+ 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 VGA1 disconnected (normal left inverted right x axis y axis) TV1 disconnected (normal left inverted right x axis y axis) 1360x768 (0xbc) 84.8MHz h: width 1360 start 1432 end 1568 total 1776 skew 0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz
Sometimes the output is TV1 sometimes it is VGA1 and sometimes these extra outputs will disappear. Another issue is that switching from X to a console for the first time causes a LCD "blooming" effect.
On Tue, 24 Aug 2010 08:57:41 +0100, Sitsofe Wheeler sitsofe@yahoo.com wrote:
The stalls became a bit better with the patch but there were still very small pauses but the tearing with more recent X bits is definitely still there. Additionally videos in totem would play as a tiny one pixel high row about a quarter of the screen across at the top left of the screen. It also seems that X has started having trouble refreshing itself so sometimes new windows are invisible (especially with compiz).
Ok, I'm a little happier that the hangcheck could be just another symptom of the problem...
I think it is safe to assume that the bug is in i915, so restricting the bisect to just drm seems plausible:
git bisect start drivers/gpu/drm git bisect good 2.6.36-rc1 git bisect bad 2.6.36-rc2
And yes, it does apppear that the false detection rate for TV has changed. The suspicion is that the change to intel_wait_for_vblank() is actually causing issues here.
On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
Ok, I'm a little happier that the hangcheck could be just another symptom of the problem...
I think it is safe to assume that the bug is in i915, so restricting the bisect to just drm seems plausible:
git bisect start drivers/gpu/drm git bisect good 2.6.36-rc1 git bisect bad 2.6.36-rc2
I should mention that I ran a similar bisect yesterday but it led to a dead end:
# bad: [9ee47476d6734c9deb9ae9ab05d963302f6b6150] Merge branch 'radix-tree' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev # good: [da5cabf80e2433131bf0ed8993abc0f7ea618c73] Linux 2.6.36-rc1 git bisect start 'HEAD' 'v2.6.36-rc1' # good: [d1126ad907ce197ff45fbc2369fbeaf8ae6f75a8] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid git bisect good d1126ad907ce197ff45fbc2369fbeaf8ae6f75a8 # bad: [4fefe435626758b14e6c05d2a5f8d71a997c0ad6] drm/i915,intel_agp: Add support for Sandybridge D0 git bisect bad 4fefe435626758b14e6c05d2a5f8d71a997c0ad6 # bad: [2e88e40bed136a7b7cb1c77d8dc6bd181d0d2732] drm/i915/sdvo: Markup a few constant strings. git bisect bad 2e88e40bed136a7b7cb1c77d8dc6bd181d0d2732 # bad: [6146b3d61925116e3fecce36c2fd873665bd6614] drm/i915: i8xx also doesn't like multiple oustanding pageflips git bisect bad 6146b3d61925116e3fecce36c2fd873665bd6614 # bad: [e044218a8ecb560b6fad65912a4e7e509db40414] drm/i915/sdvo: Add dot crawl property git bisect bad e044218a8ecb560b6fad65912a4e7e509db40414 # bad: [45d7f32c7a43cbb9592886d38190e379e2eb2226] Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile git bisect bad 45d7f32c7a43cbb9592886d38190e379e2eb2226
All the bad kernels above boot EXTREMELY slowly and it's not clear why. Using the results above to run your tests produced the following:
Bisecting: a merge base must be tested [45d7f32c7a43cbb9592886d38190e379e2eb2226] Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile git bisect bad 45d7f32c7a43cbb9592886d38190e379e2eb2226 The merge base 45d7f32c7a43cbb9592886d38190e379e2eb2226 is bad. This means the bug has been fixed between 45d7f32c7a43cbb9592886d38190e379e2eb2226 and [da5cabf80e2433131bf0ed8993abc0f7ea618c73].
As mentioned in the first mail, c584c5107bfd97e2aa41c798e3b213bcdd4eae7 seems to be good but 45d7f32c7a43cbb9592886d38190e379e2eb2226 does not...
Any ideas?
And yes, it does apppear that the false detection rate for TV has changed. The suspicion is that the change to intel_wait_for_vblank() is actually causing issues here.
OK.
On Tue, 24 Aug 2010 09:49:02 +0100, Sitsofe Wheeler sitsofe@yahoo.com wrote:
On Tue, Aug 24, 2010 at 09:16:50AM +0100, Chris Wilson wrote:
Ok, I'm a little happier that the hangcheck could be just another symptom of the problem...
I think it is safe to assume that the bug is in i915, so restricting the bisect to just drm seems plausible:
git bisect start drivers/gpu/drm git bisect good 2.6.36-rc1 git bisect bad 2.6.36-rc2
I should mention that I ran a similar bisect yesterday but it led to a dead end:
[snip]
All the bad kernels above boot EXTREMELY slowly and it's not clear why. Using the results above to run your tests produced the following:
I was hoping that git would be more intelligent than that. Is there a way to simply bisect down one side of a merge?
The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde. A trivial patch you can apply on each step is:
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 33dbcc4..88f3b6c 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -837,7 +837,7 @@ static int hpet_clocksource_register(void) * cyc/sec = FSEC_PER_SEC/hpet_period(fsec/cyc) * cyc/sec = (FSEC_PER_NSEC * NSEC_PER_SEC)/hpet_period */ - hpet_freq = FSEC_PER_NSEC * NSEC_PER_SEC; + hpet_freq = (u64) FSEC_PER_NSEC * NSEC_PER_SEC; do_div(hpet_freq, hpet_period); clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq);
On Tue, Aug 24, 2010 at 10:00:47AM +0100, Chris Wilson wrote:
I was hoping that git would be more intelligent than that. Is there a way to simply bisect down one side of a merge?
Seemingly not...
The slow boot is probably fixed by 4936a3b90d79dd8775c6ac23c2cf2dcebe29abde. A trivial patch you can apply on each step is:
Thanks that patch got it booting at normal speeds. Bisecting has now narrowed the flickering/corruption with a newer X userspace down to this:
commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 Author: Jesse Barnes jbarnes@virtuousgeek.org Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20ms
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eric Anholt eric@anholt.net
Reverting the above against HEAD seems to have fixed the misdetection of displays and hangcheck warnings don't appear (although plenty of FIFO warnings still). I notice that this commit also seemed to be the cause of problems for Ivan and Pekka in http://lkml.org/lkml/2010/8/23/452 ...
In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were converted into vblank waits. One of these caused tearing, mode detection and redraw issues on an EeePC 900 with a more recent intel userspace ( http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves the issue. --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 23157e1..116d938 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder, encoder_funcs->commit(encoder); } /* let the connector get through one full cycle before testing */ - intel_wait_for_vblank(dev, intel_crtc->pipe); + msleep(20);
return crtc; }
In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were converted into vblank waits. One of these caused tearing, mode detection and redraw issues on an EeePC 900 with a more recent intel userspace ( http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves the issue.
Signed-off-by: Sitsofe Wheeler sitsofe@yahoo.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 23157e1..116d938 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder, encoder_funcs->commit(encoder); } /* let the connector get through one full cycle before testing */ - intel_wait_for_vblank(dev, intel_crtc->pipe); + msleep(20);
return crtc; }
With the extra intel_wait_for_vblank added in commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being triggered (which were detected by i915_hangcheck_elapsed). Partially revert this change for now.
Signed-off-by: Sitsofe Wheeler sitsofe@yahoo.com --- drivers/gpu/drm/i915/intel_display.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 116d938..534f1fa 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2379,8 +2379,10 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode) I915_READ(dspbase_reg); }
- /* Wait for vblank for the disable to take effect */ - intel_wait_for_vblank_off(dev, pipe); + if (!IS_I9XX(dev)) { + /* Wait for vblank for the disable to take effect */ + intel_wait_for_vblank_off(dev, pipe); + }
/* Don't disable pipe A or pipe A PLLs if needed */ if (pipeconf_reg == PIPEACONF &&
On Tue, 24 Aug 2010 16:56:16 +0100 Sitsofe Wheeler sitsofe@yahoo.com wrote:
With the extra intel_wait_for_vblank added in commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 periodic stalls were being triggered (which were detected by i915_hangcheck_elapsed). Partially revert this change for now.
Signed-off-by: Sitsofe Wheeler sitsofe@yahoo.com
drivers/gpu/drm/i915/intel_display.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 116d938..534f1fa 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2379,8 +2379,10 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int mode) I915_READ(dspbase_reg); }
/* Wait for vblank for the disable to take effect */intel_wait_for_vblank_off(dev, pipe);
if (!IS_I9XX(dev)) {/* Wait for vblank for the disable to take effect */intel_wait_for_vblank_off(dev, pipe);}/* Don't disable pipe A or pipe A PLLs if needed */ if (pipeconf_reg == PIPEACONF &&
Hm why would we be triggering the hangcheck timer due to this code? I'd rather figure that out and fix it before covering it up like this.
Wait for vblank off will spin until the display line reg stops incrementing, so it's important that we flush any previous writes to shut off the pipe before waiting. So adding a POSTING_READ() above it might help? But that still doesn't explain why it would cause the hangcheck timer to notice a hang...
On Tue, 24 Aug 2010 16:53:59 +0100 Sitsofe Wheeler sitsofe@yahoo.com wrote:
In commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 20ms waits were converted into vblank waits. One of these caused tearing, mode detection and redraw issues on an EeePC 900 with a more recent intel userspace ( http://lkml.org/lkml/2010/8/23/432 ). Restoring the 20ms wait resolves the issue.
Signed-off-by: Sitsofe Wheeler sitsofe@yahoo.com
drivers/gpu/drm/i915/intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 23157e1..116d938 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4539,7 +4539,7 @@ struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder *intel_encoder, encoder_funcs->commit(encoder); } /* let the connector get through one full cycle before testing */
- intel_wait_for_vblank(dev, intel_crtc->pipe);
msleep(20);
return crtc;
}
Wow, tearing, mode detection and redraw problems all because of this line? Maybe because we wait for a longer period here now? Can you check and see if we're timing out in the wait_for_vblank function?
Hello, new on list but not to the kernel. I also have the issue on ThinkPad X40.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller]) Subsystem: IBM Device 0557 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at e0000000 (32-bit, prefetchable) [size=128M] Memory at d0000000 (32-bit, non-prefetchable) [size=512K] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [d0] Power Management version 1 Kernel driver in use: i915
I've been running KMS and drm-intel.git since around 2.6.30, roughly the start of this year, and I've had lots of "fun" with KMS. :p I'm very positive to the KMS concept but it's been a bumpy road so far.
In general, Xv performance with KMS leaves me with a feeling that something is not quite right in terms of playback, both with mplayer and vlc. But while movies are nice, this stalling issue is more important.
drm-intel.git as of 07-21 has sortof worked for me, but could not suspend. Later drm-intel.git would come up with the panel disabled, so basically make the system unusable. I've been using 07-21 for about a month, and just avoiding suspending.
I'm now running drm-intel.git/drm-intel-next (which seems to not get the activity first?) and the latest commit is Linus 2.6.36-rc2. I've merged wireless-testing.git on top of this for ath9k woes.
I get the stall precisely every 10 seconds. In VT mode the system stalls for about a second (the cursor stops blinking) and if I'm typing during the stall then my keypresses appear correctly after the stall ends. No errors in dmesg. Should I set drm.debug to something?
If I'm running X (I've tried xf86-video-intel 2.12.0 and current .git master) then my keypresses appear twice after the stall ends, but honouring shift. If I hold shift, type X, release shift during a stall then I'll get "Xx" after the stall ends. This makes X practically unusable for me, so I'm at a plain VT for now.
Suspend works both in VT and in X, so some things have definately improved for me since 07-21. :)
I've just upgraded my userspace and have xorg-server-1.8.2. No Xv image with either xf86-video-intel driver. I haven't tried this server with the 07-21 kernel to find out if Xv works there. The stalling is more important.
Chris' patch to i915_irq.c disabling wake-ups has no effect on the stalls in VT mode for me.
I haven't bisected, would that be a big help? I'll probably have to spend a fair amount of time on that, since the latest previous kernel I could get to start is over a month old. I've tried drm-intel.git a couple of times over this month, but for long periods of time there were no changes. (Should I look elsewhere?)
I also get intermittent FIFO errors, but I don't know how relevant they are for this issue. It seems like the stalling is a very distinct issue.
Please let me know how I can help fix this.
//Peter
Peter Stuge wrote:
Hello, new on list but not to the kernel. I also have the issue on ThinkPad X40.
As another data point, it seems that there was a similar problem with drm/radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=28411 [Bug 28411] Output polling causes latency every 10 seconds
//Peter
On Wed, 25 Aug 2010 21:15:06 +0200, Peter Stuge peter@stuge.se wrote:
In general, Xv performance with KMS leaves me with a feeling that something is not quite right in terms of playback, both with mplayer and vlc. But while movies are nice, this stalling issue is more important.
That should now be fixed in -intel, we allocating a fresh buffer for every frame and incurring massive clflush overhead. However, we have we replaced it with a worse bug...
drm-intel.git as of 07-21 has sortof worked for me, but could not suspend. Later drm-intel.git would come up with the panel disabled, so basically make the system unusable. I've been using 07-21 for about a month, and just avoiding suspending.
I'm now running drm-intel.git/drm-intel-next (which seems to not get the activity first?) and the latest commit is Linus 2.6.36-rc2. I've merged wireless-testing.git on top of this for ath9k woes.
I get the stall precisely every 10 seconds. In VT mode the system stalls for about a second (the cursor stops blinking) and if I'm typing during the stall then my keypresses appear correctly after the stall ends. No errors in dmesg. Should I set drm.debug to something?
This is caused by the hotplug polling code taking around 600ms to determine that the VGA is not connected.
https://bugs.freedesktop.org/show_bug.cgi?id=29536
If I'm running X (I've tried xf86-video-intel 2.12.0 and current .git master) then my keypresses appear twice after the stall ends, but honouring shift. If I hold shift, type X, release shift during a stall then I'll get "Xx" after the stall ends. This makes X practically unusable for me, so I'm at a plain VT for now.
Suspend works both in VT and in X, so some things have definately improved for me since 07-21. :)
I've just upgraded my userspace and have xorg-server-1.8.2. No Xv image with either xf86-video-intel driver. I haven't tried this server with the 07-21 kernel to find out if Xv works there. The stalling is more important.
https://bugs.freedesktop.org/show_bug.cgi?id=29574 (I think, Daniel reported something closer to your issue on IRC, but I don't have an actual bug for that.)
Chris' patch to i915_irq.c disabling wake-ups has no effect on the stalls in VT mode for me.
I haven't bisected, would that be a big help? I'll probably have to spend a fair amount of time on that, since the latest previous kernel I could get to start is over a month old. I've tried drm-intel.git a couple of times over this month, but for long periods of time there were no changes. (Should I look elsewhere?)
No, sounds like you've hit almost all of the recent 855 regressions. But you have a cursor, that is more than most people!
I also get intermittent FIFO errors, but I don't know how relevant they are for this issue. It seems like the stalling is a very distinct issue.
Actually reporting the FIFO issue is new, the problem has been around for a while though. The underlying issue is that we have a very pessimistic guess for the memory fetch and so estimate that we require more FIFO entries than is available on the hardware. The challenge is to build a table of suitable memory latencies that we can use for a more accurate guess, and save power.
Hi again,
Chris Wilson wrote:
In general, Xv performance with KMS leaves me with a feeling that something is not quite right in terms of playback, both with mplayer and vlc. But while movies are nice, this stalling issue is more important.
That should now be fixed in -intel,
Sounds good! I'd love to test. Which branch/commit is that? I just pulled and am using 68a5ad4.
mplayer -vo gl or gl2 works but uses sw rendering and is very slow.
Incidentally, apropos the backlight commit in xf86-video-intel, it seems like the driver always sets the backlight to 0. Whenver I start X, backlight goes to minimum. I can crank it up with Fn+Home, but if I restart X then it goes back down again.
/proc/acpi/ibm/brightness is always accurate, showing 0 after X starts.
However, we have we replaced it with a worse bug...
Oh well..
I get the stall precisely every 10 seconds.
This is caused by the hotplug polling code taking around 600ms to determine that the VGA is not connected.
Ouch. Could it rely on DDC? Maybe a quick DDC query could be done first, and if that seems to indicate that something is connected only then do the heavy work reading the border color?
Lovely! The patch works well for me, booting with drm_kms_helper.poll=0 on the kernel command line, and I'm back in X now. I need to sort out some keyboard issues, but they are unrelated.
The commit message mentions runtime switching of the polling - how is that done? As I understand it I might have to do that in order to run xrandr e.g. to set up a projector, or possibly after - or no?
I've just upgraded my userspace and have xorg-server-1.8.2. No Xv image with either xf86-video-intel driver. I haven't tried this server with the 07-21 kernel to find out if Xv works there. The stalling is more important.
https://bugs.freedesktop.org/show_bug.cgi?id=29574 (I think, Daniel reported something closer to your issue on IRC, but I don't have an actual bug for that.)
Disabling polling made no difference for Xv. I will try to merge your overlay branch.
drm-intel.git (Should I look elsewhere?)
No, sounds like you've hit almost all of the recent 855 regressions.
.36-rc2 is the first kernel in what seems like a long time that feels like a solid improvement, even if there are still some issues. Well done!
But you have a cursor, that is more than most people!
Funny you should say that! :) Actually I *don't* have a cursor in X on cold boot, but it shows up after suspend+resume.
The cursor I mentioned is the VT blinking one.
very pessimistic guess for the memory fetch
Aha. Thanks for the explanation!
//Peter
On Thu, 26 Aug 2010 01:33:15 +0200, Peter Stuge peter@stuge.se wrote:
Hi again,
Chris Wilson wrote:
In general, Xv performance with KMS leaves me with a feeling that something is not quite right in terms of playback, both with mplayer and vlc. But while movies are nice, this stalling issue is more important.
That should now be fixed in -intel,
Sounds good! I'd love to test. Which branch/commit is that? I just pulled and am using 68a5ad4.
mplayer -vo gl or gl2 works but uses sw rendering and is very slow.
Master with -vo xv should be good, if it doesn't hang.
Incidentally, apropos the backlight commit in xf86-video-intel, it seems like the driver always sets the backlight to 0. Whenver I start X, backlight goes to minimum. I can crank it up with Fn+Home, but if I restart X then it goes back down again.
/proc/acpi/ibm/brightness is always accurate, showing 0 after X starts.
That wasn't meant to be pushed. :( I was working on rectifying lack of backlight controls in on T61 and trying to reduce the number of pieces of code trying to accomplish the same thing through different means. I thought that work was contained on the T61...
Chris Wilson wrote:
Xv performance
That should now be fixed in -intel,
Sounds good! I'd love to test. Which branch/commit is that?
Master with -vo xv should be good, if it doesn't hang.
Doesn't hang, mplayer says:
X11 error: BadAlloc (insufficient resources for operation) X11 error: BadAlloc (insufficient resources for operation) X11 error: BadAlloc (insufficient resources for operation)
over and over, with a window just showing the blue overlay keying. I'm still working on the merge with your overlay branch.
Incidentally, apropos the backlight commit
That wasn't meant to be pushed. :( I was working on rectifying lack of backlight controls in on T61 and trying to reduce the number of pieces of code trying to accomplish the same thing through different means. I thought that work was contained on the T61...
It could be - the resetting backlight thing happened also before the backlight commit. Before pulling I was using the directly preceding commit.
//Peter
On Thu, 26 Aug 2010 02:15:20 +0200, Peter Stuge peter@stuge.se wrote:
It could be - the resetting backlight thing happened also before the backlight commit. Before pulling I was using the directly preceding commit.
https://bugs.freedesktop.org/show_bug.cgi?id=29716
That patch isn't complete but is on the right lines. The first bug appears to be that in the driver we have multiple bits of code to set the panel backlight with different bugs.
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Jesse Barnes -
Peter Stuge -
Sitsofe Wheeler