[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53130

--- Comment #1 from Darren Salt  2012-08-04 
21:09:24 UTC ---
Linux 3.5; HD6770.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Juniper XT [AMD Radeon HD 6000 Series] [1002:68ba]

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

[Bug 53130] New: 99c65ba breaks rendering (flickery, eventual fail)

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53130

 Bug #: 53130
   Summary: 99c65ba breaks rendering (flickery, eventual fail)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bugspam at moreofthesa.me.uk


I noticed broken rendering in mesa git fairly recently.

In Unvanquished (current release), the effect with its GL3 renderer is that the
display becomes more and more flickery, and eventually rendering apparently
ceases; the game remains otherwise responsive. Its GL ('vanilla' renderer, much
as in Tremulous) is unaffected.

Bisection points at the following commit; I've confirmed locally that git
master with this reverted does not exhibit the broken behaviour.

commit 99c65bac341f808279a8a847158ace4f058aa72e
Author: Marek Ol??k 
Date:   Sun Feb 26 20:37:43 2012 +0100

r600g: implement wait-free buffer transfer for DISCARD_RANGE

Reviewed-by: Alex Deucher 
Reviewed-by: Christian K?nig 

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

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #19 from Alexandre Demers  
2012-08-04 17:47:40 UTC ---
For info from bug 43655, it fixes the bug on Cayman (XFX 6950).

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

[bisected] nouveau: "Failed to idle channel x" after resume

2012-08-04 Thread Maxim Levitsky 
On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote: 
> On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus  wrote:
> >
> > On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> > > after resuming from suspend nouveau starts writing Failed to idle
> > > channel x (where x is 2 or 3) to the log and X appears to stop and
> > > then restart only to stop again. Starting Firefox after resuming
> > > triggers the bugs every time, and bisecting leads to 03bd6efa
> > > ("drm/nv50/fifo: use hardware channel kickoff functionality").
> >
> > Hi Ben,
> > I'm still seeing this bug with the latest from Linus
> > (v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
> >
> > lspci output:
> > 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
> > 8400M GS] (rev a1)
> >
> > Sorry I haven't followed up on this earlier,
> > Martin
> 
> I can confirm this with 3.5.0, Chromium and Arch Linux. It's a HP
> Pavilion laptop with a G86 [GeForce 8400 M GS] video card .
> Seems related to this bug:
> http://lists.freedesktop.org/archives/nouveau/2011-January/007358.html
> . If I can do anything else
> to help, I will be glad to.
Added nouveau at lists.freedesktop.org>

I confirm the same issue here.
will try to do dig it.

Best regards,
Maxim Levitsky

[Bug 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #23 from Alexander E. Patrakov  2012-08-04 
17:02:31 UTC ---
Sorry for the noise about bridges. Of course the necessary address space for
the ROM is in pci_bus :15: resource 1, it's just strange that linux doesn't
show the ROM on pci bus :16: as a resource in dmesg.

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

[Bug 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #22 from Alexander E. Patrakov  2012-08-04 
16:35:43 UTC ---
The same problem with the bridge is present in the dmesg attached by the
original poster.

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

[Bug 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #21 from Alexander E. Patrakov  2012-08-04 
16:32:36 UTC ---
pci=nocrs doesn't help, and, if it is not clear from the previous comment, the
ROM should be here:

16:00.0 0300: 1002:6740 (prog-if 00 [VGA controller])
Subsystem: 104d:9084
Physical Slot: 1-2
Flags: fast devsel, IRQ 17
Memory at b000 (64-bit, prefetchable) [size=256M]
Memory at c020 (64-bit, non-prefetchable) [size=128K]
I/O ports at 5000 [size=256]
Expansion ROM at c024 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Capabilities: [150] Advanced Error Reporting

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

[Bug 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #20 from Alexander E. Patrakov  2012-08-04 
16:14:09 UTC ---
I think that the card does have its BIOS, and the problem is really related to
a misconfigured PCI bridge. Please take this with a grain of salt, as I am not
a kernel hacker.

Some snippets from my dmesg that IMHO confirm this:

(just an interesting line, I didn't try this suggestion)
[0.701044] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug

(here is the Radeon card)
[0.722007] pci :16:00.0: [1002:6740] type 00 class 0x03
[0.722073] pci :16:00.0: reg 10: [mem 0xb000-0xbfff 64bit pref]
[0.722125] pci :16:00.0: reg 18: [mem 0xc020-0xc021 64bit]
[0.722159] pci :16:00.0: reg 20: [io  0x5000-0x50ff]
[0.76] pci :16:00.0: reg 30: [mem 0xfffe-0x pref]
[0.722395] pci :16:00.0: supports D1 D2

(and this is the bridge before it)
[0.723054] pci :15:03.0: PCI bridge to [bus 16-16]
[0.723124] pci :15:03.0:   bridge window [io  0x5000-0x5fff]
[0.723132] pci :15:03.0:   bridge window [mem 0xc020-0xc02f]
[0.723149] pci :15:03.0:   bridge window [mem 0xb000-0xbfff
64bit pref]

(this is vgaarb)
[0.743085] vgaarb: device added:
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.743186] vgaarb: device added:
PCI::16:00.0,decodes=io+mem,owns=none,locks=none
[0.743265] vgaarb: loaded
[0.743313] vgaarb: bridge control possible :16:00.0
[0.743367] vgaarb: no bridge control possible :00:02.0

(here the kernel complains about the bug that ultimately leads to unreadability
of the ROM)
[0.773497] pci :16:00.0: no compatible bridge window for [mem
0xfffe-0x pref]

(and tries to fix it up? still not good enough)
[0.775668] pci :16:00.0: BAR 6: assigned [mem 0xc024-0xc025
pref]
[0.775745] pci :15:03.0: PCI bridge to [bus 16-16]
[0.775805] pci :15:03.0:   bridge window [io  0x5000-0x5fff]
[0.775872] pci :15:03.0:   bridge window [mem 0xc020-0xc02f]
[0.775937] pci :15:03.0:   bridge window [mem 0xb000-0xbfff
64bit pref]

(so we still end up with lost resources)
[0.778723] pci_bus :15: resource 0 [io  0x3000-0x5fff]
[0.778725] pci_bus :15: resource 1 [mem 0xb000-0xc02f]
[0.778726] pci_bus :15: resource 2 [mem 0xd440-0xd44f 64bit
pref]
[0.778728] pci_bus :16: resource 0 [io  0x5000-0x5fff]
[0.778730] pci_bus :16: resource 1 [mem 0xc020-0xc02f]
[0.778731] pci_bus :16: resource 2 [mem 0xb000-0xbfff 64bit
pref]

So the main question is: why doesn't vgaarb (or who really has this job)
reconfigure the bridge so that radeon can read the ROM?

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

[Bug 53122] X lockups /

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53122

--- Comment #1 from Alex Deucher  2012-08-04 15:33:44 UTC 
---
Please attach your dmesg 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 53122] X lockups /

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53122

Alex Deucher  changed:

   What|Removed |Added

  Attachment #65122|application/octet-stream|text/plain
  mime type||

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

[Bug 53124] New: Missing Radeon R600 PCI IDs

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53124

 Bug #: 53124
   Summary: Missing Radeon R600 PCI IDs
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: fdo at gigawatt.nl


Created attachment 65124
  --> https://bugs.freedesktop.org/attachment.cgi?id=65124
r600_pci_ids.patch

Some PCI IDs are missing in radeon/r600_pci_ids.h. This patch includes three
IDs found in xf86-video-ati's ati_pciids.csv. The first of these is what's in
my computer, and I am using that without issues after adding the ID to libdrm
and mesa. The other two I got by comparing r600_pci_ids.h to ati_pciids.csv for
other missing IDs, only checking the product families that were already in
r600_pci_ids.h.

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

[Bug 53122] New: X lockups /

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53122

 Bug #: 53122
   Summary: X lockups /
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  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: 201208bugzillaz at moo.uklinux.net


Created attachment 65122
  --> https://bugs.freedesktop.org/attachment.cgi?id=65122
X log file

Upon swapping video cards, I have started getting intermittent freezes of X
on my Slackware65 13.37 AMD Opteron box (kernel 3.4.4)

The display freezes up totally, including mouse pointer; occasionally there are
short (eg ~10s) freezes which might be related, and usually it happens when
web browsing (mostly when there is embedded flash on the bbc.co.uk olympics
pages) 

I hope the below is sufficient info; I need to swap video cards back because I
can't afford such lockups ATM.


Here's the lspci lines:
0a:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4550]
(prog-if 00 [VGA controller])
Subsystem: Giga-byte Technology Device 21ae
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon


This appears in /var/log/messages (if I wait 20+mins, it seems to unfreeze
fairly reliably)

Aug  3 17:28:11 fishpond acpid: client 2126[0:0] has disconnected
Aug  3 17:28:11 fishpond acpid: client connected from 2126[0:0]
Aug  3 17:28:11 fishpond acpid: 1 client rule loaded
Aug  3 17:48:19 fishpond kernel: [68040.346054] X   D
816065c0 0  2111   2098 0x0044
Aug  3 17:50:19 fishpond kernel: [68160.346048] X   D
816065c0 0  2111   2098 0x0044
Aug  3 17:52:19 fishpond kernel: [68280.346054] X   D
816065c0 0  2111   2098 0x0044
Aug  3 17:54:19 fishpond kernel: [68400.346054] X   D
816065c0 0  2111   2098 0x0044
Aug  3 17:56:19 fishpond kernel: [68520.346048] X   D
816065c0 0  2111   2098 0x0044
Aug  3 17:58:19 fishpond kernel: [68640.346053] X   D
816065c0 0  2111   2098 0x0044
Aug  3 18:00:19 fishpond kernel: [68760.346054] X   D
816065c0 0  2111   2098 0x0044
Aug  3 18:02:19 fishpond kernel: [68880.346047] X   D
816065c0 0  2111   2098 0x0044
Aug  3 18:04:19 fishpond kernel: [69000.346052] X   D
816065c0 0  2111   2098 0x0044
Aug  3 18:06:19 fishpond kernel: [69120.346052] X   D
816065c0 0  2111   2098 0x0044

And instances of this in /var/log/syslog

[69120.346044] INFO: task X:2111 blocked for more than 120 seconds.
[69120.346049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[69120.346052] X   D 816065c0 0  2111   2098 0x0044
[69120.346058]  8801743d9b58 0082 8801743d9ae8
00011dc0
[69120.346062]  00011dc0 880179dd06d0 00011dc0
8801743d9fd8
[69120.346066]  8801743d8000 00011dc0 8801743d9fd8
00011dc0
[69120.346071] Call Trace:
[69120.346083]  [] schedule+0x29/0x70
[69120.346087]  [] schedule_preempt_disabled+0xe/0x10
[69120.346091]  [] __mutex_lock_slowpath+0xd9/0x150
[69120.346095]  [] mutex_lock+0x2b/0x50
[69120.346125]  [] radeon_bo_create+0x150/0x2a0 [radeon]
[69120.346141]  [] radeon_gem_object_create+0x5a/0x100
[radeon]
[69120.346155]  [] radeon_gem_create_ioctl+0x54/0xe0 [radeon]
[69120.346160]  [] ? mutex_lock+0x1e/0x50
[69120.346174]  [] ? radeon_gem_get_tiling_ioctl+0xbc/0xf0
[radeon]
[69120.346189]  [] drm_ioctl+0x2cf/0x520 [drm]
[69120.346204]  [] ? radeon_gem_pwrite_ioctl+0x30/0x30
[radeon]
[69120.346210]  [] do_vfs_ioctl+0x97/0x540
[69120.346213]  [] sys_ioctl+0x91/0xa0
[69120.346217]  [] system_call_fastpath+0x16/0x1b


There is no error logged by X, but here its (but note that I run 6
simultaneaous X's on vt7-vt12). I've attached a log file

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

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #18 from Kunal  2012-08-04 
13:52:23 UTC ---
(In reply to comment #16)
> Created attachment 64759 [details] [review]
> Fixup mc programing
> 
> This patch should fix your issue.

Thanks for the patch. Will test it over this weekend (4th - 5th Aug.) and post
back.

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

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=42373

Alex Deucher  changed:

   What|Removed |Added

 CC||alexandre.f.demers at gmail.co
   ||m

--- Comment #17 from Alex Deucher  2012-08-04 13:26:36 UTC 
---
*** Bug 43655 has been marked as a duplicate of this bug. ***

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

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43655

Alex Deucher  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE

--- Comment #18 from Alex Deucher  2012-08-04 13:26:36 UTC 
---


*** This bug has been marked as a duplicate of bug 42373 ***

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

[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode

2012-08-04 Thread Seth Forshee 
On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
> 
> > This is one of the things I wasn't so sure about. There are various
> > checks in intel_lvds_init() that can cause it to bail out before we try
> > to get the EDID, and I don't fully understand all of them. If non-laptop
> > machines are expected to bail out before the EDID check then the
> > approach I've taken seems reasonable. Otherwise adding a quirk probably
> > is a good idea.
> 
> I know we've previously had problems with machines with phantom LVDS 
> hardware, but I'm not sure what the current state of affairs is.

It turns out that the framebuffer console issue is due to not having a
mode when initializing LVDS. As a result 1024x768 is getting used for
the framebuffer.

So quirking is going to fix this situation. In fact, with the changes
below switcheroo seems to work perfectly, without any of these patches
at all.


diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 627fe35..d83e5bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -503,6 +503,7 @@ typedef struct drm_i915_private {
enum intel_pch pch_type;

unsigned long quirks;
+   struct drm_display_mode *lvds_quirk_mode;

/* Register state */
bool modeset_on_lid;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f615976..c810177 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7069,7 +7069,7 @@ static void intel_init_display(struct drm_device *dev)
  * resume, or other times.  This quirk makes sure that's the case for
  * affected systems.
  */
-static void quirk_pipea_force(struct drm_device *dev)
+static void quirk_pipea_force(struct drm_device *dev, void *data)
 {
struct drm_i915_private *dev_priv = dev->dev_private;

@@ -7080,7 +7080,7 @@ static void quirk_pipea_force(struct drm_device *dev)
 /*
  * Some machines (Lenovo U160) do not work with SSC on LVDS for some reason
  */
-static void quirk_ssc_force_disable(struct drm_device *dev)
+static void quirk_ssc_force_disable(struct drm_device *dev, void *data)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
dev_priv->quirks |= QUIRK_LVDS_SSC_DISABLE;
@@ -7091,48 +7091,74 @@ static void quirk_ssc_force_disable(struct drm_device 
*dev)
  * A machine (e.g. Acer Aspire 5734Z) may need to invert the panel backlight
  * brightness value
  */
-static void quirk_invert_brightness(struct drm_device *dev)
+static void quirk_invert_brightness(struct drm_device *dev, void *data)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
dev_priv->quirks |= QUIRK_INVERT_BRIGHTNESS;
DRM_INFO("applying inverted panel brightness quirk\n");
 }

+/*
+ * Some machines (e.g. certain Macbooks) may not be able to determine the
+ * LVDS mode during driver initialization
+ */
+static void quirk_lvds_panel_mode(struct drm_device *dev, void *data)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   dev_priv->lvds_quirk_mode = data;
+   DRM_INFO("applying LVDS panel mode quirk: %p\n", data);
+}
+
+/* LVDS panel mode for Macbook Pro 8,2 */
+struct drm_display_mode mbp82_panel_mode = {
+   DRM_MODE("1440x900", DRM_MODE_TYPE_DRIVER, 88750, 1440, 1488, 1520,
+1600, 0, 900, 903, 909, 926, 0,
+DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC)
+};
+
 struct intel_quirk {
int device;
int subsystem_vendor;
int subsystem_device;
-   void (*hook)(struct drm_device *dev);
+   void (*hook)(struct drm_device *dev, void *data);
+   void *hook_data;
 };

 static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
-   { 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
+   { 0x27ae, 0x103c, 0x361a, quirk_pipea_force, NULL },

/* Thinkpad R31 needs pipe A force quirk */
-   { 0x3577, 0x1014, 0x0505, quirk_pipea_force },
+   { 0x3577, 0x1014, 0x0505, quirk_pipea_force, NULL },
/* Toshiba Protege R-205, S-209 needs pipe A force quirk */
-   { 0x2592, 0x1179, 0x0001, quirk_pipea_force },
+   { 0x2592, 0x1179, 0x0001, quirk_pipea_force, NULL },

/* ThinkPad X30 needs pipe A force quirk (LP: #304614) */
-   { 0x3577,  0x1014, 0x0513, quirk_pipea_force },
+   { 0x3577,  0x1014, 0x0513, quirk_pipea_force, NULL },
/* ThinkPad X40 needs pipe A force quirk */

/* ThinkPad T60 needs pipe A force quirk (bug #16494) */
-   { 0x2782, 0x17aa, 0x201a, quirk_pipea_force },
+   { 0x2782, 0x17aa, 0x201a, quirk_pipea_force, NULL },

/* 855 & before need to leave pipe A & dpll A up */
-   { 0x3582, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
-   { 0x2562, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+   { 0x3582, PCI_ANY_ID, PCI_ANY_ID,

[PATCH] vmwgfx: add missing mutex_unlocks

2012-08-04 Thread Devendra Naga 
we have done a proper mutex_unlock in the error cases of the vmw_fifo_reserve, 
but
there are missing mutex unlocks where we return a valid pointer in 
vmw_fifo_reserve.

Signed-off-by: Devendra Naga 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index a0c2f12..e3abd7a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -355,6 +355,7 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv, 
uint32_t bytes)
if (reserveable)
iowrite32(bytes, fifo_mem +
  SVGA_FIFO_RESERVED);
+   mutex_unlock(_state->fifo_mutex);
return fifo_mem + (next_cmd >> 2);
} else {
need_bounce = true;
@@ -363,10 +364,12 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv, 
uint32_t bytes)

if (need_bounce) {
fifo_state->using_bounce_buffer = true;
-   if (bytes < fifo_state->static_buffer_size)
+   if (bytes < fifo_state->static_buffer_size) {
+   mutex_unlock(_state->fifo_mutex);
return fifo_state->static_buffer;
-   else {
+   } else {
fifo_state->dynamic_buffer = vmalloc(bytes);
+   mutex_unlock(_state->fifo_mutex);
return fifo_state->dynamic_buffer;
}
}
-- 
1.7.9.5

[PATCH] drm/radeon: fence virtual address and free it once idle v3

2012-08-04 Thread Christian König 
On 03.08.2012 23:26, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
>
> Virtual address need to be fenced to know when we can safely remove it.
> This patch also properly clear the pagetable. Previously it was
> serouisly broken.
>
> Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex 
> locking.
>
> v2: For to update pagetable when unbinding bo (don't bailout if
>  bo_va->valid is true).
> v3: Add kernel 3.5/3.4 comment.
>
> Signed-off-by: Jerome Glisse 
It should fix the problem, going to test it as soon as I find some 5min 
spare in my vacation. Till then it is:

Reviewed-by: Christian K?nig 

In the future I would really like to make the updating of the PTE also 
async, that should save us allot of problems here.

Christian.


> ---
>   drivers/gpu/drm/radeon/radeon.h|1 +
>   drivers/gpu/drm/radeon/radeon_cs.c |   32 
> +---
>   drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
>   drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
>   drivers/gpu/drm/radeon/radeon_object.c |6 +-
>   5 files changed, 55 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5431af2..8d75c65 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -300,6 +300,7 @@ struct radeon_bo_va {
>   uint64_tsoffset;
>   uint64_teoffset;
>   uint32_tflags;
> + struct radeon_fence *fence;
>   boolvalid;
>   };
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 8a4c49e..995f3ab 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
>   return 0;
>   }
>   
> +static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
> +   struct radeon_fence *fence)
> +{
> + struct radeon_fpriv *fpriv = parser->filp->driver_priv;
> + struct radeon_vm *vm = >vm;
> + struct radeon_bo_list *lobj;
> + int r;
> +
> + if (parser->chunk_ib_idx == -1)
> + return;
> + if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
> + return;
> +
> + list_for_each_entry(lobj, >validated, tv.head) {
> + struct radeon_bo_va *bo_va;
> + struct radeon_bo *rbo = lobj->bo;
> +
> + bo_va = radeon_bo_va(rbo, vm);
> + radeon_fence_unref(_va->fence);
> + bo_va->fence = radeon_fence_ref(fence);
> + }
> + return 0;
> +}
> +
>   /**
>* cs_parser_fini() - clean parser states
>* @parser: parser structure holding parsing context.
> @@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct 
> radeon_cs_parser *parser, int error)
>   {
>   unsigned i;
>   
> - if (!error)
> + if (!error) {
> + /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
> still reserved */
> + radeon_bo_vm_fence_va(parser, parser->ib.fence);
>   ttm_eu_fence_buffer_objects(>validated,
>   parser->ib.fence);
> - else
> + } else {
>   ttm_eu_backoff_reservation(>validated);
> + }
>   
>   if (parser->relocs != NULL) {
>   for (i = 0; i < parser->nrelocs; i++) {
> @@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device 
> *rdev,
>   
>   if (parser->chunk_ib_idx == -1)
>   return 0;
> -
>   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
>   return 0;
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index b372005..9912182 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
>   return -EINVAL;
>   }
>   
> - if (bo_va->valid)
> + if (bo_va->valid && mem)
>   return 0;
>   
>   ngpu_pages = radeon_bo_ngpu_pages(bo);
> @@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
>struct radeon_bo *bo)
>   {
>   struct radeon_bo_va *bo_va;
> + int r;
>   
>   bo_va = radeon_bo_va(bo, vm);
>   if (bo_va == NULL)
>   return 0;
>   
> + /* wait for va use to end */
> + while (bo_va->fence) {
> + r = radeon_fence_wait(bo_va->fence, false);
> + if (r) {
> + DRM_ERROR("error while waiting for fence: %d\n", r);
> + }
> + if (r == -EDEADLK) {
> + r = radeon_gpu_reset(rdev);
> + if (!r)
> + continue;
> + }
> + break;
> +

[PATCH] drm/radeon: fence virtual address and free it once idle v3

2012-08-04 Thread Alex Deucher 
On Fri, Aug 3, 2012 at 5:26 PM,   wrote:
> From: Jerome Glisse 
>
> Virtual address need to be fenced to know when we can safely remove it.
> This patch also properly clear the pagetable. Previously it was
> serouisly broken.
>
> Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex 
> locking.
>
> v2: For to update pagetable when unbinding bo (don't bailout if
> bo_va->valid is true).
> v3: Add kernel 3.5/3.4 comment.
>
> Signed-off-by: Jerome Glisse 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/radeon.h|1 +
>  drivers/gpu/drm/radeon/radeon_cs.c |   32 
> +---
>  drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
>  drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
>  drivers/gpu/drm/radeon/radeon_object.c |6 +-
>  5 files changed, 55 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5431af2..8d75c65 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -300,6 +300,7 @@ struct radeon_bo_va {
> uint64_tsoffset;
> uint64_teoffset;
> uint32_tflags;
> +   struct radeon_fence *fence;
> boolvalid;
>  };
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 8a4c49e..995f3ab 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
> return 0;
>  }
>
> +static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
> + struct radeon_fence *fence)
> +{
> +   struct radeon_fpriv *fpriv = parser->filp->driver_priv;
> +   struct radeon_vm *vm = >vm;
> +   struct radeon_bo_list *lobj;
> +   int r;
> +
> +   if (parser->chunk_ib_idx == -1)
> +   return;
> +   if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
> +   return;
> +
> +   list_for_each_entry(lobj, >validated, tv.head) {
> +   struct radeon_bo_va *bo_va;
> +   struct radeon_bo *rbo = lobj->bo;
> +
> +   bo_va = radeon_bo_va(rbo, vm);
> +   radeon_fence_unref(_va->fence);
> +   bo_va->fence = radeon_fence_ref(fence);
> +   }
> +   return 0;
> +}
> +
>  /**
>   * cs_parser_fini() - clean parser states
>   * @parser:parser structure holding parsing context.
> @@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct 
> radeon_cs_parser *parser, int error)
>  {
> unsigned i;
>
> -   if (!error)
> +   if (!error) {
> +   /* fence all bo va before ttm_eu_fence_buffer_objects so bo 
> are still reserved */
> +   radeon_bo_vm_fence_va(parser, parser->ib.fence);
> ttm_eu_fence_buffer_objects(>validated,
> parser->ib.fence);
> -   else
> +   } else {
> ttm_eu_backoff_reservation(>validated);
> +   }
>
> if (parser->relocs != NULL) {
> for (i = 0; i < parser->nrelocs; i++) {
> @@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device 
> *rdev,
>
> if (parser->chunk_ib_idx == -1)
> return 0;
> -
> if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
> return 0;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index b372005..9912182 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
> return -EINVAL;
> }
>
> -   if (bo_va->valid)
> +   if (bo_va->valid && mem)
> return 0;
>
> ngpu_pages = radeon_bo_ngpu_pages(bo);
> @@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
>  struct radeon_bo *bo)
>  {
> struct radeon_bo_va *bo_va;
> +   int r;
>
> bo_va = radeon_bo_va(bo, vm);
> if (bo_va == NULL)
> return 0;
>
> +   /* wait for va use to end */
> +   while (bo_va->fence) {
> +   r = radeon_fence_wait(bo_va->fence, false);
> +   if (r) {
> +   DRM_ERROR("error while waiting for fence: %d\n", r);
> +   }
> +   if (r == -EDEADLK) {
> +   r = radeon_gpu_reset(rdev);
> +   if (!r)
> +   continue;
> +   }
> +   break;
> +   }
> +   radeon_fence_unref(_va->fence);
> +
> mutex_lock(>vm_manager.lock);
> mutex_lock(>mutex);
> radeon_vm_bo_update_pte(rdev, vm, bo,

[Bug 53118] New: Rendering error in unigine heaven when GL_ARB_shader_bit_encoding is used.

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53118

 Bug #: 53118
   Summary: Rendering error in unigine heaven when
GL_ARB_shader_bit_encoding is used.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: thomas.lindroth at gmail.com


Created attachment 65111
  --> https://bugs.freedesktop.org/attachment.cgi?id=65111
screenshot

Textures are rendered incorrectly in unigine heaven on latest git drivers with
kernel 3.5.0 when shaders are set to high and ambient occlusion is on. The
problem is fixed when exporting
MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_bit_encoding"

Hardware is juniper.

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

[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset

2012-08-04 Thread Henrik Rydberg 
The nva3 copy engine exhibits random memory corruption in at least one
case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.  This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the symptoms.

Signed-off-by: Henrik Rydberg 
---
Hi Ben,

this patch is still needed in 3.6-rc1, so perhaps we should apply it
after all. I have been running it without problems for a long time
now.

Thanks,
Henrik

 drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 1cdfd6e..1866dbb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev)
case 0xa3:
case 0xa5:
case 0xa8:
-   case 0xaf:
nva3_copy_create(dev);
break;
}
-- 
1.7.11.4

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=43655

--- Comment #17 from Alexandre Demers  
2012-08-04 04:58:03 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then 
> > patch
> > there should fix your issue.
> 
> I'll try it as soon as I'll have time. Thank you Jerome for your follow-up.

(In reply to comment #15)
> If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch
> there should fix your issue.

It fixes it. Applied, rebooted 3 times without problem, went back to 3.6-rc1
(no patch) problem appeared, went back to patched kernel and still no problem.

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

[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53111

--- Comment #2 from Alexandre Demers  
2012-08-04 04:32:01 UTC ---
Small note to whoever could come here and was not following bug 45018:

Bisecting identified the following commit as culprit:

bb1f0cf3508630a9a93512c79badf8c493c46743 is the first bad commit
commit bb1f0cf3508630a9a93512c79badf8c493c46743
Author: Jerome Glisse 
Date:   Fri Dec 2 10:20:29 2011 -0500

r600g: add support for virtual address space on cayman v11

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

[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53111

--- Comment #1 from Anthony Waters  2012-08-04 04:13:14 
UTC ---
Created attachment 65108
  --> https://bugs.freedesktop.org/attachment.cgi?id=65108
dmesg of piglit r600.test crash

I also have the same issue, here is the dmesg of the crash I get when running
the piglit test case r600.test.  This is with virtual address enabled and the
patches from bug 45018 applied.

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

[Bug 53111] New: [bisected] lockups since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=53111

 Bug #: 53111
   Summary: [bisected] lockups since added support for virtual
address space on cayman v11
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: alexandre.f.demers at gmail.com


When running RendererFeatTest64, it always locks at the same test. Lockups also
happen when running piglit r600.test, locking always near the same test (sanity
tests are OK). If we disable virtual address space as explained under bug
45018, no lockups happen.

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

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

Alexandre Demers  changed:

   What|Removed |Added

Summary|[bisected] rendering|[bisected] rendering
   |regression since added  |regression and va conflicts
   |support for virtual address |since added support for
   |space on cayman v11 |virtual address space on
   ||cayman v11

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

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #107 from Alexandre Demers  
2012-08-04 03:55:56 UTC ---
Tested with 3.6-rc1 and latest mesa with both respective patches. No va issue
anymore.

However, lockups still happen with RendererFeatTest64: I tried to run some
tests and my system locked completly and restarted. This seems to be a
different problem though not related to the va conflict issue. So I'll open a
different bug for the lockups revealed by the same commit (as previously said,
without virtual address space, it doesn't lock).

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

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #106 from Anthony Waters  2012-08-04 
02:05:34 UTC ---
I tried the patch from Christian in comment 96 atop of mesa git and the patch
from Jerome in comment 102 atop of linux-3.5 and I no longer experience the
rendering regression and I have not seen the va conflict error, thanks.

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

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

2012-08-04 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26891

--- Comment #31 from David L.  
2012-08-03 23:21:21 UTC ---
(In reply to comment #30)
> (In reply to comment #29)
> > Is the lvds console display shifted if you don't connect any external 
> > monitor ?
> 
> So far I only got the LVDS to display anything by connecting the DP monitor, 
> so
> I don't really know.  I didn't try much there... I'll try some other magic
> incantations/plug sequences tomorrow, maybe there's a sequence to get 
> LVDS-only
> with it actually showing something.
> 
> Starting X while the LVDS is off works fine, reenabling it.

Correction: I just had a hard freeze after an hour or so of X use.

Since I need to get some things done, I've booted in hybrid UEFI mode now with
only the brightness patch applied.  The LVDS-blank-after-insmod issue is gone,
so it's not the backlight control I guess.

Also, interestingly, the power consumption of the laptop was considerably lower
under UEFI native mode (24W) vs. UEFI hybrid mode (29W).  Could be either the
CRTC programming patch or something completely unrelated.

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

[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset

2012-08-04 Thread Henrik Rydberg 
The nva3 copy engine exhibits random memory corruption in at least one
case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.  This patch
omits creating the engine for the specific chipset, falling back to
M2MF, which kills the symptoms.

Signed-off-by: Henrik Rydberg rydb...@euromail.se
---
Hi Ben,

this patch is still needed in 3.6-rc1, so perhaps we should apply it
after all. I have been running it without problems for a long time
now.

Thanks,
Henrik

 drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 1cdfd6e..1866dbb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev)
case 0xa3:
case 0xa5:
case 0xa8:
-   case 0xaf:
nva3_copy_create(dev);
break;
}
-- 
1.7.11.4

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

[Bug 53118] New: Rendering error in unigine heaven when GL_ARB_shader_bit_encoding is used.

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53118

 Bug #: 53118
   Summary: Rendering error in unigine heaven when
GL_ARB_shader_bit_encoding is used.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: thomas.lindr...@gmail.com


Created attachment 65111
  -- https://bugs.freedesktop.org/attachment.cgi?id=65111
screenshot

Textures are rendered incorrectly in unigine heaven on latest git drivers with
kernel 3.5.0 when shaders are set to high and ambient occlusion is on. The
problem is fixed when exporting
MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding

Hardware is juniper.

-- 
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: fence virtual address and free it once idle v3

2012-08-04 Thread Christian König 

On 03.08.2012 23:26, j.gli...@gmail.com wrote:

From: Jerome Glisse jgli...@redhat.com

Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.

Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.

v2: For to update pagetable when unbinding bo (don't bailout if
 bo_va-valid is true).
v3: Add kernel 3.5/3.4 comment.

Signed-off-by: Jerome Glisse jgli...@redhat.com
It should fix the problem, going to test it as soon as I find some 5min 
spare in my vacation. Till then it is:


Reviewed-by: Christian König christian.koe...@amd.com

In the future I would really like to make the updating of the PTE also 
async, that should save us allot of problems here.


Christian.



---
  drivers/gpu/drm/radeon/radeon.h|1 +
  drivers/gpu/drm/radeon/radeon_cs.c |   32 +---
  drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
  drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
  drivers/gpu/drm/radeon/radeon_object.c |6 +-
  5 files changed, 55 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+   struct radeon_fence *fence;
boolvalid;
  };
  
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c

index 8a4c49e..995f3ab 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
return 0;
  }
  
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,

+ struct radeon_fence *fence)
+{
+   struct radeon_fpriv *fpriv = parser-filp-driver_priv;
+   struct radeon_vm *vm = fpriv-vm;
+   struct radeon_bo_list *lobj;
+   int r;
+
+   if (parser-chunk_ib_idx == -1)
+   return;
+   if ((parser-cs_flags  RADEON_CS_USE_VM) == 0)
+   return;
+
+   list_for_each_entry(lobj, parser-validated, tv.head) {
+   struct radeon_bo_va *bo_va;
+   struct radeon_bo *rbo = lobj-bo;
+
+   bo_va = radeon_bo_va(rbo, vm);
+   radeon_fence_unref(bo_va-fence);
+   bo_va-fence = radeon_fence_ref(fence);
+   }
+   return 0;
+}
+
  /**
   * cs_parser_fini() - clean parser states
   * @parser:   parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error)
  {
unsigned i;
  
-	if (!error)

+   if (!error) {
+   /* fence all bo va before ttm_eu_fence_buffer_objects so bo are 
still reserved */
+   radeon_bo_vm_fence_va(parser, parser-ib.fence);
ttm_eu_fence_buffer_objects(parser-validated,
parser-ib.fence);
-   else
+   } else {
ttm_eu_backoff_reservation(parser-validated);
+   }
  
  	if (parser-relocs != NULL) {

for (i = 0; i  parser-nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
  
  	if (parser-chunk_ib_idx == -1)

return 0;
-
if ((parser-cs_flags  RADEON_CS_USE_VM) == 0)
return 0;
  
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c b/drivers/gpu/drm/radeon/radeon_gart.c

index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
  
-	if (bo_va-valid)

+   if (bo_va-valid  mem)
return 0;
  
  	ngpu_pages = radeon_bo_ngpu_pages(bo);

@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
 struct radeon_bo *bo)
  {
struct radeon_bo_va *bo_va;
+   int r;
  
  	bo_va = radeon_bo_va(bo, vm);

if (bo_va == NULL)
return 0;
  
+	/* wait for va use to end */

+   while (bo_va-fence) {
+   r = radeon_fence_wait(bo_va-fence, false);
+   if (r) {
+   DRM_ERROR(error while waiting for fence: %d\n, r);
+   }
+   if (r == -EDEADLK) {
+   r = radeon_gpu_reset(rdev);
+   if (!r)
+   continue;
+   }
+   break;
+   }
+   radeon_fence_unref(bo_va-fence);
+
mutex_lock(rdev-vm_manager.lock);

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=43655

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE

--- Comment #18 from Alex Deucher ag...@yahoo.com 2012-08-04 13:26:36 UTC ---


*** This bug has been marked as a duplicate of bug 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

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=42373

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 CC||alexandre.f.dem...@gmail.co
   ||m

--- Comment #17 from Alex Deucher ag...@yahoo.com 2012-08-04 13:26:36 UTC ---
*** Bug 43655 has been marked as a duplicate of this bug. ***

-- 
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: fence virtual address and free it once idle v3

2012-08-04 Thread Alex Deucher 
On Fri, Aug 3, 2012 at 5:26 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 Virtual address need to be fenced to know when we can safely remove it.
 This patch also properly clear the pagetable. Previously it was
 serouisly broken.

 Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex 
 locking.

 v2: For to update pagetable when unbinding bo (don't bailout if
 bo_va-valid is true).
 v3: Add kernel 3.5/3.4 comment.

 Signed-off-by: Jerome Glisse jgli...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/radeon.h|1 +
  drivers/gpu/drm/radeon/radeon_cs.c |   32 
 +---
  drivers/gpu/drm/radeon/radeon_gart.c   |   24 ++--
  drivers/gpu/drm/radeon/radeon_gem.c|   13 ++---
  drivers/gpu/drm/radeon/radeon_object.c |6 +-
  5 files changed, 55 insertions(+), 21 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
 index 5431af2..8d75c65 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -300,6 +300,7 @@ struct radeon_bo_va {
 uint64_tsoffset;
 uint64_teoffset;
 uint32_tflags;
 +   struct radeon_fence *fence;
 boolvalid;
  };

 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 8a4c49e..995f3ab 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
 void *data)
 return 0;
  }

 +static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
 + struct radeon_fence *fence)
 +{
 +   struct radeon_fpriv *fpriv = parser-filp-driver_priv;
 +   struct radeon_vm *vm = fpriv-vm;
 +   struct radeon_bo_list *lobj;
 +   int r;
 +
 +   if (parser-chunk_ib_idx == -1)
 +   return;
 +   if ((parser-cs_flags  RADEON_CS_USE_VM) == 0)
 +   return;
 +
 +   list_for_each_entry(lobj, parser-validated, tv.head) {
 +   struct radeon_bo_va *bo_va;
 +   struct radeon_bo *rbo = lobj-bo;
 +
 +   bo_va = radeon_bo_va(rbo, vm);
 +   radeon_fence_unref(bo_va-fence);
 +   bo_va-fence = radeon_fence_ref(fence);
 +   }
 +   return 0;
 +}
 +
  /**
   * cs_parser_fini() - clean parser states
   * @parser:parser structure holding parsing context.
 @@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct 
 radeon_cs_parser *parser, int error)
  {
 unsigned i;

 -   if (!error)
 +   if (!error) {
 +   /* fence all bo va before ttm_eu_fence_buffer_objects so bo 
 are still reserved */
 +   radeon_bo_vm_fence_va(parser, parser-ib.fence);
 ttm_eu_fence_buffer_objects(parser-validated,
 parser-ib.fence);
 -   else
 +   } else {
 ttm_eu_backoff_reservation(parser-validated);
 +   }

 if (parser-relocs != NULL) {
 for (i = 0; i  parser-nrelocs; i++) {
 @@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device 
 *rdev,

 if (parser-chunk_ib_idx == -1)
 return 0;
 -
 if ((parser-cs_flags  RADEON_CS_USE_VM) == 0)
 return 0;

 diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
 b/drivers/gpu/drm/radeon/radeon_gart.c
 index b372005..9912182 100644
 --- a/drivers/gpu/drm/radeon/radeon_gart.c
 +++ b/drivers/gpu/drm/radeon/radeon_gart.c
 @@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
 return -EINVAL;
 }

 -   if (bo_va-valid)
 +   if (bo_va-valid  mem)
 return 0;

 ngpu_pages = radeon_bo_ngpu_pages(bo);
 @@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
  struct radeon_bo *bo)
  {
 struct radeon_bo_va *bo_va;
 +   int r;

 bo_va = radeon_bo_va(bo, vm);
 if (bo_va == NULL)
 return 0;

 +   /* wait for va use to end */
 +   while (bo_va-fence) {
 +   r = radeon_fence_wait(bo_va-fence, false);
 +   if (r) {
 +   DRM_ERROR(error while waiting for fence: %d\n, r);
 +   }
 +   if (r == -EDEADLK) {
 +   r = radeon_gpu_reset(rdev);
 +   if (!r)
 +   continue;
 +   }
 +   break;
 +   }
 +   radeon_fence_unref(bo_va-fence);
 +
 mutex_lock(rdev-vm_manager.lock);
 mutex_lock(vm-mutex);
 radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
 @@ -952,12 +968,15 @@ void radeon_vm_fini(struct

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

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=42373

--- Comment #18 from Kunal kunal.gangakhed...@gmail.com 2012-08-04 13:52:23 
UTC ---
(In reply to comment #16)
 Created attachment 64759 [details] [review]
 Fixup mc programing
 
 This patch should fix your issue.

Thanks for the patch. Will test it over this weekend (4th - 5th Aug.) and post
back.

-- 
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 53124] New: Missing Radeon R600 PCI IDs

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53124

 Bug #: 53124
   Summary: Missing Radeon R600 PCI IDs
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: f...@gigawatt.nl


Created attachment 65124
  -- https://bugs.freedesktop.org/attachment.cgi?id=65124
r600_pci_ids.patch

Some PCI IDs are missing in radeon/r600_pci_ids.h. This patch includes three
IDs found in xf86-video-ati's ati_pciids.csv. The first of these is what's in
my computer, and I am using that without issues after adding the ID to libdrm
and mesa. The other two I got by comparing r600_pci_ids.h to ati_pciids.csv for
other missing IDs, only checking the product families that were already in
r600_pci_ids.h.

-- 
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 53122] X lockups /

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53122

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #65122|application/octet-stream|text/plain
  mime type||

-- 
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 53122] X lockups /

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53122

--- Comment #1 from Alex Deucher ag...@yahoo.com 2012-08-04 15:33:44 UTC ---
Please attach your dmesg 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 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #20 from Alexander E. Patrakov patra...@gmail.com 2012-08-04 
16:14:09 UTC ---
I think that the card does have its BIOS, and the problem is really related to
a misconfigured PCI bridge. Please take this with a grain of salt, as I am not
a kernel hacker.

Some snippets from my dmesg that IMHO confirm this:

(just an interesting line, I didn't try this suggestion)
[0.701044] PCI: Using host bridge windows from ACPI; if necessary, use
pci=nocrs and report a bug

(here is the Radeon card)
[0.722007] pci :16:00.0: [1002:6740] type 00 class 0x03
[0.722073] pci :16:00.0: reg 10: [mem 0xb000-0xbfff 64bit pref]
[0.722125] pci :16:00.0: reg 18: [mem 0xc020-0xc021 64bit]
[0.722159] pci :16:00.0: reg 20: [io  0x5000-0x50ff]
[0.76] pci :16:00.0: reg 30: [mem 0xfffe-0x pref]
[0.722395] pci :16:00.0: supports D1 D2

(and this is the bridge before it)
[0.723054] pci :15:03.0: PCI bridge to [bus 16-16]
[0.723124] pci :15:03.0:   bridge window [io  0x5000-0x5fff]
[0.723132] pci :15:03.0:   bridge window [mem 0xc020-0xc02f]
[0.723149] pci :15:03.0:   bridge window [mem 0xb000-0xbfff
64bit pref]

(this is vgaarb)
[0.743085] vgaarb: device added:
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.743186] vgaarb: device added:
PCI::16:00.0,decodes=io+mem,owns=none,locks=none
[0.743265] vgaarb: loaded
[0.743313] vgaarb: bridge control possible :16:00.0
[0.743367] vgaarb: no bridge control possible :00:02.0

(here the kernel complains about the bug that ultimately leads to unreadability
of the ROM)
[0.773497] pci :16:00.0: no compatible bridge window for [mem
0xfffe-0x pref]

(and tries to fix it up? still not good enough)
[0.775668] pci :16:00.0: BAR 6: assigned [mem 0xc024-0xc025
pref]
[0.775745] pci :15:03.0: PCI bridge to [bus 16-16]
[0.775805] pci :15:03.0:   bridge window [io  0x5000-0x5fff]
[0.775872] pci :15:03.0:   bridge window [mem 0xc020-0xc02f]
[0.775937] pci :15:03.0:   bridge window [mem 0xb000-0xbfff
64bit pref]

(so we still end up with lost resources)
[0.778723] pci_bus :15: resource 0 [io  0x3000-0x5fff]
[0.778725] pci_bus :15: resource 1 [mem 0xb000-0xc02f]
[0.778726] pci_bus :15: resource 2 [mem 0xd440-0xd44f 64bit
pref]
[0.778728] pci_bus :16: resource 0 [io  0x5000-0x5fff]
[0.778730] pci_bus :16: resource 1 [mem 0xc020-0xc02f]
[0.778731] pci_bus :16: resource 2 [mem 0xb000-0xbfff 64bit
pref]

So the main question is: why doesn't vgaarb (or who really has this job)
reconfigure the bridge so that radeon can read the ROM?

-- 
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 41265] KMS does not work on Radeon HD6700M

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #23 from Alexander E. Patrakov patra...@gmail.com 2012-08-04 
17:02:31 UTC ---
Sorry for the noise about bridges. Of course the necessary address space for
the ROM is in pci_bus :15: resource 1, it's just strange that linux doesn't
show the ROM on pci bus :16: as a resource in dmesg.

-- 
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 53130] New: 99c65ba breaks rendering (flickery, eventual fail)

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53130

 Bug #: 53130
   Summary: 99c65ba breaks rendering (flickery, eventual fail)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: bugs...@moreofthesa.me.uk


I noticed broken rendering in mesa git fairly recently.

In Unvanquished (current release), the effect with its GL3 renderer is that the
display becomes more and more flickery, and eventually rendering apparently
ceases; the game remains otherwise responsive. Its GL ('vanilla' renderer, much
as in Tremulous) is unaffected.

Bisection points at the following commit; I've confirmed locally that git
master with this reverted does not exhibit the broken behaviour.

commit 99c65bac341f808279a8a847158ace4f058aa72e
Author: Marek Olšák mar...@gmail.com
Date:   Sun Feb 26 20:37:43 2012 +0100

r600g: implement wait-free buffer transfer for DISCARD_RANGE

Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com

-- 
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 53130] 99c65ba breaks rendering (flickery, eventual fail)

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=53130

--- Comment #1 from Darren Salt bugs...@moreofthesa.me.uk 2012-08-04 21:09:24 
UTC ---
Linux 3.5; HD6770.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI
Juniper XT [AMD Radeon HD 6000 Series] [1002:68ba]

-- 
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: [Nouveau] [PATCH] nouveau: Do not use nva3 engine for 0xaf chipset

2012-08-04 Thread Ben Skeggs 
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote:
 The nva3 copy engine exhibits random memory corruption in at least one
 case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1.  This patch
 omits creating the engine for the specific chipset, falling back to
 M2MF, which kills the symptoms.
I've pushed this (with slightly modified commit message) to nouveau git.

I'll get it to Linus' tree in a future -fixes merge.

Thanks,
Ben.

 
 Signed-off-by: Henrik Rydberg rydb...@euromail.se
 ---
 Hi Ben,
 
 this patch is still needed in 3.6-rc1, so perhaps we should apply it
 after all. I have been running it without problems for a long time
 now.
 
 Thanks,
 Henrik
 
  drivers/gpu/drm/nouveau/nouveau_state.c | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
 b/drivers/gpu/drm/nouveau/nouveau_state.c
 index 1cdfd6e..1866dbb 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_state.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_state.c
 @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev)
   case 0xa3:
   case 0xa5:
   case 0xa8:
 - case 0xaf:
   nva3_copy_create(dev);
   break;
   }
 -- 
 1.7.11.4
 
 ___
 Nouveau mailing list
 nouv...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #108 from Alexandre Demers alexandre.f.dem...@gmail.com 
2012-08-05 04:29:39 UTC ---
Oops, I've hit a va error again. I've been using my computer all day long,
going from one window to another, using Flash on Openstreetmap and Google Map.
The error could explain some lockups I've experienced. I hit the card's maximum
memory from what I understand of the error. Should I put collected info here or
under bug 53111?

-- 
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 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11

2012-08-04 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #109 from Alexandre Demers alexandre.f.dem...@gmail.com 
2012-08-05 04:34:02 UTC ---
(In reply to comment #108)
 Oops, I've hit a va error again. I've been using my computer all day long,
 going from one window to another, using Flash on Openstreetmap and Google Map.
 The error could explain some lockups I've experienced. I hit the card's 
 maximum
 memory from what I understand of the error. Should I put collected info here 
 or
 under bug 53111?

Here is the error message without any log for now. I'll wait to see if it
should be tracked here:
[54804.656571] radeon :01:00.0: offset 0x40 is in reserved area
0x80
[54805.166815] radeon :01:00.0: bo 8800c227d800 va 0x02B0 conflict
with (bo 880202702400 0x0244 0x0344)
[54805.177976] radeon :01:00.0: bo 8800c227b000 va 0x02C38000 conflict
with (bo 880202702400 0x0244 0x0344)
[54805.178980] radeon :01:00.0: bo 880061241400 va 0x02C38000 conflict
with (bo 880202702400 0x0244 0x0344)
[54805.253953] radeon :01:00.0: bo 88021b183800 va 0x0090 conflict
with (bo 880fc000 0x0090 0x00901000)
[54806.900210] radeon :01:00.0: va above limit (0x00100200  0x0010)
[54806.927121] radeon :01:00.0: va above limit (0x001000B0  0x0010)
[54811.663812] radeon :01:00.0: bo 880223631c00 va 0x01278000 conflict
with (bo 88020270b000 0x0120 0x0170)
[54813.069082] radeon :01:00.0: bo 88021b183800 va 0x0090 conflict
with (bo 880fc000 0x0090 0x00901000)
[54813.075691] radeon :01:00.0: bo 88007f002c00 va 0x0090 conflict
with (bo 880fc000 0x0090 0x00901000)
[54813.075886] radeon :01:00.0: bo 88007f002000 va 0x0090 conflict
with (bo 880fc000 0x0090 0x00901000)
[54813.075961] gnome-shell[1025]: segfault at 50 ip 7f8af5ebe019 sp
7fff80159650 error 4 in r600_dri.so[7f8af5e53000+4b1000]

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