Re: [Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v3)
Dear Dave,
just a small typo.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6094e42..151ed49 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -139,6 +139,12 @@ intel_dp_link_required(struct drm_device *dev,
[…]
+static int
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -147,8 +153,11 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_link_clock =
intel_dp_link_clock(intel_dp_max_link_bw(intel_encoder));
int max_lanes = intel_dp_max_lane_count(intel_encoder);
- if (intel_dp_link_required(connector-dev, intel_encoder, mode-clock)
- max_link_clock * max_lanes)
+ /* only refuse the mode on non eDP since we have seen some wierd eDP
panels
s/wierd/weired/
[…]
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Thu, Jul 1, 2010 at 11:24 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
That commit changes the page cache allocation to use
+ mapping_gfp_mask (mapping) |
+ __GFP_COLD |
+ gfpmask);
if I read it right. And the default mapping_gfp_mask() is
GFP_HIGHUSER_MOVABLE, so I think you get all of
(__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
set by default.
.. and then I left out the one flag I _meant_ to have there, namely
__GFP_MOVABLE.
The old code didn't just play games with ~__GFP_NORETRY and change
that at runtime (which was buggy - no locking, no protection, no
nothing), it also initialized the gfp mask. And that code also got
removed:
In fact, I don't really see why we should use that mapping_gfp_mask()
at all, since all allocations should be going through that
i915_gem_object_get_pages() function anyway. So why not just change
that function to ignore the default gfp mask for the mapping, and just
use the mask that the o915 driver wants?
Btw, why did it want to mark the pages reclaimable?
Anyway, what I'm suggesting somebody who sees this test is just
something like the patch below (whitespace-damage - I'm cutting and
pasting, it's a trivial one-liner). Does this change any behavior?
Vefa?
I think Linus is on to something, I'll finish my testing tomorrow,
I'm stuck testing this on a laptop with a 4200rpm driver, hibernating
takes quite a long time ;-(
But I have reproduced the initial failure,reverted the patch
reproduced success, and then did a couple of cycles with Linus patch
before I left.
Tomorrow I'll do another 3-4 cycles to confirm.
the patch also needs a couple of __ before GFP_HIGHMEM, in case
anyone else was hacking it.
Dave.
Linus
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..ec8ed6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
mapping = inode-i_mapping;
for (i = 0; i page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ GFP_HIGHMEM |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] System freeze with 2.12 + 2.6.34
Hi, During the 2.6.11.901 testing phase a few people reported system freezes. What was the result of that discussion? I still experience those freezes with kernel-2.6.34 + intel 2.12, quite frequently when watching high resolution flash videos. Any idea what the problem could be? Thanks, Clemens ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] System freeze with 2.12 + 2.6.34
On Thu, 1 Jul 2010 16:55:28 +0200, Clemens Eisserer linuxhi...@gmail.com wrote: During the 2.6.11.901 testing phase a few people reported system freezes. What was the result of that discussion? I still experience those freezes with kernel-2.6.34 + intel 2.12, quite frequently when watching high resolution flash videos. Any idea what the problem could be? All depends upon the system. Jesse is working on a couple of patches that address the change in handling of the vblank interrupt in some revisions of the i945/i965 chipsets. That's the known failure mode... -- 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] System freeze with 2.12 + 2.6.34
Am 01.07.2010 16:55, schrieb Clemens Eisserer: Hi, During the 2.6.11.901 testing phase a few people reported system freezes. What was the result of that discussion? I still experience those freezes with kernel-2.6.34 + intel 2.12, quite frequently when watching high resolution flash videos. Any idea what the problem could be? i also have this issue, and can (temporary) fix this with this patch provided in the fedora src rpms: http://openelec.git.sourceforge.net/git/gitweb.cgi?p=openelec/openelec;a=blob;f=packages/x11/driver/xf86-video-intel/patches/intel-2.11-no-pageflipping.diff -- ### OpenELEC.tv ### The free and open Mediacenter Distribution 4 you http://www.openelec.tv ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Fix CRT hotplug regression in 2.6.35-rc1
On Mon, Jun 28, 2010 at 7:48 PM, Dave Airlie airl...@gmail.com wrote: On Sat, Jun 12, 2010 at 7:21 PM, Andy Lutomirski l...@mit.edu wrote: Commit 7a772c492fcfffae812ffca78a628e76fa57fe58 has two bugs which made the hotplug problems on my laptop worse instead of better. First, it did not, in fact, disable the CRT plug interrupt -- it disabled all the other hotplug interrupts. It seems rather doubtful that that bit of the patch fixed anything, so let's just remove it. (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.) Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64 and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset) causes a hotplug interrupt about three seconds later. The old code never restored PORT_HOTPLUG_EN so this could only happen once, but they new code restores those registers. So just set those bits when we set up the interrupt in the first place. ping? Intel guys? ajax? anyone? We are clearly broken on GM45 at the moment. I dunno. This is all I've heard: http://www.mail-archive.com/dri-de...@lists.freedesktop.org/msg01433.html It's kind of an ACK :) Rafael has this in his tracker now, I think. --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu/drm/i915: Add a blacklist to omit modeset on LID open
On Wed, 9 Jun 2010 21:40:54 +0200, Thomas Bächler tho...@archlinux.org wrote: On some machines (currently only the Toshiba Tecra A11 is known), the GPU locks up when modeset is forced on LID open. This patch adds a new DMI blacklist and omits modesetting for all matches. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15550 This one is still missing a Signed-off-by: (see Documentation/SubmittingPatches). Could you add that and re-send with the fixed comment? pgpqJFMn8IlmE.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Explosion following OOM in do_execbuffer.
On Wed, 9 Jun 2010 17:04:24 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: Oops, when merging the extra details following an OOM, I missed that driver_private is now NULL and the correct way to convert from the drm_gem_object into the drm_i915_gem_object is to use to_intel_bo(). BUG: unable to handle kernel NULL pointer dereference at 0069 IP: [c11a4a02] i915_gem_do_execbuffer+0x71f/0xbb6 *pde = Oops: [#1] SMP last sysfs file: /sys/devices/virtual/vc/vcsa3/uevent Doesn't compile. pgpncFXGLbabj.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm: add per-event vblank event trace points
Allows us to track each process that requests and completes events.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_irq.c |8 ++
drivers/gpu/drm/drm_trace.h | 57 --
include/drm/drmP.h |2 +
3 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 6d201a8..c2ecb3e 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -588,6 +588,7 @@ static int drm_queue_vblank_event(struct drm_device *dev,
int pipe,
return -ENOMEM;
e-pipe = pipe;
+ e-base.pid = current-pid;
e-event.base.type = DRM_EVENT_VBLANK;
e-event.base.length = sizeof e-event;
e-event.user_data = vblwait-request.signal;
@@ -615,6 +616,9 @@ static int drm_queue_vblank_event(struct drm_device *dev,
int pipe,
DRM_DEBUG(event on vblank count %d, current %d, crtc %d\n,
vblwait-request.sequence, seq, pipe);
+ trace_drm_vblank_event_queued(current-pid, pipe,
+ vblwait-request.sequence);
+
e-event.sequence = vblwait-request.sequence;
if ((seq - vblwait-request.sequence) = (1 23)) {
e-event.tv_sec = now.tv_sec;
@@ -622,6 +626,8 @@ static int drm_queue_vblank_event(struct drm_device *dev,
int pipe,
drm_vblank_put(dev, e-pipe);
list_add_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
+ trace_drm_vblank_event_delivered(current-pid, pipe,
+vblwait-request.sequence);
} else {
list_add_tail(e-base.link, dev-vblank_event_list);
}
@@ -752,6 +758,8 @@ void drm_handle_vblank_events(struct drm_device *dev, int
crtc)
drm_vblank_put(dev, e-pipe);
list_move_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
+ trace_drm_vblank_event_delivered(e-base.pid, e-pipe,
+e-event.sequence);
}
spin_unlock_irqrestore(dev-event_lock, flags);
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 8a92683..03ea964 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -11,22 +11,51 @@
#define TRACE_INCLUDE_FILE drm_trace
TRACE_EVENT(drm_vblank_event,
+ TP_PROTO(int crtc, unsigned int seq),
+ TP_ARGS(crtc, seq),
+ TP_STRUCT__entry(
+ __field(int, crtc)
+ __field(unsigned int, seq)
+ ),
+ TP_fast_assign(
+ __entry-crtc = crtc;
+ __entry-seq = seq;
+ ),
+ TP_printk(crtc=%d, seq=%d, __entry-crtc, __entry-seq)
+);
- TP_PROTO(int crtc, unsigned int seq),
-
- TP_ARGS(crtc, seq),
-
- TP_STRUCT__entry(
- __field(int, crtc)
- __field(unsigned int, seq)
- ),
-
- TP_fast_assign(
- __entry-crtc = crtc;
- __entry-seq = seq;
- ),
+TRACE_EVENT(drm_vblank_event_queued,
+ TP_PROTO(pid_t pid, int crtc, unsigned int seq),
+ TP_ARGS(pid, crtc, seq),
+ TP_STRUCT__entry(
+ __field(pid_t, pid)
+ __field(int, crtc)
+ __field(unsigned int, seq)
+ ),
+ TP_fast_assign(
+ __entry-pid = pid;
+ __entry-crtc = crtc;
+ __entry-seq = seq;
+ ),
+ TP_printk(pid=%d, crtc=%d, seq=%d, __entry-pid, __entry-crtc, \
+ __entry-seq)
+);
- TP_printk(crtc=%d, seq=%d, __entry-crtc, __entry-seq)
+TRACE_EVENT(drm_vblank_event_delivered,
+ TP_PROTO(pid_t pid, int crtc, unsigned int seq),
+ TP_ARGS(pid, crtc, seq),
+ TP_STRUCT__entry(
+ __field(pid_t, pid)
+ __field(int, crtc)
+ __field(unsigned int, seq)
+ ),
+ TP_fast_assign(
+ __entry-pid = pid;
+ __entry-crtc = crtc;
+ __entry-seq = seq;
+ ),
+ TP_printk(pid=%d, crtc=%d, seq=%d, __entry-pid, __entry-crtc, \
+ __entry-seq)
);
#endif /* _DRM_TRACE_H_ */
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..8364a70 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -403,6 +403,8 @@ struct drm_pending_event {
struct drm_event *event;
struct list_head link;
struct drm_file *file_priv;
+ pid_t pid; /* pid of requester, no guarantee it's valid by the time
+ we deliver the
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci bic...@superonline.com wrote: Based on my testing, I am happy to report that the change you suggest fixes the memory corruption (segfaults) after thaw issue for me. I can't thank you enough times for this. Hey, goodie. And you're the one to be thanked - bisecting it down to that commit that wasn't _meant_ to have any real semantic changes (except for the bug-fix of racy mapping gfp-flags update) is what really cracked the lid on the problem. Now, the obligatory question: Could we have this fix applied to 2.6.32, 2.6.33 and 2.6.34 ? No problem, except we should first determine exactly what flags are the appropriate ones. My original patch was obviously not even compile-tested, and I actually meant for people to use GFP_HIGHUSER rather than __GFP_HIGHMEM. That contains all the regular allocation flags (but not the __GFP_MOVABLE, which is still just a suspicion of being the core reason for the problem). And the original DRM code had: GFP_HIGHUSER | __GFP_COLD | __GFP_FS | __GFP_RECLAIMABLE | __GFP_NORETRY | __GFP_NOWARN | __GFP_NOMEMALLOC which is not entirely sensible (__GFP_FS is already part of GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN) are the ones the driver wants to do conditionally. But that still leaves the question about __GFP_COLD (probably sane), __GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC (usually used together with NORETRY, and I'm not at all sure it makes sense as a base flag). So I suspect the final patch should not look like the one you tested, but instead likely have GFP_HIGHUSER | __GFP_COLD and possibly the __GFP_RECLAIMABLE flag too instead of just the bare __GFP_HIGHMEM.. (Well, we already had that __GFP_COLD there from before, so it's really about replacing __GFP_HIGHMEM with something like GFP_HIGHUSER | __GFP_RECLAIMABLE). But its' great to hear that this does seem to be the underlying cause. If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that would be a good thing. After all - maybe the problem was triggered by some other flag than __GFP_MOVABLE, and as such, having some additional testing with a bigger set of allocation flags would be a really good thing. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix hibernation since 4bdadb9785696439c6e2b3efe34aa76df1149c83
From: Linus Torvalds torva...@linux-foundation.org
Since 4bdadb9785696439c6e2b3efe34aa76df1149c83, we've been passing
GFP_MOVABLE where we weren't before caused hibernate on Intel hardware
to results in a lot of memory corruptions on resume.
[airlied: linus please enhance commit msg if you commit this]
http://bugzilla.kernel.org/show_bug.cgi?id=13811
Reported-by: Evengi Golov (in bugzilla)
Signed-off-by: Dave Airlie airl...@redhat.com
Tested-by: M. Vefa Bicakci bic...@superonline.com
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..0743858 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
mapping = inode-i_mapping;
for (i = 0; i page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ GFP_HIGHUSER |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
--
1.7.0.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Fri, Jul 2, 2010 at 9:59 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci bic...@superonline.com wrote: Based on my testing, I am happy to report that the change you suggest fixes the memory corruption (segfaults) after thaw issue for me. I can't thank you enough times for this. Hey, goodie. And you're the one to be thanked - bisecting it down to that commit that wasn't _meant_ to have any real semantic changes (except for the bug-fix of racy mapping gfp-flags update) is what really cracked the lid on the problem. Now, the obligatory question: Could we have this fix applied to 2.6.32, 2.6.33 and 2.6.34 ? No problem, except we should first determine exactly what flags are the appropriate ones. My original patch was obviously not even compile-tested, and I actually meant for people to use GFP_HIGHUSER rather than __GFP_HIGHMEM. That contains all the regular allocation flags (but not the __GFP_MOVABLE, which is still just a suspicion of being the core reason for the problem). And the original DRM code had: GFP_HIGHUSER | __GFP_COLD | __GFP_FS | __GFP_RECLAIMABLE | __GFP_NORETRY | __GFP_NOWARN | __GFP_NOMEMALLOC which is not entirely sensible (__GFP_FS is already part of GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN) are the ones the driver wants to do conditionally. But that still leaves the question about __GFP_COLD (probably sane), __GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC (usually used together with NORETRY, and I'm not at all sure it makes sense as a base flag). So I suspect the final patch should not look like the one you tested, but instead likely have GFP_HIGHUSER | __GFP_COLD and possibly the __GFP_RECLAIMABLE flag too instead of just the bare __GFP_HIGHMEM.. (Well, we already had that __GFP_COLD there from before, so it's really about replacing __GFP_HIGHMEM with something like GFP_HIGHUSER | __GFP_RECLAIMABLE). But its' great to hear that this does seem to be the underlying cause. If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that would be a good thing. After all - maybe the problem was triggered by some other flag than __GFP_MOVABLE, and as such, having some additional testing with a bigger set of allocation flags would be a really good thing. I just sent a patch I tested here with GFP_HIGHUSER | __GFP_COLD instead, and it resumes okay for me, I'll play with GFP_RECLAIMABLE now, If anyone wants to know why nobody uses hibernate, this laptop with a 4200rpm driver boots faster than the hibernate cycle. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
On Thu, Jul 1, 2010 at 5:49 PM, Dave Airlie airl...@gmail.com wrote: RECLAIMABLE added also seems fine, of course you can't have RECLAIMABLE and MOVABLE (I find this out when it oopses on boot). Yes. They are both flags for the anti-fragmentation code, and I think I'll leave the decision as to whether the i915 driver should use __GFP_RECLAIMABLE to the people who work with and care about the fragmentation issues. I doubt it matters much in practice, at least not for the loads that the fragmentation people tend to care most about. So I suspect MOVABLE is the problem. but I don't know enough about gfp flags to know what RECLAIMABLE buys us, and where it might bite us so I can test some more. I think I'll just apply your previous tested patch - GFP_HIGHUSER should take care of all the flags that matter fundamentally, and then the reclaimable flag is really just a small detail for others to worry about. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
