[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #16 from Serkan Hosca  ---
Created attachment 68531
  --> https://bugs.freedesktop.org/attachment.cgi?id=68531=edit
dmesg with alex's drm-next-3.7 branch with patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/a7b37f5c/attachment.html>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #15 from Serkan Hosca  ---
I've tried the patch on git://people.freedesktop.org/~agd5f/linux drm-nex-3.7
branch and it doesn't work. The gdm sets the blue background image and freezes,
no top bar or login dialog. I ssh from another computer and dmesg is clean at
this point. I try to stop gdm and it displays some garbage, mostly black screen
with some vertical purple bars about 4 cm thick and about 2 cm from the top of
the screen, then it displays the gpu crash messages on log and then the console
comes back.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/7ea7c4b8/attachment.html>

[Bug 55919] fatal error: nouveau/nouveau_device.h: No such file or directory

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55919

--- Comment #4 from Tomasz P.  ---
Do you have only problems with version 7.11 ? Have you tried 9.0 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/6711154a/attachment.html>

[Bug 55913] Vdpau driver lag

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55913

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Andy Furniss  ---
Xv is a bit faster for me, but software decode + -vo vdpau can give a better
vsync than Xv in some circumstances.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/c18473cb/attachment.html>

[Bug 55951] New: [regression] Torchlight segfault at start with Mesa 9.0/git

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55951

  Priority: medium
Bug ID: 55951
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [regression] Torchlight segfault at start with Mesa
9.0/git
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: sa at whiz.se
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 68521
  --> https://bugs.freedesktop.org/attachment.cgi?id=68521=edit
backtrace

The latest build of the game Torchlight segfaults on start with Mesa 9.0 or git
master. The crash happens in  BlitNtoNCopyAlpha () in SDL2, but only if the
game is set to launch full-screen.

Bisecting finds this commit:

0671400dcc72553b5f9719639e86069a1734dbe5 is the first bad commit
commit 0671400dcc72553b5f9719639e86069a1734dbe5
Author: Marek Ol??k 
Date:   Mon Jan 30 08:54:01 2012 +0100

r600g: remove more dead code

:04 04 58df98411f4a2cf7dc210e8f1cd62007e6c1e498
9cb5194b10e5ff5dd0d1e0eb5da6cd834528beab Msrc

I tried reverting this on master but it seems dependent on other changes, so it
doesn't build. OTOH, the commit immediately prior to this one,
74027a9ba250f07a77ee40e105c50c27e4fc3bc0 is working so it's probably the right
one.

I'm not sure if this is a driver problem or a bug in SDL, considering that
earlier builds of the game worked fine with Mesa 9.0.


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.4
-- xserver: 1.12.4
-- mesa: 8.0.2
-- drm: 2.4.39
-- kernel: 3.5.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/5fdb9491/attachment.html>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #14 from Serkan Hosca  ---
Created attachment 68519
  --> https://bugs.freedesktop.org/attachment.cgi?id=68519=edit
dmesg linus git with patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/9371c287/attachment.html>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #13 from Serkan Hosca  ---
(In reply to comment #12)
> Yes the patch works.

I'm sorry o spoke to soon, same problem

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/f065fd23/attachment.html>

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-13 Thread Laurent Pinchart 
Hi Luis,

On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> The UAPI changes split kernel API and userspace API
> content onto two separate header files. The userspace
> API drm content was moved to include/uapi/drm/ with the
> same file name while kernel specific API content was
> kept under include/drm/ with the same file name. When
> one file was split into two files the kernel header
> includes the uapi header and a UAPI prefix was added to
> the uapi header for its header guard. When there was no
> kernel API content found the uapi header file was the
> only one that was kept and the original guard for the
> header file was kept. In this particular case the
> original users of this header file were not modified
> and the uapi header file is expected to be picked up
> by path.
> 
> This may work well at compilation on the kernel but when
> backporting this creates a few complexities.

Could you please provide more details about those complexities ?

> To help with
> backporting [0] lets be explicit about the new uapi path
> when there is no respective kernel API header file. For
> more details on the UAPI changes see the lwn article on
> this [1].
> 
> [0] https://backports.wiki.kernel.org
> [1] http://lwn.net/Articles/507794/
> 
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Cc: devel at driverdev.osuosl.org
> Cc: backports at vger.kernel.org
> 
> Cc: Rob Clark 
> Cc: Arnd Bergmann 
> Cc: Dave Jones 
> Cc: David Airlie 
> Cc: Ben Skeggs 
> Cc: Alan Cox 
> Cc: David Howells 
> Cc: Thomas Gleixner 
> Cc: Daniel Vetter 
> Cc: Jesse Barnes 
> Cc: Alex Deucher 
> Cc: Paul E. McKenney 
> Cc: Greg Kroah-Hartman 
> Cc: Laurent Pinchart 
> Signed-off-by: Luis R. Rodriguez 

-- 
Regards,

Laurent Pinchart

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #12 from Serkan Hosca  ---
Yes the patch works.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/d414ce1c/attachment-0001.html>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

Christian K?nig  changed:

   What|Removed |Added

  Attachment #68515|0   |1
is obsolete||

--- Comment #11 from Christian K?nig  ---
Created attachment 68516
  --> https://bugs.freedesktop.org/attachment.cgi?id=68516=edit
Possible fix rebased on correct branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/598efb69/attachment.html>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #10 from Christian K?nig  ---
Created attachment 68515
  --> https://bugs.freedesktop.org/attachment.cgi?id=68515=edit
Possible fix.

Could you try the attached patch ontop of Alex latest drm-nex-3.7 branch
(git://people.freedesktop.org/~agd5f/linux) ?

I'm not 100% sure that it's this problem, but it might be it.

Thanks,
Christian.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121013/42bfb707/attachment.html>

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-13 Thread Luis R. Rodriguez 
On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart
 wrote:
> Hi Luis,
>
> On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" 
>>
>> The UAPI changes split kernel API and userspace API
>> content onto two separate header files. The userspace
>> API drm content was moved to include/uapi/drm/ with the
>> same file name while kernel specific API content was
>> kept under include/drm/ with the same file name. When
>> one file was split into two files the kernel header
>> includes the uapi header and a UAPI prefix was added to
>> the uapi header for its header guard. When there was no
>> kernel API content found the uapi header file was the
>> only one that was kept and the original guard for the
>> header file was kept. In this particular case the
>> original users of this header file were not modified
>> and the uapi header file is expected to be picked up
>> by path.
>>
>> This may work well at compilation on the kernel but when
>> backporting this creates a few complexities.
>
> Could you please provide more details about those complexities ?

Sure, the backported DRM code is as-is code from linux-next. The
header search path includes a copy of a few select header files from
linux-next, the rest are part of the compat [0] project to help with
backporting and the last set are from your own kernel. In this
particular case the UAPI effort pushed into include/uapi/drm a few
files which are now no longer present in the old include/drm/ location
when there was no respective kernel-only APIs exposed. For DRM code
that did not use the new uapi/drm/ path for old header includes this
means that upon backporting the older kernel's header file would be
used obviously leading to a series of compilation failures. By being
explicit about the path, as was done with a few other header files, we
can suck out DRM code intact from the kernel to be compilable for
older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
be providing DRM modules. The new UAPI changes broke compilation on
compat-drivers when compiling DRM code so to fix this we either patch
code taken from the Linux kernel as I have done, force inclusion of a
few specific headers files, or use include_next tricks. It turns out
that forcing inclusion of -I$(M)/include/uapi as a path search prior
to your own kernel's at compilation time did not help. The
include_next trick can work as well but that'd mean synching the UAPI
files regularly into compat. I'd much prefer to have code intact when
possible when backporting so the option I stuck with then was to patch
the code directly and then as part of compat-drivers to always copy
that day's linux-next UAPI headers into the current directory for
compilation. I see no other driver code using the uapi path explicitly
though, is that by design? Would it be wrong to be explicit about
using a UAPI header alone if no kernel API files exist?

[0] https://backports.wiki.kernel.org/index.php/Documentation/compat
[1] https://backports.wiki.kernel.org/

  Luis

[PATCH 01/11] drm: add drm_send_vblank_event() helper

2012-10-13 Thread Mario Kleiner 
On 11.10.12 16:19, Laurent Pinchart wrote:
> Hi Rob,
>
> Thanks for the patch.
>
> On Monday 08 October 2012 14:50:39 Rob Clark wrote:
>> From: Rob Clark 
>>

...
>
> Do you know why some drivers don't call drm_vblank_count_and_time() ? For
> instance nouveau sets the sequence to 0 and uses do_gettimeofday(), but it
> looks like it could just call drm_vblank_count_and_time().
>

At least nouveau could use it. Lucas Stach and me wrote patches for 
nouveau-kms, and they went through many iterations and missed many 
kernel merge windows due to slow review until i think both of us got 
tired of resubmitting with tiny changes. The latest iteration is posted 
by Lucas on nouveau-devel from 26. April 2012. Not sure if they'd still 
apply after the nouveau-kms rewrite. I'll probably give them another try 
once that has landed when i have some spare time.

In principle it's very simple to use drm_vblank_count_and_time(). A 
driver needs to

1. Call drm_handle_vblank() from its vblank irq handler.

2. Make sure that in the vblank of pageflip completion 
drm_handle_vblank() is called before drm_vblank_count_and_time(), so the 
latter picks up updated counts and timestamps.

3. Big bonus for high precision and robustness: Implement the 
driver->get_vblank_timestamp() hook to provide a precise vblank 
timestamp. One simple way to do that is like radeon-kms or intel-kms do 
it: Call back into drm_calc_vbltimestamp_from_scanoutpos() and provide 
the driver->get_scanout_position() function - a function that returns 
the current hardware scanline counter. This is precise down to ~ 10 
microseconds (at least confirmed by measurements on 
intel,radeon,nouveau) and robust against delayed vblank irq handling.

-mario

[PATCH 10/11] drm/omap: use drm_send_vblank_event() helper

2012-10-13 Thread Mario Kleiner 
On 10.10.12 13:03, Rob Clark wrote:
> On Tue, Oct 9, 2012 at 10:33 PM, Mario Kleiner
>  wrote:
>> On 08.10.12 21:50, Rob Clark wrote:
>>>
>>> From: Rob Clark 
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>drivers/staging/omapdrm/omap_crtc.c |   31
>>> ++-
>>>1 file changed, 6 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/staging/omapdrm/omap_crtc.c
>>> b/drivers/staging/omapdrm/omap_crtc.c
>>> index 732f2ad..74e019a 100644
>>> --- a/drivers/staging/omapdrm/omap_crtc.c
>>> +++ b/drivers/staging/omapdrm/omap_crtc.c
>>> @@ -114,40 +114,21 @@ static void omap_crtc_load_lut(struct drm_crtc
>>> *crtc)
>>>
>>>static void vblank_cb(void *arg)
>>>{
>>> -   static uint32_t sequence = 0;
>>>  struct drm_crtc *crtc = arg;
>>>  struct drm_device *dev = crtc->dev;
>>>  struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>>> -   struct drm_pending_vblank_event *event = omap_crtc->event;
>>>  unsigned long flags;
>>> -   struct timeval now;
>>>
>>>  WARN_ON(!event);
>>> +   spin_lock_irqsave(>event_lock, flags);
>>> +
>>> +   /* wakeup userspace */
>>> +   if (omap_crtc->event)
>>> +   drm_send_vblank_event(dev, -1, omap_crtc->event);
>>>
>>>  omap_crtc->event = NULL;
>>>
>>> -   /* wakeup userspace */
>>> -   if (event) {
>>> -   do_gettimeofday();
>>> -
>>> -   spin_lock_irqsave(>event_lock, flags);
>>> -   /* TODO: we can't yet use the vblank time accounting,
>>> -* because omapdss lower layer is the one that knows
>>> -* the irq # and registers the handler, which more or
>>> -* less defeats how drm_irq works.. for now just fake
>>> -* the sequence number and use gettimeofday..
>>> -*
>>> -   event->event.sequence = drm_vblank_count_and_time(
>>> -   dev, omap_crtc->id, );
>>> -*/
>>
>>
>> I think this TOO comment should be retained as a reminder that there is work
>> to do.
>>
>>
>>> -   event->event.sequence = sequence++;
>>
>>
>> This is problematic. You lose the pseudo vblank counter implemented here,
>> which is a violation of the spec, and from my own experience it causes extra
>> pain and the need for awful workarounds in userspace clients. Nouveau-kms
>> has the same problem for no good reason.
>>
>> But then, on second thought, the way it is implemented here in the original
>> is even more wrong, returning zero might be better.
>
> I was actually debating whether or not to bother sending the omap
> patches, because I'm in middle of a re-write of the kms code in
> omapdrm that will (among many other things) give us proper vblank
> accounting..
>

Cool, that makes me happy :)

> There are a surprising # of other drivers that are just using
> do_gettimeofday() + seqn=0..  I guess, at least to be consistent,
> using seqn=0 is better than the completely bogus seqn.  Esp. when you
> consider having multiple CRTCs, they would end up not even having
> successive sequence numbers with the existing scheme.  But like I
> said, it's about to be replaced with something sane anyways :-P
>

Yes, zero is better in the meantime. E.g., to cope with nouveau's 
deficiency there, my app takes zero as "vblank count unsupported" and 
uses a fallback path, instead of getting confused.

Thanks for this nice cleanup.
-mario

[Bug 55913] Vdpau driver lag

2012-10-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=55913

--- Comment #2 from francesco  ---
Yes, really, is a issue of mplayer2, with mplayer I don't have any problem, you
can close this bug. Xv is more efficient on my pc.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[PATCH] nuoveau: only call ttm_agp_tt_create when __OS_HAS_AGP

2012-10-13 Thread Max Filippov 
ttm_agp_tt_create is itself defined under CONFIG_AGP, so there's no
point calling it otherwise.

Signed-off-by: Max Filippov 
---
This fixes allmodconfig build failure for xtensa: 
http://kisskb.ellerman.id.au/kisskb/buildresult/7346547/

 drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 259e5f1..35ac57f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -456,6 +456,7 @@ static struct ttm_tt *
 nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size,
  uint32_t page_flags, struct page *dummy_read)
 {
+#if __OS_HAS_AGP
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct drm_device *dev = drm->dev;

@@ -463,6 +464,7 @@ nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned 
long size,
return ttm_agp_tt_create(bdev, dev->agp->bridge, size,
 page_flags, dummy_read);
}
+#endif

return nouveau_sgdma_create_ttm(bdev, size, page_flags, dummy_read);
 }
-- 
1.7.7.6

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #10 from Christian König deathsim...@vodafone.de ---
Created attachment 68515
  -- https://bugs.freedesktop.org/attachment.cgi?id=68515action=edit
Possible fix.

Could you try the attached patch ontop of Alex latest drm-nex-3.7 branch
(git://people.freedesktop.org/~agd5f/linux) ?

I'm not 100% sure that it's this problem, but it might be it.

Thanks,
Christian.

-- 
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 1/2] uapi: update includes for drm content when no kernel API exists

2012-10-13 Thread Laurent Pinchart 
Hi Luis,

On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@do-not-panic.com
 
 The UAPI changes split kernel API and userspace API
 content onto two separate header files. The userspace
 API drm content was moved to include/uapi/drm/ with the
 same file name while kernel specific API content was
 kept under include/drm/ with the same file name. When
 one file was split into two files the kernel header
 includes the uapi header and a UAPI prefix was added to
 the uapi header for its header guard. When there was no
 kernel API content found the uapi header file was the
 only one that was kept and the original guard for the
 header file was kept. In this particular case the
 original users of this header file were not modified
 and the uapi header file is expected to be picked up
 by path.
 
 This may work well at compilation on the kernel but when
 backporting this creates a few complexities.

Could you please provide more details about those complexities ?

 To help with
 backporting [0] lets be explicit about the new uapi path
 when there is no respective kernel API header file. For
 more details on the UAPI changes see the lwn article on
 this [1].
 
 [0] https://backports.wiki.kernel.org
 [1] http://lwn.net/Articles/507794/
 
 Cc: dri-devel@lists.freedesktop.org
 Cc: linux-ker...@vger.kernel.org
 Cc: de...@driverdev.osuosl.org
 Cc: backpo...@vger.kernel.org
 
 Cc: Rob Clark r...@ti.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Dave Jones da...@redhat.com
 Cc: David Airlie airl...@linux.ie
 Cc: Ben Skeggs bske...@redhat.com
 Cc: Alan Cox a...@lxorguk.ukuu.org.uk
 Cc: David Howells dhowe...@redhat.com
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Jesse Barnes jbar...@virtuousgeek.org
 Cc: Alex Deucher alexander.deuc...@amd.com
 Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com

-- 
Regards,

Laurent Pinchart

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

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

  Attachment #68515|0   |1
is obsolete||

--- Comment #11 from Christian König deathsim...@vodafone.de ---
Created attachment 68516
  -- https://bugs.freedesktop.org/attachment.cgi?id=68516action=edit
Possible fix rebased on correct branch.

-- 
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

[PATCH] DRM/KMS: Add Bail-Out Conditions for Loop.

2012-10-13 Thread Egbert Eich 
When trying to obtain an accurate timestamp for the last vsync interrupt
in vblank_disable_and_save() we loop until the vsync counter after reading
the time stamp is identical to the one before.
In the case where no hardware timestamp can be obtained there is probably
no point in trying to make sure we remain within the same vsync during
the time we obtain the counter.
Furthermore we should make sure there's an 'emergency exit' so that we
don't end up in an endless loop when the driver get_vblank_timestamp()
function doesn't manage to return within the same vsync.
This may happen when this function prints out debugging information over
a slow (ie serial) line.

Signed-off-by: Egbert Eich e...@suse.de
---
 drivers/gpu/drm/drm_irq.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..580cdeb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -106,6 +106,7 @@ static void vblank_disable_and_save(struct drm_device *dev, 
int crtc)
s64 diff_ns;
int vblrc;
struct timeval tvblank;
+   int count = DRM_TIMESTAMP_MAXRETRIES;
 
/* Prevent vblank irq processing while disabling vblank irqs,
 * so no updates of timestamps or count can happen after we've
@@ -131,7 +132,10 @@ static void vblank_disable_and_save(struct drm_device 
*dev, int crtc)
do {
dev-last_vblank[crtc] = dev-driver-get_vblank_counter(dev, 
crtc);
vblrc = drm_get_last_vbltimestamp(dev, crtc, tvblank, 0);
-   } while (dev-last_vblank[crtc] != dev-driver-get_vblank_counter(dev, 
crtc));
+   } while (dev-last_vblank[crtc] != dev-driver-get_vblank_counter(dev, 
crtc)  (--count)  vblrc);
+
+   if (!count)
+   vblrc = 0;
 
/* Compute time difference to stored timestamp of last vblank
 * as updated by last invocation of drm_handle_vblank() in vblank irq.
-- 
1.7.6.3

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

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #12 from Serkan Hosca ser...@hosca.com ---
Yes the patch works.

-- 
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 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #13 from Serkan Hosca ser...@hosca.com ---
(In reply to comment #12)
 Yes the patch works.

I'm sorry o spoke to soon, same problem

-- 
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 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #14 from Serkan Hosca ser...@hosca.com ---
Created attachment 68519
  -- https://bugs.freedesktop.org/attachment.cgi?id=68519action=edit
dmesg linus git with patch

-- 
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 55951] New: [regression] Torchlight segfault at start with Mesa 9.0/git

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55951

  Priority: medium
Bug ID: 55951
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [regression] Torchlight segfault at start with Mesa
9.0/git
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: s...@whiz.se
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 68521
  -- https://bugs.freedesktop.org/attachment.cgi?id=68521action=edit
backtrace

The latest build of the game Torchlight segfaults on start with Mesa 9.0 or git
master. The crash happens in  BlitNtoNCopyAlpha () in SDL2, but only if the
game is set to launch full-screen.

Bisecting finds this commit:

0671400dcc72553b5f9719639e86069a1734dbe5 is the first bad commit
commit 0671400dcc72553b5f9719639e86069a1734dbe5
Author: Marek Olšák mar...@gmail.com
Date:   Mon Jan 30 08:54:01 2012 +0100

r600g: remove more dead code

:04 04 58df98411f4a2cf7dc210e8f1cd62007e6c1e498
9cb5194b10e5ff5dd0d1e0eb5da6cd834528beab Msrc

I tried reverting this on master but it seems dependent on other changes, so it
doesn't build. OTOH, the commit immediately prior to this one,
74027a9ba250f07a77ee40e105c50c27e4fc3bc0 is working so it's probably the right
one.

I'm not sure if this is a driver problem or a bug in SDL, considering that
earlier builds of the game worked fine with Mesa 9.0.


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.4
-- xserver: 1.12.4
-- mesa: 8.0.2
-- drm: 2.4.39
-- kernel: 3.5.2

-- 
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 55913] Vdpau driver lag

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55913

Andy Furniss li...@andyfurniss.entadsl.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com ---
Xv is a bit faster for me, but software decode + -vo vdpau can give a better
vsync than Xv in some circumstances.

-- 
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 55919] fatal error: nouveau/nouveau_device.h: No such file or directory

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55919

--- Comment #4 from Tomasz P. son_of_the_osi...@interia.pl ---
Do you have only problems with version 7.11 ? Have you tried 9.0 ?

-- 
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 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #15 from Serkan Hosca ser...@hosca.com ---
I've tried the patch on git://people.freedesktop.org/~agd5f/linux drm-nex-3.7
branch and it doesn't work. The gdm sets the blue background image and freezes,
no top bar or login dialog. I ssh from another computer and dmesg is clean at
this point. I try to stop gdm and it displays some garbage, mostly black screen
with some vertical purple bars about 4 cm thick and about 2 cm from the top of
the screen, then it displays the gpu crash messages on log and then the console
comes back.

-- 
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 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #16 from Serkan Hosca ser...@hosca.com ---
Created attachment 68531
  -- https://bugs.freedesktop.org/attachment.cgi?id=68531action=edit
dmesg with alex's drm-next-3.7 branch with patch

-- 
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

[PATCH v2] drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP

2012-10-13 Thread Max Filippov 
ttm_agp_tt_create is itself defined under CONFIG_AGP, so there's no
point calling it otherwise.

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
This fixes allmodconfig build failure for xtensa: 
http://kisskb.ellerman.id.au/kisskb/buildresult/7346547/

 drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 259e5f1..35ac57f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -456,6 +456,7 @@ static struct ttm_tt *
 nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned long size,
  uint32_t page_flags, struct page *dummy_read)
 {
+#if __OS_HAS_AGP
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct drm_device *dev = drm-dev;
 
@@ -463,6 +464,7 @@ nouveau_ttm_tt_create(struct ttm_bo_device *bdev, unsigned 
long size,
return ttm_agp_tt_create(bdev, dev-agp-bridge, size,
 page_flags, dummy_read);
}
+#endif
 
return nouveau_sgdma_create_ttm(bdev, size, page_flags, dummy_read);
 }
-- 
1.7.7.6

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

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

2012-10-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=55692

--- Comment #17 from Serkan Hosca ser...@hosca.com ---
It works with linus git without the patch with arch packages for mesa 9.0-1 and
-ati 6.14.6-2.

I tried with -ati git and mesa 9 and it worked. Then i tried with mesa git and
it failed. I started to bisect mesa but i got the following:
$ git bisect bad
Bisecting: a merge base must be tested
[2d2f1fd164218eacf2b142bc808be1f25f66e72c] docs: Add some missing features to
9.0 release notes and GL3.txt

$ git bisect bad
The merge base 2d2f1fd164218eacf2b142bc808be1f25f66e72c is bad.
This means the bug has been fixed between
2d2f1fd164218eacf2b142bc808be1f25f66e72c and
[e5fdeef1e08b55acd48dc68f0cc8fe213f2820b8].

So i did a git log --graph --oneline --all and started to git checkout between
those two commits, starting from 2d2f1fd to de92b7a are bad and with commit
ef557ea winsys/radeon: disable virtual memory on Cayman it started working.

-- 
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