Re: [PATCH] drm: make drm_wait_vblank return immediately for very old sequence values
On Mon, Feb 16, 2009 at 5:33 PM, Michel Dänzer mic...@daenzer.net wrote: On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote: On Friday, February 13, 2009 2:33 am Michel Dänzer wrote: On Thu, 2009-02-12 at 09:15 -0800, Jesse Barnes wrote: It does, but take a look at that code again. If interrupts are disabled by the timer, we'll capture the frame count. If, sometime later, they're re-enabled, we'll end up in drm_update_vblank_count. And if, between those two points, we've had a DPMS event, the frame counter will have been reset and will now be a lower value, so our drm_update_vblank_count will detect a wraparound. I think any hardware that resets its frame count will be susceptible to this problem unless we make wraparounds harmless. The modeset ioctl makes wraparounds harmless if used correctly. I don't think it does. And you may not be seeing this problem on radeon because your max_vblank_count is only 0x1f, which wouldn't trigger this behavior. Which btw looks like it's incorrect for newer Radeons with AVIVO display engine, which seem to have 24 bits in the frame counter registers - Dave/Alex? Yes 24-bits on r500 and above. Dave. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[pgarr...@optusnet.com.au: Re: [RFC] page flipping/buffer swap for DRI2]
- Forwarded message from Peter John Garrone pgarr...@optusnet.com.au - From: Peter John Garrone pgarr...@optusnet.com.au To: Jesse Barnes jbar...@virtuousgeek.org Subject: Re: [RFC] page flipping/buffer swap for DRI2 On Fri, Feb 13, 2009 at 04:44:08PM -0800, Jesse Barnes wrote: On Friday, February 13, 2009 4:18 pm Peter John Garrone wrote: In reply to Jesse Barnes post. I'm not on top of the finer details, being a consumer rather than a developer. I have the following queries: 1) Is the buffer flip to be synchronous in the hardware, or to be implemented as a software interrupt? I'm not sure what you mean... The flip is queued in the hardware ring, and delayed by hardware until the vertical blank interval starts. So in that sense the hardware takes care of it for us (we don't rely on an interrupt to get the bits on the screen). We do require an interrupt, however, to know when the flip has occurred. This lets us know that it's ok to start drawing on the new back buffer, since it's no longer being displayed to the user. I incorrectly wrote software interrupt when I meant hardware interrupt, which is confusing, sorry. I would rephrase my own particular requirement as Is the buffer flip to be implemented in the hardware, or implemented in software triggered by hardware interrupt? The intel hardware has the ability to do a buffer swap in the hardware. However I believe that the current dri infrustructure works (see mesa/src/mesa/drivers/dri/intel/intel_swapbuffers.c:intelSwapBuffers) by flushing pending rendering commands, waiting for the appropriate vertical blank interrupt, then copying the opengl back buffer to the front buffer. This is a problem when the interrupt response is slow, or when the hardware graphics queue is not empty because other opengl applications are currently rendering, so the buffer swap is delayed, creating a tear generally near the top of the screen. I don't think this quite agrees with your outline, unless your patch set addresses this problem, which would be wonderful. I currently cope with this by poking the hardware to cause the two screens to interrupt at a particular phase, and synchronizing the two rendering threads to wait until both have accomplished their screen swaps. At high loads, however, the synchronization breaks down and tearing results, and it is never possible to completly eliminate tearing. 2) By fullscreen, do you mean covering one or all screens in a multi-headed display? It's hard coded to deal with one screen in this patchset, but potentially needs to flip both heads in a shared (cloned or extended desktop) configuration. That's fine. I would hope that in a dual-headed setup, each screen (or plane) can be individually full-screen. Sometimes fullscreen is interpreted as a single window covering both screens, which is not good for me. 3) If fullscreen means covering an individual screen in a multi-headed display, will it be possible to have multiple simultaneous fullscreen tear-free applications? Yes, it should be possible. 4) Will non-fullscreen applications be tear-free? Maybe. If you're running a compositing manager that always swaps the whole screen (like the hacked version of compiz I've been using for testing does), then any non-DRI apps running under it will be tear-free. DRI apps will need special treatment, which I haven't implemented yet. To be honest, the speed of the window manager is not a big issue for me. Tearing is. In production mode, efficient fullscreen output mode is desirable. In development mode, having the output into manageable re-sizeable windows is nicer. The only way I can see non-tearing non-fullscreen applications working is with triple-buffer. i.e. a kernel screen flyback interrupt copies a screen-full from the multi-headed working buffer to a plane buffer, schedules that plane buffer to be swapped upon the next flyback, and triggers approptiate returns from the application swap-buffer function calls. I assume this is triple-buffer because there is the large possibly virtual working buffer and also two plane buffers for each screen. That would be one way of handling non-fullscreen apps. Another way would be to queue front buffer blits from such apps to occur during the vertical blank period. That's not as reliable (nor easy to implement) as full page flipping though, but has the advantage of just blitting over a small area of the screen, which will preserve most of the compressed framebuffer (if present), saving power. This appears to me to be what the code in intel_swapbuffers.c currently achieves. I'm grateful if you are creating an alternative for fullscreen applications, anyway. However a fullscreen application should be able to override this on an individual screen basis, rendering directly into the non-output display plane, and scheduling it to be swapped upon the N'th flyback. Right, that's
Re: [PATCH] drm/i915: Storage class should be before const qualifier
On Mon, 9 Feb 2009, Tobias Klauser wrote:
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
drivers/gpu/drm/i915/intel_tv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 4072154..249e0a3 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -147,7 +147,7 @@ static bool intel_sdvo_write_byte(struct intel_output
*intel_output, int addr,
#define SDVO_CMD_NAME_ENTRY(cmd) {cmd, #cmd}
/** Mapping of command numbers to names, for debug output */
-const static struct _sdvo_cmd_name {
+static const struct _sdvo_cmd_name {
u8 cmd;
char *name;
} sdvo_cmd_names[] = {
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index fbb35dc..56485d6 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -411,7 +411,7 @@ struct tv_mode {
* These values account for -1s required.
*/
-const static struct tv_mode tv_modes[] = {
+static const struct tv_mode tv_modes[] = {
{
.name = NTSC-M,
.clock = 107520,
This doesn't seem to be picked by anyone for current -next/-mmotm, I have
applied it to trivial tree. Thanks,
--
Jiri Kosina
SUSE Labs
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Storage class should be before const qualifier
On Mon, Feb 16, 2009 at 10:52 PM, Jiri Kosina jkos...@suse.cz wrote:
On Mon, 9 Feb 2009, Tobias Klauser wrote:
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
drivers/gpu/drm/i915/intel_tv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 4072154..249e0a3 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -147,7 +147,7 @@ static bool intel_sdvo_write_byte(struct intel_output
*intel_output, int addr,
#define SDVO_CMD_NAME_ENTRY(cmd) {cmd, #cmd}
/** Mapping of command numbers to names, for debug output */
-const static struct _sdvo_cmd_name {
+static const struct _sdvo_cmd_name {
u8 cmd;
char *name;
} sdvo_cmd_names[] = {
diff --git a/drivers/gpu/drm/i915/intel_tv.c
b/drivers/gpu/drm/i915/intel_tv.c
index fbb35dc..56485d6 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -411,7 +411,7 @@ struct tv_mode {
* These values account for -1s required.
*/
-const static struct tv_mode tv_modes[] = {
+static const struct tv_mode tv_modes[] = {
{
.name = NTSC-M,
.clock = 107520,
This doesn't seem to be picked by anyone for current -next/-mmotm, I have
applied it to trivial tree. Thanks,
Its in my queue for Linus drm-fixes tree already.
Dave.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Storage class should be before const qualifier
On Mon, 16 Feb 2009, Dave Airlie wrote: Its in my queue for Linus drm-fixes tree already. OK, dropped. -- Jiri Kosina -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17723] Radeon XPRESS 200M (RC410) - xorg crash when enabling compiz with 32 Mb VRAM
http://bugs.freedesktop.org/show_bug.cgi?id=17723 --- Comment #53 from Alex Villacís Lasso avill...@ceibo.fiec.espol.edu.ec 2009-02-16 08:31:46 PST --- Created an attachment (id=22981) -- (http://bugs.freedesktop.org/attachment.cgi?id=22981) Xorg.0.log for now-working case with 32 Mb VRAM I am now running updated Fedora 10 with the following stock packages: kernel-2.6.27.12-170.2.5.fc10.i686 mesa-libGL-7.2-0.15.fc10.i386 mesa-dri-drivers-7.2-0.15.fc10.i386 xorg-x11-drv-ati-6.10.0-2.fc10.i386 From an earlier advice, I am running with a xorg.conf with an explicit Virtual 1400 1080 setting. I have tried booting with 32 Mb of VRAM in the BIOS, and the crashes and corruptions are now gone, even with compiz. Attached is my current Xorg.0.log . It might be that the issue of an incorrectly-sized default Virtual setting was causing the problem all along, and this fixed the issue in my case. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17723] Radeon XPRESS 200M (RC410) - xorg crash when enabling compiz with 32 Mb VRAM
http://bugs.freedesktop.org/show_bug.cgi?id=17723 --- Comment #54 from Alex Villacís Lasso avill...@ceibo.fiec.espol.edu.ec 2009-02-16 08:32:40 PST --- Created an attachment (id=22982) -- (http://bugs.freedesktop.org/attachment.cgi?id=22982) xorg.conf used with xserver Current xorg.conf. Notice the explicit Virtual setting. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] Remove Intel drivers from linux-core
On Sat, Feb 14, 2009 at 11:24:18PM +0200, Pekka Paalanen wrote: From 29d3f6e9c1258736c3199834b293b8128faef2ad Mon Sep 17 00:00:00 2001 From: Pekka Paalanen p...@iki.fi Date: Sat, 14 Feb 2009 21:49:08 +0200 Subject: [PATCH] Remove Intel drivers from linux-core Both i810 and i915 DRM Linux kernel specific sources are removed. Intel developers have stated, that their DRM development continues elsewhere in some Linux kernel trees. This makes the code in drm.git just dead weight. This removal allows further cleanup of compatibility code. shared-core and bsd-core are left untouched. Personally i'd also kill bsd-core, since it's outdates and contains so much shit we don't want. Then again Robert may have something to say bout this. -0- -- who is still slacking on getting a fd.o account. -- I brake for chezlogs! -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: make drm_wait_vblank return immediately for very old sequence values
On Sunday, February 15, 2009 11:33 pm Michel Dänzer wrote: On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote: Recall our last discussion where I outlined the cases we'd have to deal with in the modeset ioctl if we didn't use get/put to just keep interrupts on around the calls: But we are intending to keep them on around the calls. So the problem is that you are disabling the IRQ in between? Maybe a solution could be not to mess with the counter when disabling/enabling the IRQ. It needs to be guarded by the modeset ioctl anyway, so shouldn't that work? The current problem isn't a disable between modeset ioctls, it's a disable followed by a counter reset of any kind (modeset ioctls or not), since the last count we track is just done in the disable function, not in the modeset ioctl. Doing in in the modeset ioctl instead may be possible, but as I said there are lots of cases to deal with. Can you think of a case where those frames would matter? E.g. the GLX_OML_sync_control spec says 'The graphics Media Stream Counter (or graphics MSC) is a counter that is unique to the graphics subsystem and increments for each vertical retrace that occurs.' Vertical retraces that occur while nobody's listening may not matter in simple cases, but that doesn't mean they're never relevant. But that doesn't say anything about whether the frame count must stay accurate while apps aren't running (i.e. doing anything with video/GL). The other side of this coin is that it doesn't mention this as a special case, so users of the extension can assume that the count increases regardless. But apps can't assume that; frames *will* be lost when the monitor goes off, for as long as the monitor is off. So if an app isn't actively using the framecount for something it can't count on a given value. Right? That's why I asked for an example. If we assume it's important in some cases, we can still remove the update_vblank_counter code and just provide a knob to prevent interrupts from ever being disabled. One could also question why we're bothering to disable vblank interrupts at all, given that they'll be enabled all the time with tear-free compositing anyway, which will hopefully be the usual case in the long run. Yeah, I certainly hope tear-free will be the usual case (even in the short run!), but with the hacked up compiz I've been running for testing, I don't need interrupts all the time. vblank interrupts are only enabled when needed (i.e. when a page flip is pending). That only happens when a screen update has occurred, and, on my system at least, when I'm idle no screen damage occurs, which means no page flips or interrupts. So interrupt mitigation is still a good idea. -- Jesse Barnes, Intel Open Source Technology Center -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: add page flipping ioctl
On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
On Thu, 2009-02-12 at 16:52 -0800, Jesse Barnes wrote:
This adds a new ioctl for queueing a page flip with GEM objects. There's
a completion per private object, that we use at execbuf time to wait for
any pending flips; it's cleared at vblank interrupt time when the flip
occurs. The kernel will figure out the pitch of the new frontbuffer
automatically, but the caller has to pass in dimensions and pipe
information.
On my i915, the flip never occurs and we wait forever on the the vblank.
So I presume the command we sent the chip is invalid, or we miss the
irq? (I double-checked with lockdep in case I had missed an obvious
dead-lock.) Comments on the patch itself inline.
Thanks a lot for looking at this and testing.
Hm, maybe you're not getting vblank interrupts at all? Do you see the count
increasing? Is the IRQ registered?
+static int i915_pipe_to_plane(struct drm_device *dev, int pipe)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 reg, pipe_mask;
+
+ if (pipe == 0)
+ pipe_mask = DISPPLANE_SEL_PIPE_A;
+ else
+ pipe_mask = DISPPLANE_SEL_PIPE_B;
+
+ reg = I915_READ(DSPACNTR);
+ if ((reg DISPLAY_PLANE_ENABLE)
+ ((reg DISPPLANE_SEL_PIPE_MASK) == pipe_mask))
+ return 0;
Would this be easier to read as:
pipe_mask |= DISPLAY_PLANE_ENABLE;
reg = I915_READ(DSPACNTR);
if ((reg (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) ==
pipe_mask) return 0;
reg = I915_READ(DSPBCNTR);
if ((reg (DISPLAY_PLANE_ENABLE | DISPPLANE_SEL_PIPE_MASK)) ==
pipe_mask) return 1;
Yeah, looks a bit clearer that way.
+ plane = i915_pipe_to_plane(dev, pipe);
+ if (plane 0) {
+ DRM_ERROR(bad pipe (no planes enabled?)\n);
+ return -EINVAL;
+ }
+
+ obj = drm_gem_object_lookup(dev, file_priv, flip_data-handle);
+ if (obj == NULL)
+ return -EBADF;
+
+ obj_priv = obj-driver_private;
Need to take the dev-struct_mutex here whilst reading the tiling
parameters and pinning.
Oops yeah will fix.
+ if (obj_priv-tiling_mode != I915_TILING_NONE
+ obj_priv-tiling_mode != I915_TILING_X) {
+ DRM_ERROR(can only flip non-tiled or X tiled pages\n);
+ ret = -EINVAL;
+ goto out_unref;
+ }
+
+ ret = i915_gem_object_pin(obj, 0);
Since we do not appear to explicitly track and unpin the old scan-out
buffer, presumably we are just reliant on user space destroying the old
buffers in a timely manner in order to recover their gtt space (and the
precious fence register)?
Yeah, I'm open to suggestions there... Current (i.e. non-KMS) userspace pins
the buffers itself, but it *should* be ok to unpin the old buffer at
completion time. I'll have to give that a try.
As for tiling, we really need to change Mesa to use 3D blits (with
corresponding tile parameters) so that we don't have to use the fence regs as
much. But even so, unpinning and removing the fence reg from the old buffer
would be a good thing.
+ if (ret) {
+ DRM_ERROR(failed to pin object for flip\n);
+ ret = -EBUSY;
+ goto out_unref;
+ }
+
+ offset = obj_priv-gtt_offset;
+ pitch = obj_priv-stride;
+ tiled = !!(obj_priv-tiling_mode == I915_TILING_X);
Having pinned the buffer, we can now drop the mutex.
Ok.
+ /*
+* Queue the flip with the lock held in case the flip happens
+* immediately.
+*/
+ spin_lock_irqsave(dev_priv-vblank_lock, flags);
vblank_lock is never initialised.
Heh, yeah I realized that just after I sent it out.
+
+ BEGIN_LP_RING(4);
+ OUT_RING(CMD_OP_DISPLAYBUFFER_INFO | (plane 20));
+ OUT_RING((pitch / 8) 3); /* flip queue and/or pitch */
+ OUT_RING(offset | tiled);
+ OUT_RING(((flip_data-x - 1) 16) | (flip_data-y - 1));
x/y look reversed compared to other commands (but I'm just speculating
without the documentation).
According to the public docs, X is 27:16 and Y is 11:0, so I *think* it's
right (though it appears previous chips don't have this field).
+ obj_priv = object_list[i]-driver_private;
+ spin_lock_irqsave(dev_priv-vblank_lock, irqflags);
+ if (!list_empty(obj_priv-vblank_head)) {
+ spin_unlock_irqrestore(dev_priv-vblank_lock,
+ irqflags);
+ wait_for_completion(obj_priv-vblank);
+ } else
+ spin_unlock_irqrestore(dev_priv-vblank_lock,
+ irqflags);
This is quite untidy. Move it to an inline? (And reduce it to only need
a single unlock.)
Yeah was thinking the same thing; should just be if (flip_pending(obj_priv))
or something instead, followed by the wait.
[Bug 12419] possible circular locking dependency on i915 dma
http://bugzilla.kernel.org/show_bug.cgi?id=12419 --- Comment #5 from r...@sisk.pl 2009-02-16 12:43 --- On Monday 16 February 2009, Wang Chen wrote: Rafael J. Wysocki said the following on 2009-2-15 4:38: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.28. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419 Subject : possible circular locking dependency on i915 dma Submitter : Wang Chen wangc...@cn.fujitsu.com Date: 2009-01-08 14:11 (38 days old) References : http://marc.info/?l=linux-kernelm=123142399720125w=4 Yes. It's still there in mainline. I think the commit 546b0974c39657017407c86fe79811100b60700d i915: Use struct_mutex to protect ring in GEM mode. brought this regression. The lockdep problem is as following: thread-1 i915_cmdbuffer() | --- lock(drm_device-struct_mutex) | V i915_dispatch_cmdbuffer() | i915_emit_box() | -copy_from_user() | -might_fault() | ---lock(mm-mmap_sem) thread-2 dup_mm() | ---lock(mm-mmap_sem) | V drm_vm_open() | --- lock(drm_device-struct_mutex) The different order to lock mmap_sem and drm_dev-struct_mutex introduces the problem. But it seems no way to reverse the lock order in i915. So how about refine the lock granularity of drm_dev-struct_mutex and exclude the mmap_sem lock/unlock out of the drm_dev-struct_mutex lock/unlock range? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12419] possible circular locking dependency on i915 dma
http://bugzilla.kernel.org/show_bug.cgi?id=12419 --- Comment #6 from r...@sisk.pl 2009-02-16 12:48 --- First-Bad-Commit : 546b0974c39657017407c86fe79811100b60700d Notify-Also : Eric Anholt e...@anholt.net Notify-Also : Dave Airlie airl...@redhat.com -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12444] X hangs following switch from radeonfb console - Bisected
http://bugzilla.kernel.org/show_bug.cgi?id=12444 --- Comment #4 from r...@sisk.pl 2009-02-16 13:51 --- Caused by: commit 7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a Author: Dave Airlie airl...@redhat.com Date: Fri Nov 28 14:22:24 2008 +1000 drm: move to kref per-master structures. Signed-off-by: Dave Airlie airl...@redhat.com -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12444] X hangs following switch from radeonfb console - Bisected
http://bugzilla.kernel.org/show_bug.cgi?id=12444 --- Comment #5 from r...@sisk.pl 2009-02-16 13:52 --- First-Bad-Commit : 7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12444] X hangs following switch from radeonfb console - Bisected
http://bugzilla.kernel.org/show_bug.cgi?id=12444 --- Comment #3 from r...@sisk.pl 2009-02-16 13:51 --- On Monday 16 February 2009, Graham Murray wrote: Rafael J. Wysocki r...@sisk.pl writes: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.28. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444 Subject : X hangs following switch from radeonfb console - Bisected Submitter : Graham Murray gra...@gmurray.org.uk Date: 2009-01-13 14:03 (33 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a I am still seeing the problem with 2.6.29-rc5 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12705] X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
http://bugzilla.kernel.org/show_bug.cgi?id=12705 rui.zh...@intel.com changed: What|Removed |Added CC|acpi- |e...@anholt.net |bugzi...@lists.sourceforge.n| |et | AssignedTo|acpi_power-vi...@kernel-|drivers_video-...@kernel- |bugs.osdl.org |bugs.osdl.org Status|NEEDINFO|NEW Component|Power-Video |Video(DRI) Product|ACPI|Drivers --- Comment #2 from rui.zh...@intel.com 2009-02-16 16:59 --- http://marc.info/?l=linux-kernelm=123479975503827w=2 e806b4957412bf472d826bd8cc571da041248799 is the first commit cc Eric -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19804] [Ubuntu-8.10] - Incorrect fonts appear using Google Earth-4.2
http://bugs.freedesktop.org/show_bug.cgi?id=19804 Sunil Mekathotti sbmekatho...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #9 from Sunil Mekathotti sbmekatho...@gmail.com 2009-02-16 22:16:50 PST --- This problem is not observed with the following X-stack: mesa/drm: master (git) 16-FEB-2009 mesa/mesa :7.2 xorg/xserver:1.5.2 xorg/xf86-video-ati: master(git) 16-FEB-2009 xorg/driver/xf86-input-keyboard - 1.3.0 xorg/driver/xf86-input-mouse-1.3.0 - No other changes in my driver build procedure. closing the bug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19804] [Ubuntu-8.10] - Incorrect fonts appear using Google Earth-4.2
http://bugs.freedesktop.org/show_bug.cgi?id=19804 Sunil Mekathotti sbmekatho...@gmail.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
