[Bug 43481] New: DVI-0 with unknown connection but available modes

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

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

 Bug #: 43481
   Summary: DVI-0 with unknown connection but available modes
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: h.judt at gmx.at


This might not be a bug, but a few kernel revisions ago, DVI-0 became active:

xrandr:
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
DVI-0 unknown connection (normal left inverted right x axis y axis)
   1024x768   60.0  
   800x60060.3  
   640x48059.9  
   512x384   120.0  
   400x300   120.6  
   320x240   120.1  
LVDS connected 1440x900+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
   1440x900   60.0*+
   1280x854   59.9  
   1280x800   59.8  
   1280x720   59.9  
   1152x768   59.8  
   1024x768   59.9  
   800x60059.9  
   848x48059.7  
   720x48059.7  
   640x48059.4  
VGA-0 disconnected (normal left inverted right x axis y axis)

Hardware: Lenovo Thinkpad T400
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400
Series

What's this DVI-0? LVDS and VGA-0 (when connected) work fine, and DVI-0 does
not hurt, but still I thought I'd report this here in case this shouldn't be as
it is now ;-)

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

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.12.02 at 21:06 +0100, Markus Trippelsdorf wrote:
> On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
> > On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
> > > On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> > > > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > > > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > > > > 
> > > > > > > FIX idr_layer_cache: Marking all objects used
> > > > > >
> > > > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > > > > exactly the same spot again. (CCing the drm list)
> > > > > 
> > > > > Well this is looks like write after free.
> > > > > 
> > > > > > =
> > > > > > BUG idr_layer_cache: Poison overwritten
> > > > > > -
> > > > > > Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > > Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > > Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > > Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > > Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > > Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > > 6b 6b  
> > > > > 
> > > > > And its an integer sized write of 0. If you look at the struct 
> > > > > definition
> > > > > and lookup the offset you should be able to locate the field that
> > > > > was modified.
> > > 
> > > It also happens with CONFIG_SLAB. 
> > > (If someone wants to reproduce the issue, just run a kexec boot loop and
> > > the bug will occur after a few (~10) iterations.)
> > > 
> > 
> > Can you provide the kexec command line you are using and full kernel
> > log (mostly interested in kernel option).
> 
> /usr/sbin/kexec -l "/usr/src/linux/arch/x86/boot/bzImage" 
> --append="root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit 
> rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet"
> /usr/sbin/kexec -e
> 
> (The loop happens after autologin in .zprofile:
> sleep 4 && sudo /etc/minit/ctrlaltdel/run
> (the last script kills, unmounts and then runs the two kexec commands
> above))

BTW I always see (mostly only on screen, sometimes in the logs):

[Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400, 
but the register is already in use for vector 0xf9 on another cpu
[Firmware Bug]: cpu 2, IBS interrupt offset 0 not available 
(MSRC001103A=0x0100)
[Firmware Bug]: using offset 1 for IBS interrupts
[Firmware Bug]: workaround enabled for IBS LVT offset
perf: AMD IBS detected (0x001f) 

But I hope that it is only a harmless warning. 
(perf Instruction-Based Sampling)

Robert?

-- 
Markus

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
> On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
> > On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> > > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > > > 
> > > > > > FIX idr_layer_cache: Marking all objects used
> > > > >
> > > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > > > exactly the same spot again. (CCing the drm list)
> > > > 
> > > > Well this is looks like write after free.
> > > > 
> > > > > =
> > > > > BUG idr_layer_cache: Poison overwritten
> > > > > -
> > > > > Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > > Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > > Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > > Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > > Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > > Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > > 6b  
> > > > 
> > > > And its an integer sized write of 0. If you look at the struct 
> > > > definition
> > > > and lookup the offset you should be able to locate the field that
> > > > was modified.
> > 
> > It also happens with CONFIG_SLAB. 
> > (If someone wants to reproduce the issue, just run a kexec boot loop and
> > the bug will occur after a few (~10) iterations.)
> > 
> 
> Can you provide the kexec command line you are using and full kernel
> log (mostly interested in kernel option).

/usr/sbin/kexec -l "/usr/src/linux/arch/x86/boot/bzImage" 
--append="root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit 
rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet"
/usr/sbin/kexec -e

(The loop happens after autologin in .zprofile:
sleep 4 && sudo /etc/minit/ctrlaltdel/run
(the last script kills, unmounts and then runs the two kexec commands
above))

Linux version 3.2.0-rc4-00089-g621fc1e-dirty (markus at x4.trippels.de) (gcc 
version 4.6.3 20111202 (prerelease) (GCC) ) #134 SMP PREEMPT Fri Dec 2 11:06:20 
CET 2011
Command line: root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 
init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 
quiet
KERNEL supported cpus:
  AMD AuthenticAMD
BIOS-provided physical RAM map:
 BIOS-e820: 0100 - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e6000 - 0010 (reserved)
 BIOS-e820: 0010 - dfe9 (usable)
 BIOS-e820: dfe9 - dfea8000 (ACPI data)
 BIOS-e820: dfea8000 - dfed (ACPI NVS)
 BIOS-e820: dfed - dff0 (reserved)
 BIOS-e820: fff0 - 0001 (reserved)
 BIOS-e820: 0001 - 00022000 (usable)
NX (Execute Disable) protection: active
DMI present.
DMI: System manufacturer System Product Name/M4A78T-E, BIOS 340608/20/2010
e820 update range:  - 0001 (usable) ==> (reserved)
e820 remove range: 000a - 0010 (usable)
last_pfn = 0x22 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-E uncachable
  F-F write-protect
MTRR variable ranges enabled:
  0 base  mask 8000 write-back
  1 base 8000 mask C000 write-back
  2 base C000 mask E000 write-back
  3 base F000 mask F800 write-combining
  4 disabled
  5 disabled
  6 disabled
  7 disabled
TOM2: 00022000 aka 8704M
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
last_pfn = 0xdfe90 max_arch_pfn = 0x4
initial memory mapped : 0 - 2000
Base memory trampoline at [8809d000] 9d000 size 8192
Using GB pages for direct mapping
init_memory_mapping: -dfe9
 00 - 00c000 page 1G
 00c000 - 00dfe0 page 2M
 00dfe0 - 00dfe9 page 4k
kernel direct mapping tables u

[Bug 43477] rendering errors in unigine tropics and sanctuary (regression)

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

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

--- Comment #1 from Alex Deucher  2011-12-02 12:52:02 PST 
---
Can you bisect?

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

[Bug 43478] New: rendering error in unigine sanctuary

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

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

 Bug #: 43478
   Summary: rendering error in unigine sanctuary
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: aaalmosss at gmail.com


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

Stained glass windows and reliefs are rendered with some noise added. Tested
with 7.11 and 7.12-dev on hd6850.

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

[Bug 43477] New: rendering errors in unigine tropics and sanctuary (regression)

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

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

 Bug #: 43477
   Summary: rendering errors in unigine tropics and sanctuary
(regression)
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: aaalmosss at gmail.com


Some shaders fail to compile with mesa 7.12-dev, this is printed to console a
couple of times:
GLShader::loadFragment(): error in
"core/shaders/meshes/fragment_base_light_omni.shader" file
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_TRANSLUCENT,USE_PARALLAX,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM
0:460(18): error: syntax error, unexpected NEW_IDENTIFIER

In tropics the night scenes are rendered incorrectly, in sanctuary almost
everything is gray. With 7.11 these demos render correctly. Tested on hd6850.

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

[PATCH] drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id

[alexdeuc...@gmail.com]

From: Alex Deucher 

Seems like something got mis-merged here.

Noticed by kallisti5 on IRC.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_encoders.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 06e413e..4b27efa 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -233,13 +233,12 @@ u16 radeon_encoder_get_dp_bridge_encoder_id(struct 
drm_encoder *encoder)
switch (radeon_encoder->encoder_id) {
case ENCODER_OBJECT_ID_TRAVIS:
case ENCODER_OBJECT_ID_NUTMEG:
-   return true;
+   return radeon_encoder->encoder_id;
default:
-   return false;
+   return ENCODER_OBJECT_ID_NONE;
}
}
-
-   return false;
+   return ENCODER_OBJECT_ID_NONE;
 }

 void radeon_panel_mode_fixup(struct drm_encoder *encoder,
-- 
1.7.3.4

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Jerome Glisse]

On Thu, Nov 24, 2011 at 09:50:40AM +0100, Markus Trippelsdorf wrote:
> On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > 
> > > > FIX idr_layer_cache: Marking all objects used
> > >
> > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > exactly the same spot again. (CCing the drm list)
> > 
> > Well this is looks like write after free.
> > 
> > > =
> > > BUG idr_layer_cache: Poison overwritten
> > > -
> > > Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > > Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > > Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > > Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > > Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > > Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> > > 
> > 
> > And its an integer sized write of 0. If you look at the struct definition
> > and lookup the offset you should be able to locate the field that
> > was modified.
> 
> Here are two more BUGs that seem to point to the same bug:
> 
> 1)
> ...
> Nov 21 18:30:30 x4 kernel: [drm] radeon: irq initialized.
> Nov 21 18:30:30 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
> 131072
> Nov 21 18:30:30 x4 kernel: [drm] Loading RS780 Microcode
> Nov 21 18:30:30 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
> 0xC004).
> Nov 21 18:30:30 x4 kernel: radeon :01:05.0: WB enabled
> Nov 21 18:30:30 x4 kernel: 
> =
> Nov 21 18:30:30 x4 kernel: BUG task_xstate: Not a valid slab page
> Nov 21 18:30:30 x4 kernel: 
> -
> Nov 21 18:30:30 x4 kernel:
> Nov 21 18:30:30 x4 kernel: INFO: Slab 0xea044300 objects=32767 
> used=65535 fp=0x  (null) flags=0x0401
> Nov 21 18:30:30 x4 kernel: Pid: 9, comm: ksoftirqd/1 Not tainted 
> 3.2.0-rc2-00274-g6fe4c6d-dirty #75
> Nov 21 18:30:30 x4 kernel: Call Trace:
> Nov 21 18:30:30 x4 kernel: [] slab_err+0x7d/0x90
> Nov 21 18:30:30 x4 kernel: [] ? dump_trace+0x16f/0x2e0
> Nov 21 18:30:30 x4 kernel: [] ? free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [] ? free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [] check_slab+0x96/0xc0
> Nov 21 18:30:30 x4 kernel: [] 
> free_debug_processing+0x34/0x19c
> Nov 21 18:30:30 x4 kernel: [] ? set_track+0x5a/0x190
> Nov 21 18:30:30 x4 kernel: [] ? sys_open+0x1b/0x20
> Nov 21 18:30:30 x4 kernel: [] __slab_free+0x33/0x2d0
> Nov 21 18:30:30 x4 kernel: [] ? sys_open+0x1b/0x20
> Nov 21 18:30:30 x4 kernel: [] kmem_cache_free+0x104/0x120
> Nov 21 18:30:30 x4 kernel: [] free_thread_xstate+0x24/0x40
> Nov 21 18:30:30 x4 kernel: [] free_thread_info+0x14/0x30
> Nov 21 18:30:30 x4 kernel: [] free_task+0x2f/0x50
> Nov 21 18:30:30 x4 kernel: [] __put_task_struct+0xb0/0x110
> Nov 21 18:30:30 x4 kernel: [] 
> delayed_put_task_struct+0x3b/0xa0
> Nov 21 18:30:30 x4 kernel: [] 
> __rcu_process_callbacks+0x12a/0x350
> Nov 21 18:30:30 x4 kernel: [] 
> rcu_process_callbacks+0x62/0x140
> Nov 21 18:30:30 x4 kernel: [] __do_softirq+0xa8/0x200
> Nov 21 18:30:30 x4 kernel: [] run_ksoftirqd+0x107/0x210
> Nov 21 18:30:30 x4 kernel: [] ? __do_softirq+0x200/0x200
> Nov 21 18:30:30 x4 kernel: [] kthread+0x87/0x90
> Nov 21 18:30:30 x4 kernel: [] kernel_thread_helper+0x4/0x10
> Nov 21 18:30:30 x4 kernel: [] ? 
> kthread_flush_work_fn+0x10/0x10
> Nov 21 18:30:30 x4 kernel: [] ? gs_change+0xb/0xb
> Nov 21 18:30:30 x4 kernel: FIX task_xstate: Object at 0x8110cf2b not 
> freed
> Nov 21 18:30:30 x4 kernel: [drm] ring test succeeded in 1 usecs
> Nov 21 18:30:30 x4 kernel: [drm] radeon: ib pool ready.
> Nov 21 18:30:30 x4 kernel: [drm] ib test succeeded in 0 usecs
> Nov 21 18:30:30 x4 kernel: [drm] Radeon Display Connectors
> Nov 21 18:30:30 x4 kernel: [drm] Connector 0
> 
> 2)
> ...
> Nov 21 17:04:38 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
> Nov 21 17:04:38 x4 kernel: Console: switching to colour frame buffer device 
> 131x105
> Nov 21 17:04:38 x4 kernel: fb0: radeondrmfb frame buffer device
> Nov 21 17:04:38 x4 kernel: drm: registered panic notifier
> Nov 21 17:04:38 x4 kernel: [drm] Initialized radeon 2.11.0 20080528 for 
> :01:05.0 on minor 0
> Nov 21 17:04:38 x4 kernel: loop: module loaded
> Nov 21 17:04:38 x4 kernel: ahci :00:11.0: version 3.0
> Nov 21 17:04:38 x4 kernel: ahci :00:11.0: PCI INT A -> GSI 22 (level, 
> low) -> IRQ 22
> Nov 21 17:04:38 x4 kernel: ahci :00:11.0: AHCI 0001.0100 32 

[PATCH] UGLY DEBUGING

[Jerome Glisse]

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
---
 drivers/gpu/drm/drm_crtc.c |2 ++
 drivers/gpu/drm/drm_pci.c  |2 ++
 drivers/gpu/drm/drm_platform.c |2 ++
 lib/idr.c  |6 +-
 mm/slab.c  |2 +-
 5 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8323fc3..a1a0a69 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -242,6 +242,7 @@ again:

obj->id = new_id;
obj->type = obj_type;
+DRM_INFO("allocating idr %p %d idr %d\n", obj, obj_type, new_id);
return 0;
 }

@@ -259,6 +260,7 @@ static void drm_mode_object_put(struct drm_device *dev,
struct drm_mode_object *object)
 {
mutex_lock(>mode_config.idr_mutex);
+DRM_INFO("remove idr %p %d idr %d\n", object, object->type, object->id);
idr_remove(>mode_config.crtc_idr, object->id);
mutex_unlock(>mode_config.idr_mutex);
 }
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index d4d10b7..7932ebb 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -345,11 +345,13 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,

if (drm_core_check_feature(dev, DRIVER_MODESET)) {
pci_set_drvdata(pdev, dev);
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
goto err_g2;
}

+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
if ((ret = drm_get_minor(dev, >primary, DRM_MINOR_LEGACY)))
goto err_g3;

diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index ae9db5e..3e7e401 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -65,11 +65,13 @@ int drm_get_platform_dev(struct platform_device *platdev,

if (drm_core_check_feature(dev, DRIVER_MODESET)) {
dev_set_drvdata(>dev, dev);
+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, >control, DRM_MINOR_CONTROL);
if (ret)
goto err_g1;
}

+printk(KERN_INFO "%s %d\n", __func__, __LINE__);
ret = drm_get_minor(dev, >primary, DRM_MINOR_LEGACY);
if (ret)
goto err_g2;
diff --git a/lib/idr.c b/lib/idr.c
index ed055b2..22c3ec6 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -427,6 +427,7 @@ void idr_remove(struct idr *idp, int id)
 * layers that fall into the freelist are those that have been
 * preallocated.
 */
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
}
return;
@@ -489,6 +490,7 @@ void idr_destroy(struct idr *idp)
 {
while (idp->id_free_cnt) {
struct idr_layer *p = get_from_free_list(idp);
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
}
 }
@@ -841,8 +843,10 @@ int ida_get_new_above(struct ida *ida, int starting_id, 
int *p_id)
 */
if (ida->idr.id_free_cnt || ida->free_bitmap) {
struct idr_layer *p = get_from_free_list(>idr);
-   if (p)
+   if (p) {
+printk(KERN_INFO "%s free idr %p\n", __func__, p);
kmem_cache_free(idr_layer_cache, p);
+   }
}

return 0;
diff --git a/mm/slab.c b/mm/slab.c
index 708efe8..83864f9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1926,7 +1926,7 @@ static void check_poison_obj(struct kmem_cache *cachep, 
void *objp)
/* Mismatch ! */
/* Print header */
if (lines == 0) {
-   printk(KERN_ERR
+   WARN(1, 
"Slab corruption: %s start=%p, 
len=%d\n",
cachep->name, realobj, size);
print_objinfo(cachep, objp, 0);
-- 
1.7.7.1


--6c2NcOVqGQ03X4Wi--

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54078|text/x-log  |text/plain
  mime type||
  Attachment #54078|0   |1
   is patch||

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54077|application/octet-stream|text/plain
  mime type||
  Attachment #54077|0   |1
   is patch||

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #4 from marc-aurele  2011-12-02 07:20:40 
PST ---
Created attachment 54078
  --> https://bugs.freedesktop.org/attachment.cgi?id=54078
xorg log

And here is my xorg log. Thanks for your interest and sorry for the bad glxinfo
log.

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #3 from marc-aurele  2011-12-02 07:15:26 
PST ---
Created attachment 54077
  --> https://bugs.freedesktop.org/attachment.cgi?id=54077
libgl verbose glxinfo

Here is the correct output of LIBGL_DEBUG=verbose glxinfo

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

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Jerome Glisse]

On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
> On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
> > On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> > > On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > > 
> > > > > FIX idr_layer_cache: Marking all objects used
> > > >
> > > > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > > > exactly the same spot again. (CCing the drm list)
> > > 
> > > Well this is looks like write after free.
> > > 
> > > > =
> > > > BUG idr_layer_cache: Poison overwritten
> > > > -
> > > > Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > > Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > > Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > > Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > > Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > > Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
> > > > 6b  
> > > 
> > > And its an integer sized write of 0. If you look at the struct definition
> > > and lookup the offset you should be able to locate the field that
> > > was modified.
> 
> It also happens with CONFIG_SLAB. 
> (If someone wants to reproduce the issue, just run a kexec boot loop and
> the bug will occur after a few (~10) iterations.)
> 

Can you provide the kexec command line you are using and full kernel
log (mostly interested in kernel option).

Cheers,
Jerome

[RFC v2 2/2] dma-buf: Documentation for buffer sharing framework

[Sumit Semwal]

Add documentation for dma buffer sharing framework, explaining the
various operations, members and API of the dma buffer sharing
framework.

Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 Documentation/dma-buf-sharing.txt |  223 +
 1 files changed, 223 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
new file mode 100644
index 000..2c1bdf6
--- /dev/null
+++ b/Documentation/dma-buf-sharing.txt
@@ -0,0 +1,223 @@
+DMA Buffer Sharing API Guide
+
+
+Sumit Semwal
+
+ 
+
+This document serves as a guide to device-driver writers on what is the dma-buf
+buffer sharing API, how to use it for exporting and using shared buffers.
+
+Any device driver which wishes to be a part of DMA buffer sharing, can do so as
+either the 'exporter' of buffers, or the 'user' of buffers.
+
+Say a driver A wants to use buffers created by driver B, then we call B as the
+exporter, and A as buffer-user.
+
+The exporter
+- implements and manages operations[1] for the buffer
+- allows other users to share the buffer by using dma_buf sharing APIs,
+- manages the details of buffer allocation,
+- decides about the actual backing storage where this allocation happens,
+- takes care of any migration of scatterlist - for all (shared) users of this
+   buffer,
+- optionally, provides mmap capability for drivers that need it.
+
+The buffer-user
+- is one of (many) sharing users of the buffer.
+- doesn't need to worry about how the buffer is allocated, or where.
+- needs a mechanism to get access to the scatterlist that makes up this buffer
+   in memory, mapped into its own address space, so it can access the same area
+   of memory.
+
+
+The dma_buf buffer sharing API usage contains the following steps:
+
+1. Exporter announces that it wishes to export a buffer
+2. Userspace gets the file descriptor associated with the exported buffer, and
+   passes it around to potential buffer-users based on use case
+3. Each buffer-user 'connects' itself to the buffer
+4. When needed, buffer-user requests access to the buffer from exporter
+5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
+6. when buffer-user is done using this buffer completely, it 'disconnects'
+   itself from the buffer.
+
+
+1. Exporter's announcement of buffer export
+
+   The buffer exporter announces its wish to export a buffer. In this, it
+   connects its own private buffer data, provides implementation for operations
+   that can be performed on the exported dma_buf, and flags for the file
+   associated with this buffer.
+
+   Interface:
+  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+int flags)
+
+   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
+   pointer to the same. It also associates an anonymous file with this buffer,
+   so it can be exported. On failure to allocate the dma_buf object, it returns
+   NULL.
+
+2. Userspace gets a handle to pass around to potential buffer-users
+
+   Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
+   anonymous file associated with the buffer. It can then share the fd with 
other
+   drivers and/or processes.
+
+   Interface:
+  int dma_buf_fd(struct dma_buf *dmabuf)
+
+   This API installs an fd for the anonymous file associated with this buffer;
+   returns either 'fd', or error.
+
+3. Each buffer-user 'connects' itself to the buffer
+
+   Each buffer-user now gets a reference to the buffer, using the fd passed to
+   it.
+
+   Interface:
+  struct dma_buf *dma_buf_get(int fd)
+
+   This API will return a reference to the dma_buf, and increment refcount for
+   it.
+
+   After this, the buffer-user needs to attach its device with the buffer, 
which
+   helps the exporter to know of device buffer constraints.
+
+   Interface:
+  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+struct device *dev)
+
+   This API returns reference to an attachment structure, which is then used
+   for scatterlist operations. It will optionally call the 'attach' dma_buf
+   operation, if provided by the exporter.
+
+   The dma-buf sharing framework does the bookkeeping bits related to managing
+   the list of all attachments to a buffer.
+
+Until this stage, the buffer-exporter has the option to choose not to actually
+allocate the backing storage for this buffer, but wait for the first 
buffer-user
+to request use of buffer for allocation.
+
+
+4. When needed, buffer-user requests access to the buffer
+
+   Whenever a buffer-user wants to use the buffer for any DMA, it asks for
+   access to the buffer using dma_buf_map_attachment 

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Sumit Semwal]

This is the first step in defining a dma buffer sharing mechanism.

A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.

Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.

*OPTIONALLY*: mmap() file operation is provided for the associated 'fd', as
wrapper over the optional allocator defined mmap(), to be used by devices
that might need one.

More details are there in the documentation patch.

This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann , Rob Clark  
and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer 
sharing
between two v4l2 devices. [2]

[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 drivers/base/Kconfig|   10 ++
 drivers/base/Makefile   |1 +
 drivers/base/dma-buf.c  |  290 +++
 include/linux/dma-buf.h |  176 
 4 files changed, 477 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..07d8095 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,14 @@ config SYS_HYPERVISOR

 source "drivers/base/regmap/Kconfig"

+config DMA_SHARED_BUFFER
+   bool "Buffer framework to be shared between drivers"
+   default n
+   depends on ANON_INODES
+   help
+ This option enables the framework for buffer-sharing between
+ multiple drivers. A buffer is associated with a file using driver
+ APIs extension; the file's descriptor can then be passed on to other
+ driver.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 99a375a..d0df046 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)  += devtmpfs.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
new file mode 100644
index 000..4b9005e
--- /dev/null
+++ b/drivers/base/dma-buf.c
@@ -0,0 +1,290 @@
+/*
+ * Framework for buffer objects that can be shared across devices/subsystems.
+ *
+ * Copyright(C) 2011 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwal 
+ *
+ * Many thanks to linaro-mm-sig list, and specially
+ * Arnd Bergmann , Rob Clark  and
+ * Daniel Vetter  for their support in creation and
+ * refining of this idea.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static inline int is_dma_buf_file(struct file *);
+
+static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   if (!dmabuf->ops->mmap)
+   return -EINVAL;
+
+   return dmabuf->ops->mmap(dmabuf, vma);
+}
+
+static int dma_buf_release(struct inode *inode, struct file *file)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   

[RFC v2 0/2] Introduce DMA buffer sharing mechanism

[Sumit Semwal]

Hello Everyone,

This is RFC v2 for DMA buffer sharing mechanism - changes from v1 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann , Rob Clark  
and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer 
sharing
between two v4l2 devices. [2]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v2

Earlier version at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users

- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original

Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  223 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  290 +
 include/linux/dma-buf.h   |  176 ++
 5 files changed, 700 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #2 from Alex Deucher  2011-12-02 06:07:09 PST 
---
Looks like you attached the wrong glxinfo output.  Please attach your xorg log
as well.

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54049|application/octet-stream|text/plain
  mime type||
  Attachment #54049|0   |1
   is patch||

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

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54048|application/octet-stream|text/plain
  mime type||
  Attachment #54048|0   |1
   is patch||

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

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Konrad Rzeszutek Wilk]

On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
> 
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
> 
> The framework allows:
> - different devices to 'attach' themselves to this buffer, to facilitate
>   backing storage negotiation, using dma_buf_attach() API.
> - association of a file pointer with each user-buffer and associated
>allocator-defined operations on that buffer. This operation is called the
>'export' operation.
> - this exported buffer-object to be shared with the other entity by asking for
>its 'file-descriptor (fd)', and sharing the fd across.
> - a received fd to get the buffer object back, where it can be accessed using
>the associated exporter-defined operations.
> - the exporter and user to share the scatterlist using map_dma_buf and
>unmap_dma_buf operations.
> 
> Atleast one 'attach()' call is required to be made prior to calling the
> map_dma_buf() operation.
> 
> Couple of building blocks in map_dma_buf() are added to ease introduction
> of sync'ing across exporter and users, and late allocation by the exporter.
> 
> *OPTIONALLY*: mmap() file operation is provided for the associated 'fd', as
> wrapper over the optional allocator defined mmap(), to be used by devices
> that might need one.
> 
> More details are there in the documentation patch.
> 
> This is based on design suggestions from many people at the mini-summits[1],
> most notably from Arnd Bergmann , Rob Clark  
> and
> Daniel Vetter .
> 
> The implementation is inspired from proof-of-concept patch-set from
> Tomasz Stanislawski , who demonstrated buffer 
> sharing
> between two v4l2 devices. [2]
> 
> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
> [2]: http://lwn.net/Articles/454389
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 

You have a clone? You only need one SOB.


> ---
>  drivers/base/Kconfig|   10 ++
>  drivers/base/Makefile   |1 +
>  drivers/base/dma-buf.c  |  290 
> +++
>  include/linux/dma-buf.h |  176 
>  4 files changed, 477 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/base/dma-buf.c
>  create mode 100644 include/linux/dma-buf.h
> 
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 21cf46f..07d8095 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -174,4 +174,14 @@ config SYS_HYPERVISOR
>  
>  source "drivers/base/regmap/Kconfig"
>  
> +config DMA_SHARED_BUFFER
> + bool "Buffer framework to be shared between drivers"
> + default n
> + depends on ANON_INODES
> + help
> +   This option enables the framework for buffer-sharing between
> +   multiple drivers. A buffer is associated with a file using driver
> +   APIs extension; the file's descriptor can then be passed on to other
> +   driver.
> +
>  endmenu
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 99a375a..d0df046 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)+= devtmpfs.o
>  obj-y+= power/
>  obj-$(CONFIG_HAS_DMA)+= dma-mapping.o
>  obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
> +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
>  obj-$(CONFIG_ISA)+= isa.o
>  obj-$(CONFIG_FW_LOADER)  += firmware_class.o
>  obj-$(CONFIG_NUMA)   += node.o
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> new file mode 100644
> index 000..4b9005e
> --- /dev/null
> +++ b/drivers/base/dma-buf.c
> @@ -0,0 +1,290 @@
> +/*
> + * Framework for buffer objects that can be shared across devices/subsystems.
> + *
> + * Copyright(C) 2011 Linaro Limited. All rights reserved.
> + * Author: Sumit Semwal 

OK, so the SOB should be from @ti.com then.

> + *
> + * Many thanks to linaro-mm-sig list, and specially
> + * Arnd Bergmann , Rob Clark  and
> + * Daniel Vetter  for their support in creation and
> + * refining of this idea.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static inline int is_dma_buf_file(struct file *);
> +
> +static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + 

[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M

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

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

--- Comment #8 from Marek Ol??k  2011-12-02 03:18:31 PST 
---
I've got a hunch that the texture hack is GPU-dependent. The comment next to
the hack suggests it fixes a problem on Evergreen. The problem might have been
fixed already by some other commit, not sure.

I am okay with reverting the commit.

Ideally piglit should be tested on Evergreen and if there are regressions, the
hack should be applied to Evergreen only, or another solution should be found,
but I guess that can be sorted out after the revert.

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

nouveau fixes contain a few oops fixes found on Fedora recently, 
main radeon one fixes a GPU reset race where the CPU hangs in an endless loop,
and in core a framebuffer leak fix from Chris.

Otherwise a couple of radeon scanout fixes for a case we hadn't tested a 
lot, and dropping an ACPI message that was a bit louder than it should 
have been.

Dave.


The following changes since commit 11d814a20166461358e1cefaf6bcd425698b8460:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband (2011-11-30 
16:25:02 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (4):
  drm/radeon/kms: add some loop timeouts in pageflip code
  drm/radeon/kms: add some new pci ids
  drm/radeon/kms: fix scanout of 2D tiled buffers on EG/CM
  drm/radeon/kms: fix 2D tiling CS support on EG/CM

Ben Skeggs (4):
  drm/nouveau: add dumb ioctl support
  drm/nvd0/disp: fix sor dpms typo, preventing dpms on in some situations
  drm/nouveau: fix oopses caused by clear being called on unpopulated ttms
  drm/nv50/disp: silence compiler warning

Chris Wilson (1):
  drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)

Christoph Bumiller (1):
  drm/nvc0/gr: fix TP init for transform feedback offset queries

Dave Airlie (1):
  Merge branch 'drm-nouveau-fixes' of 
git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Jean Delvare (2):
  drm/radeon/kms: Hide debugging message
  drm/radeon/kms: Skip ACPI call to ATIF when possible

Xi Wang (1):
  vmwgfx: integer overflow in vmw_kms_update_layout_ioctl()

Younes Manton (1):
  drm/nouveau: Keep RAMIN heap within the channel.

 drivers/gpu/drm/drm_crtc_helper.c |   27 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |   45 +
 drivers/gpu/drm/nouveau/nouveau_drv.c |4 +
 drivers/gpu/drm/nouveau/nouveau_drv.h |6 +
 drivers/gpu/drm/nouveau/nouveau_object.c  |2 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c   |3 +
 drivers/gpu/drm/nouveau/nv50_display.c|4 +-
 drivers/gpu/drm/nouveau/nvc0_graph.c  |2 +
 drivers/gpu/drm/nouveau/nvd0_display.c|2 +-
 drivers/gpu/drm/radeon/atombios_crtc.c|   35 +++-
 drivers/gpu/drm/radeon/evergreen.c|7 +-
 drivers/gpu/drm/radeon/evergreen_cs.c |  149 -
 drivers/gpu/drm/radeon/evergreen_reg.h|   29 ++
 drivers/gpu/drm/radeon/evergreend.h   |   31 ++
 drivers/gpu/drm/radeon/r100.c |7 +-
 drivers/gpu/drm/radeon/radeon_acpi.c  |   11 +-
 drivers/gpu/drm/radeon/rs600.c|7 +-
 drivers/gpu/drm/radeon/rv770.c|7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   11 +-
 include/drm/drm_pciids.h  |8 ++
 20 files changed, 349 insertions(+), 48 deletions(-)

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7

[Konrad Rzeszutek Wilk]

On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote:
> On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com wrote:
> > Important fix to patch 14, fix accounting of ghost bo. When creating a
> > ghost bo we don't account it, so set its acc_size to 0 so that when
> > ghost is release we don't overfree.
> > 
> > I wonder how i didn't run into this before.
> > 
> > Patch are also at
> > 
> > http://people.freedesktop.org/~glisse/ttmdma/
> > 
> > Cheers,
> > Jerome
> > 
> 
> Oh i forgot to add some of the reviewed by, i updated patches on fdo,
> i don't resend to the ml.

Great! How should we ask Dave to pull them? Does he prefer to do it via git
tree? In which I can create a branch with those patches and send him a GIT PULL
email? Or is there a more convient way?

> Cheers,
> Jerome

[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M

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

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

--- Comment #7 from idunham at lavabit.com 2011-12-01 22:54:50 PST ---
Created attachment 54051
  --> https://bugs.freedesktop.org/attachment.cgi?id=54051
Revert texture hack

Revert the relevant commit.
This results in good graphics with both glxgears & Google Earth.

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

No subject

start_kernel
|-> setup_arch
|-> x86_init.oem.arch_setup = xen_arch_setup

|-> check_bugs
|-> identify_boot_cpu
|-> identify_cpu
|-> select_idle_routine


so xen_arch_setup will set pm_idle and select_idle_routine will honour
it. I'm being told this is run either in the dom0 or the paravirt guest
and if so, I don't see any issue with this for baremetal. So you can
have my ACK provided this is tested on baremetal too.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

--- Comment #1 from marc-aurele  2011-12-01 19:26:28 
PST ---
Created attachment 54049
  --> https://bugs.freedesktop.org/attachment.cgi?id=54049
libgl verbose glxinfo

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

[Bug 43448] New: No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

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

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

 Bug #: 43448
   Summary: No native 3D acceleration with Radeon FirePro M7740
(m97 / rv740) -> llvm pipe
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: marcaureleii at yahoo.fr


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

Dear,

I try to get native 3D acceleration with my graphic card. I have a Dell
Precision M6500 with Radeon FirePro M7740. The chipset (rv740) is rather well
supported but I can't obtain native 3D acceleration. I have Linux Fedora 16,
libmesa 7.11.1.

I don't understand where is the problem...

I attach my dmesg and LIBGL_DEBUG=verbose glxinfo. This last one indicates :
"libGL error: failed to create dri screen"

Please help me.

Thanks a lot

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

[Bug 43444] New: i915_get_shader_param: Unknown cap 19.

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

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

 Bug #: 43444
   Summary: i915_get_shader_param: Unknown cap 19.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com


-- chipset: 945GM
-- system architecture: i686
-- xf86-video-intel: 2.15.901
-- xserver: 1.10.4
-- mesa: a4c952f36f0c6b55f1410bc678b21f75de253a74 (master)
-- libdrm version: 2.4.27
-- kernel version: 3.2.0-2-generic
-- Linux distribution: Ubuntu 12.04 i386

Run piglit. Many tests will display this warning message.

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

[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M

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

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

--- Comment #6 from idunham at lavabit.com 2011-12-01 16:28:46 PST ---
Reverting the commit results in perfect display.

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

[RFC v2 2/2] dma-buf: Documentation for buffer sharing framework

[Sumit Semwal]

Add documentation for dma buffer sharing framework, explaining the
various operations, members and API of the dma buffer sharing
framework.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 Documentation/dma-buf-sharing.txt |  223 +
 1 files changed, 223 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
new file mode 100644
index 000..2c1bdf6
--- /dev/null
+++ b/Documentation/dma-buf-sharing.txt
@@ -0,0 +1,223 @@
+DMA Buffer Sharing API Guide
+
+
+Sumit Semwal
+sumit dot semwal at linaro dot org
+ sumit dot semwal at ti dot com
+
+This document serves as a guide to device-driver writers on what is the dma-buf
+buffer sharing API, how to use it for exporting and using shared buffers.
+
+Any device driver which wishes to be a part of DMA buffer sharing, can do so as
+either the 'exporter' of buffers, or the 'user' of buffers.
+
+Say a driver A wants to use buffers created by driver B, then we call B as the
+exporter, and A as buffer-user.
+
+The exporter
+- implements and manages operations[1] for the buffer
+- allows other users to share the buffer by using dma_buf sharing APIs,
+- manages the details of buffer allocation,
+- decides about the actual backing storage where this allocation happens,
+- takes care of any migration of scatterlist - for all (shared) users of this
+   buffer,
+- optionally, provides mmap capability for drivers that need it.
+
+The buffer-user
+- is one of (many) sharing users of the buffer.
+- doesn't need to worry about how the buffer is allocated, or where.
+- needs a mechanism to get access to the scatterlist that makes up this buffer
+   in memory, mapped into its own address space, so it can access the same area
+   of memory.
+
+
+The dma_buf buffer sharing API usage contains the following steps:
+
+1. Exporter announces that it wishes to export a buffer
+2. Userspace gets the file descriptor associated with the exported buffer, and
+   passes it around to potential buffer-users based on use case
+3. Each buffer-user 'connects' itself to the buffer
+4. When needed, buffer-user requests access to the buffer from exporter
+5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
+6. when buffer-user is done using this buffer completely, it 'disconnects'
+   itself from the buffer.
+
+
+1. Exporter's announcement of buffer export
+
+   The buffer exporter announces its wish to export a buffer. In this, it
+   connects its own private buffer data, provides implementation for operations
+   that can be performed on the exported dma_buf, and flags for the file
+   associated with this buffer.
+
+   Interface:
+  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+int flags)
+
+   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
+   pointer to the same. It also associates an anonymous file with this buffer,
+   so it can be exported. On failure to allocate the dma_buf object, it returns
+   NULL.
+
+2. Userspace gets a handle to pass around to potential buffer-users
+
+   Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
+   anonymous file associated with the buffer. It can then share the fd with 
other
+   drivers and/or processes.
+
+   Interface:
+  int dma_buf_fd(struct dma_buf *dmabuf)
+
+   This API installs an fd for the anonymous file associated with this buffer;
+   returns either 'fd', or error.
+
+3. Each buffer-user 'connects' itself to the buffer
+
+   Each buffer-user now gets a reference to the buffer, using the fd passed to
+   it.
+
+   Interface:
+  struct dma_buf *dma_buf_get(int fd)
+
+   This API will return a reference to the dma_buf, and increment refcount for
+   it.
+
+   After this, the buffer-user needs to attach its device with the buffer, 
which
+   helps the exporter to know of device buffer constraints.
+
+   Interface:
+  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+struct device *dev)
+
+   This API returns reference to an attachment structure, which is then used
+   for scatterlist operations. It will optionally call the 'attach' dma_buf
+   operation, if provided by the exporter.
+
+   The dma-buf sharing framework does the bookkeeping bits related to managing
+   the list of all attachments to a buffer.
+
+Until this stage, the buffer-exporter has the option to choose not to actually
+allocate the backing storage for this buffer, but wait for the first 
buffer-user
+to request use of buffer for allocation.
+
+
+4. When needed, buffer-user requests access to the buffer
+
+   Whenever a buffer-user 

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Sumit Semwal]

This is the first step in defining a dma buffer sharing mechanism.

A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.

Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.

*OPTIONALLY*: mmap() file operation is provided for the associated 'fd', as
wrapper over the optional allocator defined mmap(), to be used by devices
that might need one.

More details are there in the documentation patch.

This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
Daniel Vetter dan...@ffwll.ch.

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices. [2]

[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 drivers/base/Kconfig|   10 ++
 drivers/base/Makefile   |1 +
 drivers/base/dma-buf.c  |  290 +++
 include/linux/dma-buf.h |  176 
 4 files changed, 477 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..07d8095 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,14 @@ config SYS_HYPERVISOR
 
 source drivers/base/regmap/Kconfig
 
+config DMA_SHARED_BUFFER
+   bool Buffer framework to be shared between drivers
+   default n
+   depends on ANON_INODES
+   help
+ This option enables the framework for buffer-sharing between
+ multiple drivers. A buffer is associated with a file using driver
+ APIs extension; the file's descriptor can then be passed on to other
+ driver.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 99a375a..d0df046 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)  += devtmpfs.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
new file mode 100644
index 000..4b9005e
--- /dev/null
+++ b/drivers/base/dma-buf.c
@@ -0,0 +1,290 @@
+/*
+ * Framework for buffer objects that can be shared across devices/subsystems.
+ *
+ * Copyright(C) 2011 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwal sumit.sem...@ti.com
+ *
+ * Many thanks to linaro-mm-sig list, and specially
+ * Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
+ * Daniel Vetter dan...@ffwll.ch for their support in creation and
+ * refining of this idea.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/fs.h
+#include linux/slab.h
+#include linux/dma-buf.h
+#include linux/anon_inodes.h
+#include linux/export.h
+
+static inline int is_dma_buf_file(struct file *);
+
+static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   if (!dmabuf-ops-mmap)
+   

[RFC v2 0/2] Introduce DMA buffer sharing mechanism

[Sumit Semwal]

Hello Everyone,

This is RFC v2 for DMA buffer sharing mechanism - changes from v1 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
Daniel Vetter dan...@ffwll.ch.

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices. [2]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v2

Earlier version at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users
 
- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original

Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  223 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  290 +
 include/linux/dma-buf.h   |  176 ++
 5 files changed, 700 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

nouveau fixes contain a few oops fixes found on Fedora recently, 
main radeon one fixes a GPU reset race where the CPU hangs in an endless loop,
and in core a framebuffer leak fix from Chris.

Otherwise a couple of radeon scanout fixes for a case we hadn't tested a 
lot, and dropping an ACPI message that was a bit louder than it should 
have been.

Dave.


The following changes since commit 11d814a20166461358e1cefaf6bcd425698b8460:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband (2011-11-30 
16:25:02 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (4):
  drm/radeon/kms: add some loop timeouts in pageflip code
  drm/radeon/kms: add some new pci ids
  drm/radeon/kms: fix scanout of 2D tiled buffers on EG/CM
  drm/radeon/kms: fix 2D tiling CS support on EG/CM

Ben Skeggs (4):
  drm/nouveau: add dumb ioctl support
  drm/nvd0/disp: fix sor dpms typo, preventing dpms on in some situations
  drm/nouveau: fix oopses caused by clear being called on unpopulated ttms
  drm/nv50/disp: silence compiler warning

Chris Wilson (1):
  drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)

Christoph Bumiller (1):
  drm/nvc0/gr: fix TP init for transform feedback offset queries

Dave Airlie (1):
  Merge branch 'drm-nouveau-fixes' of 
git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Jean Delvare (2):
  drm/radeon/kms: Hide debugging message
  drm/radeon/kms: Skip ACPI call to ATIF when possible

Xi Wang (1):
  vmwgfx: integer overflow in vmw_kms_update_layout_ioctl()

Younes Manton (1):
  drm/nouveau: Keep RAMIN heap within the channel.

 drivers/gpu/drm/drm_crtc_helper.c |   27 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |   45 +
 drivers/gpu/drm/nouveau/nouveau_drv.c |4 +
 drivers/gpu/drm/nouveau/nouveau_drv.h |6 +
 drivers/gpu/drm/nouveau/nouveau_object.c  |2 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c   |3 +
 drivers/gpu/drm/nouveau/nv50_display.c|4 +-
 drivers/gpu/drm/nouveau/nvc0_graph.c  |2 +
 drivers/gpu/drm/nouveau/nvd0_display.c|2 +-
 drivers/gpu/drm/radeon/atombios_crtc.c|   35 +++-
 drivers/gpu/drm/radeon/evergreen.c|7 +-
 drivers/gpu/drm/radeon/evergreen_cs.c |  149 -
 drivers/gpu/drm/radeon/evergreen_reg.h|   29 ++
 drivers/gpu/drm/radeon/evergreend.h   |   31 ++
 drivers/gpu/drm/radeon/r100.c |7 +-
 drivers/gpu/drm/radeon/radeon_acpi.c  |   11 +-
 drivers/gpu/drm/radeon/rs600.c|7 +-
 drivers/gpu/drm/radeon/rv770.c|7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   11 +-
 include/drm/drm_pciids.h  |8 ++
 20 files changed, 349 insertions(+), 48 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M

[bugzilla-daemon]

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

--- Comment #8 from Marek Olšák mar...@gmail.com 2011-12-02 03:18:31 PST ---
I've got a hunch that the texture hack is GPU-dependent. The comment next to
the hack suggests it fixes a problem on Evergreen. The problem might have been
fixed already by some other commit, not sure.

I am okay with reverting the commit.

Ideally piglit should be tested on Evergreen and if there are regressions, the
hack should be applied to Evergreen only, or another solution should be found,
but I guess that can be sorted out after the revert.

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

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

   What|Removed |Added

  Attachment #54048|application/octet-stream|text/plain
  mime type||
  Attachment #54048|0   |1
   is patch||

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

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

   What|Removed |Added

  Attachment #54049|application/octet-stream|text/plain
  mime type||
  Attachment #54049|0   |1
   is patch||

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher ag...@yahoo.com 2011-12-02 06:07:09 PST ---
Looks like you attached the wrong glxinfo output.  Please attach your xorg log
as well.

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

--- Comment #3 from marc-aurele marcaurel...@yahoo.fr 2011-12-02 07:15:26 PST 
---
Created attachment 54077
  -- https://bugs.freedesktop.org/attachment.cgi?id=54077
libgl verbose glxinfo

Here is the correct output of LIBGL_DEBUG=verbose glxinfo

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

--- Comment #4 from marc-aurele marcaurel...@yahoo.fr 2011-12-02 07:20:40 PST 
---
Created attachment 54078
  -- https://bugs.freedesktop.org/attachment.cgi?id=54078
xorg log

And here is my xorg log. Thanks for your interest and sorry for the bad glxinfo
log.

-- 
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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

[bugzilla-daemon]

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

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

   What|Removed |Added

  Attachment #54078|text/x-log  |text/plain
  mime type||
  Attachment #54078|0   |1
   is patch||

-- 
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: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Jerome Glisse]

On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
 On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
  On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
   On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
   
 FIX idr_layer_cache: Marking all objects used
   
Yesterday I couldn't reproduce the issue at all. But today I've hit
exactly the same spot again. (CCing the drm list)
   
   Well this is looks like write after free.
   
=
BUG idr_layer_cache: Poison overwritten
-
Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
6b  
   
   And its an integer sized write of 0. If you look at the struct definition
   and lookup the offset you should be able to locate the field that
   was modified.
 
 It also happens with CONFIG_SLAB. 
 (If someone wants to reproduce the issue, just run a kexec boot loop and
 the bug will occur after a few (~10) iterations.)
 

Can you provide the kexec command line you are using and full kernel
log (mostly interested in kernel option).

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

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
 On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
  On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
   On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:

  FIX idr_layer_cache: Marking all objects used

 Yesterday I couldn't reproduce the issue at all. But today I've hit
 exactly the same spot again. (CCing the drm list)

Well this is looks like write after free.

 =
 BUG idr_layer_cache: Poison overwritten
 -
 Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  
 Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  
 Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  
 Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  
 Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  
 Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
 6b  

And its an integer sized write of 0. If you look at the struct 
definition
and lookup the offset you should be able to locate the field that
was modified.
  
  It also happens with CONFIG_SLAB. 
  (If someone wants to reproduce the issue, just run a kexec boot loop and
  the bug will occur after a few (~10) iterations.)
  
 
 Can you provide the kexec command line you are using and full kernel
 log (mostly interested in kernel option).

/usr/sbin/kexec -l /usr/src/linux/arch/x86/boot/bzImage 
--append=root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit 
rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet
/usr/sbin/kexec -e

(The loop happens after autologin in .zprofile:
sleep 4  sudo /etc/minit/ctrlaltdel/run
(the last script kills, unmounts and then runs the two kexec commands
above))

Linux version 3.2.0-rc4-00089-g621fc1e-dirty (mar...@x4.trippels.de) (gcc 
version 4.6.3 20111202 (prerelease) (GCC) ) #134 SMP PREEMPT Fri Dec 2 11:06:20 
CET 2011
Command line: root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 
init=/sbin/minit rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 
quiet
KERNEL supported cpus:
  AMD AuthenticAMD
BIOS-provided physical RAM map:
 BIOS-e820: 0100 - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e6000 - 0010 (reserved)
 BIOS-e820: 0010 - dfe9 (usable)
 BIOS-e820: dfe9 - dfea8000 (ACPI data)
 BIOS-e820: dfea8000 - dfed (ACPI NVS)
 BIOS-e820: dfed - dff0 (reserved)
 BIOS-e820: fff0 - 0001 (reserved)
 BIOS-e820: 0001 - 00022000 (usable)
NX (Execute Disable) protection: active
DMI present.
DMI: System manufacturer System Product Name/M4A78T-E, BIOS 340608/20/2010
e820 update range:  - 0001 (usable) == (reserved)
e820 remove range: 000a - 0010 (usable)
last_pfn = 0x22 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-E uncachable
  F-F write-protect
MTRR variable ranges enabled:
  0 base  mask 8000 write-back
  1 base 8000 mask C000 write-back
  2 base C000 mask E000 write-back
  3 base F000 mask F800 write-combining
  4 disabled
  5 disabled
  6 disabled
  7 disabled
TOM2: 00022000 aka 8704M
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
last_pfn = 0xdfe90 max_arch_pfn = 0x4
initial memory mapped : 0 - 2000
Base memory trampoline at [8809d000] 9d000 size 8192
Using GB pages for direct mapping
init_memory_mapping: -dfe9
 00 - 00c000 page 1G
 00c000 - 00dfe0 page 2M
 00dfe0 - 00dfe9 page 4k
kernel direct mapping tables up to dfe9 @ 1fffd000-2000
init_memory_mapping: 0001-00022000
 01 - 02 page 1G
 02 - 022000 page 2M
kernel direct mapping tables up to 22000 @ dfe8e000-dfe9
ACPI: RSDP 000fb880 00024 (v02 ACPIAM)
ACPI: XSDT dfe90100 0005C (v01 082010 XSDT1403 20100820 MSFT 0097)
ACPI: FACP dfe90290 000F4 (v03 082010 FACP1403 20100820 MSFT 0097)
ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 
0x/0x1 (20110623/tbfadt-560)
ACPI: DSDT dfe90450 0E6FE (v01  A1152 A1152000  INTL 20060113)
ACPI: FACS dfea8000 00040
ACPI

[Bug 43477] New: rendering errors in unigine tropics and sanctuary (regression)

[bugzilla-daemon]

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

 Bug #: 43477
   Summary: rendering errors in unigine tropics and sanctuary
(regression)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: aaalmo...@gmail.com


Some shaders fail to compile with mesa 7.12-dev, this is printed to console a
couple of times:
GLShader::loadFragment(): error in
core/shaders/meshes/fragment_base_light_omni.shader file
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_TRANSLUCENT,USE_PARALLAX,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,BASE_LIGHT_OMNI,OMNI,SHADOW,PHONG_RIM
0:460(18): error: syntax error, unexpected NEW_IDENTIFIER

In tropics the night scenes are rendered incorrectly, in sanctuary almost
everything is gray. With 7.11 these demos render correctly. Tested on hd6850.

-- 
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 43478] New: rendering error in unigine sanctuary

[bugzilla-daemon]

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

 Bug #: 43478
   Summary: rendering error in unigine sanctuary
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: aaalmo...@gmail.com


Created attachment 54081
  -- https://bugs.freedesktop.org/attachment.cgi?id=54081
window screenshot.png

Stained glass windows and reliefs are rendered with some noise added. Tested
with 7.11 and 7.12-dev on hd6850.

-- 
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: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.12.02 at 21:06 +0100, Markus Trippelsdorf wrote:
 On 2011.12.02 at 14:43 -0500, Jerome Glisse wrote:
  On Thu, Dec 01, 2011 at 09:44:37AM +0100, Markus Trippelsdorf wrote:
   On 2011.11.24 at 09:50 +0100, Markus Trippelsdorf wrote:
On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
 On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
 
   FIX idr_layer_cache: Marking all objects used
 
  Yesterday I couldn't reproduce the issue at all. But today I've hit
  exactly the same spot again. (CCing the drm list)
 
 Well this is looks like write after free.
 
  =
  BUG idr_layer_cache: Poison overwritten
  -
  Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
  Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
  Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
  Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
  Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
  Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 
  6b 6b  
 
 And its an integer sized write of 0. If you look at the struct 
 definition
 and lookup the offset you should be able to locate the field that
 was modified.
   
   It also happens with CONFIG_SLAB. 
   (If someone wants to reproduce the issue, just run a kexec boot loop and
   the bug will occur after a few (~10) iterations.)
   
  
  Can you provide the kexec command line you are using and full kernel
  log (mostly interested in kernel option).
 
 /usr/sbin/kexec -l /usr/src/linux/arch/x86/boot/bzImage 
 --append=root=PARTUUID=6d6a4009-3a90-40df-806a-e63f48189719 init=/sbin/minit 
 rootflags=logbsize=262144 fbcon=rotate:3 drm_kms_helper.poll=0 quiet
 /usr/sbin/kexec -e
 
 (The loop happens after autologin in .zprofile:
 sleep 4  sudo /etc/minit/ctrlaltdel/run
 (the last script kills, unmounts and then runs the two kexec commands
 above))

BTW I always see (mostly only on screen, sometimes in the logs):

[Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400, 
but the register is already in use for vector 0xf9 on another cpu
[Firmware Bug]: cpu 2, IBS interrupt offset 0 not available 
(MSRC001103A=0x0100)
[Firmware Bug]: using offset 1 for IBS interrupts
[Firmware Bug]: workaround enabled for IBS LVT offset
perf: AMD IBS detected (0x001f) 

But I hope that it is only a harmless warning. 
(perf Instruction-Based Sampling)

Robert?

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

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Jerome Glisse]

On Thu, Nov 24, 2011 at 09:50:40AM +0100, Markus Trippelsdorf wrote:
 On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
  On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
  
FIX idr_layer_cache: Marking all objects used
  
   Yesterday I couldn't reproduce the issue at all. But today I've hit
   exactly the same spot again. (CCing the drm list)
  
  Well this is looks like write after free.
  
   =
   BUG idr_layer_cache: Poison overwritten
   -
   Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
   Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
   Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
   Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
   Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
   Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
   
  
  And its an integer sized write of 0. If you look at the struct definition
  and lookup the offset you should be able to locate the field that
  was modified.
 
 Here are two more BUGs that seem to point to the same bug:
 
 1)
 ...
 Nov 21 18:30:30 x4 kernel: [drm] radeon: irq initialized.
 Nov 21 18:30:30 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
 131072
 Nov 21 18:30:30 x4 kernel: [drm] Loading RS780 Microcode
 Nov 21 18:30:30 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
 0xC004).
 Nov 21 18:30:30 x4 kernel: radeon :01:05.0: WB enabled
 Nov 21 18:30:30 x4 kernel: 
 =
 Nov 21 18:30:30 x4 kernel: BUG task_xstate: Not a valid slab page
 Nov 21 18:30:30 x4 kernel: 
 -
 Nov 21 18:30:30 x4 kernel:
 Nov 21 18:30:30 x4 kernel: INFO: Slab 0xea044300 objects=32767 
 used=65535 fp=0x  (null) flags=0x0401
 Nov 21 18:30:30 x4 kernel: Pid: 9, comm: ksoftirqd/1 Not tainted 
 3.2.0-rc2-00274-g6fe4c6d-dirty #75
 Nov 21 18:30:30 x4 kernel: Call Trace:
 Nov 21 18:30:30 x4 kernel: [81101c1d] slab_err+0x7d/0x90
 Nov 21 18:30:30 x4 kernel: [8103e29f] ? dump_trace+0x16f/0x2e0
 Nov 21 18:30:30 x4 kernel: [81044764] ? free_thread_xstate+0x24/0x40
 Nov 21 18:30:30 x4 kernel: [81044764] ? free_thread_xstate+0x24/0x40
 Nov 21 18:30:30 x4 kernel: [81102566] check_slab+0x96/0xc0
 Nov 21 18:30:30 x4 kernel: [814c5c29] 
 free_debug_processing+0x34/0x19c
 Nov 21 18:30:30 x4 kernel: [81101d9a] ? set_track+0x5a/0x190
 Nov 21 18:30:30 x4 kernel: [8110cf2b] ? sys_open+0x1b/0x20
 Nov 21 18:30:30 x4 kernel: [814c5e55] __slab_free+0x33/0x2d0
 Nov 21 18:30:30 x4 kernel: [8110cf2b] ? sys_open+0x1b/0x20
 Nov 21 18:30:30 x4 kernel: [81105134] kmem_cache_free+0x104/0x120
 Nov 21 18:30:30 x4 kernel: [81044764] free_thread_xstate+0x24/0x40
 Nov 21 18:30:30 x4 kernel: [81044794] free_thread_info+0x14/0x30
 Nov 21 18:30:30 x4 kernel: [8106a4ff] free_task+0x2f/0x50
 Nov 21 18:30:30 x4 kernel: [8106a5d0] __put_task_struct+0xb0/0x110
 Nov 21 18:30:30 x4 kernel: [8106eb4b] 
 delayed_put_task_struct+0x3b/0xa0
 Nov 21 18:30:30 x4 kernel: [810aa01a] 
 __rcu_process_callbacks+0x12a/0x350
 Nov 21 18:30:30 x4 kernel: [810aa2a2] 
 rcu_process_callbacks+0x62/0x140
 Nov 21 18:30:30 x4 kernel: [81072e18] __do_softirq+0xa8/0x200
 Nov 21 18:30:30 x4 kernel: [81073077] run_ksoftirqd+0x107/0x210
 Nov 21 18:30:30 x4 kernel: [81072f70] ? __do_softirq+0x200/0x200
 Nov 21 18:30:30 x4 kernel: [8108bb87] kthread+0x87/0x90
 Nov 21 18:30:30 x4 kernel: [814cdcf4] kernel_thread_helper+0x4/0x10
 Nov 21 18:30:30 x4 kernel: [8108bb00] ? 
 kthread_flush_work_fn+0x10/0x10
 Nov 21 18:30:30 x4 kernel: [814cdcf0] ? gs_change+0xb/0xb
 Nov 21 18:30:30 x4 kernel: FIX task_xstate: Object at 0x8110cf2b not 
 freed
 Nov 21 18:30:30 x4 kernel: [drm] ring test succeeded in 1 usecs
 Nov 21 18:30:30 x4 kernel: [drm] radeon: ib pool ready.
 Nov 21 18:30:30 x4 kernel: [drm] ib test succeeded in 0 usecs
 Nov 21 18:30:30 x4 kernel: [drm] Radeon Display Connectors
 Nov 21 18:30:30 x4 kernel: [drm] Connector 0
 
 2)
 ...
 Nov 21 17:04:38 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
 Nov 21 17:04:38 x4 kernel: Console: switching to colour frame buffer device 
 131x105
 Nov 21 17:04:38 x4 kernel: fb0: radeondrmfb frame buffer device
 Nov 21 17:04:38 x4 kernel: drm: registered panic notifier
 Nov 21 17:04:38 x4 kernel: [drm] Initialized radeon 2.11.0 20080528 for 
 :01:05.0 on minor 0
 Nov 21 17:04:38 

[Bug 43481] New: DVI-0 with unknown connection but available modes

[bugzilla-daemon]

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

 Bug #: 43481
   Summary: DVI-0 with unknown connection but available modes
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: h.j...@gmx.at


This might not be a bug, but a few kernel revisions ago, DVI-0 became active:

xrandr:
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
DVI-0 unknown connection (normal left inverted right x axis y axis)
   1024x768   60.0  
   800x60060.3  
   640x48059.9  
   512x384   120.0  
   400x300   120.6  
   320x240   120.1  
LVDS connected 1440x900+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
   1440x900   60.0*+
   1280x854   59.9  
   1280x800   59.8  
   1280x720   59.9  
   1152x768   59.8  
   1024x768   59.9  
   800x60059.9  
   848x48059.7  
   720x48059.7  
   640x48059.4  
VGA-0 disconnected (normal left inverted right x axis y axis)

Hardware: Lenovo Thinkpad T400
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400
Series

What's this DVI-0? LVDS and VGA-0 (when connected) work fine, and DVI-0 does
not hurt, but still I thought I'd report this here in case this shouldn't be as
it is now ;-)

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

[PATCH] drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Seems like something got mis-merged here.

Noticed by kallisti5 on IRC.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_encoders.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 06e413e..4b27efa 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -233,13 +233,12 @@ u16 radeon_encoder_get_dp_bridge_encoder_id(struct 
drm_encoder *encoder)
switch (radeon_encoder-encoder_id) {
case ENCODER_OBJECT_ID_TRAVIS:
case ENCODER_OBJECT_ID_NUTMEG:
-   return true;
+   return radeon_encoder-encoder_id;
default:
-   return false;
+   return ENCODER_OBJECT_ID_NONE;
}
}
-
-   return false;
+   return ENCODER_OBJECT_ID_NONE;
 }
 
 void radeon_panel_mode_fixup(struct drm_encoder *encoder,
-- 
1.7.3.4

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

[Bug 43481] DVI-0 with unknown connection but available modes

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher ag...@yahoo.com 2011-12-02 16:24:48 PST ---
It's on a docking station.  As to why it's suddenly getting detected, can you
bisect?

-- 
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 43477] rendering errors in unigine tropics and sanctuary (regression)

[bugzilla-daemon]

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

--- Comment #2 from Vadim pt...@yandex.ru 2011-12-02 17:04:58 PST ---
Probably this is a known bug with GL_EXT_TEXTURE_ARRAY in Unigine engines and
glsl  1.30. IIRR they are using the extension without enabling it in the
shaders.

Disabling the extension completely with the environment variable should help:

MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_array

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