[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] [drm:in
[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 1:52 PM, Daniel Vetter 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 >> 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 >> > >> > --- >> > >> > 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] drm/i915: enable semaphores on gen6 if dmar is not active
On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter 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 > > --- > > 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] i915 SNB: hotplug events when charging causing poor interactivity
On Tue, Feb 21, 2012 at 12:02 PM, Daniel Vetter wrote: > On Tue, Feb 21, 2012 at 01:37:37PM +, Daniel J Blueman wrote: >> On 16 February 2012 13:07, Daniel Vetter wrote: >> > On Thu, Feb 16, 2012 at 11:44:46AM +, Daniel J Blueman wrote: >> >> When charging Dell E5420 laptops, I see the Sandy Bridge South Display >> >> Engine port C hotplug interrupt fire consistently at around 20Hz. Each >> [] >> >> Notably, when only using battery or only using AC, the port C >> >> interrupts don't fire. It feels like the platform is using South >> >> Display Port C for GPIO/I2C; setting the port C pulse duration from >> >> 2ms to 100ms doesn't change the behaviour. I'll dump off the GPIO >> >> settings, but what else is good to debug this? >> > >> > Yep, dumping the register state (intel_reg_dumper from intel-gpu-tools is >> > handy for that) in the different situations sounds useful. >> [] >> > If this is indeed the bios we need to quirk this away. But I think we >> > should check first whether we don't butcher something else accidently. >> >> When charging the battery, I see the SDE_PORTB_HOTPLUG, PORTC, PORTD >> and SDE_AUX_MASK bits set (sometimes at different times) at ~20Hz >> until the battery is charged, which is disconcerting. >> >> Hotplugging a HDMI cable, SDE_PORTB_HOTPLUG and SDE_AUX_MASK bits are >> set once, so we can't mask these on this platform. >> >> Attached are the reg dumps. We see the backlight register >> (BLC_PWM_CPU_CTL) and the A surface register (DSPASURF) vary across >> multiple reads as expected. >> >> Any ideas? > > Nope, as in absolutely no idea. The only idea I have is that the expects > us to do something with either acpi or opregion that we currently don't, > but that's just handwaving. > > So I think you're left with filing a bug report with all the things you've > gathered and hoping that we stumble over the missing piece of > documentation :( There used to be a bug on GM45 that would cause digital outputs that weren't connected to occasionally generate bogus hotplug interrupts. I wonder if there's a pin that's floating that picks up noise or stray charge depending on what the battery charger is doing. IIRC there's something in vbios that the driver could use to detect and disable unwired ports. Do you actually have a port C? --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 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
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett 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] [RFC] Reduce idle vblank wakeups
2011/11/16 Matthew Garrett : > 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] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Wed, Nov 16, 2011 at 9:16 AM, Keith Packard wrote: > On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter > wrote: > >> So we need to check whether DMAR is enabled (on the >> entire system, i.e. the variable exported for the ilk workaround is >> not good enough) > > Can you figure out what *would* be sufficient? Getting semaphores turned > on for the 99% who aren't enabling VT-d would be a fairly nice > performance improvement. AFAICT my snb laptop has always been stable with semaphores and VT-d enabled. Is this problem possibly restricted to just desktop machines? I'm happy to test, since my box that can reproduce the hang instantly is still around. Also, rc6-by-default would be very nice. It decreases the total power consumption on my laptop from over 13W to around 8W. That's huge. --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 wrote: > On Tue, 4 Oct 2011 18:50:18 -0700 > "Kay, Allen M" 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" 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
> ---
> 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 6:19 PM, Ben Widawsky wrote: > > > On Sep 7, 2011, at 5:30 PM, Andrew Lutomirski wrote: > >> On Wed, Sep 7, 2011 at 4:12 PM, Ben Widawsky 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 >>> Cc: Daniel Vetter >>> Cc: Eric Anholt >>> Signed-off-by: Ben Widawsky >>> --- >>> 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 1/2] drm/i915: Dumb down the semaphore logic
On Wed, Sep 7, 2011 at 4:12 PM, Ben Widawsky 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 > Cc: Daniel Vetter > Cc: Eric Anholt > Signed-off-by: Ben Widawsky > --- > 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] 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" wrote: > On Wed, 31 Aug 2011 14:30:00 -0400, Andrew Lutomirski 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: Revert i915.semaphore=1 default from 47ae63e0
On Mon, Aug 22, 2011 at 12:53 PM, Jesse Barnes wrote: > On Fri, 10 Jun 2011 10:06:39 -0400 > Andrew Lutomirski wrote: > >> On Tue, Jun 7, 2011 at 3:12 AM, Eric Anholt 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 >> > 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: add GPU frequency control file
On Wed, Jul 27, 2011 at 1:17 PM, Jesse Barnes 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] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote: > From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001 > From: Keith Packard > Date: Mon, 25 Jul 2011 22:37:51 -0700 > Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from > DP" > > This reverts commit 885a50147f00a8a80108904bf58a18af357717f3. > > We actually *do* need to track DPMS state so that on hotplug, we don't > retrain the link until DPMS is disabled. > > intel_dp->output_reg = output_reg; > + intel_dp->dpms_mode = -1; Should that be some actual mode constant instead of -1? In any case, this patch, applied manually on top of the struct_mutex fix, seems to work. xset dpms force off turns the display off briefly (presumably X or GNOME helpfully turns it back on), but if I let the display turn off on its own, it comes back. There's still an obnoxious bug, though: I use audio over DP, and when the display turns off, the attached speaker crackles loudly for a second or two. I don't think it's a hardware problem with the monitor, because if I just pull the plug it doesn't make any noise. Should the driver do something to drop the audio link before turning off the DP link as a whole? --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard 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
>> ---
>> 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_pol
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
Will test tonight.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean "off," not "on."
See attached trace. perf rocks, even over ssh :)
--Andy
On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard 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
>> ---
>> 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.
>
> Looks like the ->detect function is similarly protected at the call
> site (though one level up in ->fill_modes), so it should be safe.
> Looks like all the call sites in the link_status function are safe too.
>
> Reviewed-by: Jesse Barnes
>
> Let's get this one upstream asap. Should probably be cc'd to
> sta...@kernel.org as well.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
Xorg 1463/1463 [000] 8894.988115: intel_dp_dpms: (a0093026)
a0093027 intel_dp_dpms
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/i915/i915.ko)
a002d6e8 drm_mode_connector_property_set_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
a002085f drm_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
811049a5 do_vfs_ioctl ([kernel.kallsyms])
81104a3c sys_ioctl ([kernel.kallsyms])
814376bb system_call ([kernel.kallsyms])
30260d8957 __GI_ioctl (/lib64/libc-2.14.so)
Xorg 1463/1463 [000] 8895.005199: intel_dp_dpms_return: (a0093026 <-
a006321b)
81433108 kretprobe_trampoline_holder ([kernel.kallsyms])
a002d6e8 drm_mode_connector_property_set_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
a002085f drm_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
811049a5 do_vfs_ioctl ([kernel.kallsyms])
81104a3c sys_ioctl ([kernel.kallsyms])
814376bb system_call ([kernel.kallsyms])
30260d8957 __GI_ioctl (/lib64/libc-2.14.so)
Xorg 1463/1463 [000] 8905.765634: intel_dp_dpms: (a0093026)
a0093027 intel_dp_dpms
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/i915/i915.ko)
a002d6e8 drm_mode_connector_property_set_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
a002085f drm_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
811049a5 do_vfs_ioctl ([kernel.kallsyms])
81104a3c sys_ioctl ([kernel.kallsyms])
814376bb system_call ([kernel.kallsyms])
30260d8957 __GI_ioctl (/lib64/libc-2.14.so)
Xorg 1463/1463 [000] 8905.765650: intel_dp_start_link_train:
(a009225f)
a0092260 intel_dp_start_link_train
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/i915/i915.ko)
81433108 kretprobe_trampoline_holder ([kernel.kallsyms])
a002d6e8 drm_mode_connector_property_set_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
a002085f drm_ioctl
(/lib/modules/3.0.0-rc6-bpp+/kernel/drivers/gpu/drm/drm.ko)
811049a5 do_vfs_ioctl ([kernel.kallsyms])
81104a3c sys_ioctl ([kernel.kallsyms])
814376bb system_call ([kernel.kallsyms])
30260d8957 __GI
Re: [Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
On Mon, Jul 25, 2011 at 12:08 PM, Keith Packard wrote: > On Mon, 25 Jul 2011 11:23:17 -0400, Andrew Lutomirski 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, abort
Re: [Intel-gfx] 3.0 (or SNA?) regression: failed to train DP, aborting
On Mon, Jul 25, 2011 at 12:54 AM, Keith Packard wrote: > On Sat, 23 Jul 2011 14:40:36 -0400, Andrew Lutomirski 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 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 Reviewed-by: Keith Packard Signed-off-by: Keith Packard 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 Sat, Jul 23, 2011 at 2:40 PM, Andrew Lutomirski 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
[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] Root-causing kswapd spinning on Sandy Bridge laptops?
On Fri, Jun 24, 2011 at 12:44 PM, Andi Kleen wrote: > Andrew Lutomirski writes: > > [Putting the Intel graphics driver developers in cc.] My Sandy Bridge laptop is to blame, the graphics aren't the culprit. It's this: BIOS-e820: 0001 - 00010060 (usable) The kernel can't handle the tiny bit of memory above 4G. Mel's patches work so far. --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 wrote: > On Tue, 21 Jun 2011 20:38:51 +0200 (CEST), "Nicolas Kalkhof" > 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] gen6 (SNB) GPU still stalling besides latest patches
On Tue, Jun 21, 2011 at 2:18 PM, Chris Wilson wrote: > On Tue, 21 Jun 2011 19:41:52 +0200 (CEST), "Nicolas Kalkhof" > 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] [PATCH] drm/i915: Revert i915.semaphore=1 default from 47ae63e0
On Tue, Jun 7, 2011 at 3:12 AM, Eric Anholt wrote: > On Thu, 19 May 2011 16:50:00 -0400, Andrew Lutomirski wrote: >> On Thu, May 19, 2011 at 3:56 PM, Keith Packard wrote: >> > On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski 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 > 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 wrote: > On Thu, May 19, 2011 at 3:56 PM, Keith Packard wrote: >> On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski 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
[Intel-gfx] GMBUS: modprobe eeprom hangs forever (2.6.39 regression?)
On two different Sandy Bridge machines, modprobe eeprom does this: [ 35.627075] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.679006] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.730938] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.782889] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.834804] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.886739] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.938654] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 35.990588] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 36.042539] [drm] GMBUS timed out, falling back to bit banging on pin 1 [i915 gmbus ssc] and hangs forever. 100% reproducible, and it might be a 2.6.39 regression. Maybe this is a hint for some of the display-detection issues. --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 3:56 PM, Keith Packard wrote: > On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski 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 config and dmidecode output attached. I'm happy to help test after Sunday. I'm currently out of town and busy trying to make my Sandy Bridge laptop work. (It has a different non-i915-related problem.) --Andy config.txt.xz Description: application/xz dmi.txt.xz Description: application/xz ___ 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 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 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
[Intel-gfx] [2.6.39 regression] hard lock when GNOME starts
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. --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 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 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] rfc: breaking old userspace gamma for 10-bit support
On Wed, Apr 20, 2011 at 3:05 PM, Jesse Barnes wrote: > On Tue, 27 Jul 2010 11:03:56 -0400 > Adam Jackson wrote: > >> On Fri, 2010-07-23 at 16:29 -0400, Andrew Lutomirski wrote: >> >> > Does that include not breaking DirectColor? If we program the gamma >> > ramp to 129 slots, old userspace submits 256 entries that are not >> > monotonic, and we decimate the gamma ramp, we'll display the wrong >> > thing. I have no idea if there are any programs *at all* that do >> > that, though. (If they did, presumably they'd make the entire screen >> > look rather odd.) >> >> If I'm remembering this right, it's like this: >> >> GM45 and earlier can only do 10bpc with 10-bit, 129-stop interpolated >> LUT. There is no way to support DirectColor with this, the hardware >> assumes that each step is monotonically increasing and will do very >> weird things if it's not. So the DDX driver needs to simply not set up >> any DC visuals when run at 10bpc on this hardware. That's fine though: >> DC is a pretty rarely-used feature, and it brings with it all the >> colormap-flashing nightmares you remember from pseudocolor. >> >> Ironlake and later can do 30bpc as either 10-bit 1024-stop, or 12-bit >> 512-stop interpolated. For the 12-bit ramp you'd need to do the same as >> for the GM45 10-bit ramp: DDX driver doesn't set up DC visuals. >> >> Once you've done this, the DRM driver can unambiguously determine what >> gamma ramp size to use based on what DDX passes down. At least in >> current RANDR you only get to pick one ramp size. You could in >> principle wire up an output property to change this, but I suggest that >> you don't bother. >> >> There are some places in the server where we assume 256 stops, and some >> other places where we make the weaker assumption that all CRTCs have the >> same ramp size. >> >> Having done all that you'd need to go out to gnome-color-manager and >> friends and make sure they don't assume they have 2^n stops of gamma for >> an n bpc display. > > [Resurrecting this ancient thread now that 30bpp has been posted] > > I think we'll also want a kernel getparam flag to indicate whether the > kernel can handle the larger ramp sizes, otherwise a new DDX and old > kernel will silently break horribly. > > Current DDX always assumes a 256 entry ramp, and we'd want to preserve > that for old kernels w/o support for other sizes. For new DDX and new > kernel, we should be able to key the palette load based on the size > passed in to the gamma_set callback. For some reason that callback > includes a 'start' value, but fortunately the ioctl makes you load the > whole thing everytime, so the start value is always 0. > > Sounds like dealing with chipset variations will be a bit of a pain > though, so we'll want per-chipset gamma_set functions at least. > > Andrew, do you have anything hacked together for this yet? Nope. I gave up because I couldn't even get the mode to set. :) 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. Presumably, people would prefer the low depth mode if they care about DirectColor (does anyone care about DirectColor?) or if they want to save a little bit of power and people would use high depth if they plan to use the gamma ramp for calibration. --Andy > > Thanks, > -- > Jesse Barnes, Intel Open Source Technology Center > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] On SNB: Hangcheck timer elapsed... GPU hung
On Wed, Feb 16, 2011 at 8:20 AM, Andrew Lutomirski wrote: > On Wed, Feb 16, 2011 at 8:13 AM, Ivan Bulatovic wrote: >> On Tue, 2011-02-15 at 11:46 +1000, Ted Phelps wrote: >>> Hi Andy, >>> >>> Andi Kleen writes: >>> > Ted Phelps 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:33 AM, Ivan Bulatovic wrote: > On Wed, 2011-02-16 at 08:20 -0500, Andrew Lutomirski wrote: >> 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 > > xf86-video-intel 2.14 > OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop GEM > 20100330 DEVELOPMENT > OpenGL version string: 2.1 Mesa 7.10.1-devel > X.Org X Server 1.9.4 > Release Date: 2011-02-04 > Current Operating System: Linux silverstone 2.6.38-rc5-RC #1 SMP PREEMPT > Wed Feb 16 13:32:11 CET 2011 x86_64 > You have a newer mesa than I do. I'll leave debugging this to the experts (and not update my mesa until then). I'm running 7.10-devel. --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 wrote: > On Tue, 2011-02-15 at 11:46 +1000, Ted Phelps wrote: >> Hi Andy, >> >> Andi Kleen writes: >> > Ted Phelps 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:47 PM, Keith Packard wrote: > On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski wrote: > >> 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. > > Right, so eliminating any race seems like the basic requirement. Can > that be done? I'll give it a shot. Do you know if there's an existing tool to call drm_wait_vblank from userspace for testing? I know approximately nothing about libdrm or any userspace graphics stuff whatsoever. --Andy > > -- > 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: Aggressively disable vblanks
On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard wrote: > On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski 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 1:23 PM, Jesse Barnes wrote: > On Thu, 9 Dec 2010 12:47:52 -0500 > Andrew Lutomirski wrote: > >> On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes >> wrote: >> > On Wed, 8 Dec 2010 13:33:20 -0500 >> > Andrew Lutomirski wrote: >> > >> >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski wrote: >> >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson >> >> > wrote: >> >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski >> >> >> wrote: >> >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski >> >> >>> 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 >> >> >> >> 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] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
On Thu, Dec 9, 2010 at 12:20 PM, Jesse Barnes wrote: > On Wed, 8 Dec 2010 13:33:20 -0500 > Andrew Lutomirski wrote: > >> On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski wrote: >> > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson >> > wrote: >> >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski wrote: >> >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski 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 >> >> 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
[Intel-gfx] [TERRIBLE PATCH] Re: [regression?] i915 generating wakeups even when idle
On Wed, Dec 8, 2010 at 1:17 PM, Andrew Lutomirski wrote: > On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson wrote: >> On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski wrote: >>> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski 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 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); > > --Andy > >> >> -- >> Chris Wilson, Intel Open Source Technology Centre >> > ___ 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 wrote: > On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote: >> On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick > wrote: >> > On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: >> >> On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick >> >> >> > >> > 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
Re: [Intel-gfx] [regression?] i915 generating wakeups even when idle
On Tue, Dec 7, 2010 at 5:13 PM, Chris Wilson wrote: > On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski wrote: >> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski 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: [ 708.109447] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109464] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1 [ 708.109524] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.109543] [drm:drm_ioctl], pid=1889, cmd=0x40406469, nr=0x69, dev 0xe200, auth=1 [ 708.109574] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109590] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.109602] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109616] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.109704] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109729] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.109743] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109757] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.109774] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev 0xe200, auth=1 [ 708.109787] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.109800] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109813] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.109828] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev 0xe200, auth=1 [ 708.109843] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109856] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109869] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109882] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109896] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.109909] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.109921] [drm:drm_ioctl], pid=1889, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1 [ 708.109944] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.109963] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.109977] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.109991] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.110067] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.110090] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.110105] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.110120] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.110138] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev 0xe200, auth=1 [ 708.110152] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.110166] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.110180] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.110196] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev 0xe200, auth=1 [ 708.110211] [drm:drm_ioctl], pid=1889, cmd=0x4020645d, nr=0x5d, dev 0xe200, auth=1 [ 708.110232] [drm:drm_ioctl], pid=1889, cmd=0xc0086457, nr=0x57, dev 0xe200, auth=1 [ 708.110247] [drm:drm_ioctl], pid=1889, cmd=0xc00c6466, nr=0x66, dev 0xe200, auth=1 [ 708.110261] [drm:drm_ioctl], pid=1889, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [ 708.110278] [drm:drm_ioctl], pid=1889, cmd=0x40046460, nr=0x60, dev 0xe200, auth=1 [ 708.110292] [drm:drm_ioctl], pid=1889, cmd=0xc008645
Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick wrote: > On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: >> On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick > wrote: >> > On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote: >> > > This is just a preliminary attempt to see if this even helps. Obviously >> > > some more effort will need to be spent investigating a better choice of >> > > latency and when we need to request it, but first: does this help? >> > >> > Sorry, but it does not. glxgears is still jerky. Do you have the 2.6.36.2 candidate patch that fixes pm_qos in? From the description, it looks like pm_qos doesn't work at all without it. --Andy >> >> I thought we were trying to fix the reported framerate? > > Yep, it reports 20-30 instead of 60 > >> Try adjusting the >> request max latency down from 20 to 1, or even 0. > > Will try. > > Regards > Vasily > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ 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 wrote: > On Tue, 7 Dec 2010 16:31:24 -0500, Andrew Lutomirski wrote: >> On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski 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 Bs3^A<88> 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] [regression?] i915 generating wakeups even when idle
On Tue, Dec 7, 2010 at 4:03 PM, Andrew Lutomirski 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
[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] [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 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:50 AM, Rasto Sramek 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] Zaphod mode support?
On Wed, Oct 6, 2010 at 10:03 AM, Rasto Sramek 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] [PATCH 7/7] drm/i915: wait for actual vblank, not just 20ms
On Wed, Aug 18, 2010 at 5:05 PM, Jesse Barnes wrote:
> On Wed, 18 Aug 2010 21:48:50 +0100
> Owain Ainsworth wrote:
>
>> On Wed, Aug 18, 2010 at 12:00:36PM -0700, Jesse Barnes wrote:
>> > 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
>> > ---
>> > drivers/gpu/drm/i915/i915_reg.h | 1 +
>> > drivers/gpu/drm/i915/intel_crt.c | 2 +-
>> > drivers/gpu/drm/i915/intel_display.c | 75
>> > ++
>> > drivers/gpu/drm/i915/intel_dp.c | 3 +-
>> > drivers/gpu/drm/i915/intel_drv.h | 3 +-
>> > drivers/gpu/drm/i915/intel_sdvo.c | 3 +-
>> > drivers/gpu/drm/i915/intel_tv.c | 9 ++--
>> > 7 files changed, 71 insertions(+), 25 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index cf41c67..822b21c 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -2080,6 +2080,7 @@
>> > #define PIPE_DITHER_TYPE_ST01 (1 << 2)
>> > /* Pipe A */
>> > #define PIPEADSL 0x7
>> > +#define DSL_LINEMASK 0x0fff
>> > #define PIPEACONF 0x70008
>> > #define PIPEACONF_ENABLE (1<<31)
>> > #define PIPEACONF_DISABLE 0
>> > diff --git a/drivers/gpu/drm/i915/intel_crt.c
>> > b/drivers/gpu/drm/i915/intel_crt.c
>> > index ee0732b..4a2f593 100644
>> > --- a/drivers/gpu/drm/i915/intel_crt.c
>> > +++ b/drivers/gpu/drm/i915/intel_crt.c
>> > @@ -331,7 +331,7 @@ intel_crt_load_detect(struct drm_crtc *crtc, struct
>> > intel_encoder *intel_encoder
>> > I915_WRITE(pipeconf_reg, pipeconf | PIPECONF_FORCE_BORDER);
>> > /* Wait for next Vblank to substitue
>> > * border color for Color info */
>> > - intel_wait_for_vblank(dev);
>> > + intel_wait_for_vblank(dev, pipe);
>> > st00 = I915_READ8(VGA_MSR_WRITE);
>> > status = ((st00 & (1 << 4)) != 0) ?
>> > connector_status_connected :
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 928bcc2..27e60b8 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -972,11 +972,57 @@ intel_find_pll_g4x_dp(const intel_limit_t *limit,
>> > struct drm_crtc *crtc,
>> > return true;
>> > }
>> >
>> > -void
>> > -intel_wait_for_vblank(struct drm_device *dev)
>> > +/**
>> > + * intel_wait_for_vblank - wait for vblank on a given pipe
>> > + * @dev: drm device
>> > + * @pipe: pipe to wait for
>> > + *
>> > + * Wait for vblank to occur on a given pipe. Needed for various bits of
>> > + * mode setting code.
>> > + */
>> > +void intel_wait_for_vblank(struct drm_device *dev, int pipe)
>> > +{
>> > + struct drm_i915_private *dev_priv = dev->dev_private;
>> > + int pipestat_reg = (pipe == 0 ? PIPEASTAT : PIPEBSTAT);
>> > + unsigned long timeout = jiffies + msecs_to_jiffies(100);
>> > +
>> > + /* Wait for vblank interrupt bit to set */
>> > + while (!(I915_READ(pipestat_reg) & PIPE_VBLANK_INTERRUPT_STATUS) &&
>> > + time_after(timeout, jiffies))
>> > + mdelay(1);
>>
>> Why not actually go to sleep and let the interrupt wake you up? let the
>> machine do something else in the meantime.
>
> Yeah, I thought that might be nice, but I was worried about locking and
> the KDB paths...
msleep at least? that's a lot of latency on single-processor otherwise.
>
> --
> 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] Fixing the hotplug storm bugs once and for all?
On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt wrote: > On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski 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] 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] [] __might_sleep+0xe8/0xed [20815.509749] [] do_page_fault+0x1aa/0x2ac [20815.509759] [] page_fault+0x1f/0x30 [20815.509770] [] ? __wake_up_common+0x25/0x84 [20815.509778] [] __wake_up+0x39/0x4d [20815.509823] [] i915_wedged_write+0xd4/0x10d [i915] [20815.509834] [] ? security_file_permission+0x16/0x18 [20815.509845] [] vfs_write+0xae/0x10b [20815.509852] [] sys_write+0x4a/0x6e [20815.509863] [] 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:[] [] __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] [] __wake_up+0x39/0x4d [20815.510257] [] i915_wedged_write+0xd4/0x10d [i915] [20815.510257] [] ? security_file_permission+0x16/0x18 [20815.510257] [] vfs_write+0xae/0x10b [20815.510257] [] sys_write+0x4a/0x6e [20815.510257] [] 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 [] __wake_up_common+0x25/0x84 [20815.510257] RSP [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 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
Re: [Intel-gfx] rfc: breaking old userspace gamma for 10-bit support
On Fri, Jul 23, 2010 at 4:13 PM, Eric Anholt wrote: > On Fri, 23 Jul 2010 14:00:30 -0400, Andrew Lutomirski wrote: >> 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? > > The kernel doesn't get to break old userspace. The kernel could support > new userspace that only asks for 129 slots and set a mode that has > better precision in that case. New interfaces would probably be > required to communicate that up front -- I haven't looked into it, but I > just want to make sure you don't spend a bunch of time going down a path > that will be rejected. > Does that include not breaking DirectColor? If we program the gamma ramp to 129 slots, old userspace submits 256 entries that are not monotonic, and we decimate the gamma ramp, we'll display the wrong thing. I have no idea if there are any programs *at all* that do that, though. (If they did, presumably they'd make the entire screen look rather odd.) I'll look in to whether we can switch between 256 and 129 slot modes without flicker. We can maybe take advantage of the fact that current userspace doesn't even check the reported gamma ramp size but just blindly shoves 256 entries at the kernel. --Andy ___ 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
Re: [Intel-gfx] Fwd: State of 10 bits/channel?
On Fri, Jul 23, 2010 at 8:26 AM, Chris Wilson wrote: > On Thu, 22 Jul 2010 17:34:09 -0400, Andrew Lutomirski 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] 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 wrote: > On Sat, Jun 12, 2010 at 7:21 PM, Andy Lutomirski 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 wrote: > On Fri, Jun 18, 2010 at 4:04 PM, Jesse Barnes > wrote: >> On Thu, 17 Jun 2010 19:44:10 -0700 >> Jesse Barnes wrote: >> >>> On Fri, 18 Jun 2010 02:20:23 +0200 >>> Marc Deop i Argemí 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 wrote: > On Thu, 17 Jun 2010 19:44:10 -0700 > Jesse Barnes wrote: > >> On Fri, 18 Jun 2010 02:20:23 +0200 >> Marc Deop i Argemí 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] [ANNOUNCE] xf86-video-intel 2.11.901
On Thu, Jun 17, 2010 at 4:32 PM, Jesse Barnes wrote: > On Wed, 16 Jun 2010 11:07:21 -0400 > Andrew Lutomirski wrote: > >> On Wed, Jun 16, 2010 at 7:38 AM, Andrew Lutomirski wrote: >> > On Wed, Jun 16, 2010 at 7:25 AM, Marc Deop i Argemí >> > wrote: >> >> On Wednesday June 16 2010 11:20:09 Chris Wilson wrote: >> >> >> >> Freeze is... freeze :P >> >> >> >> Now, seriously, the computer stops responding. I'm not able to switch >> >> between >> >> VT nor to ping nor login to the machine via my cell phone. If I'm playing >> >> sound the machine gets in kind of a loop with the last sound it played >> >> repeating again and again. >> > >> > No ping? Sounds like a kernel bug to me. You could try netconsole to >> > get a oops dump. >> >> Hah. I just got a freeze, too. As in, frozen so hard that caps lock >> and magic sysrq didn't work. This is git master from today >> (a25573d5c47ebea34c076075e1993233d7db2b4f). > > Are these both on 945? If so, can you guys try two of the patches I > posted earlier? In particular: This is GM45. > drm/i915: fix page flipping on gen3 > drm/i915: don't queue flips during a flip pending event Neither patch applies for me. $ patch -p1 <0003-drm-i915-don-t-queue-flips-during-a-flip-pending-eve.patch patching file drivers/gpu/drm/i915/intel_display.c Hunk #1 FAILED at 4235. [more output about fuzz] $ git reset --hard origin/master HEAD is now at 7e27d6e Linux 2.6.35-rc3 $ patch -p1 <0006-drm-i915-fix-page-flipping-on-gen3.patch [stuff that worked] patching file drivers/gpu/drm/i915/i915_irq.c Hunk #1 FAILED at 924. 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_irq.c.rej [more stuff that worked] --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 Wed, Jun 16, 2010 at 7:38 AM, Andrew Lutomirski wrote: > On Wed, Jun 16, 2010 at 7:25 AM, Marc Deop i Argemí > wrote: >> On Wednesday June 16 2010 11:20:09 Chris Wilson wrote: >> >> Freeze is... freeze :P >> >> Now, seriously, the computer stops responding. I'm not able to switch between >> VT nor to ping nor login to the machine via my cell phone. If I'm playing >> sound the machine gets in kind of a loop with the last sound it played >> repeating again and again. > > No ping? Sounds like a kernel bug to me. You could try netconsole to > get a oops dump. Hah. I just got a freeze, too. As in, frozen so hard that caps lock and magic sysrq didn't work. This is git master from today (a25573d5c47ebea34c076075e1993233d7db2b4f). --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 Wed, Jun 16, 2010 at 7:25 AM, Marc Deop i Argemí wrote: > On Wednesday June 16 2010 11:20:09 Chris Wilson wrote: >> After a freeze, can you grab a copy of dmesg, Xorg.log, intel_reg_dump, >> and /sys/kernel/debug/dri/0/i915_error_state. From my perspective, the >> last contains the most interesting information (the batchbuffer executing >> at the time of a gpu hang). If there is nothing in any of those, echo t > >> /proc/sysrq-trigger and look for the stacktraces in dmesg. > > I checked some of those files (dmesg, Xorg.log) and couldn't fine anything. > I'll try again and will check the other files you mention > >> >> Also what type of freeze is it? A complete hard hang, the system no longer >> even pingable? The cursor continues to move, but no other screen updates? >> The screen entirely frozen (or maybe flashing in a hypnotic pattern) but >> the machine nevertheless is accessible over the network? Does VT switching >> still work? Etc. 'Freeze' covers a whole multitude of sins, the more >> information you can give us, the quicker we can pinpoint the cause. > > Freeze is... freeze :P > > Now, seriously, the computer stops responding. I'm not able to switch between > VT nor to ping nor login to the machine via my cell phone. If I'm playing > sound the machine gets in kind of a loop with the last sound it played > repeating again and again. No ping? Sounds like a kernel bug to me. You could try netconsole to get a oops dump. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [2.6.35 regression ping] i915 is unusable due to CRT hotplug bug
Hi all- Just a friendly regression reminder: a recent patch intended to fix the long-standing hotplug storm bugs in i915 instead made it a good deal worse -- I now get hotplug interrupts constantly as long as anything (plymouth or Xorg, for example) is querying CRT status. Analysis and potential at: https://patchwork.kernel.org/patch/105727/ Briefly, the offending commit (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7a772c492fcfffae812ffca78a628e76fa57fe58) cleaned up the programming of CRT detection parameters in such a way that they get reprogrammed every time CRT status is read, which causes the GPU to helpfully report a hotplug interrupt shortly afterwards. It would be nice to get a fix queued up in time for -rc4. Thanks, Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] hotplug storms still here
On Tue, Jun 8, 2010 at 10:09 AM, Adam Jackson wrote: > On Tue, 2010-06-08 at 04:12 -0400, Andrew Lutomirski wrote: >> On my trusty X200s (GM45), I still have such frequent i915 hotplug >> storms that any standard kernel is essentially unusable. > > You're not running master, it looks like. I'd be interested to know if > this patch helps: > > commit 6e0032f0ae4440e75256bee11b163552cae21962 > Author: Karsten Wiese > Date: Sat Mar 27 22:48:33 2010 +0100 > > drm/i915: Don't touch PORT_HOTPLUG_EN in intel_dp_detect() I'm on 2.6.34 and your patch does not seem to help. (This is still with hdmi and sdvo disabled.) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] hotplug storms still here
On Tue, Jun 8, 2010 at 6:43 AM, Andrew Lutomirski wrote: > > Time for the next try. Now I have SDVO and HDMI disabled and the bug's still there. $ ls /sys/class/drm/card0 card0-DisplayPort-1 card0-DisplayPort-3 card0-VGA-1 device subsystem card0-DisplayPort-2 card0-LVDS-1 dev power uevent VGA's probably not the problem, since I haven't seen this bug on kernels with VGA enabled but all digital outputs disabled. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] hotplug storms still here
On Tue, Jun 8, 2010 at 4:12 AM, Andrew Lutomirski wrote:
> On my trusty X200s (GM45), I still have such frequent i915 hotplug
> storms that any standard kernel is essentially unusable.
>
[...]
>
> I'll try selectively disabling outputs and seeing if I can narrow it down.
This patch did *not* fix it:
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo
index 87d9536..448ad7a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2779,6 +2779,7 @@ bool intel_sdvo_init(struct drm_device *dev, int sdvo_reg)
u8 ch[0x40];
int i;
+ return false;
intel_encoder = kcalloc(sizeof(struct intel_encoder)+sizeof(struct intel
if (!intel_encoder) {
The output looked like this:
[ 109.480089] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 109.666704] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 109.668747] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 109.669083] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 109.670007] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 109.670218] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 109.670656] hotplug event received, iir 0x0002, stat
0x0820, mask 0x38000800
[ 109.671394] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
And it kept happening (in bursts of a couple seconds with a few
seconds of silence between) even after I switched to a console and did
killall -STOP Xorg.
Time for the next try.
--Andy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] hotplug storms still here
On my trusty X200s (GM45), I still have such frequent i915 hotplug
storms that any standard kernel is essentially unusable.
Here's an example:
[ 138.717645] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.718029] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.718157] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.719149] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.719389] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.719780] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.720682] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.721418] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.721804] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.722265] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.723540] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.723841] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.724501] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.725796] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.726601] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.727630] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.727965] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.728469] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.728627] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.729078] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.729251] hotplug event received, iir 0x0002, stat
0x2820, mask 0x38000800
[ 138.729339] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.729795] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.730578] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
[ 138.730667] hotplug event received, iir 0x0002, stat
0x2020, mask 0x38000800
etc. (I often see statuses different from 0x2020.)
That's with this patch applied:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index df6a9cd..58e403a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -903,8 +903,8 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
(iir & I915_DISPLAY_PORT_INTERRUPT)) {
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
- DRM_DEBUG_DRIVER("hotplug event received, stat
0x%08x\n",
- hotplug_status);
+ printk(KERN_ERR "hotplug event received, iir 0x%08x,
stat 0x%08x,
mask 0x%08x\n",
+ iir, hotplug_status,
dev_priv->hotplug_supported_mask);
if (hotplug_status & dev_priv->hotplug_supported_mask)
queue_work(dev_priv->wq,
&dev_priv->hotplug_work);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77e40cf..3ac3dd8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1172,6 +1172,7 @@ intel_dp_detect(struct drm_connector *connector)
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dp_priv *dp_priv = intel_encoder->dev_priv;
+ uint32_t orig_hotplug_en;
uint32_t temp, bit;
enum drm_connector_status status;
@@ -1180,10 +1181,10 @@ intel_dp_detect(struct drm_connector *connector)
if (HAS_PCH_SPLIT(dev))
return ironlake_dp_detect(connector);
- temp = I915_READ(PORT_HOTPLUG_EN);
+ orig_hotplug_en = I915_READ(PORT_HOTPLUG_EN);
I915_WRITE(PORT_HOTPLUG_EN,
- temp |
+ orig_hotplug_en |
DPB_HOTPLUG_INT_EN |
DPC_HOTPLUG_INT_EN |
DPD_HOTPLUG_INT_EN);
@@ -1201,13 +1202,16 @@ intel_dp_detect(struct drm_connector *connector)
bit = DPD_HOTPLUG_INT_STATUS;
break;
default:
- return connector_status_unknown;
+ status = connector_status_unknown;
+ goto out;
}
temp = I915_READ(PORT_HOTPLUG_STAT);
- if ((temp & bit) == 0)
- return connector_status_disconnected;
+ if ((temp & bit) == 0) {
+ status = connector_status_disconnected;
+ goto out;
+ }
status = connector_status_disconnected;
if (intel_dp_aux_native_
Re: [Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
On Tue, May 25, 2010 at 10:46 AM, Adam Jackson wrote: > On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote: >> On Mon, May 24, 2010 at 4:46 PM, Adam Jackson 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 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 8:17 PM, SD wrote: > > > --- On Sat, 5/15/10, Andrew Lutomirski wrote: > >> From: Andrew Lutomirski >> Subject: Re: [Intel-gfx] Picture quality on laptop LCD with i915GM chipset. >> To: "SD" >> Cc: intel-gfx@lists.freedesktop.org >> Date: Saturday, May 15, 2010, 3:21 AM >> On Fri, May 14, 2010 at 7:17 PM, SD >> >> 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 >> > > I have tried OpenSuse 11.2, which is with newer kernel and it shows the same > bad like Fedora 12. So I decided to shift on fedora, but unfortunately > although Fedora 13 shows screen better - it is still not usable (actually > screen picture on Fedora 12 was really awful). I have tried to compare video > output on OpenSuse 11.1 and Fedora 13, all of the has the same, except of > "xdpyinfo": on suse it tells about 3 visuals ( number of visuals: 3), but > on Fedora 13 - 32 visuals. Fedora 12 got 72. > > Problems is not with fonts at all, problem with whole screen. Font, because > it very contrast, is more noticeable. Also, of course I use freetype for the > full hinting. > Does it happened to all intel chipset, or to only i915GM, because I of course > going to change my laptop, and it looks like I am not going to by a one with > intel video. In addition to changing the kernel, you've changed the entire userspace as well. Build your own kernel and the kernel people will pay attention. FWIW, my GM45 machine looks just fine on every kernel (and userspace) I've ever tried. (Well, the panel's a piece of crap, but that has nothing to do with the GPU or software.) --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 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
Re: [Intel-gfx] Page flipping not working as expected for compositing - engineering resource available to help fix it
On Mon, May 10, 2010 at 12:59 PM, Simon Farnsworth wrote: > On Monday 10 May 2010, Simon Farnsworth wrote: >> On Friday 7 May 2010, Simon Farnsworth wrote: >> > I've attached my test program (it's based on our C++ OpenGL compositor, >> > but cut down to just test OpenGL pageflipping) as performance.c, and my >> > test X stack's Xorg.0.log after one run of "performance -indirect" >> > (which ran for 573 frames). I'm using a 32-bit PAE kernel - I can add >> > information as required, and I'm happy to run tests or experiments for >> > people. >> > >> > 2) How should I go about fixing compositing? Should I fix indirect >> > rendering to use pageflipping (and if so, where do I start looking for >> > the code that's getting it wrong), or should I make TFP work when direct >> > rendering (and again, where should I start looking)? >> >> Is this the expected behaviour when indirect rendering? If so, I'll dive >> back into the stack and see if I can work out why TFP and direct rendering >> don't interact nicely. If not, roughly where should I look to fix it? > > I've found why direct rendering and TFP don't interact nicely, and it's a > client side error. > > Briefly, my compositor was being started as our signage user, who does not > have > access to /dev/dri/card0, so was falling back to swrast. When you're using > swrast, TFP only appears to work for pixmaps you create, not for compositing > pixmaps. Your program still fails for me running as an ordinary user (with, I'm pretty sure, all necessary rights) when compositing is enabled. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] bad render errors (Re: Page flipping not working as expected for compositing - engineering resource available to help fix it)
On Fri, May 7, 2010 at 9:07 AM, Simon Farnsworth wrote: > Hello, > I don't know exactly what this program is supposed to do, but here's what it does right now, on GM45 and F13 with -linus be1066bbcd443a65df312fdecea7e4959adedb45 (approx 2.6.34-rc6). (Note: I have an extra patch to turn off all digital outputs except LVDS -- I still need that to use my laptop reliably.) compiz, no -indirect: solid color. metacity, no -indirect: annoying flashing. metacity, -indirect: annoying flashing. compiz, -indirect: solid color. But last time I ran it, X blew up quite thoroughly - no caps lock, no VT switching, and no sysrq+r response. sysrq+k killed X, but after a couple rounds, X wouldn't respond without lagging after restarting it. dmesg had: [61997.737046] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61997.737057] render error detected, EIR: 0x [61997.737414] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415947 at 1415940) [61998.890100] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61998.890105] render error detected, EIR: 0x [61998.890129] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415949 at 1415940) [61999.741248] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61999.741260] render error detected, EIR: 0x [61999.741317] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415953 at 1415940) [61999.963257] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [61999.963261] render error detected, EIR: 0x [62000.331262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62000.331272] render error detected, EIR: 0x [62000.950043] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62000.950048] render error detected, EIR: 0x [62000.950210] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415964 at 1415940) [62001.413288] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.413293] render error detected, EIR: 0x [62001.413306] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415969 at 1415940) [62001.509261] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.509270] render error detected, EIR: 0x [62001.631262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62001.631272] render error detected, EIR: 0x [62002.006281] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62002.006291] render error detected, EIR: 0x [62002.982266] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62002.982279] render error detected, EIR: 0x [62002.982327] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415975 at 1415940) [62003.079261] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.079271] render error detected, EIR: 0x [62003.201262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.201272] render error detected, EIR: 0x [62003.323012] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.323022] render error detected, EIR: 0x [62003.567013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.567023] render error detected, EIR: 0x [62003.691262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62003.691272] render error detected, EIR: 0x [62004.425263] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62004.425273] render error detected, EIR: 0x [62004.915013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62004.915023] render error detected, EIR: 0x [62005.660013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62005.660023] render error detected, EIR: 0x [62006.404052] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62006.404063] render error detected, EIR: 0x [62006.404146] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415987 at 1415940) [62006.504011] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62006.504021] render error detected, EIR: 0x [62006.638013] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62006.638023] render error detected, EIR: 0x [62007.652288] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [62007.652300] render error detected, EIR: 0x [62007.652615] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1415994 at 1415940) [62007.748262] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hu
[Intel-gfx] X (or the screensaver or the compositor) sometimes wedges on resume
This might be the wrong list, but here goes... On my X200s (GM45) laptop, my system sometimes lags badly on resume. This seems to mostly happen after the laptop has been suspended for a long time (an hour or more, maybe). The symptoms are that, starting a second or two after resuming, nothing updates on the screen. I can usually, but not always, move the mouse. The CPU is mostly idle. I usually see the unlock window, but I can sometimes see all the windows behind the screensaver. Switching VTs works fine, and VTs other than X also work fine, but when I switch back to X, it's still hung. Killing kscreenlocker sometimes fixes it. Other times I have to kill kwin as well. The problem usually resolves itself after a minute or so, though. Since I usually have this issue on KDE (kwin + kscreenlocker) but I just saw the same problem on GNOME (i.e. compiz + gnome-screensaver), I'm wondering if it could be a problem with Xorg or the intel driver. Any ideas or debugging hints? I can't trigger it at will, but I see it very often after suspending for awhile. Thanks, Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/intel: Attempt to use 10-bit gamma palette mode
Should this patch be enough to output 10 bits/channel on a digital
output? I just ordered some 10-bit monitors and it would be fun to
use them in all their high-precision glory?
It should be relatively easy to use spotread (from Argyll) along with
some hacked-up gamma loader to verify that it's working.
--Andy
On Mon, Apr 26, 2010 at 6:24 PM, Peter Clifton wrote:
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 ++-
> drivers/gpu/drm/i915/intel_display.c | 33 ++---
> 2 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ab1bd2d..7a0c6ac 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1766,6 +1766,9 @@
> #define PIPECONF_INTERLACE_W_FIELD_INDICATION (6 << 21)
> #define PIPECONF_INTERLACE_FIELD_0_ONLY (7 << 21)
> #define PIPECONF_CXSR_DOWNCLOCK (1<<16)
> +#define PIPEAGCMAXRED 0x70010
> +#define PIPEAGCMAXGREEN 0x70014
> +#define PIPEAGCMAXBLUE 0x70018
> #define PIPEASTAT 0x70024
> #define PIPE_FIFO_UNDERRUN_STATUS (1UL<<31)
> #define PIPE_CRC_ERROR_ENABLE (1UL<<29)
> @@ -1958,13 +1961,15 @@
> /* Pipe B */
> #define PIPEBDSL 0x71000
> #define PIPEBCONF 0x71008
> +#define PIPEBGCMAXRED 0x71010
> +#define PIPEBGCMAXGREEN 0x71014
> +#define PIPEBGCMAXBLUE 0x71018
> #define PIPEBSTAT 0x71024
> #define PIPEBFRAMEHIGH 0x71040
> #define PIPEBFRAMEPIXEL 0x71044
> #define PIPEB_FRMCOUNT_GM45 0x71040
> #define PIPEB_FLIPCOUNT_GM45 0x71044
>
> -
> /* Display B control */
> #define DSPBCNTR 0x71180
> #define DISPPLANE_ALPHA_TRANS_ENABLE (1<<15)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 456f738..5e8191a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3433,6 +3433,9 @@ void intel_crtc_load_lut(struct drm_crtc *crtc)
> int pipe = intel_crtc->pipe;
> int pal_reg = (pipe == 0) ? PALETTE_A : PALETTE_B;
> int pipeconf_reg = (pipe == 0) ? PIPEACONF : PIPEBCONF;
> + int maxr_reg = (pipe == 0) ? PIPEAGCMAXRED : PIPEBGCMAXRED;
> + int maxg_reg = (pipe == 0) ? PIPEAGCMAXGREEN : PIPEBGCMAXGREEN;
> + int maxb_reg = (pipe == 0) ? PIPEAGCMAXBLUE : PIPEBGCMAXBLUE;
> int pipeconf = I915_READ(pipeconf_reg);
> int i;
>
> @@ -3445,17 +3448,33 @@ void intel_crtc_load_lut(struct drm_crtc *crtc)
> pal_reg = (intel_crtc->pipe == 0) ? LGC_PALETTE_A :
> LGC_PALETTE_B;
>
> - /* Switch to 8-bit gamma mode */
> - pipeconf &= ~PIPEACONF_GAMMA;
> + /* Switch to 10-bit gamma mode */
> + pipeconf |= PIPEACONF_GAMMA;
> I915_WRITE(pipeconf_reg, pipeconf);
> I915_READ(pipeconf_reg);
>
> - for (i = 0; i < 256; i++) {
> - I915_WRITE(pal_reg + 4 * i,
> - ((intel_crtc->lut_r[i] >> 8) << 16) |
> - ((intel_crtc->lut_g[i] >> 8) << 8) |
> - (intel_crtc->lut_b[i] >> 8));
> + /* Use every other value from the LUT passed,
> + * 10-bit mode uses 128 entries. */
> + for (i = 0; i < 128; i++) {
> + I915_WRITE(pal_reg + 8 * i,
> + ((intel_crtc->lut_r[2 * i] & 0xFF) << 16) |
> + ((intel_crtc->lut_g[2 * i] & 0xFF) << 8) |
> + (intel_crtc->lut_b[2 * i] & 0xFF));
> + I915_WRITE(pal_reg + 8 * i + 4,
> + ((intel_crtc->lut_r[2 * i] >> 8) << 16) |
> + ((intel_crtc->lut_g[2 * i] >> 8) << 8) |
> + (intel_crtc->lut_b[2 * i] >> 8));
> }
> +
> + /* FIXME: Distortion here, we're trying to get 129 evenly spaced
> + * samples from a LUT with 256 entries. We use 0, 2, 4 ... 254,
> + * for the main palette, then entry 255 for this last register.
> + */
> + /* Note that these registers _could_ take the LUT value of
> + * 1024, but we're maxing out at 1023.984375 as it is easier. */
> + I915_WRITE(maxr_reg, intel_crtc->lut_r[255]);
> + I915_WRITE(maxg_reg, intel_crtc->lut_g[255]);
> + I915_WRITE(maxb_reg, intel_crtc->lut_b[255]);
> }
>
> static int intel_crtc_cursor_set(struct drm_crtc *crtc,
> --
> 1.7.0.4
>
> ___
> 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
