Re: [Known BUG?] i915 hang on 3.0.0-12 (Ubuntu 11.10 release)

[Yong Zhang]

On Fri, Oct 28, 2011 at 01:56:39PM +0100, Chris Wilson wrote:
> On Fri, 28 Oct 2011 20:22:35 +0800, Yong Zhang  wrote:
> > Hi,
> > 
> > Just got below error on Ubuntu-11.10 (kernel: 3.0.0-12-generic),
> > and after that my screen can't show normally.
> > No sure if it's a known issue.
> 
> No, that is the first time I've seen that. It looks as if the fence was
> not released, or reacquired, before the the batch was executed. (There
> is a later batch that also uses this buffer.)
> 
> The fence is programmed with:
>   fence[15] = 04e1
> valid, x-tiled, pitch: 512, start: 0x04e0, size: 1048576
> 
> And the BLT command uses:
>   0x0df006b0:  0x5434: XY_COLOR_BLT (rgb enabled, alpha enabled, dst 
> tile 
> 0)
>   0x0df006b4:  0x03f00100:format , pitch 256, clipping disabled
>   0x0df006b8:  0x:(0,0)
>   0x0df006bc:  0x00140037:(55,20)
>   0x0df006c0:  0x04e0:offset 0x04e0
>   0x0df006c4:  0x:color
>   0x0df006c8:  0x54f6: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, 
> src tile 0, dst tile 0)
>   0x0df006cc:  0x03cc0100:format , dst pitch 256, clipping 
> disabled
>   0x0df006d0:  0x:dst (0,0)
>   0x0df006d4:  0x00140037:dst (55,20)
>   0x0df006d8:  0x04e0:dst offset 0x04e0
>   0x0df006dc:  0x012c0003:src (3,300)
>   0x0df006e0:  0x0400:src pitch 1024
>   0x0df006e4:  0x0850:src offset 0x0850
> 
> So we try to perform an undefined operation and the GPU hangs. I suspect
> this will be timing dependent, but if you can find a way to reproduce
> it, that would be very useful.

Just got it by accident when I'm browsing web with firefox & chromium,
and the machine has been running for a long time.

No reliable way to reproduce it for now :(

Thanks,
Yong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/radeon/benchmark: signedness bug in radeon_benchmark_move()

[Dan Carpenter]

radeon_benchmark_do_move() returns an int so "time" should be int
too.  Making it unsigned breaks the error handling.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 5cafc90..17e1a9b 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -98,7 +98,7 @@ static void radeon_benchmark_move(struct radeon_device *rdev, 
unsigned size,
struct radeon_bo *sobj = NULL;
uint64_t saddr, daddr;
int r, n;
-   unsigned int time;
+   int time;
 
n = RADEON_BENCHMARK_ITERATIONS;
r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, &sobj);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

[Daniel Vetter]

On Sat, Oct 29, 2011 at 08:52:25AM +0200, Tormod Volden wrote:
> On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter  wrote:
> > On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
> >> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter  
> >> wrote:
> >> ...
> >> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, 
> >> > struct drm_file *file,
> >> ...
> >> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> >> > +               item->req.size = mem->size;
> >> > +               sis_malloc(&item->req);
> >> > +               if (item->req.size == 0)
> >> > +                       retval = -ENOMEN;
> >>
> >> ENOMEN is omen, I guess this was not compile tested with either CONFIG?
> >
> > Oh gosh, this is embarassing ;-) I've indeed fumbled this and forgotten to
> > check that config option. Smashed your patch on top of mine. btw, do you
> > have some actual hw to test this on, or have you just checked out of
> > curiosity?
> 
> I do not have sis hardware, but I am testing this on savage and my
> config happened to have this option set.
> 
> By the way, is there anything in special I can try to (stress-)test
> this? I have tested Quake III demos and multiple parallel GL
> screensaver hacks. On the other hand, is there a possibility this
> might fix some random DMA crashes or lock-ups (I mean the savage
> locking fix here)?

Well, it only changes the exit path, i.e. the changed code only gets
executed when you close a direct rendering client. So if you can restart
openaren (and the Xserver sometimes, too) that would test this code
decently. The locking is imo pretty borked, so don't expect miracles.
Also, I don't change anything of the hw programming, so this won't help
for gpu lockups and similar stuff.

If it works for you, Tested-by for the savage patch highly appreciated.

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36386] Amnesia game crashes on RV570 (r300g)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36386

--- Comment #5 from va...@gmx.de 2011-10-29 02:53:20 PDT ---
> This game has been reported as working, and it's not really clear if this was
> even a driver bug in the first place, so I'm closing this bug.  Please re-open
> it if you are still having problems.

Sorry, I've forgot about this report.
Actually I've nailed down the problem to the s3tc texture compression.

With a Mesa version compiled following the hints this article
http://dri.freedesktop.org/wiki/S3TC 
the game runs fine on my r300 and r600.
But without manually installing libtxc_dxtn and enabling
USE_EXTERNAL_DXTN_LIB=1 in Mesa the games crashes as described above.

I guess the game is to blame for not doing enough extension checks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: do not sleep on vblank while holding a mutex

[Daniel Vetter]

On Fri, Oct 28, 2011 at 09:44:54PM -0500, Ilija Hadzic wrote:
> Now suppose that the drm_wait_vblank is enteret in the context of
> two different PIDs and suppose that there are no locks. Let's say
> that the first process wants to wait on vblank N and the second
> wants to wait on vblank N+1. First process can reach the point just
> before it wants to write to last_vblank_wait and lose the processor
> there (so it has N in vblank.request (on its stack) calculated, but
> it has not written it into last_vblank_wait yet (because it lost the
> CPU right there). Then the second process gets the CPU, and executes
> and let's say that it goes all the way through so it writes N+1 into
> last_vblank_wait and then schedules away (it called DRM_WAIT_ON).
> Now the first process gets the CPU where it left off and overwrites
> N+1 in last_vblank_wait with N, which is now stale.

Ok, and here's why your locking (or any locking that drops the lock before
calling schedule) won't work: Dropping the lock allows more than one
process waiting for a vblank on the same crtc (the hole point of this
exerices). So let's say N processes are waiting for vblank on crtc A, but
we only have one storage place for last_vblank_wait. So by necessity, it's
gonna be stale for N-1 processes. And because the scheduler is free to
take away the cpu between the unlock and the schedule, you can freely pick
for which process it's gonna be the right one, there's zero ordering
guarantees possible.

By throwing in a modeset call that disables vblanks it's pretty easy to
come up with a process that waits for vblank x+1 (when x is the last
vblank before the vblank counter got stopped before the modeset) and
last_vblank_wait == x.

Which is why I think adding decent tracepoints would be much better, but
that's a different patch.

[snip]

Agreed on not locking the debug file and postponing other cleanups, that's
all material for different patches.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: add some comments to drm_wait_vblank and drm_queue_vblank_event

[Daniel Vetter]

On Fri, Oct 28, 2011 at 05:44:23PM -0400, Ilija Hadzic wrote:
> during the review of the fix for locks problems in drm_wait_vblank,
> a couple of false concerns were raised about how the drm_vblank_get
> and drm_vblank_put are used in this function; it turned out that the
> code is correct and that it cannot be simplified
> 
> add a few comments to explain non-obvious flows in the code,
> to prevent "false alarms" in the future
> 
> Signed-off-by: Ilija Hadzic 
> ---
>  drivers/gpu/drm/drm_irq.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8b4da8..e9dd19d 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1065,6 +1065,10 @@ out:
>   return ret;
>  }
>  
> +/* must acquire vblank reference count (call drm_vblank_get) */
> +/* before calling this function; the matching drm_vblank_put */
> +/* will either be issued here or in drm_handle_vblank_events */
> +/* after the vblank is signaled */
>  static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
> union drm_wait_vblank *vblwait,
> struct drm_file *file_priv)
> @@ -1124,6 +1128,9 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, int pipe,
>   trace_drm_vblank_event_delivered(current->pid, pipe,
>vblwait->request.sequence);
>   } else {
> + /* can't call drm_vblank_put here because interrupt */
> + /* must remain enabled until the event occurs */
> + /* drm_handle_vblank_events will do this for us */
>   list_add_tail(&e->base.link, &dev->vblank_event_list);
>   vblwait->reply.sequence = vblwait->request.sequence;
>   }
> @@ -1215,6 +1222,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>  
>   if (flags & _DRM_VBLANK_EVENT) {
>   spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> + /* drm_queue_vblank_event() will call drm_vblank_put() */

I think three comments for this is a bit overkill. Imo one here at the
only callsite of queue_vblank_event saying that it needs to hold onto the
vblank ref untill the event fires and hence will call drm_vblank_put
asynchronously is good enought.

>   return drm_queue_vblank_event(dev, crtc, vblwait, file_priv);
>   }
>  
> -- 
> 1.7.7
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: do not sleep on vblank while holding a mutex

[Ilija Hadzic]

On Sat, 29 Oct 2011, Daniel Vetter wrote:



Ok, and here's why your locking (or any locking that drops the lock before
calling schedule) won't work: [SNIP]



You just came full circle. Recall that in my v1 patch I went all the way 
to enqueuing the process in the wait queue before dropping the lock. That 
would have guaranteed that if there is a hangup, what last_vblank_wait 
says is the last is really the last. If there is no hang, then it doesn't 
matter because last_vlank_wait is constantly overwritten (and is indeed 
stale for N-1 processes). However, that was disliked in the review and I 
didn't want to argue.


So in the interest of making progress, it looks that you would be happy if 
this patch just dropped DRM_UNLOCKED and declared that we don't care about 
(potentially theoretical) critical section related to last_vblank_wait.


If that's the case, I'll cut a relatvely trivial patch that drops 
DRM_UNLOCKED from this system call to solve the problem that I pointed 
earlier in this thread and leave all the rest of the locking discussion 
for other patches.


Would that be fine by you ?

thanks,

Ilija

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40986] xorg-r600: graphical glitches on cursor display

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40986

--- Comment #2 from Kai  2011-10-29 05:42:08 PDT ---
Still there as described in comment #1 with the following stack:
Mesa: Git/09a92e37
libdrm: 2.4.26-1
X.Org: 2:1.11.1.901-2 (1.11.1.901 (1.11.2 RC 1))
KDE: 4:4.6.5-2
GPU: 1002:9553

The X.Org log hasn't changed (except for the reported versions). Let me know,
if you need further information.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()

[Thomas Reim]

Dear Alex, 

but we use DDC probing e. g. to identify connectors with improperly
terminated i2c bus. Instead of flooding logs and terminals with EDID
dumps, we decided some months ago to use this function during module
loading to inform the user once (and only once!), which connector has a
monitor connected with valid EDID and which connector has not. See the
example dmesg log below:

[   14.912386] [drm] Radeon Display Connectors
[   14.912389] [drm] Connector 0:
[   14.912391] [drm]   VGA
[   14.912394] [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48
0x7e5c 0x7e4c
[   14.912397] [drm]   Encoders:
[   14.912398] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   14.912401] [drm] Connector 1:
[   14.912402] [drm]   S-video
[   14.912404] [drm]   Encoders:
[   14.912405] [drm] TV1: INTERNAL_KLDSCP_DAC1
[   14.912407] [drm] Connector 2:
[   14.912409] [drm]   HDMI-A
[   14.912410] [drm]   HPD2
[   14.912413] [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68
0x7e4c 0x7e6c
[   14.912415] [drm]   Encoders:
[   14.912417] [drm] DFP2: INTERNAL_DDI
[   14.912419] [drm] Connector 3:
[   14.912421] [drm]   DVI-D
[   14.912423] [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58
0x7e4c 0x7e5c
[   14.912425] [drm]   Encoders:
[   14.912427] [drm] DFP3: INTERNAL_LVTM1
[   15.071566] HDA Intel :00:14.2: PCI INT A -> GSI 16 (level, low)
-> IRQ 16
[   15.071645] HDA Intel :00:14.2: irq 42 for MSI/MSI-X
[   15.072678] [drm] Radeon display connector VGA-1: No display
connected or invalid EDID
[   15.470734] Raw EDID:
[   15.470745] <3>00 00 00 00 00 00 00 00 00 00 00 07 00 00 00
00  
[   15.470748] <3>00 00 00 00 00 00 00 00 00 00 07 00 00 00 00
00  
[   15.470751] <3>00 00 00 00 00 00 00 00 00 00 7f 00 00 00 00
00  
[   15.470754] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   15.470757] <3>00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00
00  
[   15.470760] <3>00 00 00 00 00 07 00 00 00 00 00 7f 00 00 00
00  
[   15.470762] <3>00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
00  
[   15.470765] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01  
[   15.470767] 
[   15.779568] Raw EDID:
[   15.779578] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   15.779581] <3>00 00 00 00 00 7f 00 00 00 00 03 00 00 00 00
00  
[   15.779584] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   15.779587] <3>00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00
00  
[   15.779590] <3>00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00
00  
[   15.779593] <3>00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
00  
[   15.779596] <3>00 00 00 7f 00 00 00 00 00 03 07 00 00 00 00
00  
[   15.779598] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   15.779600] 
[   16.151817] Raw EDID:
[   16.151827] <3>00 00 00 00 00 00 1f 00 00 00 00 00 00 00 00
00  
[   16.151830] <3>00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
00  
[   16.151833] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   16.151836] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00  
[   16.151839] <3>00 00 1f 00 00 00 00 00 00 00 00 00 00 00 0f
00  
[   16.151842] <3>01 00 00 00 00 00 00 00 01 00 00 00 00 07 00
ff  
[   16.151844] <3>00 00 00 00 00 00 ff 00 00 00 00 00 00 00 7f
00  
[   16.151847] <3>00 0f 00 00 00 00 00 00 00 3f 00 00 00 00 00
00  .?..
[   16.151849] 
[   16.444209] Raw EDID:
[   16.444220] <3>00 07 00 00 00 00 00 00 ff 00 00 00 00 ff 00
00  
[   16.444223] <3>00 00 3f 00 00 00 00 00 00 00 00 00 00 ff 00
00  ..?.
[   16.444226] <3>00 00 00 00 00 00 00 00 00 07 00 00 00 01 0f
00  
[   16.444229] <3>00 07 00 00 00 00 00 00 00 00 01 07 00 00 00
00  
[   16.444231] <3>00 00 00 00 00 00 00 00 7f 00 00 00 00 1f 00
00  
[   16.444234] <3>00 00 03 00 00 00 00 3f 00 03 00 00 00 00 00
00  ...?
[   16.444237] <3>7f 00 00 1f 00 00 00 00 00 00 00 00 0f 07 00
00  
[   16.444240] <3>00 00 00 00 00 00 00 00 00 00 03 00 00 00 00
00  
[   16.444242] 
[   16.444248] radeon :01:05.0: HDMI-A-1: EDID block 0 invalid.
[   16.444252] [drm] Radeon display connector HDMI-A-1: No display
connected or invalid EDID
[   16.762734] [drm] Radeon display connector DVI-D-1: Found valid EDID

Graphic solutions in general have several connectors integrated, and
it's sometimes really difficult to identify, which one of the does not
work as expected, based on the logs. From above log we see, that a
monitor is connected to DVI connector, nothing is connected to the VGA
connector, and we have a problem with the HDMI connector. Without this
fuinction, nothing helpful from radeon 

RFC: Radeon multi ring support branch

[Christian König]

Hello everybody,

to support multiple compute rings, async DMA engines and UVD we need to 
teach the radeon kernel module how to sync buffers between different 
rings and make some changes to the command submission ioctls.


Since we can't release any documentation about async DMA or UVD (yet), 
my current branch concentrates on getting the additional compute rings 
on cayman running. Unfortunately those rings have hardware bugs that 
can't be worked around, so they are actually not very useful in a 
production environment, but they should do quite well for this testing 
purpose.


The branch can be found here: 
http://cgit.freedesktop.org/~deathsimple/linux/log/


Since some of the patches are quite intrusive, constantly rebaseing them 
could get a bit painful. So I would like to see most of the stuff 
included into drm-next, even if we don't make use of the new 
functionality right now.


Comments welcome,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: do not sleep on vblank while holding a mutex

[Daniel Vetter]

On Sat, Oct 29, 2011 at 06:59:42AM -0500, Ilija Hadzic wrote:
> On Sat, 29 Oct 2011, Daniel Vetter wrote:
> >Ok, and here's why your locking (or any locking that drops the lock before
> >calling schedule) won't work: [SNIP]
> 
> You just came full circle. Recall that in my v1 patch I went all the
> way to enqueuing the process in the wait queue before dropping the
> lock. That would have guaranteed that if there is a hangup, what
> last_vblank_wait says is the last is really the last. If there is no
> hang, then it doesn't matter because last_vlank_wait is constantly
> overwritten (and is indeed stale for N-1 processes). However, that
> was disliked in the review and I didn't want to argue.

Not quite full circle. Holding the lock until you're on the waitqueue
doesn't really change anything - we wake up everybody on every vblank
anyway. The thing I was nitpicking over was that vblank_last_wait isn't
really protected on the read side, but as you've pointed out, that's not a
big problem. Essentially the only thing about vblank_last_wait that we can
guarantee is that somewhen somebody tried to wait on this vblank. Nothing
else is possible (and the reason why I think we should ditch this all and
replace it we some decent tracing - material for a differen patch though).

> So in the interest of making progress, it looks that you would be
> happy if this patch just dropped DRM_UNLOCKED and declared that we
> don't care about (potentially theoretical) critical section related
> to last_vblank_wait.
> 
> If that's the case, I'll cut a relatvely trivial patch that drops
> DRM_UNLOCKED from this system call to solve the problem that I
> pointed earlier in this thread and leave all the rest of the locking
> discussion for other patches.
> 
> Would that be fine by you ?

Yeah.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42373] New: Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

 Bug #: 42373
   Summary: Radeon HD 6450 (NI CAICOS) screen corruption on boot
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: kunal.gangakhed...@gmail.com
Depends on: 40935


Created attachment 52891
  --> https://bugs.freedesktop.org/attachment.cgi?id=52891
dmesg log

Bought a new Radeon HD 6450 for the new desktop I was building using PhenomII
X6 1075T.

Installed Kubuntu Oneiric (11.10) amd64.
As soon as any FB client (e.g. plymouth splash screen) starts accessing the
card after switching to KMS, the screen image gets totally corrupted.

Even Xorg/KDM fail to show anything useful.
I can only reset the machine using the power button soft-off.
Three-finger-salute also doesn't work.

However, it does work in about 1 out of 10 times - if somehow the apps trying
to use FB device can be killed while the radeon driver is trying to work on the
chip.

If KMS is disabled, the machine boots up, but Xorg fails to start saying "KMS
is needed for CAICOS".

The screenshots are available at:
a. KMS with plymouth splash:
http://img1.UploadScreenshot.com/images/main/10/30100130871.jpg
b. KMS without plymouth splash (shows init msgs with bluish tinge in the
background): http://img1.UploadScreenshot.com/images/main/10/30100182712.jpg
c. KMS + Xorg lockup:
http://img1.UploadScreenshot.com/images/main/10/30100211337.jpg
d. KMS + Xorg successful start:
http://img1.UploadScreenshot.com/images/main/10/30100232928.jpg

I believe this is the same as bug #40935 - however, I haven't been able to boot
into the system to test suspend/resume yet.

Finally, I used an old nVidia GeForce 7100 GS  on the same system that I had
lying around as a workaround.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 40935] radeon lockup on resume

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=40935

Kunal  changed:

   What|Removed |Added

 Blocks||42373

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #1 from Kunal  2011-10-29 09:05:02 
PDT ---
Created attachment 52892
  --> https://bugs.freedesktop.org/attachment.cgi?id=52892
lspci -vvnn output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #2 from Kunal  2011-10-29 09:05:45 
PDT ---
Created attachment 52893
  --> https://bugs.freedesktop.org/attachment.cgi?id=52893
Xorg.log when it booted up fine

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.27

[Eric Anholt]

Ben Widawsky (1):
  intel: shared header for shader debugging

Chih-Wei Huang (1):
  Specify the return type explicitly.

Daniel Vetter (2):
  drm/intel: don't clobber bufmgr->pci_device
  drm/i915: y tiling on i915G/i915GM is different

Dave Airlie (3):
  drm/test: handle usub being empty
  drmtest: make check should fail so hard on unable to open device
  nouveau: free in error path if drmAvailable fails.

Eric Anholt (6):
  intel: Use stdbool.h for dealing with boolean values.
  intel: Add an interface for removing relocs after they're added.
  intel: Remove stale comment.
  intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done.
  intel: Share the implementation of BO unmap between CPU and GTT mappings.
  configure: version bump for 2.4.27 release.

Jakob Bornecrantz (5):
  tests: Add vmwgfx driver to probed drivers in tests
  vbltest: Check error codes returned from libdrm
  modetest: Check error message from pageflip ioctl
  modetest: Print extra info if we fail to create a framebuffer
  modetest: Call dirty fb on modeset

Jesse Barnes (1):
  modetest: use 24 bit depth on the framebuffer

Marcin Slusarz (2):
  drm mode: fix drmIoctl wrapper
  nouveau: assert argument cannot have side effects

Matt Turner (1):
  modeprint.c: use PRIu64 for printing uint64_t

Tapani Pälli (1):
  xf86drm.h : wrap C code for C++ compilation/linking

Yuanhan Liu (1):
  intel: fix the wrong method check for bo_get_subdata

git tag: 2.4.27

http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.bz2
MD5:  0fba4f42735cd3d24dd7a8cde0023fbd  libdrm-2.4.27.tar.bz2
SHA1: f5b40d30a7f2bfa369ab9b3bd9a0aa844a7f1e16  libdrm-2.4.27.tar.bz2
SHA256: ea6b04dd3298e36c7a43aadd5f80f48baeafe4caaabcf78b01dc919c5c757973  
libdrm-2.4.27.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.gz
MD5:  235dd2e75d0286a91019cd3aec1b4b47  libdrm-2.4.27.tar.gz
SHA1: 2dd6005e2a7e2f186d7b5780fc5e0143d18f90e7  libdrm-2.4.27.tar.gz
SHA256: 9f11d369925222c013773ad7ec0812feb4f5388e70a8ef0f729251f956acd7bf  
libdrm-2.4.27.tar.gz


pgpSCzf05bTBM.pgp
Description: PGP signature
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Eugeni Dodonov]

On Fri, Oct 28, 2011 at 15:56, Keith Packard  wrote:

> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard 
> Cc: Ben Widawsky 
>

Reviewed-By: Eugeni Dodonov 

We have no need for the workaround when we don't have IOMMU.

-- 
Eugeni Dodonov

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

[Tormod Volden]

On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter  
wrote:
...
> @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, struct 
> drm_file *file,
...
> +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> + ? ? ? ? ? ? ? item->req.size = mem->size;
> + ? ? ? ? ? ? ? sis_malloc(&item->req);
> + ? ? ? ? ? ? ? if (item->req.size == 0)
> + ? ? ? ? ? ? ? ? ? ? ? retval = -ENOMEN;

ENOMEN is omen, I guess this was not compile tested with either CONFIG?

Cheers,
Tormod

[PATCH] drm/sis: Fix building with CONFIG_FB_SIS/CONFIG_FB_SIS_MODULE

[Tormod Volden]

From: Tormod Volden 

---

On top of danvet's kill-with-fire ad83cc3.

Tormod

 drivers/gpu/drm/sis/sis_mm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 112a43b..63c2f75 100644
--- a/drivers/gpu/drm/sis/sis_mm.c
+++ b/drivers/gpu/drm/sis/sis_mm.c
@@ -116,7 +116,7 @@ static int sis_drm_alloc(struct drm_device *dev, struct 
drm_file *file,
item->req.size = mem->size;
sis_malloc(&item->req);
if (item->req.size == 0)
-   retval = -ENOMEN;
+   retval = -ENOMEM;
offset = item->req.offset;
 #else
retval = drm_mm_insert_node(&dev_priv->vram_mm,
@@ -343,7 +343,7 @@ void sis_reclaim_buffers_locked(struct drm_device *dev,
drm_mm_remove_node(&entry->mm_node);
 #if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
else
-   sis_free(entry->req->offset);
+   sis_free(entry->req.offset);
 #endif
kfree(entry);
}
-- 
1.7.5.4

[PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

[Daniel Vetter]

On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter  
> wrote:
> ...
> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, 
> > struct drm_file *file,
> ...
> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> > + ? ? ? ? ? ? ? item->req.size = mem->size;
> > + ? ? ? ? ? ? ? sis_malloc(&item->req);
> > + ? ? ? ? ? ? ? if (item->req.size == 0)
> > + ? ? ? ? ? ? ? ? ? ? ? retval = -ENOMEN;
> 
> ENOMEN is omen, I guess this was not compile tested with either CONFIG?

Oh gosh, this is embarassing ;-) I've indeed fumbled this and forgotten to
check that config option. Smashed your patch on top of mine. btw, do you
have some actual hw to test this on, or have you just checked out of
curiosity?

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH v2] drm: do not sleep on vblank while holding a mutex

[Daniel Vetter]

On Fri, Oct 28, 2011 at 05:42:23PM -0400, Ilija Hadzic wrote:
> drm_wait_vblank must be DRM_UNLOCKED because otherwise it
> will grab the drm_global_mutex and then go to sleep until the vblank
> event it is waiting for. That can wreck havoc in the windowing system
> because if one process issues this ioctl, it will block all other
> processes for the duration of all vblanks between the current and the
> one it is waiting for. In some cases it can block the entire windowing
> system. So, make this ioctl DRM_UNLOCKED, wrap the remaining
> (very short) critical section with dev->vbl_lock spinlock, and
> add a comment to the code explaining what we are protecting with
> the lock.
> 
> v2: incorporate comments received from Daniel Vetter and
> Michel Daenzer.
> 
> Signed-off-by: Ilija Hadzic 
> ---
>  drivers/gpu/drm/drm_drv.c |2 +-
>  drivers/gpu/drm/drm_irq.c |   14 +-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index e159f17..c990dab 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -124,7 +124,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
>   DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_sg_alloc_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_sg_free, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>  
> - DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, 0),
> + DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, DRM_UNLOCKED),
>  
>   DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0),
>  
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3830e9e..c8b4da8 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1160,6 +1160,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   union drm_wait_vblank *vblwait = data;
>   int ret = 0;
>   unsigned int flags, seq, crtc, high_crtc;
> + unsigned long irqflags;
>  
>   if ((!drm_dev_to_irq(dev)) || (!dev->irq_enabled))
>   return -EINVAL;
> @@ -1193,6 +1194,13 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   }
>   seq = drm_vblank_count(dev, crtc);
>  
> + /* the lock protects this section from itself executed in */
> + /* the context of another PID, ensuring that the process that */
> + /* wrote dev->last_vblank_wait is really the last process */
> + /* that was here; processes waiting on different CRTCs */
> + /* do not need to be interlocked, but rather than introducing */
> + /* a new per-crtc lock, we reuse vbl_lock for simplicity */

Multiline comments are done with one pair of /* */, see CodingStyle

> + spin_lock_irqsave(&dev->vbl_lock, irqflags);
>   switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) {
>   case _DRM_VBLANK_RELATIVE:
>   vblwait->request.sequence += seq;
> @@ -1200,12 +1208,15 @@ int drm_wait_vblank(struct drm_device *dev, void 
> *data,
>   case _DRM_VBLANK_ABSOLUTE:
>   break;
>   default:
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
>   ret = -EINVAL;
>   goto done;
>   }
>  
> - if (flags & _DRM_VBLANK_EVENT)
> + if (flags & _DRM_VBLANK_EVENT) {
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
>   return drm_queue_vblank_event(dev, crtc, vblwait, file_priv);
> + }
>  
>   if ((flags & _DRM_VBLANK_NEXTONMISS) &&
>   (seq - vblwait->request.sequence) <= (1<<23)) {
> @@ -1215,6 +1226,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>   DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> vblwait->request.sequence, crtc);
>   dev->last_vblank_wait[crtc] = vblwait->request.sequence;
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);

Imo the only thing we need to protect here is dev->last_vblank_wait
against concurrent access from drm_vblank_info in drm_info.c

But the locking there is horribly broken: It grabs dev->struct_mutex, but
that protects exactly nothing, afaics:
- dev->vblank_refcount is an atomic
- vblank_count is protected by a the handrolled seqlock in
  drm_vblank_count
- dev->last_vblank_wait was protected by the global lock, but is now
  protected by the dev->vbl_spinlock on the write side
- dev->vblank_inmodeset is protected by the global lock for ums setups
  (locked ioctl) and by dev->mode_config.mutex for kms

And I just don't see anything else you might protect here - vblwait is
just the ioctl data copied in by the drm core ioctl helpers.

So I don't quite see what you protect here with that spinlock. Imo
- either make dev->last_vblank_wait into an atomic_t
- or just don't care about it, locking of vblank_info is already horribly
  broken.
In both cases you don't need the dev->vbl_lock spinlock.

I personally vote for no additional locking at all here and just drop the
global lock. Or maybe I'm blind 

[Bug 36386] Amnesia game crashes on RV570 (r300g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36386

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #4 from Tom Stellard  2011-10-28 17:59:46 
PDT ---
This game has been reported as working, and it's not really clear if this was
even a driver bug in the first place, so I'm closing this bug.  Please re-open
it if you are still having problems.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2] drm: make DRM_UNLOCKED ioctls with their own mutex

[Daniel Vetter]

On Fri, Oct 28, 2011 at 05:43:28PM -0400, Ilija Hadzic wrote:
> drm_getclient, drm_getstats and drm_getmap (with a few minor
> adjustments) do not need global mutex, so fix that and
> make the said ioctls DRM_UNLOCKED. Details:
> 
>   drm_getclient: the only thing that should be protected here
>   is dev->filelist and that is already protected everywhere with
>   dev->struct_mutex.
> 
>   drm_getstats: there is no need for any mutex here because the
>   loop runs through quasi-static (set at load time only)
>   data, and the actual count access is done with atomic_read()
> 
>   drm_getmap already uses dev->struct_mutex to protect
>   dev->maplist, which also used to protect the same structure
>   everywhere else except at three places:
>   * drm_getsarea, which doesn't grab *any* mutex before
> touching dev->maplist (so no drm_global_mutex doesn't help
> here either; different issue for a different patch).
> However, drivers seem to call it only at
> initialization time so it probably doesn't matter
>   * drm_master_destroy, which is called from drm_master_put,
> which in turn is protected with dev->struct_mutex
> everywhere else in drm module, so we are good here too.
>   * drm_getsareactx, which releases the dev->struct_mutex
> too early, but this patch includes the fix for that.
> 
> v2: * incorporate comments received from Daniel Vetter
> * include the (long) explanation above to make it clear what
>   we are doing (and why), also at Daniel Vetter's request
> * tighten up mutex grab/release locations to only
>   encompass real critical sections, rather than some
>   random code around them
> 
> Signed-off-by: Ilija Hadzic 

Quite a load of stuff to check for this, i.e. next time around maybe split
it up into one patch for each of the three functions changed (and move the
locking bugfix in drm_getsareactx into its own patch).

Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 29951] [r300g] xscreensaver hack "antspotlight" reveals something other than desktop

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29951

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #19 from Tom Stellard  2011-10-28 18:29:56 
PDT ---
This appears to be an issue with xscreensaver and not a driver bug.  I
recommend notifying the xscreensaver developers.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41569] [r600 KMS] Asus A53T A4-3400

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41569

Robert Nelson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Robert Nelson  2011-10-28 
22:41:01 PDT ---
Awesome! Thanks Alex.

KMS is now works perfectly on this laptop..

Using v3.1.0 + airlied's drm-next pull for (3.2)

Patch 2 was missing another change you had posted, so it didn't apply:
http://people.freedesktop.org/~agd5f/0009-drm-radeon-kms-rework-DP-bridge-checks.patch

and that patch missed one of the function conversions, so i'm posting a
git-format patch dump of the 4 patches I used here:

http://rcn-ee.homeip.net:81/testing/asus-a53t/a4-kms/

Thanks,

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

[Tormod Volden]

On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter  wrote:
> On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
>> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter  
>> wrote:
>> ...
>> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, 
>> > struct drm_file *file,
>> ...
>> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
>> > + ? ? ? ? ? ? ? item->req.size = mem->size;
>> > + ? ? ? ? ? ? ? sis_malloc(&item->req);
>> > + ? ? ? ? ? ? ? if (item->req.size == 0)
>> > + ? ? ? ? ? ? ? ? ? ? ? retval = -ENOMEN;
>>
>> ENOMEN is omen, I guess this was not compile tested with either CONFIG?
>
> Oh gosh, this is embarassing ;-) I've indeed fumbled this and forgotten to
> check that config option. Smashed your patch on top of mine. btw, do you
> have some actual hw to test this on, or have you just checked out of
> curiosity?

I do not have sis hardware, but I am testing this on savage and my
config happened to have this option set.

By the way, is there anything in special I can try to (stress-)test
this? I have tested Quake III demos and multiple parallel GL
screensaver hacks. On the other hand, is there a possibility this
might fix some random DMA crashes or lock-ups (I mean the savage
locking fix here)?

Thanks,
Tormod



> Thanks, Daniel
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
>

[patch] drm/radeon/benchmark: signedness bug in radeon_benchmark_move()

[Dan Carpenter]

radeon_benchmark_do_move() returns an int so "time" should be int
too.  Making it unsigned breaks the error handling.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c 
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 5cafc90..17e1a9b 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -98,7 +98,7 @@ static void radeon_benchmark_move(struct radeon_device *rdev, 
unsigned size,
struct radeon_bo *sobj = NULL;
uint64_t saddr, daddr;
int r, n;
-   unsigned int time;
+   int time;

n = RADEON_BENCHMARK_ITERATIONS;
r = radeon_bo_create(rdev, size, PAGE_SIZE, true, sdomain, &sobj);

[PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

[Daniel Vetter]

On Sat, Oct 29, 2011 at 08:52:25AM +0200, Tormod Volden wrote:
> On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter  wrote:
> > On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
> >> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter  
> >> wrote:
> >> ...
> >> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, 
> >> > struct drm_file *file,
> >> ...
> >> > +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> >> > + ? ? ? ? ? ? ? item->req.size = mem->size;
> >> > + ? ? ? ? ? ? ? sis_malloc(&item->req);
> >> > + ? ? ? ? ? ? ? if (item->req.size == 0)
> >> > + ? ? ? ? ? ? ? ? ? ? ? retval = -ENOMEN;
> >>
> >> ENOMEN is omen, I guess this was not compile tested with either CONFIG?
> >
> > Oh gosh, this is embarassing ;-) I've indeed fumbled this and forgotten to
> > check that config option. Smashed your patch on top of mine. btw, do you
> > have some actual hw to test this on, or have you just checked out of
> > curiosity?
> 
> I do not have sis hardware, but I am testing this on savage and my
> config happened to have this option set.
> 
> By the way, is there anything in special I can try to (stress-)test
> this? I have tested Quake III demos and multiple parallel GL
> screensaver hacks. On the other hand, is there a possibility this
> might fix some random DMA crashes or lock-ups (I mean the savage
> locking fix here)?

Well, it only changes the exit path, i.e. the changed code only gets
executed when you close a direct rendering client. So if you can restart
openaren (and the Xserver sometimes, too) that would test this code
decently. The locking is imo pretty borked, so don't expect miracles.
Also, I don't change anything of the hw programming, so this won't help
for gpu lockups and similar stuff.

If it works for you, Tested-by for the savage patch highly appreciated.

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 36386] Amnesia game crashes on RV570 (r300g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36386

--- Comment #5 from vand2 at gmx.de 2011-10-29 02:53:20 PDT ---
> This game has been reported as working, and it's not really clear if this was
> even a driver bug in the first place, so I'm closing this bug.  Please re-open
> it if you are still having problems.

Sorry, I've forgot about this report.
Actually I've nailed down the problem to the s3tc texture compression.

With a Mesa version compiled following the hints this article
http://dri.freedesktop.org/wiki/S3TC 
the game runs fine on my r300 and r600.
But without manually installing libtxc_dxtn and enabling
USE_EXTERNAL_DXTN_LIB=1 in Mesa the games crashes as described above.

I guess the game is to blame for not doing enough extension checks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v2] drm: do not sleep on vblank while holding a mutex

[Daniel Vetter]

On Fri, Oct 28, 2011 at 09:44:54PM -0500, Ilija Hadzic wrote:
> Now suppose that the drm_wait_vblank is enteret in the context of
> two different PIDs and suppose that there are no locks. Let's say
> that the first process wants to wait on vblank N and the second
> wants to wait on vblank N+1. First process can reach the point just
> before it wants to write to last_vblank_wait and lose the processor
> there (so it has N in vblank.request (on its stack) calculated, but
> it has not written it into last_vblank_wait yet (because it lost the
> CPU right there). Then the second process gets the CPU, and executes
> and let's say that it goes all the way through so it writes N+1 into
> last_vblank_wait and then schedules away (it called DRM_WAIT_ON).
> Now the first process gets the CPU where it left off and overwrites
> N+1 in last_vblank_wait with N, which is now stale.

Ok, and here's why your locking (or any locking that drops the lock before
calling schedule) won't work: Dropping the lock allows more than one
process waiting for a vblank on the same crtc (the hole point of this
exerices). So let's say N processes are waiting for vblank on crtc A, but
we only have one storage place for last_vblank_wait. So by necessity, it's
gonna be stale for N-1 processes. And because the scheduler is free to
take away the cpu between the unlock and the schedule, you can freely pick
for which process it's gonna be the right one, there's zero ordering
guarantees possible.

By throwing in a modeset call that disables vblanks it's pretty easy to
come up with a process that waits for vblank x+1 (when x is the last
vblank before the vblank counter got stopped before the modeset) and
last_vblank_wait == x.

Which is why I think adding decent tracepoints would be much better, but
that's a different patch.

[snip]

Agreed on not locking the debug file and postponing other cleanups, that's
all material for different patches.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: add some comments to drm_wait_vblank and drm_queue_vblank_event

[Daniel Vetter]

On Fri, Oct 28, 2011 at 05:44:23PM -0400, Ilija Hadzic wrote:
> during the review of the fix for locks problems in drm_wait_vblank,
> a couple of false concerns were raised about how the drm_vblank_get
> and drm_vblank_put are used in this function; it turned out that the
> code is correct and that it cannot be simplified
> 
> add a few comments to explain non-obvious flows in the code,
> to prevent "false alarms" in the future
> 
> Signed-off-by: Ilija Hadzic 
> ---
>  drivers/gpu/drm/drm_irq.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8b4da8..e9dd19d 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1065,6 +1065,10 @@ out:
>   return ret;
>  }
>  
> +/* must acquire vblank reference count (call drm_vblank_get) */
> +/* before calling this function; the matching drm_vblank_put */
> +/* will either be issued here or in drm_handle_vblank_events */
> +/* after the vblank is signaled */
>  static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
> union drm_wait_vblank *vblwait,
> struct drm_file *file_priv)
> @@ -1124,6 +1128,9 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, int pipe,
>   trace_drm_vblank_event_delivered(current->pid, pipe,
>vblwait->request.sequence);
>   } else {
> + /* can't call drm_vblank_put here because interrupt */
> + /* must remain enabled until the event occurs */
> + /* drm_handle_vblank_events will do this for us */
>   list_add_tail(&e->base.link, &dev->vblank_event_list);
>   vblwait->reply.sequence = vblwait->request.sequence;
>   }
> @@ -1215,6 +1222,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>  
>   if (flags & _DRM_VBLANK_EVENT) {
>   spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> + /* drm_queue_vblank_event() will call drm_vblank_put() */

I think three comments for this is a bit overkill. Imo one here at the
only callsite of queue_vblank_event saying that it needs to hold onto the
vblank ref untill the event fires and hence will call drm_vblank_put
asynchronously is good enought.

>   return drm_queue_vblank_event(dev, crtc, vblwait, file_priv);
>   }
>  
> -- 
> 1.7.7
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH v2] drm: do not sleep on vblank while holding a mutex

[Ilija Hadzic]

On Sat, 29 Oct 2011, Daniel Vetter wrote:

>
> Ok, and here's why your locking (or any locking that drops the lock before
> calling schedule) won't work: [SNIP]
>

You just came full circle. Recall that in my v1 patch I went all the way 
to enqueuing the process in the wait queue before dropping the lock. That 
would have guaranteed that if there is a hangup, what last_vblank_wait 
says is the last is really the last. If there is no hang, then it doesn't 
matter because last_vlank_wait is constantly overwritten (and is indeed 
stale for N-1 processes). However, that was disliked in the review and I 
didn't want to argue.

So in the interest of making progress, it looks that you would be happy if 
this patch just dropped DRM_UNLOCKED and declared that we don't care about 
(potentially theoretical) critical section related to last_vblank_wait.

If that's the case, I'll cut a relatvely trivial patch that drops 
DRM_UNLOCKED from this system call to solve the problem that I pointed 
earlier in this thread and leave all the rest of the locking discussion 
for other patches.

Would that be fine by you ?

thanks,

Ilija

[Bug 40986] xorg-r600: graphical glitches on cursor display

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40986

--- Comment #2 from Kai  2011-10-29 05:42:08 PDT 
---
Still there as described in comment #1 with the following stack:
Mesa: Git/09a92e37
libdrm: 2.4.26-1
X.Org: 2:1.11.1.901-2 (1.11.1.901 (1.11.2 RC 1))
KDE: 4:4.6.5-2
GPU: 1002:9553

The X.Org log hasn't changed (except for the reported versions). Let me know,
if you need further information.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()

[Thomas Reim]

ove log we see, that a
monitor is connected to DVI connector, nothing is connected to the VGA
connector, and we have a problem with the HDMI connector. Without this
fuinction, nothing helpful from radeon module would be in the logs.

Maybe we can keep this function, but call it only for connectors, for
which it works, i. e. not for DP, eDP and DP bridge connectors.

Best regards

Thomas Reim

Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeucher at gmail.com:

> From: Alex Deucher 
> 
> The function didn't work with DP, eDP, or DP bridge
> connectors and thus confused users as it lead them to
> believe nothing was connected or the EDID was invalid
> when in fact is was, just on the aux bus rather an i2c.
> 
> It should also speed up module loading as it avoids a
> bunch of extra DDC probing.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/radeon_display.c |   33 
> ---
>  1 files changed, 0 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 6adb3e5..4998736 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -33,8 +33,6 @@
>  #include "drm_crtc_helper.h"
>  #include "drm_edid.h"
>  
> -static int radeon_ddc_dump(struct drm_connector *connector);
> -
>  static void avivo_crtc_load_lut(struct drm_crtc *crtc)
>  {
>   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device 
> *dev)
>  static bool radeon_setup_enc_conn(struct drm_device *dev)
>  {
>   struct radeon_device *rdev = dev->dev_private;
> - struct drm_connector *drm_connector;
>   bool ret = false;
>  
>   if (rdev->bios) {
> @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
>   if (ret) {
>   radeon_setup_encoder_clones(dev);
>   radeon_print_display_setup(dev);
> - list_for_each_entry(drm_connector, 
> &dev->mode_config.connector_list, head)
> - radeon_ddc_dump(drm_connector);
>   }
>  
>   return ret;
> @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector 
> *radeon_connector)
>   return 0;
>  }
>  
> -static int radeon_ddc_dump(struct drm_connector *connector)
> -{
> - struct edid *edid;
> - struct radeon_connector *radeon_connector = 
> to_radeon_connector(connector);
> - int ret = 0;
> -
> - /* on hw with routers, select right port */
> - if (radeon_connector->router.ddc_valid)
> - radeon_router_select_ddc_port(radeon_connector);
> -
> - if (!radeon_connector->ddc_bus)
> - return -1;
> - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
> - /* Log EDID retrieval status here. In particular with regard to
> -  * connectors with requires_extended_probe flag set, that will prevent
> -  * function radeon_dvi_detect() to fetch EDID on this connector,
> -  * as long as there is no valid EDID header found */
> - if (edid) {
> - DRM_INFO("Radeon display connector %s: Found valid EDID",
> - drm_get_connector_name(connector));
> - kfree(edid);
> - } else {
> - DRM_INFO("Radeon display connector %s: No monitor connected or 
> invalid EDID",
> - drm_get_connector_name(connector));
> - }
> - return ret;
> -}
> -
>  /* avivo */
>  static void avivo_get_fb_div(struct radeon_pll *pll,
>u32 target_clock,


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111029/d1ca810c/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111029/d1ca810c/attachment.pgp>

RFC: Radeon multi ring support branch

[Christian König]

Hello everybody,

to support multiple compute rings, async DMA engines and UVD we need to 
teach the radeon kernel module how to sync buffers between different 
rings and make some changes to the command submission ioctls.

Since we can't release any documentation about async DMA or UVD (yet), 
my current branch concentrates on getting the additional compute rings 
on cayman running. Unfortunately those rings have hardware bugs that 
can't be worked around, so they are actually not very useful in a 
production environment, but they should do quite well for this testing 
purpose.

The branch can be found here: 
http://cgit.freedesktop.org/~deathsimple/linux/log/

Since some of the patches are quite intrusive, constantly rebaseing them 
could get a bit painful. So I would like to see most of the stuff 
included into drm-next, even if we don't make use of the new 
functionality right now.

Comments welcome,
Christian.

[PATCH v2] drm: do not sleep on vblank while holding a mutex

[Daniel Vetter]

On Sat, Oct 29, 2011 at 06:59:42AM -0500, Ilija Hadzic wrote:
> On Sat, 29 Oct 2011, Daniel Vetter wrote:
> >Ok, and here's why your locking (or any locking that drops the lock before
> >calling schedule) won't work: [SNIP]
> 
> You just came full circle. Recall that in my v1 patch I went all the
> way to enqueuing the process in the wait queue before dropping the
> lock. That would have guaranteed that if there is a hangup, what
> last_vblank_wait says is the last is really the last. If there is no
> hang, then it doesn't matter because last_vlank_wait is constantly
> overwritten (and is indeed stale for N-1 processes). However, that
> was disliked in the review and I didn't want to argue.

Not quite full circle. Holding the lock until you're on the waitqueue
doesn't really change anything - we wake up everybody on every vblank
anyway. The thing I was nitpicking over was that vblank_last_wait isn't
really protected on the read side, but as you've pointed out, that's not a
big problem. Essentially the only thing about vblank_last_wait that we can
guarantee is that somewhen somebody tried to wait on this vblank. Nothing
else is possible (and the reason why I think we should ditch this all and
replace it we some decent tracing - material for a differen patch though).

> So in the interest of making progress, it looks that you would be
> happy if this patch just dropped DRM_UNLOCKED and declared that we
> don't care about (potentially theoretical) critical section related
> to last_vblank_wait.
> 
> If that's the case, I'll cut a relatvely trivial patch that drops
> DRM_UNLOCKED from this system call to solve the problem that I
> pointed earlier in this thread and leave all the rest of the locking
> discussion for other patches.
> 
> Would that be fine by you ?

Yeah.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 42373] New: Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

 Bug #: 42373
   Summary: Radeon HD 6450 (NI CAICOS) screen corruption on boot
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: kunal.gangakhedkar at gmail.com
Depends on: 40935


Created attachment 52891
  --> https://bugs.freedesktop.org/attachment.cgi?id=52891
dmesg log

Bought a new Radeon HD 6450 for the new desktop I was building using PhenomII
X6 1075T.

Installed Kubuntu Oneiric (11.10) amd64.
As soon as any FB client (e.g. plymouth splash screen) starts accessing the
card after switching to KMS, the screen image gets totally corrupted.

Even Xorg/KDM fail to show anything useful.
I can only reset the machine using the power button soft-off.
Three-finger-salute also doesn't work.

However, it does work in about 1 out of 10 times - if somehow the apps trying
to use FB device can be killed while the radeon driver is trying to work on the
chip.

If KMS is disabled, the machine boots up, but Xorg fails to start saying "KMS
is needed for CAICOS".

The screenshots are available at:
a. KMS with plymouth splash:
http://img1.UploadScreenshot.com/images/main/10/30100130871.jpg
b. KMS without plymouth splash (shows init msgs with bluish tinge in the
background): http://img1.UploadScreenshot.com/images/main/10/30100182712.jpg
c. KMS + Xorg lockup:
http://img1.UploadScreenshot.com/images/main/10/30100211337.jpg
d. KMS + Xorg successful start:
http://img1.UploadScreenshot.com/images/main/10/30100232928.jpg

I believe this is the same as bug #40935 - however, I haven't been able to boot
into the system to test suspend/resume yet.

Finally, I used an old nVidia GeForce 7100 GS  on the same system that I had
lying around as a workaround.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 40935] radeon lockup on resume

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40935

Kunal  changed:

   What|Removed |Added

 Blocks||42373

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #1 from Kunal  2011-10-29 09:05:02 
PDT ---
Created attachment 52892
  --> https://bugs.freedesktop.org/attachment.cgi?id=52892
lspci -vvnn output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #2 from Kunal  2011-10-29 09:05:45 
PDT ---
Created attachment 52893
  --> https://bugs.freedesktop.org/attachment.cgi?id=52893
Xorg.log when it booted up fine

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[ANNOUNCE] libdrm 2.4.27

[Eric Anholt]

Ben Widawsky (1):
  intel: shared header for shader debugging

Chih-Wei Huang (1):
  Specify the return type explicitly.

Daniel Vetter (2):
  drm/intel: don't clobber bufmgr->pci_device
  drm/i915: y tiling on i915G/i915GM is different

Dave Airlie (3):
  drm/test: handle usub being empty
  drmtest: make check should fail so hard on unable to open device
  nouveau: free in error path if drmAvailable fails.

Eric Anholt (6):
  intel: Use stdbool.h for dealing with boolean values.
  intel: Add an interface for removing relocs after they're added.
  intel: Remove stale comment.
  intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done.
  intel: Share the implementation of BO unmap between CPU and GTT mappings.
  configure: version bump for 2.4.27 release.

Jakob Bornecrantz (5):
  tests: Add vmwgfx driver to probed drivers in tests
  vbltest: Check error codes returned from libdrm
  modetest: Check error message from pageflip ioctl
  modetest: Print extra info if we fail to create a framebuffer
  modetest: Call dirty fb on modeset

Jesse Barnes (1):
  modetest: use 24 bit depth on the framebuffer

Marcin Slusarz (2):
  drm mode: fix drmIoctl wrapper
  nouveau: assert argument cannot have side effects

Matt Turner (1):
  modeprint.c: use PRIu64 for printing uint64_t

Tapani P?lli (1):
  xf86drm.h : wrap C code for C++ compilation/linking

Yuanhan Liu (1):
  intel: fix the wrong method check for bo_get_subdata

git tag: 2.4.27

http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.bz2
MD5:  0fba4f42735cd3d24dd7a8cde0023fbd  libdrm-2.4.27.tar.bz2
SHA1: f5b40d30a7f2bfa369ab9b3bd9a0aa844a7f1e16  libdrm-2.4.27.tar.bz2
SHA256: ea6b04dd3298e36c7a43aadd5f80f48baeafe4caaabcf78b01dc919c5c757973  
libdrm-2.4.27.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.gz
MD5:  235dd2e75d0286a91019cd3aec1b4b47  libdrm-2.4.27.tar.gz
SHA1: 2dd6005e2a7e2f186d7b5780fc5e0143d18f90e7  libdrm-2.4.27.tar.gz
SHA256: 9f11d369925222c013773ad7ec0812feb4f5388e70a8ef0f729251f956acd7bf  
libdrm-2.4.27.tar.gz
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111029/bc2e4dd3/attachment.pgp>
-- next part --
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
-- next part --
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Intel-gfx] [PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

[Eugeni Dodonov]

On Fri, Oct 28, 2011 at 15:56, Keith Packard  wrote:

> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard 
> Cc: Ben Widawsky 
>

Reviewed-By: Eugeni Dodonov 

We have no need for the workaround when we don't have IOMMU.

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111029/82908743/attachment.html>