[Intel-gfx] Warnings on boot resume on Dell XPS 13 (Skylake)
I have a brand-new XPS 13 Skylake laptop. It's running 4.3 plus some wireless-next bits. Everything seems to more-or-less work (even suspend/resume, although resume feels a bit slower than it should be to my untrained eye, which may be related). When I resume my Dell XPS 13, I get: [ 1870.380265] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1870.391278] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1870.402294] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1870.413276] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1870.424303] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1870.424332] [drm:intel_dp_aux_ch [i915]] *ERROR* dp_aux_ch not done status 0xad40001f [ 1870.478777] brcmfmac :3a:00.0 wlp58s0: renamed from wlan0 [ 1870.495764] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready [ 1870.592271] ACPI Error: Cannot release Mutex [PATM], not acquired (20150818/exmutex-376) [ 1870.592276] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.ECDV._Q66] (Node 8802b80e40c8), AE_AML_MUTEX_NOT_ACQUIRED (20150818/psparse-542) [ 1871.017949] [drm] RC6 on [ 1871.592204] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [ 1871.784358] [drm:intel_dp_complete_link_train [i915]] *ERROR* failed to start channel equalization Grepping my logs for all i915 stuff, I get: [1.724524] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0 [1.945499] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [1.956452] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [1.967437] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [1.978420] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [1.989422] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [1.989441] [drm:intel_dp_aux_ch [i915]] *ERROR* dp_aux_ch not done status 0xad40001f [1.995441] WARNING: CPU: 0 PID: 458 at drivers/gpu/drm/i915/intel_dp.c:854 intel_dp_aux_ch+0x114/0x6a0 [i915]() [1.995451] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops rtsx_pci_sdmmc drm mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel rtsx_pci serio_raw i2c_hid video [1.995491] [] intel_dp_aux_ch+0x114/0x6a0 [i915] [1.995511] [] intel_dp_aux_transfer+0xd5/0x1e0 [i915] [1.995537] [] intel_dp_sink_dpms+0x9e/0xe0 [i915] [1.99] [] intel_ddi_post_disable+0x17f/0x1e0 [i915] [1.995576] [] haswell_crtc_disable+0x137/0x2f0 [i915] [1.995596] [] intel_atomic_commit+0x127/0x13d0 [i915] [1.995661] [] intel_fbdev_set_par+0x1a/0x60 [i915] [1.995705] [] intel_fbdev_initial_config+0x1b/0x20 [i915] [4.173108] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [4.365251] [drm:intel_dp_complete_link_train [i915]] *ERROR* failed to start channel equalization [4.614981] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 12.268254] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 286.652441] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 286.664429] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 286.676371] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 286.676416] [drm:intel_dp_aux_ch [i915]] *ERROR* dp_aux_ch not done status 0xad40001f [ 287.706203] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 289.334548] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 371.787856] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 371.798856] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 371.809867] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 371.820874] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 371.831884] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 371.831897] [drm:intel_dp_aux_ch [i915]] *ERROR* dp_aux_ch not done status 0xad40001f [ 372.741129] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 374.412420] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment [ 390.884030] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 390.896031] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 390.907959] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 390.907999]
[Intel-gfx] i915 (sandy bridge mobile) gets stuck at high power
I've twice seen my laptop start sucking power. Both times, turbostat (the fancy new linux-3.8 pending version) shows GFX_W 7. Restarting gnome-shell has no effect. Suspending and resuming it seems to bring the average power down to well under 1W. I have no funny i915 module options set. I'm on 3.7-rc6. Any ideas? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active
On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Inspired by the recent ppgtt regression report, where switching of dmar only for the gpu seems to fix things completely, I've looked again at the semaphores+vt-d situation. Contrary to my earlier testing a few months back my system is now stable with dmar disabled for the igd, and not only when disabling dmar completely. So I'm rather hopeful that all our recent fixes for snb have changed things for code and it's time to try enabling semaphores again. We've also had issues with enabling semaphores which are not vt-d related, but I guess these are all fixed by the autoreport-disabling and lazy request fix. And there's only one way to find out whether there are still other issues ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- If no further vt-d regressions show up in the 3.4 cycle I plan to merge this into -next for 3.5 (in a month or so). Comments about how unfeasibly you deem this highly welcome. -Daniel --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8e0b686..ac52433 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev) if (i915_semaphores = 0) return i915_semaphores; - /* Disable semaphores on SNB */ - if (INTEL_INFO(dev)-gen == 6) - return 0; +#ifdef CONFIG_INTEL_IOMMU + /* Disable semaphores on SNB if VT-d is on. */ + if (INTEL_INFO(dev)-gen == 6 intel_iommu_gfx_mapped) + return false; It might be nice to have a printk here giving instructions for how to work around this. For example: i915: Disabling semaphores to work around a DMAR issue. As an alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or whatever it's supposed to be]. The documentation in kernel-parameters.txt is at best unclear to the uninitiated. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active
On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote: On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Inspired by the recent ppgtt regression report, where switching of dmar only for the gpu seems to fix things completely, I've looked again at the semaphores+vt-d situation. Contrary to my earlier testing a few months back my system is now stable with dmar disabled for the igd, and not only when disabling dmar completely. So I'm rather hopeful that all our recent fixes for snb have changed things for code and it's time to try enabling semaphores again. We've also had issues with enabling semaphores which are not vt-d related, but I guess these are all fixed by the autoreport-disabling and lazy request fix. And there's only one way to find out whether there are still other issues ... Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- If no further vt-d regressions show up in the 3.4 cycle I plan to merge this into -next for 3.5 (in a month or so). Comments about how unfeasibly you deem this highly welcome. -Daniel --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 8e0b686..ac52433 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev) if (i915_semaphores = 0) return i915_semaphores; - /* Disable semaphores on SNB */ - if (INTEL_INFO(dev)-gen == 6) - return 0; +#ifdef CONFIG_INTEL_IOMMU + /* Disable semaphores on SNB if VT-d is on. */ + if (INTEL_INFO(dev)-gen == 6 intel_iommu_gfx_mapped) + return false; It might be nice to have a printk here giving instructions for how to work around this. For example: i915: Disabling semaphores to work around a DMAR issue. As an alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or whatever it's supposed to be]. The documentation in kernel-parameters.txt is at best unclear to the uninitiated. If this really does work, I'll look into this. Atm it's still unclear where to exactly put the plain, we need to annoy internal hardware people to analyze this. Once we have enough evidence that the combination of gpu with various features enable plus VT-d just doesn't seem to work reliably. So can you check whether things do indeed work with this patch, atop kernel 3.4-rc1? Iirc you've been the one with the most trouble when semaphores are enabled ... I've had a hard time reproducing the problems lately. The unconditional instant hard hang went away a few months ago, I think. I'll give it another shot when I get home to that machine. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Thu, Nov 17, 2011 at 1:22 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Oops, sorry for wasting your time, wrong branch. Can you try the for-poland one? And also please try what happens when enabling the iommu. for-poland with semaphores, rc6, and iommu on seems to work. I'm sending this email from that kernel right now :) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
2011/11/16 Matthew Garrett mj...@srcf.ucam.org: On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel Dänzer wrote: I thought the main reason for the delay wasn't broken hardware but to avoid constantly ping-ponging the vblank IRQ between on and off with apps which regularly neeed the vblank counter value, as that could make the counter unreliable. Maybe I'm misremembering though. If turning it on and off results in the counter value being wrong then surely that's a hardware problem? I've tested that turning it on and off between every IRQ still gives valid counter values on sandybridge. This, and the thread that contains it, might be interesting: http://permalink.gmane.org/gmane.comp.video.dri.devel/53201 In summary: there was some resistance to doing this in January, but I couldn't find any legitimate reason. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote: On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote: For Radeon, I'd have thought you could handle this by scheduling an irq for the beginning of scanout (avivo has a register for that) and delaying the vblank disable until you hit it? For Radeon there is such an irq, but iirc we had some discussions on this, also with Alex Deucher, a while ago and some irq's weren't considered very reliable, or already used for other stuff. The idea i had goes like this: Use the crtc scanout position queries together with the vblank counter queries inside some calibration loop, maybe executed after each modeset, to find out the scanline range in which the hardware vblank counter increments -- basically a forbidden range of scanline positions where the race would happen. Then at each vblank off/on, query scanout position before and after the hw vblank counter query. If according to the scanout positions the vblank counter query happened within the forbidden time window, retry the query. With a well working calibration that should add no delay in most cases and a delay to the on/off code of a few dozen microseconds (=duration of a few scanlines) worst case. Assuming we're sleeping rather than busy-looping, that's certainly ok. My previous experiments with radeon indicated that the scanout irq was certainly not entirely reliable - on the other hand, I was trying to use it for completing memory reclocking within the vblank interval. It was typically still within a few scanlines, so a sanity check there wouldn't pose too much of a problem. I think there's a simpler fix: just keep the hardware and software counts in sync -- if everything is working correctly (even with all these crazy races), the difference should be constant. Patch coming momentarily. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] unbinding graphics driver
On Wed, Oct 5, 2011 at 9:38 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Tue, 4 Oct 2011 18:50:18 -0700 Kay, Allen M allen.m@intel.com wrote: I'm working on assigning Intel graphics to a guest OS in Xen/KVM environment. Before assigning the device to the guest OS, I need to first unbind the i915 driver from the device in the host kernel. If I unbind the i915 driver by doing echo -n :00:02.0 /sys/bus/pci/devices/:00:02.0/driver/unbind, I get a kernel oops with no stack trace. Is this something theoretically allowed? It can be unloaded, but you also have to unbind it from the console: $ echo 0 /sys/class/vtconsole/vtcon1/bind # or whatever is your fbcon and of course it has to be unused. You can't unbind it if X is running for example. That said, I've never tested the unbind functionality as above, I only ever unload the module. So we could have undiscovered bugs there. I have also tried to prevent the i915 driver from loading by renaming the drm directory in /lib/modules to drm.0. However, i915 driver is still loaded from somewhere, I don't know how it can happen. Is there a easy way to disable the i915 driver in the kernel? Probably getting loaded by your initrd image. After you've renamed it in /lib/modules (or removed it) you can re-generate your initrd using mkinitrd or mkinitramfs (depending on distro). Alternatively, you can take advantage of one of my favorite misfeatures. Boot with i915.asjkdhfjklasehf=1 and i915 will fail to load :) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kicking rings considered harmful
I'm up and running again. What's the latest patch I'm supposed to test? i915.semaphores=1 intel_iommu=off appears to work. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kicking rings considered harmful
On Sep 26, 2011 9:00 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Only do it in the hope of resurrecting the gpu. Disable when reset is
disabled because it seems to tremendously increases our changes to
actually capture an error_state before the system goes all belly-up.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Hi Andrew,
Can you please apply this patch and boot your system with
Will do in a couple days. I'm several thousand miles from that computer
right now :)
--Andy
i915.reset=0 i915.semaphores=1
and rehang your gpu? This patch to fully disable any attempts at
resurrecting a dead gpu hopefully prevents the full system hang you're
experiencing. At least it helps greatly here on my systems.
If the systems isn't completely dead with this, can you please ssh
into the machine and grabe dmesg, i915_error_state, Xorg.log and
whatever else there might be?
Thanks a lot,
Daniel
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index b79c6f1..ad85c13 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -91,7 +91,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
Override selection of SDVO panel mode in the VBT
(default: auto));
-static bool i915_try_reset __read_mostly = true;
+bool i915_try_reset __read_mostly = true;
module_param_named(reset, i915_try_reset, bool, 0600);
MODULE_PARM_DESC(reset, Attempt GPU resets (default: true));
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 3621336..788a801 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -995,6 +995,7 @@ extern unsigned int i915_semaphores __read_mostly;
extern unsigned int i915_lvds_downclock __read_mostly;
extern unsigned int i915_panel_use_ssc __read_mostly;
extern int i915_vbt_sdvo_panel_type __read_mostly;
+extern bool i915_try_reset __read_mostly;
extern unsigned int i915_enable_rc6 __read_mostly;
extern unsigned int i915_enable_fbc __read_mostly;
extern bool i915_enable_hangcheck __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index da5d607..09c11e4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1694,7 +1694,7 @@ void i915_hangcheck_elapsed(unsigned long data)
if (dev_priv-hangcheck_count++ 1) {
DRM_ERROR(Hangcheck timer elapsed... GPU hung\n);
- if (!IS_GEN2(dev)) {
+ if (!IS_GEN2(dev) i915_try_reset) {
/* Is the chip hanging on a WAIT_FOR_EVENT?
* If so we can simply poke the RB_WAIT bit
* and break the hang. This should work on
--
1.7.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Dumb down the semaphore logic
On Wed, Sep 7, 2011 at 4:12 PM, Ben Widawsky b...@bwidawsk.net wrote: While I think the previous code is correct, it was hard to follow and hard to debug. Since we already have a ring abstraction, might as well use it to handle the semaphore updates and compares. I don't expect this code to make semaphores better or worse, but you never know... Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Eric Anholt e...@anholt.net Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 176 +--- drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +- 4 files changed, 145 insertions(+), 48 deletions(-) Sadly, it still instantly crashes. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Dumb down the semaphore logic
On Wed, Sep 7, 2011 at 6:19 PM, Ben Widawsky b...@bwidawsk.net wrote: On Sep 7, 2011, at 5:30 PM, Andrew Lutomirski l...@mit.edu wrote: On Wed, Sep 7, 2011 at 4:12 PM, Ben Widawsky b...@bwidawsk.net wrote: While I think the previous code is correct, it was hard to follow and hard to debug. Since we already have a ring abstraction, might as well use it to handle the semaphore updates and compares. I don't expect this code to make semaphores better or worse, but you never know... Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Eric Anholt e...@anholt.net Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/intel_ringbuffer.c | 176 +--- drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +- 4 files changed, 145 insertions(+), 48 deletions(-) Sadly, it still instantly crashes. --Andy Remind me again... Does ssh still work? I haven't tried, but I'd be surprised. The *reset* button (the hardware one that's attached to the motherboard) doesn't work. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert i915.semaphore=1 default from 47ae63e0
On Mon, Aug 22, 2011 at 12:53 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 10 Jun 2011 10:06:39 -0400 Andrew Lutomirski l...@mit.edu wrote: On Tue, Jun 7, 2011 at 3:12 AM, Eric Anholt e...@anholt.net wrote: I fear this bug is just getting more asynchronous with the GPU means we trigger race conditions on the GPU more easily. On that note, could you retest with Mesa as of this commit, since I'm told this is a GT1 CPU: commit ef59049c5242a1be7fa59a182d342191185dd62b Author: Eric Anholt e...@anholt.net Date: Sun Jun 5 23:20:57 2011 -0700 i965: Fix flipped GT1 vs GT2 URB VS entry count limits. Nope -- I still got the reset-button-not-working hang. I'm pretty sure I installed mesa right -- I moved everything in /usr/lib64/dri out of the way and put the files in mesa/lib/ in there. Andrew, what's the latest with this? Are you still seeing problems when semaphores are enabled? Yes. On the latest -rc, the system still freezes hard when mutter starts up if I set i915.semaphores=1. [I typed this email last week but apparently it got stuck as a draft. Sorry.] --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert i915.semaphore=1 default from 47ae63e0
Yes. I suspect that, as soon as any 3D happens, the machine locks hard. How does it even get into a state that makes the hardware reset button not work? On Aug 31, 2011 3:08 PM, Keith Packard kei...@keithp.com wrote: On Wed, 31 Aug 2011 14:30:00 -0400, Andrew Lutomirski l...@mit.edu wrote: Yes. On the latest -rc, the system still freezes hard when mutter starts up if I set i915.semaphores=1. Ok. You said that you were running compiz before and that failed, and are now running mutter and that fails also? -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add GPU frequency control file
On Wed, Jul 27, 2011 at 1:17 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Mainly for use in debugging and benchmarking, this file allows the user to control the max frequency used by the GPU. Frequency may still vary based on workload (if the frequency is set to higher than the minimum) but won't go over the newly set value. Would i915_max_freq be a better name? --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
On Mon, Jul 25, 2011 at 12:54 AM, Keith Packard kei...@keithp.com wrote: On Sat, 23 Jul 2011 14:40:36 -0400, Andrew Lutomirski l...@mit.edu wrote: I have a Q67 (DQ67SW board) attached to a Dell U2711 via DP. In previous kernels, the DP link has worked flawlessly. I just booted 3.0-final and simultaneously enabled SNA, and now when my screen goes to sleep I don't get an image back until I power cycle the monitor. dmesg says: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting Jesse put together a set of 7 display port patches around July 7 which were merged just after 3.0-rc6. If you try 3.0-rc6 and find that it works, you should be able to bisect that really quickly; there are only 13 patches post-rc6 in drivers/gpu/drm/i915: $ git bisect start v3.0 v3.0-rc6 -- drivers/gpu/drm/i915 The offending commit appears to be: commit 885a50147f00a8a80108904bf58a18af357717f3 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Jul 7 11:11:01 2011 -0700 drm/i915/dp: remove DPMS mode tracking from DP We currently use this when a hot plug event is received, only checking the link status and re-training if we had previously configured a link. However if we want to preserve the DP configuration across both hot plug and DPMS events (which we do for userspace apps that don't respond to hot plug uevents), we need to unconditionally check the link and try to bring it up on hot plug. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Keith Packard kei...@keithp.com Signed-off-by: Keith Packard kei...@keithp.com A debugging patch and its output are attached. If I had to guess, though, it's a race: a hotplug event happens during the intel_dp_dpms callback, confusing the code that's trying to train the link. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
On Mon, Jul 25, 2011 at 12:08 PM, Keith Packard kei...@keithp.com wrote: On Mon, 25 Jul 2011 11:23:17 -0400, Andrew Lutomirski l...@mit.edu wrote: A debugging patch and its output are attached. I didn't get any attachment. If I had to guess, though, it's a race: a hotplug event happens during the intel_dp_dpms callback, confusing the code that's trying to train the link. Interesting possibility. Please re-send the attachments and I'll take a look. Done. I'm pretty sure the debugging patch is barking up the wrong tree. If you like, I can do a different one to instrument intel_dp_dpms and hotplug later on. -- keith.pack...@intel.com [ 437.718439] [drm:intel_dp_link_down], [ 439.250105] [drm:i915_hotplug_work_func], running encoder hotplug functions [ 439.250322] [drm:intel_dp_check_link_status], DPCD was 110A8401 [ 439.250536] [drm:intel_dp_check_link_status], DPCD is now 110A8401 [ 439.301732] [drm:intel_wait_for_vblank], vblank wait timed out [ 439.303716] [drm:intel_dp_complete_link_train], Training worked. DPCD=110A8401 [ 439.303942] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4, result 0 [ 439.303946] [drm:intel_crt_detect], CRT not detected via hotplug [ 439.303950] [drm:output_poll_execute], [CONNECTOR:5:VGA-1] status updated from 2 to 2 [ 439.316359] [drm:output_poll_execute], [CONNECTOR:8:HDMI-A-1] status updated from 2 to 2 [ 439.316363] [drm:ironlake_dp_detect], DPCD was [ 439.316878] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.316882] [drm:ironlake_dp_detect], Try 0: ret=-110 DPCD= [ 439.319216] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.319219] [drm:ironlake_dp_detect], Try 1: ret=-110 DPCD= [ 439.321217] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.321222] [drm:ironlake_dp_detect], Try 2: ret=-110 DPCD= [ 439.322704] [drm:ironlake_dp_detect], No link. DPCD: [ 439.322711] [drm:output_poll_execute], [CONNECTOR:11:DP-1] status updated from 2 to 2 [ 439.335104] [drm:output_poll_execute], [CONNECTOR:14:HDMI-A-2] status updated from 2 to 2 [ 439.347505] [drm:output_poll_execute], [CONNECTOR:16:HDMI-A-3] status updated from 2 to 2 [ 439.347509] [drm:ironlake_dp_detect], DPCD was 110A8401 [ 439.347724] [drm:ironlake_dp_detect], Try 0: ret=4 DPCD=110A8401 [ 439.347730] [drm:ironlake_dp_detect], Happy now! [ 439.347732] [drm:ironlake_dp_detect], No link. DPCD: 110a8401 [ 439.348687] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [ 439.376262] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [ 439.403831] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [ 439.403835] [drm:drm_detect_monitor_audio], Monitor has basic audio support [ 439.403838] [drm:output_poll_execute], [CONNECTOR:17:DP-2] status updated from 1 to 1 [ 439.403842] [drm:ironlake_dp_detect], DPCD was [ 439.404357] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.404360] [drm:ironlake_dp_detect], Try 0: ret=-110 DPCD= [ 439.406164] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.406165] [drm:ironlake_dp_detect], Try 1: ret=-110 DPCD= [ 439.408167] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 439.408169] [drm:ironlake_dp_detect], Try 2: ret=-110 DPCD= [ 439.409663] [drm:ironlake_dp_detect], No link. DPCD: [ 439.409671] [drm:output_poll_execute], [CONNECTOR:19:DP-3] status updated from 2 to 2 [ 442.956501] [drm:ironlake_crtc_dpms], crtc 0/0 dpms on [ 443.120115] [drm:intel_dp_link_down], [ 443.137460] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off [ 443.189440] [drm:intel_wait_for_vblank], vblank wait timed out [ 443.211838] [drm:sandybridge_update_wm], FIFO watermarks For pipe A - plane 13, cursor: 6 [ 443.211845] [drm:ironlake_check_srwm], watermark 1: display plane 25, fbc lines 3, cursor 6 [ 443.211849] [drm:ironlake_check_srwm], watermark 2: display plane 33, fbc lines 3, cursor 6 [ 443.211854] [drm:ironlake_check_srwm], watermark 3: display plane 169, fbc lines 4, cursor 10 [ 443.211858] [drm:intel_update_fbc], [ 444.644607] [drm:i915_hotplug_work_func], running encoder hotplug functions [ 444.644823] [drm:intel_dp_check_link_status], DPCD was 110A8401 [ 444.645037] [drm:intel_dp_check_link_status], DPCD is now 110A8401 [ 444.696526] [drm:intel_wait_for_vblank], vblank wait timed out [ 444.751506] [drm:intel_wait_for_vblank], vblank wait timed out [ 444.806485] [drm:intel_wait_for_vblank], vblank wait timed out [ 444.861428] [drm:intel_wait_for_vblank], vblank wait timed out [ 444.916419] [drm:intel_wait_for_vblank], vblank wait timed out [ 444.971376] [drm:intel_wait_for_vblank], vblank wait timed out [ 445.026356] [drm:intel_wait_for_vblank], vblank wait timed out [ 445.028771] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 445.028775] [drm:intel_dp_complete_link_train], DPCD is 110A8401
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 25 Jul 2011 10:10:29 -0700 Keith Packard kei...@keithp.com wrote: Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_irq.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 3b03f85..5fe8f28 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -306,12 +306,15 @@ static void i915_hotplug_work_func(struct work_struct *work) struct drm_mode_config *mode_config = dev-mode_config; struct intel_encoder *encoder; + mutex_lock(dev_priv-dev-struct_mutex); DRM_DEBUG_KMS(running encoder hotplug functions\n); list_for_each_entry(encoder, mode_config-encoder_list, base.head) if (encoder-hot_plug) encoder-hot_plug(encoder); + mutex_unlock(dev_priv-dev-struct_mutex); + /* Just fire off a uevent and let userspace tell us what to do */ drm_helper_hpd_irq_event(dev); } yay, sounds like this will fix Andrew's problem and probably lots of other random DP related failures. Doesn't help :( When I do 'xset dpms force off', one of two things happens. Either the display comes back all by itself or it never comes back until I power cycle it. If the display is generating a hotplug event after the dpms code drops the link, then with drm/i915/dp: remove DPMS mode tracking from DP applied the driver will try to bring the display back up. Maybe my display can't handle coming back up that quickly after being told to go to sleep, or maybe there's another bug. Is the original patch supposed to bring the display up if the user unplugs it and re-plugs it? If so, why? And shouldn't a dpms off command at least stick until a hotplug event reports that the display isn't there? --Andy [ 209.146016] xset dpms force off [ 214.014555] [drm:drm_mode_addfb], [FB:48] [ 214.162664] [drm:drm_mode_addfb], [FB:40] [ 214.485742] [drm:drm_mode_addfb], [FB:48] [ 214.652646] [drm:drm_mode_addfb], [FB:40] [ 214.934948] [drm:drm_mode_addfb], [FB:48] [ 215.119459] [drm:drm_mode_addfb], [FB:40] [ 215.378005] [drm:drm_mode_addfb], [FB:48] [ 215.581211] [drm:drm_mode_addfb], [FB:40] [ 217.541498] [drm:drm_mode_addfb], [FB:48] [ 217.579117] [drm:drm_mode_addfb], [FB:40] [ 217.588287] [drm:drm_mode_addfb], [FB:48] [ 217.604938] [drm:drm_mode_addfb], [FB:40] [ 217.638301] [drm:drm_mode_addfb], [FB:48] [ 217.654970] [drm:drm_mode_addfb], [FB:40] [ 217.671641] [drm:drm_mode_addfb], [FB:48] [ 217.728388] [drm:drm_mode_addfb], [FB:40] [ 218.007141] [drm:drm_mode_addfb], [FB:48] [ 218.030397] btrfs: free space inode generation (0) did not match free space cache generation (132273) [ 218.030402] btrfs: failed to load free space cache for block group 18282971136 [ 218.275505] [drm:drm_mode_addfb], [FB:40] [ 218.353250] [drm:drm_mode_addfb], [FB:48] [ 218.378388] [drm:drm_mode_addfb], [FB:40] [ 218.405154] [drm:drm_mode_addfb], [FB:48] [ 218.422545] [drm:drm_mode_addfb], [FB:40] [ 218.455165] [drm:drm_mode_addfb], [FB:48] [ 218.471794] [drm:drm_mode_addfb], [FB:40] [ 218.490260] [drm:drm_mode_addfb], [FB:48] [ 218.521845] [drm:drm_mode_addfb], [FB:40] [ 218.538515] [drm:drm_mode_addfb], [FB:48] [ 218.556996] [drm:drm_mode_addfb], [FB:40] [ 218.600422] [drm:drm_mode_addfb], [FB:48] [ 218.806993] [drm:drm_mode_addfb], [FB:40] [ 225.711943] [drm:intel_dp_dpms], start dpms - 3 [ 225.712160] [drm:intel_dp_link_down], [ 225.729245] [drm:intel_dp_dpms], finish dpms - 3 [ 227.242038] [drm:i915_hotplug_work_func], running encoder hotplug functions [ 227.242043] [drm:intel_dp_hot_plug], about to check status [ 227.242046] [drm:intel_dp_hot_plug], done checking status [ 227.242049] [drm:intel_dp_hot_plug], about to check status [ 227.242474] [drm:intel_dp_check_link_status], eq okay [ 227.294320] [drm:intel_wait_for_vblank], vblank wait timed out [ 227.295270] [drm:intel_dp_check_link_status], start_link_train done [ 227.296520] [drm:intel_dp_check_link_status], complete_link_train done [ 227.296523] [drm:intel_dp_hot_plug], done checking status [ 227.296525] [drm:intel_dp_hot_plug], about to check status [ 227.296527] [drm:intel_dp_hot_plug], done checking status [ 227.296539] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4, result 0 [ 227.296543] [drm:intel_crt_detect], CRT not detected via hotplug [ 227.296547] [drm:output_poll_execute], [CONNECTOR:5:VGA-1]
[Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
I have a Q67 (DQ67SW board) attached to a Dell U2711 via DP. In previous kernels, the DP link has worked flawlessly. I just booted 3.0-final and simultaneously enabled SNA, and now when my screen goes to sleep I don't get an image back until I power cycle the monitor. dmesg says: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting I don't know whether this is a 3.0 regression or whether it's triggered by SNA, but something broke. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
On Sat, Jul 23, 2011 at 2:40 PM, Andrew Lutomirski l...@mit.edu wrote: I have a Q67 (DQ67SW board) attached to a Dell U2711 via DP. In previous kernels, the DP link has worked flawlessly. I just booted 3.0-final and simultaneously enabled SNA, and now when my screen goes to sleep I don't get an image back until I power cycle the monitor. dmesg says: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting I don't know whether this is a 3.0 regression or whether it's triggered by SNA, but something broke. It's not SNA. Building with --disable-sna doesn't help. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
On Tue, Jun 21, 2011 at 2:18 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 21 Jun 2011 19:41:52 +0200 (CEST), Nicolas Kalkhof nkalk...@web.de wrote: However now it seems I'm unable to get my framebuffer console back after I bailed out of X. The screen stays black but my system is still responsive via ssh. This happens without your patch. I'll do some more investigation to make sure I didnt introduce this issue. No, that's another bug with /dev/dri/card0 not honouring O_NONBLOCK. Give X a swift kick and it'll wake up again. -Chris Any plans on fixing this (and related bugs)? The SNA driver makes X freeze sometimes for me, and it's hard to recover on a laptop when ctrl-alt-backspace and even alt-sysrq-v don't seem to give me control of my system back. ssh-ing in and killall -9 Xorg works, but it's not so easy on a laptop. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gen6 (SNB) GPU still stalling besides latest patches
On Tue, Jun 21, 2011 at 3:11 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 21 Jun 2011 20:38:51 +0200 (CEST), Nicolas Kalkhof nkalk...@web.de wrote: Thanks for bringing that up. Is there a bug report for this issue? I was just about to file a report myself but I don't want to create any duplicates. @Chris: What do you mean with giving X a kick? Neither mouse nor keyboard are responding anymore. Killing X from a remote ssh is the only option. :( ssh from-other-machine killall -INT X; is the only way to do it because X is blocked waiting for an event /dev/dri/card0. Btw. This only happens with SNA enabled. When using the classic (UXA?), dropping back to framebuffer console works fine. It's a consequence of handling zaphod and trying to drain all in-fligh DRI2 events to paper-over a crash should one arrive after the Xserver has freed all Resources without calling the destroy handlers... Shouldn't sysrq-v switch even if X isn't cooperating, though? --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert i915.semaphore=1 default from 47ae63e0
On Tue, Jun 7, 2011 at 3:12 AM, Eric Anholt e...@anholt.net wrote: On Thu, 19 May 2011 16:50:00 -0400, Andrew Lutomirski l...@mit.edu wrote: On Thu, May 19, 2011 at 3:56 PM, Keith Packard kei...@keithp.com wrote: On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski l...@mit.edu wrote: My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs instantly when GNOME loads and it hangs so hard the reset button doesn't work. Setting i915.semaphore=0 fixes it. Can you describe precisely what hardware you have? The make and model of the motherboard and the exact model of CPU? I'd like to get this issue resolved for 2.6.40 and need to have a reliable way to reproduce the hang; replicating your hardware may be a good way of doing that. Intel DQ67SW. AMT is enabled but the port 5900 is closed (because I can't figure out how to turn on the kvm). The system boots from UEFI (which is buggy, both because efifb doesn't recognize my hardware, because asking the firmware for the boot menu causes all efivars entries to be ignored, and because unless I set reboot=k the system crashes on reboot). Userspace is F15 running compiz (*not* gnome-shell). BIOS is SWQ6710H.86A.0051.2011.0413.1154. CPU is: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 I fear this bug is just getting more asynchronous with the GPU means we trigger race conditions on the GPU more easily. On that note, could you retest with Mesa as of this commit, since I'm told this is a GT1 CPU: commit ef59049c5242a1be7fa59a182d342191185dd62b Author: Eric Anholt e...@anholt.net Date: Sun Jun 5 23:20:57 2011 -0700 i965: Fix flipped GT1 vs GT2 URB VS entry count limits. Nope -- I still got the reset-button-not-working hang. I'm pretty sure I installed mesa right -- I moved everything in /usr/lib64/dri out of the way and put the files in mesa/lib/ in there. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Revert i915.semaphore=1 default from 47ae63e0
On Thu, May 19, 2011 at 4:50 PM, Andrew Lutomirski l...@mit.edu wrote: On Thu, May 19, 2011 at 3:56 PM, Keith Packard kei...@keithp.com wrote: On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski l...@mit.edu wrote: My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs instantly when GNOME loads and it hangs so hard the reset button doesn't work. Setting i915.semaphore=0 fixes it. Can you describe precisely what hardware you have? The make and model of the motherboard and the exact model of CPU? I'd like to get this issue resolved for 2.6.40 and need to have a reliable way to reproduce the hang; replicating your hardware may be a good way of doing that. I'm getting hangs on my X220 Core i7 laptop as well with 2.6.39 and i915.semaphores=1. They're not as reliable -- sometimes the system hangs on log in, sometimes after a few seconds, and sometimes it doesn't hang. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [2.6.39 regression] hard lock when GNOME starts
On Fri, May 13, 2011 at 1:38 AM, Andrew Lutomirski l...@mit.edu wrote: Hi- Something in the range ^8aa7500 40c7f2112ce18fa5eb ^b04d0a90908c causes by Q67 Sandy Bridge box to lock hard about one second after I start GNOME. It locks so hard that the reset button doesn't work and netconsole doesn't say anything. I'm about to have trouble finishing the bisection because I've had trouble running revisions that are older than 2.6.38 and the next bit of bisection has merge conflicts if I merge in 2.6.38. I can power through it, but maybe one of you will recognize the bug from the fact that there aren't that many revisions in there and there can't be many ways to make the reset button stop working. It's semaphores. I have: 00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) which is on a Q67/i7-2600 box. The git history for semaphores is worthless. AFAICT they were disabled around 2.6.38-rc7 by a merge that pulled in a1656b9090f7008d2941c314f5a64724bea2ae37. They were then re-enabled by this commit: commit 47ae63e0c2e5fdb582d471dc906eb29be94c732f Merge: c59a333 467cffb Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Mar 7 12:32:44 2011 + Merge branch 'drm-intel-fixes' into drm-intel-next Apply the trivial conflicting regression fixes, but keep GPU semaphores enabled. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_execbuffer.c This pulled in the disable-semaphores patch. So the merge with trivial regression fixes undid the patch that disabled semaphores. This is really annoying for two reasons. One is that the commit message sucks. Two is much worse: the semaphore disabling patch made it into 2.6.38 but this merge went in for 2.6.39. That means that the patch that made my system unusable on 2.6.39 versions *does not exist in the set v2.6.38..v2.6.39-rc7* except as a trivial merge. Which means that the two fscking days I spent bisecting this were completely wasted because there was no way that the bisection could have found the bug. In the future, if you change something, that might cause severe breakage, please make it an actual commit. --Andy --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DisplayPort support
Intel DH67GD connected to Dell U2711 over DP works fine on recent kernels. (U2711 is even higher bandwidth than anything Apple makes.) --Andy On Tue, Apr 26, 2011 at 9:42 PM, Paul McGarry p...@paulmcgarry.com wrote: Hi all, Can someone tell me whether the info on: http://www.x.org/wiki/DisplayPort There is a branch of the intel driver that attempts DP setup. It's not clear whether this branch supports DP-DVI connections, but it certainly doesn't support DP-DP connections yet. is up to date or is DisplayPort now part of the mainline driver? I have bought an Intel DH67GD and 2600k as an upgrade for my linux computer hopeing to be able to connect it to my 27 inch iMac as a monitor (it's mini-displayport works as both input and output http://support.apple.com/kb/ht3924). On boot the BIOS and grub screens appear on the iMac as expected but when X starts it doesn't seem to detect the DisplayPort connection. http://paulmcgarry.com/stuff/xorglog.txt http://paulmcgarry.com/stuff/xorgconf.txt I am happy to chase further as long as I'm not going up a dead end as the X wiki page suggests. Paul ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] rfc: breaking old userspace gamma for 10-bit support
On Wed, Apr 20, 2011 at 3:38 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Andrew, do you have anything hacked together for this yet? Nope. I gave up because I couldn't even get the mode to set. :) Ok well you should be able to now. :) Using the patchset I posted earlier along with the two attached patches, the testdisplay program in intel-gpu-tools will set a 30bpp mode and draw some nice gradients (though without a 10bpc gamma ramp loaded). Will test at home (that's where by 10bpc display is). One issue was that the RandR apis aren't really designed for cards that can accept more than one gamma ramp size. Someone (I forget who) suggested adding a display property to control it. It might be possible to kill two birds with one stone by adding a property with two settings: - Low depth: the logic you implemented: the bit depth is set to match the framebuffer when possible and the gamma ramp size is set according to the framebuffer depth. - High depth: the bit depth is set to the maximum that the encoder, connector, and monitor support at the requested resolution and the gamma ramp size is set to whatever gives the highest precision in each entry. Well, I haven't implemented anything, gamma-wise. If you select say 30bpp when you start X *and* you have a kernel with my patches applied, you'll get 10bpc all the way out to the display if it supports it. If the display does *not* support 10bpc, the pipe will dither it to 8bpc before sending it to the encoder. Current DDX on an old kernel will fail to create an FB with 10bpc because the kernel will reject it. So I guess I don't understand your low vs high distinction; the bit depth is ultimately tied to the framebuffer and its allocation. Correction happens after the fact in hw when the plane feeds bits to the pipe. I want to have a 24-bit display plane with a 10-bit precision (or 12-bit interpolated) gamma ramp driving a 10bpc pipe and 10bpc over DisplayPort. That way I can ask Argyll for a 10bpc gamma ramp and I get a gamma-corrected display without any banding but also without having to wait for all the userspace stuff (mesa, compiz, etc.) to be able to draw to a 30-bit framebuffer. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] On SNB: Hangcheck timer elapsed... GPU hung
On Wed, Feb 16, 2011 at 8:20 AM, Andrew Lutomirski l...@mit.edu wrote: On Wed, Feb 16, 2011 at 8:13 AM, Ivan Bulatovic combus...@gmx.com wrote: On Tue, 2011-02-15 at 11:46 +1000, Ted Phelps wrote: Hi Andy, Andi Kleen writes: Ted Phelps phe...@gnusto.com writes: Apologies if this is a known issue, but I haven't been able to convince myself that someone is looking after it. I've been seeing this issue with Linux kernel 2.6.37, 2.6.38-rc4 and the most recent merge of Linus's git tree and drm-intel-fixes. I'm happy to provide more information, apply patches, run tools, read code, as requested. Do you use displayport dual-head? I had this problem with dual head. No such issue with only a single monitor. I'm using only one head attached to the DVI connector. I'm curious what userspace you're all running. I'm using xf86-video-intel from git on Feb 4 with 2.6.37 (completely unpatched!) and my i7-2600 is quite stable. The only problem I have is that compiz has hung twice since I got the machine. In both cases, killall -9 compiz rescued the system. Fedora 14's xf86-video-intel didn't work so well (compiz dropped enough frames that the effects weren't really visible). I'm single head on DisplayPort. (Even firefox 4 webgl works nicely.) I spoke too soon. I ran 2.6.38-rc5 (actually 6f576d5 from Linus' tree) for a few hours, and X hung. I could still move the cursor, but the cursor icon didn't change and everything was frozen. I could still switch VTs, though. Xorg.0.log said: [ 26219.458] (EE) intel(0): failed to set cursor: Input/output error [ 26219.488] (EE) intel(0): failed to set cursor: Input/output error [ 26219.518] (EE) intel(0): failed to set cursor: Input/output error [ 26219.523] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Input/output error [ 26219.529] (EE) intel(0): failed to set cursor: Input/output error [ 26219.587] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Input/output error [ 26219.633] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Input/output error [ 26219.633] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Input/output error and the kernel said: [25918.930325] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [25918.931803] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 2652998 at 2652995, next 2653000) [25919.218729] compiz[1949]: segfault at 0 ip 7fd5957f5ea6 sp 7fff9d0394d0 error 6 in i965_dri.so[7fd59577+372000] abrt[2932]: saved core dump of pid 1949 (/usr/bin/compiz) to /var/spool/abrt/ccpp-1298262996-1949.new/coredump (77180928 bytes) lspci says: 00:02.0 VGA compatible controller [0300]: Intel Corporation Sandy Bridge Integrated Graphics Controller [8086:0102] (rev 09) so I don't think the other patch in this thread will do anything. 2.6.37 has been stable and the userspace is identical. gdb on the core file gives garbage (the faulting address looks legit but does not correspond to any module). Curiously, info shared doesn't show libdrm or any of the intel_drv stuff. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] On SNB: Hangcheck timer elapsed... GPU hung
On Wed, Feb 16, 2011 at 8:13 AM, Ivan Bulatovic combus...@gmx.com wrote: On Tue, 2011-02-15 at 11:46 +1000, Ted Phelps wrote: Hi Andy, Andi Kleen writes: Ted Phelps phe...@gnusto.com writes: Apologies if this is a known issue, but I haven't been able to convince myself that someone is looking after it. I've been seeing this issue with Linux kernel 2.6.37, 2.6.38-rc4 and the most recent merge of Linus's git tree and drm-intel-fixes. I'm happy to provide more information, apply patches, run tools, read code, as requested. Do you use displayport dual-head? I had this problem with dual head. No such issue with only a single monitor. I'm using only one head attached to the DVI connector. I'm curious what userspace you're all running. I'm using xf86-video-intel from git on Feb 4 with 2.6.37 (completely unpatched!) and my i7-2600 is quite stable. The only problem I have is that compiz has hung twice since I got the machine. In both cases, killall -9 compiz rescued the system. Fedora 14's xf86-video-intel didn't work so well (compiz dropped enough frames that the effects weren't really visible). I'm single head on DisplayPort. (Even firefox 4 webgl works nicely.) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard kei...@keithp.com wrote: On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote: Enabling and disabling the vblank interrupt (on devices that support it) is cheap. So disable it quickly after each interrupt. So, the concern (and reason for the original design) was that you might lose count of vblank interrupts as vblanks are counted differently while off than while on. If vblank interrupts get enabled near the interrupt time, is it possible that you'll end up off by one somehow? So the race is: 1. Vblank happens. 2. vblank_get runs, reads hardware counter, and enables the interrupt (and maybe not quite in that order) 3. Interrupt fires and increments the counter. Now the counter is one too high. What if we read the hardware counter from the IRQ the first time that it fires after being enabled? That way, if the hardware and software counters match (mod 2^23 or whatever the magic number is), we don't increment the counter. Leaving them enabled for 'a while' was supposed to reduce the impact of this potential error. Fair enough, But five seconds is a *long* time, and anything short enough that the interrupt actually gets turned off in normal use risks the same race. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 8 Dec 2010 13:33:20 -0500 Andrew Lutomirski l...@mit.edu wrote: On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski l...@mit.edu wrote: On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski l...@mit.edu wrote: Hi all- Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + 2.6.36.1, i915 started generating exactly 50 interrupts per second (suspiciously equal to my refresh rate) when X is running. I have the Xorg driver 2.12.0 (specifically xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text console but leave X running, the interrupts stop. Any ideas what to look at? Quitting compiz fixes it. Suspending compiz also fixes it. So it is the vblank interrupt. The vblank interrupt is get alive for a few seconds after the last use. If it keeps going, then either the system is as idle as you believe or we lost track of the last user and forget to switch off the interrupt. drm.debug=0xf (echo 0xf /sys/module/drm/parameters/debug) will have the gory details of who/when triggers the vblank interrupt. -Chris It's the seconds on the clock. That causes activity once per second, which looks like this: [...] Maybe that several seconds (5, according to the source) timer is way too long. Is there any reason that drm_vblank_put doesn't turn off interrupts immediately (or, at the latest, on the very next vblank interrupt)? After all, preventing deep sleep whenever there is display activity every five seconds seems like a waste of power. This patch fixes it. It's obviously not ready for prime time, but if you're OK with the idea I can fix it up and submit it. Signed-off-by: Andy Lutomirski l...@mit.edu Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 9d3a503..49eca3f 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc) /* Last user schedules interrupt disable */ if (atomic_dec_and_test(dev-vblank_refcount[crtc])) - mod_timer(dev-vblank_disable_timer, jiffies + 5*DRM_HZ); + mod_timer(dev-vblank_disable_timer, jiffies); } EXPORT_SYMBOL(drm_vblank_put); This will just move the problem around a bit; 5s is arguably too long to wait before disabling interrupts, but having a second hand or blinking : in your clock is the real issue here. Why don't you disable that instead? I did. But I might also scroll a webpage every second or so (or have a webpage loaded at some point that updates itself every second) and I see no reason to prevent the system from going into its maximum sleep state in between updates. IOW, I think we should optimize for mostly-idle machines in addition to completely-idle machines. --Andy -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
On Thu, Dec 9, 2010 at 1:23 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 9 Dec 2010 12:47:52 -0500 Andrew Lutomirski l...@mit.edu wrote: On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 8 Dec 2010 13:33:20 -0500 Andrew Lutomirski l...@mit.edu wrote: On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski l...@mit.edu wrote: On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski l...@mit.edu wrote: Hi all- Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + 2.6.36.1, i915 started generating exactly 50 interrupts per second (suspiciously equal to my refresh rate) when X is running. I have the Xorg driver 2.12.0 (specifically xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text console but leave X running, the interrupts stop. Any ideas what to look at? Quitting compiz fixes it. Suspending compiz also fixes it. So it is the vblank interrupt. The vblank interrupt is get alive for a few seconds after the last use. If it keeps going, then either the system is as idle as you believe or we lost track of the last user and forget to switch off the interrupt. drm.debug=0xf (echo 0xf /sys/module/drm/parameters/debug) will have the gory details of who/when triggers the vblank interrupt. -Chris It's the seconds on the clock. That causes activity once per second, which looks like this: [...] Maybe that several seconds (5, according to the source) timer is way too long. Is there any reason that drm_vblank_put doesn't turn off interrupts immediately (or, at the latest, on the very next vblank interrupt)? After all, preventing deep sleep whenever there is display activity every five seconds seems like a waste of power. This patch fixes it. It's obviously not ready for prime time, but if you're OK with the idea I can fix it up and submit it. Signed-off-by: Andy Lutomirski l...@mit.edu Diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 9d3a503..49eca3f 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -471,7 +471,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc) /* Last user schedules interrupt disable */ if (atomic_dec_and_test(dev-vblank_refcount[crtc])) - mod_timer(dev-vblank_disable_timer, jiffies + 5*DRM_HZ); + mod_timer(dev-vblank_disable_timer, jiffies); } EXPORT_SYMBOL(drm_vblank_put); This will just move the problem around a bit; 5s is arguably too long to wait before disabling interrupts, but having a second hand or blinking : in your clock is the real issue here. Why don't you disable that instead? I did. But I might also scroll a webpage every second or so (or have a webpage loaded at some point that updates itself every second) and I see no reason to prevent the system from going into its maximum sleep state in between updates. IOW, I think we should optimize for mostly-idle machines in addition to completely-idle machines. It's probably safe to reduce the timeout quite a bit (maybe to 500ms or so); the idea behind 5s was just to avoid whacking the interrupt hardware too frequently and to avoid situations where we continually enable/disable interrupts over a short period of time due to an app that's only periodically using vblank interrupts. So it would probably be best to make the 5*DRM_HZ into its own define, DRM_VBLANK_IDLE_TIMEOUT or similar, and reduce it by a lot, maybe to as low as a few frames; it could even be dynamic based on the refresh rate. How about triggering it off the vblank interrupt instead of a timer? So when a vblank happens and no one has asked for a vblank interrupt since the previous one (or two or whatever), turn it off. --Andy -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
On Wed, Dec 8, 2010 at 1:14 PM, Vasily Khoruzhick anars...@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 anars...@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 anars...@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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [regression?] i915 generating wakeups even when idle
Hi all- Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + 2.6.36.1, i915 started generating exactly 50 interrupts per second (suspiciously equal to my refresh rate) when X is running. I have the Xorg driver 2.12.0 (specifically xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text console but leave X running, the interrupts stop. Any ideas what to look at? --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [regression?] i915 generating wakeups even when idle
On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski l...@mit.edu wrote: Hi all- Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + 2.6.36.1, i915 started generating exactly 50 interrupts per second (suspiciously equal to my refresh rate) when X is running. I have the Xorg driver 2.12.0 (specifically xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text console but leave X running, the interrupts stop. Any ideas what to look at? Quitting compiz fixes it. Suspending compiz also fixes it. If I turn on sync to vblank in compiz, I get wakeups. If I turn it off, I don't get wakeups. I'm having trouble reproducing this on nouveau, but I don't know if that means anything. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [regression?] i915 generating wakeups even when idle
On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski l...@mit.edu wrote: On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski l...@mit.edu wrote: Hi all- Somewhere between Fedora 13 (with 2.6.35, I think) and Fedora 14 + 2.6.36.1, i915 started generating exactly 50 interrupts per second (suspiciously equal to my refresh rate) when X is running. I have the Xorg driver 2.12.0 (specifically xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64). When I switch to a text console but leave X running, the interrupts stop. Any ideas what to look at? Quitting compiz fixes it. Suspending compiz also fixes it. So it is the vblank interrupt. The vblank interrupt is get alive for a few seconds after the last use. If it keeps going, then either the system is as idle as you believe or we lost track of the last user and forget to switch off the interrupt. drm.debug=0xf (echo 0xf /sys/module/drm/parameters/debug) will have the gory details of who/when triggers the vblank interrupt. Will do tomorrow. I'm currently hampered by: 47: 9073 9455 PCI-MSI-edge A0Bs3^A88 in /proc/interrupts after a reboot (I *think*, but I'm not entirely sure, that that's supposed to be i915). --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.
Out of curiousity, what happened to ACPI_BM_BREAK_EN here: https://bugs.freedesktop.org/show_bug.cgi?id=30364 On my box, that register is (according to setpci) 0x00, but I'm testing on an ICH9M and I don't seem to be affected anyway. --Andy On Mon, Nov 1, 2010 at 4:23 PM, Eric Anholt e...@anholt.net wrote: This is a series I came up with as a result of KS discussions. The plan was to pin the CPU C state to keep the GPU going as fast as possible while it was active, since there's some relation between the two (we don't know for sure yet, per chipset, whether it's due to latency of DMA writes having to bring CPU state up, or reduced memory bandwidth due to bus frequency reduction, or other). The actual patch series doesn't achieve that -- a hint is provided to the scheduler and cpufreq/cpuidle, which may choose not to sleep as deeply as it would otherwise. I found a 1% performance difference in nexuiz on my Ironlake system from the last patch in this series (HEAD~1 didn't have a statistically significant effect). If that's all the difference, I'll drop this. It may pay off higher for non-Ironlake, in which case I'll work on a proper solution of actually clamping C-states while graphics is active. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Zaphod mode support?
On Wed, Oct 6, 2010 at 10:03 AM, Rasto Sramek rsra...@inf.ethz.ch wrote:
Hello *,
sorry in case this has been raised many times. Zaphod mode support (In
my understanding one card, one xserver, multiple screens) seems to not
work in intel drivers anymore. Is that so?
AFAICT Zaphod mode is one device but multiple X servers (presumably
used independently by different people). I think very few drivers
support it these days.
If yes, are there any plans to re-introduce it? (Or does anyone know of
a way to get this functionality from xrandr?) Up to now I used ati and
nvidia cards and I lack this functionality in intel drivers.
What annoys me most is the inability to change workspaces independently
on the two screens. I can't believe I'm the only one.
The modern approach is one screen divided among multiple monitors
using RandR. I'm not sure what fglrx and nvidia do.
In any case, switching workspaces the way you want would be a feature
of the window manager or compositing manager, not the driver. If you
use compiz + GNOME, try installing ccsm. Then look in Desktop Wall /
Viewport Switching and change the Multimonitor behavior setting.
(If you're on Fedora and you enable compiz through desktop-effects,
you'll need to modify /usr/bin/compiz-gtk like this:
function runCompiz() {
gtk-window-decorator
if ( [ -e /usr/lib/compizconfig/backends/libgconf.so ] || [ -e
/usr/lib64/compizconfig/backends/libgconf.so ] )
then
exec compiz --ignore-desktop-hints ccp $@
else
#exec compiz --ignore-desktop-hints glib gconf gnomecompat $@
exec compiz --ignore-desktop-hints ccp gnomecompat $@
fi
}
due to a long-standing bug).
If you use metacity or kwin, you'll have to figure it out yourself :)
--Andy
Thanks and best regards,
Rasto Sramek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkysgZUACgkQ0dFX9xR9iCUgvACg2XWWb5PZGMNBxGb2EA3v3Ev5
jzgAn2bObY9N0/M7gqdNpFPvyCcaWm68
=IChr
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Zaphod mode support?
On Wed, Oct 6, 2010 at 10:50 AM, Rasto Sramek rsra...@inf.ethz.ch wrote: AFAICT Zaphod mode is one device but multiple X servers (presumably used independently by different people). I think very few drivers support it these days. Well, whatever it is called, I am referring to the configuration when I have a single X server but multiple screens, like screen0 and screen1. The modern approach is one screen divided among multiple monitors using RandR. I'm not sure what fglrx and nvidia do. Anything can of course use RandR, however at least nvidia drivers support multiple screens. Afaik intel used to support it as well. With nvidia one simply declares 2 monitors, and 2 screens. In any case, switching workspaces the way you want would be a feature of the window manager or compositing manager, not the driver. If you use compiz + GNOME, try installing ccsm. Then look in Desktop Wall / Viewport Switching and change the Multimonitor behavior setting. (If you're on Fedora and you enable compiz through desktop-effects, you'll need to modify /usr/bin/compiz-gtk like this: I use fluxbox which needs screen0 and screen1. I know that awesome is aware of xrandr and can simulate separate screen behavior but I do not know of other WMs that can do so. The reason I prefer having multiple screens is that it is in my view a simple and correct behavior which has worked for years. I think any modern WM should support xrandr. Also, that way you can drag windows from one screen to the other. Or you could Google around for Xinerama -- that might help. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fixing the hotplug storm bugs once and for all?
On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt e...@anholt.net wrote: On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski l...@mit.edu wrote: For well over a year now, I (and apparently lots of other people) have had to run patched kernels to avoid crippling hotplug storms. As far as I can tell, on my laptop, enabling DPC_HOTPLUG_INT_EN is safe, but setting either DPB_... or DPD_... (or both) will cause intermittent hotplug interrupt storms. (Turning off all three DP hotplug bits also makes the laptop stable but prevents the DP port from working.) My laptop is a Lenovo X200s with VGA and LVDS on the laptop itself and DP on the docking port. If I boot w/o the docking port, I have: General definitions block: CRT DDC GMBUS addr: 0x02 Use ACPI DPMS CRT power states: no Skip CRT detect at boot: no Use DPMS on AIM devices: yes Boot display type: 0x TV data block present: yes Child device info: Device type: 1009 (TV) Signature: AIM offset: 0 DVO port: 0x05 Child device info: Device type: 1022 (LFP) Signature: AIM offset: 52048 DVO port: 0x04 Child device info: Device type: 68c6 (DisplayPort) Signature: AIM offset: 61152 DVO port: 0x08 Maybe it's time we started reading that part of VBIOS to detect which outputs really exist. (If that's unsafe, we could add a DMI list.) Any thoughts? It would be nice if 2.6.36 could work without patches. We had patches to not probe outputs unless they were in child dev tables for a while. The issue with reading child dev tables is that some BIOSes would give you different child dev results depending on whether you were docked or not, so you wouldn't get your DP probed unless you booted docked. Do you have a link? I can try to resurrect them. (Can Xorg handle new outputs appearing and disappearing at runtime? If not, we could just pretend to create all possible outputs up front.) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fixing the hotplug storm bugs once and for all?
For well over a year now, I (and apparently lots of other people) have had to run patched kernels to avoid crippling hotplug storms. As far as I can tell, on my laptop, enabling DPC_HOTPLUG_INT_EN is safe, but setting either DPB_... or DPD_... (or both) will cause intermittent hotplug interrupt storms. (Turning off all three DP hotplug bits also makes the laptop stable but prevents the DP port from working.) My laptop is a Lenovo X200s with VGA and LVDS on the laptop itself and DP on the docking port. If I boot w/o the docking port, I have: General definitions block: CRT DDC GMBUS addr: 0x02 Use ACPI DPMS CRT power states: no Skip CRT detect at boot: no Use DPMS on AIM devices: yes Boot display type: 0x TV data block present: yes Child device info: Device type: 1009 (TV) Signature: AIM offset: 0 DVO port: 0x05 Child device info: Device type: 1022 (LFP) Signature: AIM offset: 52048 DVO port: 0x04 Child device info: Device type: 68c6 (DisplayPort) Signature: AIM offset: 61152 DVO port: 0x08 Maybe it's time we started reading that part of VBIOS to detect which outputs really exist. (If that's unsafe, we could add a DMI list.) Any thoughts? It would be nice if 2.6.36 could work without patches. Thanks, Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 (GM45) instability (and an oops)
I've been running 2.6.35 rc's and xf86-drv-intel git master for awhile, and X has been a bit unstable. Every now and then, graphics freeze completely, except that the mouse still works (I think) and capslock toggles the LED. If I switch to a different VT and killall -9 Xorg, everything recovers. If I switch to a different VT and switch directly back to X, X hangs completely -- mouse can't move and capslock doesn't work. Alt-SysRq-R doesn't work either (not sure why). It just happened again and I tried something a bit different. I switched to a console, did 'echo 1 i915_wedged', and got an oops: [20815.509691] [drm] Manually setting wedged to 1 [20815.509701] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1072 [20815.509708] in_atomic(): 0, irqs_disabled(): 1, pid: 4543, name: bash [20815.509716] Pid: 4543, comm: bash Not tainted 2.6.35-rc6+ #40 [20815.509722] Call Trace: [20815.509738] [81036eed] __might_sleep+0xe8/0xed [20815.509749] [81446e2d] do_page_fault+0x1aa/0x2ac [20815.509759] [814441ef] page_fault+0x1f/0x30 [20815.509770] [8102c1af] ? __wake_up_common+0x25/0x84 [20815.509778] [8102fc53] __wake_up+0x39/0x4d [20815.509823] [a0079608] i915_wedged_write+0xd4/0x10d [i915] [20815.509834] [811b6e0f] ? security_file_permission+0x16/0x18 [20815.509845] [810f4f3d] vfs_write+0xae/0x10b [20815.509852] [810f505a] sys_write+0x4a/0x6e [20815.509863] [81002b2b] system_call_fastpath+0x16/0x1b [20815.509880] Oops: [#1] SMP [20815.509947] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_now [20815.510097] CPU 1 [20815.510128] Modules linked in: fuse tun tp_smapi thinkpad_ec cpufreq_ondemand xt_multiport ipt_MASQUERADE iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput arc4 snd_hda_codec_conexant ecb snd_hda_intel iwlagn snd_hda_codec snd_hwdep iwlcore snd_seq snd_seq_device snd_pcm mac80211 thinkpad_acpi snd_timer tpm_tis hwmon cfg80211 tpm iTCO_wdt i2c_i801 tpm_bios snd iTCO_vendor_support snd_page_alloc microcode soundcore aes_x86_64 aes_generic xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [20815.510257] [20815.510257] Pid: 4543, comm: bash Not tainted 2.6.35-rc6+ #40 7465CTO/7465CTO [20815.510257] RIP: 0010:[8102c1af] [8102c1af] __wake_up_common+0x25/0x84 [20815.510257] RSP: 0018:8800378f1e28 EFLAGS: 00010082 [20815.510257] RAX: ffe8 RBX: 880135770350 RCX: [20815.510257] RDX: 0001 RSI: 0003 RDI: 880135770358 [20815.510257] RBP: 8800378f1e68 R08: R09: 000a [20815.510257] R10: 0005 R11: R12: 0003 [20815.510257] R13: 0001 R14: 7fd2044d5000 R15: 0001 [20815.510257] FS: 7fd2044a5700() GS:880001f0() knlGS: [20815.510257] CS: 0010 DS: ES: CR0: 80050033 [20815.510257] CR2: CR3: b805c000 CR4: 000406e0 [20815.510257] DR0: DR1: DR2: [20815.510257] DR3: DR6: 0ff0 DR7: 0400 [20815.510257] Process bash (pid: 4543, threadinfo 8800378f, task 880137705bc0) [20815.510257] Stack: [20815.510257] 88013577 0001 7fd2044d5000 880135770350 [20815.510257] 0 0286 0001 7fd2044d5000 0001 [20815.510257] 0 8800378f1ea8 8102fc53 8800378f1e98 [20815.510257] Call Trace: [20815.510257] [8102fc53] __wake_up+0x39/0x4d [20815.510257] [a0079608] i915_wedged_write+0xd4/0x10d [i915] [20815.510257] [811b6e0f] ? security_file_permission+0x16/0x18 [20815.510257] [810f4f3d] vfs_write+0xae/0x10b [20815.510257] [810f505a] sys_write+0x4a/0x6e [20815.510257] [81002b2b] system_call_fastpath+0x16/0x1b [20815.510257] Code: 48 01 78 28 c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 48 8b 47 08 41 89 f4 48 83 e8 18 48 83 c7 08 4c 8b 68 18 89 d3 41 89 cf 49 83 ed 18 48 89 7d c8 eb 33 44 8b [20815.510257] RIP [8102c1af] __wake_up_common+0x25/0x84 [20815.510257] RSP 8800378f1e28 [20815.510257] CR2: I then switched back to Xorg and it was completely frozen. SysRq+R did nothing, but SysRq+K got me a VT back. Xorg was unkillable (sorry, should have gotten a stack trace, but I didn't). cat i915_wedged showed that wedged = 1. I tried echo 1 i915_wedged again and the system froze hard -- even SysRq+B did nothing. This is my trusty bug-exposing GM45 laptop :) The backtrace is on 2.6.35-rc6+. --Andy ___ Intel-gfx mailing list
Re: [Intel-gfx] Fwd: State of 10 bits/channel?
On Fri, Jul 23, 2010 at 8:26 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Thu, 22 Jul 2010 17:34:09 -0400, Andrew Lutomirski l...@mit.edu wrote: [resend b/c I used the wrong from address last time] I have a 10 bit/channel monitor (DisplayPort) which works quite nicely in 8 bit mode. I saw some patches from Peter Clifton related to 10 bit support go in awhile ago. [snip] What is the hardware capable of, and what is the state of affairs right now? AIUI, all the intel chips are capable of driving 30-bit displays. The later generations are more flexible and faster with greater bit depth for LUTs etc. The output driver support should (in theory) be complete, but it hasn't been well tested due to scarcity of suitable displays. OK. I'll try to figure out how to program the output driver. Do we want to drive outputs at 30 bits even when the primary surface is 24 bits? (Benefit: 10-bit LUTs. Disadvantage: Could break existing setups.) Expect lots of questions from me when I run into things that are unclear or wrong in the docs. I'm running 2.6.35-rc4+ with a hacked up xf86-video-intel with this patch: Please submit this as a format-patch to the list for inclusion. You only say that because there's one line too few of context to see how dumb the patch is. I'll fix and submit. With that patch and DefaultDepth 30, I get a mostly working system, but there's no direct rendering (seems to be disabled because DRI is disabled because it runs only at depths 16 and 24) title bars on gnome-terminal draw incorrectly. Hmm, the render paths should work on 10bpc surfaces. Please do file bugs for the failures. Will do. I'll also see how close to working I can get DRI in 30-bit mode. (Enabling it right now exposes a silly bug in the compiz startup scripts which results in having no window manager at all on F13. I'll figure out whose bug it is and file that one as well.) -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] rfc: breaking old userspace gamma for 10-bit support
AFAICT intel hardware wants a 129-entry LUT when using high precision gamma ramps. Rather than hacking some kind of decimation into the kernel driver (and thus silently breaking DirectColor), I'd like to teach userspace how to deal with variable gamma sizes. gnome-color-manager already more-or-less supports arbitrary gamma ramp sizes (supposedly), dispwin ought to do it, and there might not be any other software that really cares. gnome-screensaver saves and restores the gamma ramp, and I haven't checked if it works right for funny sizes. The worst problem we'll have is that current xf86-drv-intel can't handle non-256 gamma sizes at all. So if we change the kernel we'll break it completely. One option is to have the kernel report gamma_size = 129 but still accept 256 and decimate itself. That might cause current userspace to keep working (except for DirectColor). Any thoughts? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fwd: State of 10 bits/channel?
[resend b/c I used the wrong from address last time] I have a 10 bit/channel monitor (DisplayPort) which works quite nicely in 8 bit mode. I saw some patches from Peter Clifton related to 10 bit support go in awhile ago. There are (at least) three modes that would be nice: (1) 8bpp framebuffer, 8 bit outputs, but 10-bit LUT with dithering. (2) 8bpp framebuffer, 10 bit outputs and LUT. (3) 10 bpp framebuffer, outputs, and LUT. (1) would be nice with any hardware -- color calibration would look better. (2) would be a good start for 10 bit displays -- I could calibrate without banding and userspace would be none the wiser (except for a different-looking gamma ramp). (3) would be really cool and would differentiate us nicely from Windows, which AFAICT doesn't really support 10 bit outputs on most (all?) hardware. What is the hardware capable of, and what is the state of affairs right now? I'm running 2.6.35-rc4+ with a hacked up xf86-video-intel with this patch: diff --git a/src/intel_driver.c b/src/intel_driver.c index 7761ccf..d0d1a37 100644 --- a/src/intel_driver.c +++ b/src/intel_driver.c @@ -570,6 +570,7 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags) case 15: case 16: case 24: + case 30: break; default: xf86DrvMsg(scrn-scrnIndex, X_ERROR, (Otherwise, DefaultDepth 30 won't start at all.) With that patch and DefaultDepth 30, I get a mostly working system, but there's no direct rendering (seems to be disabled because DRI is disabled because it runs only at depths 16 and 24) title bars on gnome-terminal draw incorrectly. Do any of you know how to ask the system what depth the output is configured at and what depth the framebuffer is configured at? Currently, XRRGetCrtcGammaSize return 256, which IIRC should be 129 if 10 bit gamma ramps are being used. (That's on both CRTCs, one of which is DP connected to the 10 bit device.) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Fix CRT hotplug regression in 2.6.35-rc1
On Mon, Jun 28, 2010 at 7:48 PM, Dave Airlie airl...@gmail.com wrote: On Sat, Jun 12, 2010 at 7:21 PM, Andy Lutomirski l...@mit.edu wrote: Commit 7a772c492fcfffae812ffca78a628e76fa57fe58 has two bugs which made the hotplug problems on my laptop worse instead of better. First, it did not, in fact, disable the CRT plug interrupt -- it disabled all the other hotplug interrupts. It seems rather doubtful that that bit of the patch fixed anything, so let's just remove it. (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.) Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64 and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset) causes a hotplug interrupt about three seconds later. The old code never restored PORT_HOTPLUG_EN so this could only happen once, but they new code restores those registers. So just set those bits when we set up the interrupt in the first place. ping? Intel guys? ajax? anyone? We are clearly broken on GM45 at the moment. I dunno. This is all I've heard: http://www.mail-archive.com/dri-de...@lists.freedesktop.org/msg01433.html It's kind of an ACK :) Rafael has this in his tracker now, I think. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901
On Sun, Jun 20, 2010 at 11:29 AM, Andrew Lutomirski l...@mit.edu wrote: On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 17 Jun 2010 19:44:10 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 18 Jun 2010 02:20:23 +0200 Marc Deop i Argemí damnsh...@gmail.com wrote: On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote: Neither patch applies for me. One of them do apply for me, the other one doesn't. Testing done on latest 2.6.35-rc3, the building fails. Arg, ok, I'll refresh them and post new ones tomorrow. Ok here are some updated ones. Running these patches on 2.6.35-rc3 (plus the brown-paper-bag TCP fix, plus my hotplug_mask hack, plus my CRT regression fix) with xf86-video-intel be55066c6481b4c5e2cd39ef1c0f3be88cae0c93 (which is about a day old) seems stable and I don't have any visible corruption. Just froze again. I moved my mouse and the screen turned black except for the mouse cursor and a little underscore in the top left that looked like the fbcon cursor. Again, magic sysrq didn't work, which I'd imagine would help narrow things down (presumably, no matter how hard the graphics hardware gets wedged, magic sysrq should still work). --Andy That being said, if I rotate the screen, then typing becomes very annoyingly laggy. I have no idea whether that's a regression or not. --Andy -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901
On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 17 Jun 2010 19:44:10 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 18 Jun 2010 02:20:23 +0200 Marc Deop i Argemí damnsh...@gmail.com wrote: On Friday June 18 2010 02:17:53 Andrew Lutomirski wrote: Neither patch applies for me. One of them do apply for me, the other one doesn't. Testing done on latest 2.6.35-rc3, the building fails. Arg, ok, I'll refresh them and post new ones tomorrow. Ok here are some updated ones. Running these patches on 2.6.35-rc3 (plus the brown-paper-bag TCP fix, plus my hotplug_mask hack, plus my CRT regression fix) with xf86-video-intel be55066c6481b4c5e2cd39ef1c0f3be88cae0c93 (which is about a day old) seems stable and I don't have any visible corruption. That being said, if I rotate the screen, then typing becomes very annoyingly laggy. I have no idea whether that's a regression or not. --Andy -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
On Tue, May 25, 2010 at 10:46 AM, Adam Jackson a...@redhat.com wrote: On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote: On Mon, May 24, 2010 at 4:46 PM, Adam Jackson a...@redhat.com wrote: Disable the CRT plug interrupt while doing the force cycle, explicitly clear any CRT interrupt we may have generated, and restore when done. Should mitigate interrupt storms from hotplug detection. Is there any locking in here to protect PORT_HOTPLUG_EN? I'm asking because I *still* can't use mainline kernels reliably without commenting out digital output initialization, and that's one place where a bug might be lurking. At least in d-i-n, PORT_HOTPLUG_EN is only ever written to from -detect in the connector vtable, and from IRQ setup. I don't have a firm understanding of the locking around either path, but I'd be rather surprised if it was racy in any practical sense, since neither of those should get called from interrupt context and you typically only have one app doing setup. -detect seems to be called from status_show in drm_sysfs.c, which makes its way into intel_crt_detect_hotplug, which plays with PORT_HOTPLUG_EN without any locking. If another detect function (or the same one, even) is called at the same time, PORT_HOTPLUG_EN can be left in a bad state. There should probably be a mutex protecting PORT_HOTPLUG_EN. --Andy - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
On Mon, May 24, 2010 at 4:46 PM, Adam Jackson a...@redhat.com wrote: Disable the CRT plug interrupt while doing the force cycle, explicitly clear any CRT interrupt we may have generated, and restore when done. Should mitigate interrupt storms from hotplug detection. Is there any locking in here to protect PORT_HOTPLUG_EN? I'm asking because I *still* can't use mainline kernels reliably without commenting out digital output initialization, and that's one place where a bug might be lurking. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Picture quality on laptop LCD with i915GM chipset.
On Fri, May 14, 2010 at 7:17 PM, SD sd.dom...@yahoo.com wrote: Dear All. My question may look strange but I have some serious problem that prevent me of using any linuxes on kernel higher then 2.6.27. Explanation: I have laptop i686 Celeron i915GM video. On it there is two OS - OpenSuse 11.1 (kernel 2.6.27) and now Fedora 13 (2.6.33 - 85). I have tested Fedora 12, nut upgrade it to 13. Have you tried OpenSuse 11.1 with a newer kernel? If the problem is just the fonts, you might be seeing a result of different fonts, subpixel rendering settings, or freetype version. If the problem is really due to the graphics driver, you should be able to take a screenshot in one OS and look at it in the other and see a difference. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
