Btw, is http://cgit.freedesktop.org/nouveau/linux-2.6 not used anymore?

I kind of liked it. Makes bisecting easier on aged machines. And it allows to test new patches more easily.

Now it's all hidden between a huge changeset between v3.13 final and v3.14-rc1. And sometimes even spread out over several periods in time causing full rebuilds.

Please notice the new CC (is that a +1?).

Made a small typo.

X starts, but not without problems. I saw rectangular parts of Opera alternate between correct display and black triangles.

triangles->squares.

(In reply to comment #1)
> Btw, is http://cgit.freedesktop.org/nouveau/linux-2.6 not used anymore?

It is... e.g. look at the drm-nouveau-next branch. I don't think the 'master' branch is really maintained anymore, this is happening in http://cgit.freedesktop.org/~darktama/nouveau/ which you may also be able to use to bisect without the rest of the kernel, if your range is sufficiently small. (Although that repo is a little different...)

> 
> I kind of liked it. Makes bisecting easier on aged machines. And it allows
> to test new patches more easily.
> 
> Now it's all hidden between a huge changeset between v3.13 final and
> v3.14-rc1. And sometimes even spread out over several periods in time
> causing full rebuilds.

I'm confused by what you're trying to say here. v3.14-rc1 and v3.13 are all available in linus's repo. Use that to bisect....

git bisect start v3.14-rc1 v3.13 -- drivers/gpu/drm/nouveau

That should only look at changes in nouveau between those 2 revs...

Hmm seems like a duplicate of the old bug you've reported - bug 71116.

Can you update libdrm/libdrm-nouveau to 2.4.48 before doing any bisection ? A fresh dmesg may be useful as well.

@Ilia Mirkin: Ah, yes the next repo seems promising. Thank you.

About the 'old' master repo: Say, for example, stable was v3.8 and then this machine would happily use it. Every week I would pull from this master branch the patches for v3.9 based on the v3.8 tree.

These patches are localized in the nouveau driver, so I have quick rebuilds and thus quick bisects. Problems are narrowed down easily and most importantly: fast.

Using Linux his tree sometimes means doing a lot more bisects since a lot of changes come in at once after two months. Furthermore, it's not just the nouveau driver that changes but the entire tree. So bisecting would imply also doing full rebuilds.

However, drm-nouveau-next seems to fill the gap which master left behind.

@Emil Velikov: Does not seem like it:

[gebruiker@delta linux]$ pacman -Qi libdrm
Naam : libdrm
Versie : 2.4.52-1
Beschrijving : Userspace interface to kernel DRM services
Architectuur : i686

ArchLinux is quick with it's updates. Which is really nice.

Ow well, on to the bisect then =)

It's "drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU access"

Despite it's name it touches generic stuff. I'm running v3.14-rc2 with this patch reverted -> no issue's yet.

commit a554090664728384c94b027ba15bc7df87f9ac09
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date:   Tue Nov 12 13:34:09 2013 +0100

    drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU access
    
    Moves bo's to TTM_PL_TT for BAR mapping, to hide tiling from user.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e4623e9..39ca36c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1241,6 +1241,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
 {
 	struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
 	struct nouveau_drm *drm = nouveau_bdev(bdev);
+	struct nouveau_mem *node = mem->mm_node;
 	struct drm_device *dev = drm->dev;
 	int ret;
 
@@ -1263,14 +1264,16 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
 			mem->bus.is_iomem = !dev->agp->cant_use_aperture;
 		}
 #endif
-		break;
+		if (!node->memtype)
+			/* untiled */
+			break;
+		/* fallthrough, tiled memory */
 	case TTM_PL_VRAM:
 		mem->bus.offset = mem->start << PAGE_SHIFT;
 		mem->bus.base = pci_resource_start(dev->pdev, 1);
 		mem->bus.is_iomem = true;
 		if (nv_device(drm->device)->card_type >= NV_50) {
 			struct nouveau_bar *bar = nouveau_bar(drm->device);
-			struct nouveau_mem *node = mem->mm_node;
 
 			ret = bar->umap(bar, node, NV_MEM_ACCESS_RW,
 					&node->bar_vma);
@@ -1306,6 +1309,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
 	struct nouveau_bo *nvbo = nouveau_bo(bo);
 	struct nouveau_device *device = nv_device(drm->device);
 	u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
+	int ret;
 
 	/* as long as the bo isn't in vram, and isn't tiled, we've got
 	 * nothing to do here.
@@ -1314,10 +1318,20 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
 		if (nv_device(drm->device)->card_type < NV_50 ||
 		    !nouveau_bo_tile_layout(nvbo))
 			return 0;
+
+		if (bo->mem.mem_type == TTM_PL_SYSTEM) {
+			nouveau_bo_placement_set(nvbo, TTM_PL_TT, 0);
+
+			ret = nouveau_bo_validate(nvbo, false, false);
+			if (ret)
+				return ret;
+		}
+		return 0;
 	}
 
 	/* make sure bo is in mappable vram */
-	if (bo->mem.start + bo->mem.num_pages < mappable)
+	if (nv_device(drm->device)->card_type >= NV_50 ||
+	    bo->mem.start + bo->mem.num_pages < mappable)
 		return 0;

That code _really_ shouldn't affect anything pre-nv50...

The only thing is in second hunk. node->memtype is only ever set to != 0 for nv50+, but... who knows.

Can you add a WARN_ON_ONCE(node->memtype) in there?

The third hunk only affects code for card_type >= NV_50... unless I'm reading something very wrong.

Aha, I think I know what's going on. You're using AGP, which means you get to use the ttm_bo_manager_func. This in turn allocates nodes as drm_mm_node, which is *totally* different from nouveau_mem. (And that's what gets stored in mem->mm_node.)

Can you change

		if (!node->memtype)
			/* untiled */
			break;

to

if (nv_device(drm->device)->card_type < NV_50 || !node->memtype)
  break;

and see if that helps? I actually semi-suspect that this is a giant issue with the TTM stuff the way we're using it, but perhaps all the other uses are guarded behind card < NV_50 logic as well, but that's not obvious to me.

Yes, that fixes it.

(In reply to comment #9)
> Yes, that fixes it.

Awesome! I sent a patch to the ML + cc'd you (I assume you got it) a few hours ago. Feel free to respond with a Tested-by. I'll close this bug when the patch hits mainline.

Thanks for bisecting, and sorry that you're running into so many problems!

No need to apologize. I'm learning a lot *and* get to contribute. I'll get back to you about the other 2 bugs.

The fix should now be upstream, and will be included in the next 3.14-rc:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34d595081812da62b5357579267c4ab5eae64ac1

Thanks, I changed my gitconfig and I'm already pulling from drm-nouveau-next :) .