Created attachment 32793 [details]
nouveau-related dmesg output

Created attachment 32794 [details]
pretty minimal xorg.conf

It's known, the problem is these cards are all onboard. So that makes it harder
to test. The same problem applies to 8200 and 8300 and g102m (the last one is
iirc). They are either NVAA or NVAC. Ben Skeggs is probably the person with the
biggest chance of getting this running, but he doesn't have one.

I'm seeing what might be the same problem with an NV4E (a GeForce 6150 which is built into my ASUS M2NPV-VM motherboard) running in a 64-bit environment.  I have a work-around, but it doesn't make any sense to me.

I've managed to track my issue down to the TTM interface changes:

    77bce8e  drm/nouveau: fix for ttm interface changes, and
    ad49f50  drm/ttm/radeon: add dma32 support.

If I force the last argument to ttm_bo_device_init to false then the GPU channel is successfully created and 2D acceleration works.  I'm currently using the following patch:

diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 8f3a12f..10d1663 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -590,7 +590,7 @@ nouveau_mem_init(struct drm_device *dev)
        ret = ttm_bo_device_init(&dev_priv->ttm.bdev,
                                 dev_priv->ttm.bo_global_ref.ref.object,
                                 &nouveau_bo_driver, DRM_FILE_PAGE_OFFSET,
-                                dma_bits <= 32 ? true : false);
+                                /* dma_bits <= 32 ? true : */ false);
        if (ret) {
                NV_ERROR(dev, "Error initialising bo driver: %d\n", ret);
                return ret;

The bit that I find most confusing is that I can't just force dma_bits to be 40 (or 64, for that matter) -- it apparently must be 32.

To summarize, this only works for me if: dma_bits=32 and TTM_PAGE_FLAG_DMA32 is not in bdev's flags.

I hope this means something to someone...

Thanks,
-Ted

Maarten: Is there any more information or help I can provide?  Or any hardware I can donate?  Unfortunately donating a $1500 Mac laptop isn't something I'm comfortable doing, but if someone could find a cheap (<= $450?) laptop with the same or similar NVAC chipset, I might be able to justify buying one for Ben to test on.  If he thinks remote testing will do, I'd be happy to hang out in #nouveau on the weekend and help (unfortunately during the week isn't possible for me).

Ted: interesting... are you running a 64bit system?  If so, does that mean TTM is trying to use > 32bit DMA?  Perhaps something in the hardware doesn't support > 32bit DMA, and that fact isn't being detected properly.

Brian: Yes, I am using a 64-bit system.

TTM_PAGE_FLAG_DMA32 is used only by ttm_tt_alloc_page(), where it causes alloc_page() to be called with the __GFP_DMA32 flag set.  This is supposed to cause it to return only pages in the first 4GB of RAM, so I'm baffled as to why it's breaking anything.

FWIW, I only have 4GB of RAM in the machine, so in theory all of it could be safe for 32-bit DMA.

I note that you're also using an x86-64 CPU, and I'd be curious to know if the patch in comment #4 helps you.  If not, I should open a new bug report.

Thanks,
-Ted

Nope, unfortunately your patch doesn't help.  Same error in the log.

4GB of RAM means you go over 32 bits memory space (your gpu and other hardware
also needs memory space). Why it breaks in this strange way i do not know.

Brian Tarricone: I think the cheapest would be to dig up a NVAA/NVAC based
motherboard (they seem to exist in socket AM2+ variety only), combined with an
AMD Athlon II X2, some ram, a case, small harddrive and a dvd writer/player.
But it might be worthwhile to find out what is keeping Ben Skeggs from having
such hardware, i will add him to the CC list.

Ted Phelps: you should open a seperate bug report

Brian: Thanks for testing.
Maarten: I've submitted bug #26201 to track this.  Thanks for having a look.

-Ted

Ok, I did some printf()ing, and found out at least part of what's failing.  Hopefully this is useful.  Call stack looks something like this (with some of
the actual args passed:

libdrm.so:drmCommandWrite(fd, DRM_NOUVEAU_GEM_CPU_PREP, ...)
libdrm_nouveau.so:nouveau_bo_wait(bo, 0x8, 0, 0)
libdrm_nouveau.so:nouveau_bo_map_range(bo, 0, 65536, 0x0c)
libdrm_nouveau.so:nouveau_bo_map()
libdrm_nouveau.so:nouveau_channel_alloc()
nouveau_drv.so:NVInitDma()
[etc.]

And drmCommandWrite() returns -EBUSY.

I poked around in the drm kernel module, but that's where things get a little
weird.  I found nouveau_gem_ioctl_cpu_prep(), and added a printk() at the top,
but I never see any output in dmesg.  So then I added some in drm_drv.c:drm_ioctl(), but even *that* doesn't seem to be called.  Not sure what's going on there.  I'm probably misunderstanding something.

(In reply to comment #8)
> Brian Tarricone: I think the cheapest would be to dig up a NVAA/NVAC based
> motherboard (they seem to exist in socket AM2+ variety only), combined with an
> AMD Athlon II X2, some ram, a case, small harddrive and a dvd writer/player.

I have an NVAC on a Socket 755 Gigabyte GA-E7AUM-DS2H, x86_64. After reading this I made a quick test and confirmed that it is hit by this bug as well.
There is one used one for sell at amazon.com (out of stock for new ones):
http://www.amazon.com/gp/offer-listing/B001RUI3P6/ref=dp_olp_used?ie=UTF8&condition=used

For those not on #nouveau @ freenode: Ben Skeggs got access to this hardware over ssh, and found the bug, so a patch may appear soon.

Ok, with today's commits (presumably 1ac45d0f945734fe9dcd6f006b0c626da6d7334f is the one that matters, since the other two seem unrelated), EXA setup is "fixed," but X comes up with a mostly black screen with random red, blue, and green pixels every now and then, and big white bands and partial-bands across the screen.  Machine appears hard-locked (forgot to ssh-test, though, so might have just been input-locked).

Actually now that I think about it, I doubt it's hard-locked -- otherwise I doubt Xorg.0.log would have made it to disk after the lockup.  Kernel's probably still alive, to some extent.

Verified with a bisect that 1ac45d0f945734fe9dcd6f006b0c626da6d7334f causes the lockup.

I also tried setting the module param vram_notify=1 and vram_notify=0, but still the same problem either way.

No worry I'm getting the same thing with ION, looks like X dies somewhere along:

X: nouveau_pushbuf.c:271: nouveau_pushbuf_flush: Assertion `!nouveau_pushbuf_space(chan, min)' failed.

So it looks like more vram magic is needed. I guess we will need to catch darktama once again and let him ssh into the machine :P

see ya,
#nouveau irc nick: hax0r1

I don't think he has even attempted to fix it yet. He said it wasn't trivial. He's on vacation for the next week, so be patient.

NVAC should be fixed in latest nouveau git.  It worked on the macbook I got access to at least :)

Great, works fine here!