Re: Linux 3.4-rc4

2012-04-22 Thread Dave Airlie 
On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
 wrote:
> David & co, any ideas?

I've been asking Ben about this, I might have to use a bit more pressure,

It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.

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

Re: [PATCHv5 00/13] Integration of videobuf2 with dmabuf

2012-04-22 Thread Rob Landley 
On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing to V4L2 stack.
> The support for DMABUF exporting was moved to separate patchset
> due to dependency on patches for DMA mapping redesign by
> Marek Szyprowski [4].

Would it be an an option to _not_ cc: all 14 patches to the linux-doc
list when 12 of them have nothing to do with documentation? (Or do the
tools not allow for that?)

Just wondering...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm: Store vendor IDs directly in the EDID quirk structure

2012-04-22 Thread Ian Pilcher 
EDID vendor IDs are always 3 characters long (4 with the terminating
0).  It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.

Signed-off-by: Ian Pilcher 
---
 drivers/gpu/drm/drm_edid.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..8c27395 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -81,7 +81,7 @@ struct detailed_mode_closure {
 #define LEVEL_CVT  3
 
 static struct edid_quirk {
-   char *vendor;
+   char vendor[4];
int product_id;
u32 quirks;
 } edid_quirk_list[] = {
-- 
1.7.7.6

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

Re: Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
> 
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.

Since the original bisection was restricted to drivers/gpu, and there
appears to be exactly 0 commits between v3.2 and v3.3 that touch files
in drivers/gpu outside of drivers/gpu/drm, I think this should make no
difference?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
> 
> git bisect visualize
> 
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
> 
>git reset --hard 
> 
> to force bisection to try another place. That way you can sometimes
> avoid the problem spots, and continue the bisection.

Unfortunately, I think the whole swath of commits bisect wants to test
are broken (as in, they panic before I get to see whether or not the VGA
is working), because the commit from which most of the drm trees were
based appears to be broken.  Nevertheless, I've included the new bisect
log (four new commits marked skip as opposed to last time).  I've also
included the boot log from a crashing kernel, in case someone recognizes
how I can avoid this during bisection.  Note that this crash is *not* a
regression that exists in current mainline -- bisecting this issue was
the first time I had ever seen it.

(Aside: is there a way to run "git bisect skip" without causing a new
working tree to be immediately checked out?  When I'm going to be
picking the next commit manually anyway, having git bisect checkout a
new tree arbitrarily, potentially forcing a complete recompile (~30
minutes) when the commit I picked could have been incrementally compiled
in ~1 minute is pretty annoying...)

  git bisect start 'drivers/gpu'
  # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
  git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
  # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
  git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
  # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch 
'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into 
drm-core-next
  git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
  # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual 
mapping support
  git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
  # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports 
for i810 driver.
  git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042
  # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an MSI 
quirk for Dell RS690
  git bisect skip 44517c44496062180a6376cc704b33129441ce60
  # --- The commits below this point are newly tested ---
  # skip: [f7b24c42da1a7bbb98145d27aa716d8af3cae2a6] drm/nouveau/ttm: fix crash 
as a result of a recent ttm change
  git bisect skip f7b24c42da1a7bbb98145d27aa716d8af3cae2a6
  # skip: [0c101461e267850925218d6a6872c379f2498b16] drm/nv40/pm: parse fan pwm 
divisor from vbios tables
  git bisect skip 0c101461e267850925218d6a6872c379f2498b16
  # skip: [06e4cd64174b48345cbd99179b780a2bf4f96ab6] drm/radeon/kms: don't use 
0 bpc for adjusting hdmi clock
  git bisect skip 06e4cd64174b48345cbd99179b780a2bf4f96ab6
  # skip: [1fbe6f625f69e48c4001051dc1431afc704acfaa] Merge tag 'v3.2-rc6' of 
/home/airlied/devel/kernel/linux-2.6 into drm-core-next
  git bisect skip 1fbe6f625f69e48c4001051dc1431afc704acfaa

Linux version 3.2.0-rc6-bisect-00099-g1fbe6f6 (nick@artemis) (gcc version 4.5.3 
(Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #60 PREEMPT Sun Apr 22 12:04:36 EDT 2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  0100061

Re: Linux 3.4-rc4

2012-04-22 Thread Geert Uytterhoeven 
On Sun, Apr 22, 2012 at 18:40, Nick Bowler  wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out?  When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially forcing a complete recompile (~30
> minutes) when the commit I picked could have been incrementally compiled
> in ~1 minute is pretty annoying...)

I can recommend using ccache for all your compiles.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND] egl-fbdev: Fix compile-error by including errno.h

2012-04-22 Thread David Herrmann 
Hi Dave

You applied the following patch which breaks fbdev-egl backend:

http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/egl/fbdev/native_fbdev.c?id=b60120608f6ddf4098bc324363197c979ee04cb7

It doesn't compile anymore. I appended the correct fix below. I also
CC'ed mesa-dev and the people who reviewed the original patch this
time as I have no idea who I need to send this to.

Thanks
David

**

egl-fbdev: Fix compile-error by including errno.h

We use errno and EINVAL so include errno.h.

Signed-off-by: David Herrmann 
---
 src/gallium/state_trackers/egl/fbdev/native_fbdev.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
b/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
index b45ab5c..b17a8ce 100644
--- a/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
+++ b/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
@@ -41,6 +41,7 @@
 *  - no pixmap support
 */
+#include 
 #include 
 #include 
 #include 
--
1.7.10
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm: add optional per device rwsem for all ioctls

2012-04-22 Thread Marcin Slusarz 
Nouveau, in normal circumstances, does not need device lock for every ioctl,
but incoming "gpu reset" code needs exclusive access to the device.
This commit adds drm_driver flag which turns on read lock ioctl encapsulation.

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/drm_drv.c  |6 ++
 drivers/gpu/drm/drm_stub.c |2 ++
 include/drm/drmP.h |4 
 3 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6116e3b..c54e9f8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -464,6 +464,9 @@ long drm_ioctl(struct file *filp,
} else
memset(kdata, 0, usize);
 
+   if (dev->driver->ioctls_need_rwsem)
+   down_read(&dev->ioctls_rwsem);
+
if (ioctl->flags & DRM_UNLOCKED)
retcode = func(dev, kdata, file_priv);
else {
@@ -472,6 +475,9 @@ long drm_ioctl(struct file *filp,
mutex_unlock(&drm_global_mutex);
}
 
+   if (dev->driver->ioctls_need_rwsem)
+   up_read(&dev->ioctls_rwsem);
+
if (cmd & IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
 usize) != 0)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index aa454f8..4af3227 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -275,6 +275,8 @@ int drm_fill_in_dev(struct drm_device *dev,
mutex_init(&dev->struct_mutex);
mutex_init(&dev->ctxlist_mutex);
 
+   init_rwsem(&dev->ioctls_rwsem);
+
if (drm_ht_create(&dev->map_hash, 12)) {
return -ENOMEM;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index dd73104..527dca5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -954,6 +954,8 @@ struct drm_driver {
int dev_priv_size;
struct drm_ioctl_desc *ioctls;
int num_ioctls;
+   bool ioctls_need_rwsem;
+
const struct file_operations *fops;
union {
struct pci_driver *pci;
@@ -1070,6 +1072,8 @@ struct drm_device {
/*@{ */
spinlock_t count_lock;  /**< For inuse, drm_device::open_count, 
drm_device::buf_use */
struct mutex struct_mutex;  /**< For others */
+
+   struct rw_semaphore ioctls_rwsem;
/*@} */
 
/** \name Usage Counters */
-- 
1.7.8.5

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

[PATCH 2/5] drm/nouveau: base fence timeout on time of emission

2012-04-22 Thread Marcin Slusarz 
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index a22b9ad..59f92e9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -44,6 +44,7 @@ struct nouveau_fence {
 
uint32_t sequence;
bool signalled;
+   unsigned long emitted_at;
 
void (*work)(void *priv, bool signalled);
void *priv;
@@ -172,6 +173,7 @@ nouveau_fence_emit(struct nouveau_fence *fence)
}
OUT_RING (chan, fence->sequence);
FIRE_RING(chan);
+   fence->emitted_at = jiffies;
 
return 0;
 }
@@ -230,7 +232,8 @@ __nouveau_fence_signalled(void *sync_obj, void *sync_arg)
 int
 __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr)
 {
-   unsigned long timeout = jiffies + (3 * DRM_HZ);
+   struct nouveau_fence *fence = nouveau_fence(sync_obj);
+   unsigned long timeout = fence->emitted_at + 3 * DRM_HZ;
unsigned long sleep_time = NSEC_PER_MSEC / 1000;
ktime_t t;
int ret = 0;
-- 
1.7.8.5

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

[PATCH 3/5] drm/nouveau: propagate errors from vm flushes

2012-04-22 Thread Marcin Slusarz 
We need this for lockup recovery.

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |9 +++--
 drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
 drivers/gpu/drm/nouveau/nouveau_vm.c  |   20 ++--
 drivers/gpu/drm/nouveau/nouveau_vm.h  |   18 +-
 drivers/gpu/drm/nouveau/nv50_fifo.c   |4 ++--
 drivers/gpu/drm/nouveau/nv50_graph.c  |   12 
 drivers/gpu/drm/nouveau/nv50_mpeg.c   |4 ++--
 drivers/gpu/drm/nouveau/nv50_vm.c |   30 --
 drivers/gpu/drm/nouveau/nv84_crypt.c  |4 ++--
 drivers/gpu/drm/nouveau/nva3_copy.c   |4 ++--
 drivers/gpu/drm/nouveau/nvc0_vm.c |3 ++-
 11 files changed, 67 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 638ae32..5b0dc50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1230,10 +1230,15 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct 
nouveau_vm *vm,
return ret;
 
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
-   nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
+   ret = nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
else
if (nvbo->bo.mem.mem_type == TTM_PL_TT)
-   nouveau_vm_map_sg(vma, 0, size, node);
+   ret = nouveau_vm_map_sg(vma, 0, size, node);
+
+   if (ret) {
+   nouveau_vm_put(vma);
+   return ret;
+   }
 
list_add_tail(&vma->head, &nvbo->vma_list);
vma->refcount = 1;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 2f8e80a..d120baf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -320,7 +320,7 @@ struct nouveau_exec_engine {
int  (*object_new)(struct nouveau_channel *, int engine,
   u32 handle, u16 class);
void (*set_tile_region)(struct drm_device *dev, int i);
-   void (*tlb_flush)(struct drm_device *, int engine);
+   int (*tlb_flush)(struct drm_device *, int engine);
 };
 
 struct nouveau_instmem_engine {
@@ -387,7 +387,7 @@ struct nouveau_fifo_engine {
void (*destroy_context)(struct nouveau_channel *);
int  (*load_context)(struct nouveau_channel *);
int  (*unload_context)(struct drm_device *);
-   void (*tlb_flush)(struct drm_device *dev);
+   int  (*tlb_flush)(struct drm_device *dev);
 };
 
 struct nouveau_display_engine {
@@ -1246,7 +1246,7 @@ extern int  nv50_fifo_create_context(struct 
nouveau_channel *);
 extern void nv50_fifo_destroy_context(struct nouveau_channel *);
 extern int  nv50_fifo_load_context(struct nouveau_channel *);
 extern int  nv50_fifo_unload_context(struct drm_device *);
-extern void nv50_fifo_tlb_flush(struct drm_device *dev);
+extern int  nv50_fifo_tlb_flush(struct drm_device *dev);
 
 /* nvc0_fifo.c */
 extern int  nvc0_fifo_init(struct drm_device *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.c 
b/drivers/gpu/drm/nouveau/nouveau_vm.c
index 2bf6c03..e2d4853 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.c
@@ -27,7 +27,7 @@
 #include "nouveau_mm.h"
 #include "nouveau_vm.h"
 
-void
+int
 nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, struct nouveau_mem *node)
 {
struct nouveau_vm *vm = vma->vm;
@@ -67,16 +67,16 @@ nouveau_vm_map_at(struct nouveau_vma *vma, u64 delta, 
struct nouveau_mem *node)
}
}
 
-   vm->flush(vm);
+   return vm->flush(vm);
 }
 
-void
+int
 nouveau_vm_map(struct nouveau_vma *vma, struct nouveau_mem *node)
 {
-   nouveau_vm_map_at(vma, 0, node);
+   return nouveau_vm_map_at(vma, 0, node);
 }
 
-void
+int
 nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 length,
  struct nouveau_mem *mem)
 {
@@ -110,10 +110,10 @@ nouveau_vm_map_sg(struct nouveau_vma *vma, u64 delta, u64 
length,
}
}
 
-   vm->flush(vm);
+   return vm->flush(vm);
 }
 
-void
+int
 nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, u64 length)
 {
struct nouveau_vm *vm = vma->vm;
@@ -144,13 +144,13 @@ nouveau_vm_unmap_at(struct nouveau_vma *vma, u64 delta, 
u64 length)
}
}
 
-   vm->flush(vm);
+   return vm->flush(vm);
 }
 
-void
+int
 nouveau_vm_unmap(struct nouveau_vma *vma)
 {
-   nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
+   return nouveau_vm_unmap_at(vma, 0, (u64)vma->node->length << 12);
 }
 
 static void
diff --git a/drivers/gpu/drm/nouveau/nouveau_vm.h 
b/drivers/gpu/drm/nouveau/nouveau_vm.h
index 4fb6e72..59dc206 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_vm.h
@@ -73,7 +73,7 @@ struct nouveau_vm {
void (*map_sg)(struct nouveau_vma *, struct nouveau_gpuobj *,
   struct nouveau_mem *, u32 pte, u32 cn

[PATCH 4/5] drm/nv50: let applications hanging on vm flush to be killed

2012-04-22 Thread Marcin Slusarz 
Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nv50_graph.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c 
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -435,6 +435,11 @@ nv84_graph_tlb_flush(struct drm_device *dev, int engine)
if ((tmp & 7) == 1)
idle = false;
}
+
+   if (fatal_signal_pending(current)) {
+   ret = -ERESTARTSYS;
+   break;
+   }
} while (!idle && !(timeout = ptimer->read(dev) - start > 20));
 
if (timeout) {
-- 
1.7.8.5

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

[RFC PATCH 5/5] drm/nouveau: gpu lockup recovery

2012-04-22 Thread Marcin Slusarz 
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.

GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits

Signed-off-by: Marcin Slusarz 
---
Tested only on nv92.
---
 drivers/gpu/drm/nouveau/Makefile   |2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_channel.c  |5 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c  |3 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h  |   33 ++-
 drivers/gpu/drm/nouveau/nouveau_fence.c|7 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c  |   14 +++-
 drivers/gpu/drm/nouveau/nouveau_notifier.c |3 +
 drivers/gpu/drm/nouveau/nouveau_object.c   |6 +
 drivers/gpu/drm/nouveau/nouveau_reset.c|  144 
 drivers/gpu/drm/nouveau/nouveau_state.c|5 +
 drivers/gpu/drm/nouveau/nv50_graph.c   |   11 +-
 12 files changed, 221 insertions(+), 14 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_reset.c

diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 03860f5..77d0c33 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -9,7 +9,7 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o 
nouveau_mem.o \
  nouveau_bo.o nouveau_fence.o nouveau_gem.o nouveau_ttm.o \
  nouveau_hw.o nouveau_calc.o nouveau_bios.o nouveau_i2c.o \
  nouveau_display.o nouveau_connector.o nouveau_fbcon.o \
- nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o \
+ nouveau_hdmi.o nouveau_dp.o nouveau_ramht.o nouveau_reset.o \
 nouveau_pm.o nouveau_volt.o nouveau_perf.o nouveau_temp.o \
 nouveau_mm.o nouveau_vm.o nouveau_mxm.o nouveau_gpio.o \
  nv04_timer.o \
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5b0dc50..7de6cad 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -936,7 +936,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict, 
bool intr,
}
 
/* Software copy if the card isn't up and running yet. */
-   if (!dev_priv->channel) {
+   if (!dev_priv->channel || nouveau_gpu_reset_in_progress(dev_priv->dev)) 
{
ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
no_wait_gpu, new_mem);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 846afb0..c0fa5a7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -420,7 +420,7 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
init->fb_ctxdma_handle,
init->tt_ctxdma_handle);
if (ret)
-   return ret;
+   goto out;
init->channel  = chan->id;
 
if (nouveau_vram_pushbuf == 0) {
@@ -450,6 +450,9 @@ nouveau_ioctl_fifo_alloc(struct drm_device *dev, void *data,
if (ret == 0)
atomic_inc(&chan->users); /* userspace reference */
nouveau_channel_put(&chan);
+out:
+   if (ret == -EIO)
+   ret = nouveau_reset_device(dev);
return ret;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 090fff6..22c435f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -237,7 +237,7 @@ nouveau_pci_suspend(struct pci_dev *pdev, pm_message_t 
pm_state)
if (!dev_priv->eng[e])
continue;
 
-   ret = dev_priv->eng[e]->fini(dev, e, true);
+   ret = dev_priv->eng[e]->fini(dev, e, 
!nouveau_gpu_reset_in_progress(dev));
if (ret) {
NV_ERROR(dev, "... engine %d failed: %d\n", e, ret);
goto out_abort;
@@ -483,6 +483,7 @@ static struct drm_driver driver = {
.disable_vblank = nouveau_vblank_disable,
.reclaim_buffers = drm_core_reclaim_buffers,
.ioctls = nouveau_ioctls,
+   .ioctls_need_rwsem = true,
.fops = &nouveau_driver_fops,
.gem_init_object = nouveau_gem_object_new,
.gem_free_object = nouveau_gem_object_del,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index d120baf..01500e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -708,6 +708,10 @@ struct drm_nouveau_private {
struct drm_device *dev;
bool noaccel;
 
+   struct mutex reset_lock;
+   atomic_t gpureset_in_progress;
+   unsigned long last_gpu_reset;
+
/* the card type, takes NV_* as values */
enum nou

Re: Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> > 
> > git bisect visualize
> > 
> > and try to pick a good commit (avoding the problems you hit) when you
> > hit a problem, and then do
> > 
> >git reset --hard 
> > 
> > to force bisection to try another place. That way you can sometimes
> > avoid the problem spots, and continue the bisection.
> 
> Unfortunately, I think the whole swath of commits bisect wants to test
> are broken (as in, they panic before I get to see whether or not the VGA
> is working), because the commit from which most of the drm trees were
> based appears to be broken.  Nevertheless, I've included the new bisect
> log (four new commits marked skip as opposed to last time).  I've also
> included the boot log from a crashing kernel, in case someone recognizes
> how I can avoid this during bisection.  Note that this crash is *not* a
> regression that exists in current mainline -- bisecting this issue was
> the first time I had ever seen it.

Following up on the above, the commit which introduces the panics during
boot is this one:

commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse 
Date:   Wed Nov 9 17:15:26 2011 -0500

drm/ttm: isolate dma data from ttm_tt V4

Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.

V2 Rebase on top of no memory account changes (where/when is my
   delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes

Signed-off-by: Jerome Glisse 
Reviewed-by: Thomas Hellstrom 

and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
pool when swiotlb is active V3") works properly.

Sometime this week I suppose I'll try to track down the commit which
fixed the crashes...

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350

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

--- Comment #11 from Tom Stellard  2012-04-22 18:10:00 PDT 
---
(In reply to comment #10)
> Created attachment 57314 [details]
> xvmc log obtained via RADEON_DEBUG=all
> 
> Having a similar problem on a R420.
> When using mplayer -vo xvmc to play an MPEG-2 file (recorded from DVB) I can
> only see a window filled with a majority of green squares flashing.
> On stderr, the following message is shown:
> 
> r300 FP: Compiler Error:
> compiler/r300_fragprog_emit.c::begin_tex(): Too many texture indirections
> Using a dummy shader instead.
> 

Can you try the latest version of mesa from git?  I don't think xvmc playback
works, but that error message should be fixed.  If you still see that error,
please use the environment variable RADEON_DEBUG=fp,vp and post the output.

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

Re: Linux 3.4-rc4

2012-04-22 Thread Konrad Rzeszutek Wilk 
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > > 
> > > git bisect visualize
> > > 
> > > and try to pick a good commit (avoding the problems you hit) when you
> > > hit a problem, and then do
> > > 
> > >git reset --hard 
> > > 
> > > to force bisection to try another place. That way you can sometimes
> > > avoid the problem spots, and continue the bisection.
> > 
> > Unfortunately, I think the whole swath of commits bisect wants to test
> > are broken (as in, they panic before I get to see whether or not the VGA
> > is working), because the commit from which most of the drm trees were
> > based appears to be broken.  Nevertheless, I've included the new bisect
> > log (four new commits marked skip as opposed to last time).  I've also
> > included the boot log from a crashing kernel, in case someone recognizes
> > how I can avoid this during bisection.  Note that this crash is *not* a
> > regression that exists in current mainline -- bisecting this issue was
> > the first time I had ever seen it.
> 
> Following up on the above, the commit which introduces the panics during
> boot is this one:

I think

dea7e0a ttm: fix agp since ttm tt rework

fixed that.
> 
> commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> Author: Jerome Glisse 
> Date:   Wed Nov 9 17:15:26 2011 -0500
> 
> drm/ttm: isolate dma data from ttm_tt V4
> 
> Move dma data to a superset ttm_dma_tt structure which herit
> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
> 
> V2 Rebase on top of no memory account changes (where/when is my
>delorean when i need it ?)
> V3 Make sure page list is initialized empty
> V4 typo/syntax fixes
> 
> Signed-off-by: Jerome Glisse 
> Reviewed-by: Thomas Hellstrom 
> 
> and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
> pool when swiotlb is active V3") works properly.
> 
> Sometime this week I suppose I'll try to track down the commit which
> fixed the crashes...
> 
> Cheers,
> -- 
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

2012-04-22 Thread Ben Skeggs 
On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
> On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
>  wrote:
> > David & co, any ideas?
> 
> I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from continuing to try and narrow down the change that caused the issue.

I've been using the VGA output on a lot of different boards (including
of the same generation as the one in the original bug report) with the
latest code without an issue..

Ben.

> 
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
> 
> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

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

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

--- Comment #45 from Alexandre Demers  2012-04-22 
22:56:08 PDT ---
I'm now working with a 3.4-rc4 kernel. I activated ColorTiling2D. However, it
didn't change anything.

On the other hand, if you have the hardware under hand, I want to let you know
that since the problem appeared (after kernel 3.2 and the culprit commit under
mesa), you should be able to recreate the problem by running piglit tests
(r600.tests). I'm able to recreate it each time if I also enable GLSL130. Doing
the same, but with a 3.2 kernel will not produce the crash, as expected.

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

Linux 3.4-rc4

2012-04-22 Thread Dave Airlie 
On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
 wrote:
> David & co, any ideas?

I've been asking Ben about this, I might have to use a bit more pressure,

It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.

Dave.

[PATCH 1/1] drm: Store vendor IDs directly in the EDID quirk structure

2012-04-22 Thread Ian Pilcher 
EDID vendor IDs are always 3 characters long (4 with the terminating
0).  It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.

Signed-off-by: Ian Pilcher 
---
 drivers/gpu/drm/drm_edid.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..8c27395 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -81,7 +81,7 @@ struct detailed_mode_closure {
 #define LEVEL_CVT  3

 static struct edid_quirk {
-   char *vendor;
+   char vendor[4];
int product_id;
u32 quirks;
 } edid_quirk_list[] = {
-- 
1.7.7.6

Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
> 
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.

Since the original bisection was restricted to drivers/gpu, and there
appears to be exactly 0 commits between v3.2 and v3.3 that touch files
in drivers/gpu outside of drivers/gpu/drm, I think this should make no
difference?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
> 
> git bisect visualize
> 
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
> 
>git reset --hard 
> 
> to force bisection to try another place. That way you can sometimes
> avoid the problem spots, and continue the bisection.

Unfortunately, I think the whole swath of commits bisect wants to test
are broken (as in, they panic before I get to see whether or not the VGA
is working), because the commit from which most of the drm trees were
based appears to be broken.  Nevertheless, I've included the new bisect
log (four new commits marked skip as opposed to last time).  I've also
included the boot log from a crashing kernel, in case someone recognizes
how I can avoid this during bisection.  Note that this crash is *not* a
regression that exists in current mainline -- bisecting this issue was
the first time I had ever seen it.

(Aside: is there a way to run "git bisect skip" without causing a new
working tree to be immediately checked out?  When I'm going to be
picking the next commit manually anyway, having git bisect checkout a
new tree arbitrarily, potentially forcing a complete recompile (~30
minutes) when the commit I picked could have been incrementally compiled
in ~1 minute is pretty annoying...)

  git bisect start 'drivers/gpu'
  # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
  git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
  # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
  git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
  # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch 
'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into 
drm-core-next
  git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
  # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual 
mapping support
  git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
  # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports 
for i810 driver.
  git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042
  # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an MSI 
quirk for Dell RS690
  git bisect skip 44517c44496062180a6376cc704b33129441ce60
  # --- The commits below this point are newly tested ---
  # skip: [f7b24c42da1a7bbb98145d27aa716d8af3cae2a6] drm/nouveau/ttm: fix crash 
as a result of a recent ttm change
  git bisect skip f7b24c42da1a7bbb98145d27aa716d8af3cae2a6
  # skip: [0c101461e267850925218d6a6872c379f2498b16] drm/nv40/pm: parse fan pwm 
divisor from vbios tables
  git bisect skip 0c101461e267850925218d6a6872c379f2498b16
  # skip: [06e4cd64174b48345cbd99179b780a2bf4f96ab6] drm/radeon/kms: don't use 
0 bpc for adjusting hdmi clock
  git bisect skip 06e4cd64174b48345cbd99179b780a2bf4f96ab6
  # skip: [1fbe6f625f69e48c4001051dc1431afc704acfaa] Merge tag 'v3.2-rc6' of 
/home/airlied/devel/kernel/linux-2.6 into drm-core-next
  git bisect skip 1fbe6f625f69e48c4001051dc1431afc704acfaa

Linux version 3.2.0-rc6-bisect-00099-g1fbe6f6 (nick at artemis) (gcc version 
4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #60 PREEMPT Sun Apr 22 12:04:36 EDT 
2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  010

Linux 3.4-rc4

2012-04-22 Thread Geert Uytterhoeven 
On Sun, Apr 22, 2012 at 18:40, Nick Bowler  wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out? ?When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially forcing a complete recompile (~30
> minutes) when the commit I picked could have been incrementally compiled
> in ~1 minute is pretty annoying...)

I can recommend using ccache for all your compiles.

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

[PATCH RESEND] egl-fbdev: Fix compile-error by including errno.h

2012-04-22 Thread David Herrmann 
Hi Dave

You applied the following patch which breaks fbdev-egl backend:

http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/egl/fbdev/native_fbdev.c?id=b60120608f6ddf4098bc324363197c979ee04cb7

It doesn't compile anymore. I appended the correct fix below. I also
CC'ed mesa-dev and the people who reviewed the original patch this
time as I have no idea who I need to send this to.

Thanks
David

**

egl-fbdev: Fix compile-error by including errno.h

We use errno and EINVAL so include errno.h.

Signed-off-by: David Herrmann 
---
?src/gallium/state_trackers/egl/fbdev/native_fbdev.c | ? ?1 +
?1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
b/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
index b45ab5c..b17a8ce 100644
--- a/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
+++ b/src/gallium/state_trackers/egl/fbdev/native_fbdev.c
@@ -41,6 +41,7 @@
?* ?- no pixmap support
?*/
+#include 
?#include 
?#include 
?#include 
--
1.7.10

Linux 3.4-rc4

2012-04-22 Thread Nick Bowler 
On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> > 
> > git bisect visualize
> > 
> > and try to pick a good commit (avoding the problems you hit) when you
> > hit a problem, and then do
> > 
> >git reset --hard 
> > 
> > to force bisection to try another place. That way you can sometimes
> > avoid the problem spots, and continue the bisection.
> 
> Unfortunately, I think the whole swath of commits bisect wants to test
> are broken (as in, they panic before I get to see whether or not the VGA
> is working), because the commit from which most of the drm trees were
> based appears to be broken.  Nevertheless, I've included the new bisect
> log (four new commits marked skip as opposed to last time).  I've also
> included the boot log from a crashing kernel, in case someone recognizes
> how I can avoid this during bisection.  Note that this crash is *not* a
> regression that exists in current mainline -- bisecting this issue was
> the first time I had ever seen it.

Following up on the above, the commit which introduces the panics during
boot is this one:

commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse 
Date:   Wed Nov 9 17:15:26 2011 -0500

drm/ttm: isolate dma data from ttm_tt V4

Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.

V2 Rebase on top of no memory account changes (where/when is my
   delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes

Signed-off-by: Jerome Glisse 
Reviewed-by: Thomas Hellstrom 

and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
pool when swiotlb is active V3") works properly.

Sometime this week I suppose I'll try to track down the commit which
fixed the crashes...

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

2012-04-22 Thread Konrad Rzeszutek Wilk 
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > > 
> > > git bisect visualize
> > > 
> > > and try to pick a good commit (avoding the problems you hit) when you
> > > hit a problem, and then do
> > > 
> > >git reset --hard 
> > > 
> > > to force bisection to try another place. That way you can sometimes
> > > avoid the problem spots, and continue the bisection.
> > 
> > Unfortunately, I think the whole swath of commits bisect wants to test
> > are broken (as in, they panic before I get to see whether or not the VGA
> > is working), because the commit from which most of the drm trees were
> > based appears to be broken.  Nevertheless, I've included the new bisect
> > log (four new commits marked skip as opposed to last time).  I've also
> > included the boot log from a crashing kernel, in case someone recognizes
> > how I can avoid this during bisection.  Note that this crash is *not* a
> > regression that exists in current mainline -- bisecting this issue was
> > the first time I had ever seen it.
> 
> Following up on the above, the commit which introduces the panics during
> boot is this one:

I think

dea7e0a ttm: fix agp since ttm tt rework

fixed that.
> 
> commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> Author: Jerome Glisse 
> Date:   Wed Nov 9 17:15:26 2011 -0500
> 
> drm/ttm: isolate dma data from ttm_tt V4
> 
> Move dma data to a superset ttm_dma_tt structure which herit
> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
> 
> V2 Rebase on top of no memory account changes (where/when is my
>delorean when i need it ?)
> V3 Make sure page list is initialized empty
> V4 typo/syntax fixes
> 
> Signed-off-by: Jerome Glisse 
> Reviewed-by: Thomas Hellstrom 
> 
> and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
> pool when swiotlb is active V3") works properly.
> 
> Sometime this week I suppose I'll try to track down the commit which
> fixed the crashes...
> 
> Cheers,
> -- 
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel