Created attachment 111018 [details]
This started with kernel version 3.17.3. I can use the mouse but the cursor is invisible.
I bisected the stable branch and the offending commit is 2a0a68a350d188451611a23c34e79cc8b52a16bb. My Xorg version is 22.214.171.1241 (1.16.3 RC 1).
Created attachment 111019 [details]
That bisection seems unlikely... that commit unbroke agp boards. Probably before then nouveau wasn't getting used properly at all and you were actually getting the vesa driver or something.
Can you double-check the X log at the parent of the commit you identified?
I will do that tomorrow just to double-check and post the Xorg log but I'm pretty sure I've been using nouveau all along. Right now I'm running version 3.17.2 (the last release that worked) and the Xorg log shows that it's using nouveau.
(In reply to Fernando Rodriguez from comment #3)
> I will do that tomorrow just to double-check and post the Xorg log but I'm
> pretty sure I've been using nouveau all along. Right now I'm running version
> 3.17.2 (the last release that worked) and the Xorg log shows that it's using
Xorg log + dmesg from 3.17.2 would be fine.
Created attachment 111026 [details]
dmesg from 3.17.2
There you go.
Created attachment 111027 [details]
Xorg log 3.17.2
(In reply to Fernando Rodriguez from comment #6)
> Created attachment 111027 [details]
> Xorg log 3.17.2
As I suspected:
[ 20.659] (EE) NOUVEAU(0): Error creating GPU channel: -13
[ 20.659] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel
And in dmesg:
[ 20.658982] nouveau E[ DEVICE][0000:01:00.0][0x80000080][ffff880076072c00] failed to create 0x00000002, -13
I see. So that commit fixed that bug and triggered another one? Does that means that is falling back on vesa or it's still using nouveau to some extent without acceleration? I tried using vesa before and IIRC some effects that work with nouveau didn't worked with vesa.
Another symptom that I forgot to mention is that the only way I can stop kdm when running a 3.17.3 (or greater) is with kill -9. I will post the logs after it refuses to stop tomorrow.
I also just tried booting v3.17.3 and logged in to kde and switched the compositor to OpenGL (which obviously never worked before on this machine). When I did that all window decorations disappeared and Xorg seemed to freeze but I was still able to switch to a VT. I immediately switched back to X it was back on KDM so I guess it crashed kde and the cursor is not the only thing broken.
Is there anything else I can do?
(In reply to Fernando Rodriguez from comment #8)
> I see. So that commit fixed that bug and triggered another one? Does that
An earlier commit broke AGP. That commit went into 3.17, I believe. The commit you bisected to restored AGP.
Please test out kernel 4acfd707^ -- I think that was the commit that broke things... maybe. If that still doesn't get you acceleration, just try 3.16. Basically I'd like to figure out if there was a time when acceleration *and* the cursor worked all at the same time, and if so, to figure out when that broke.
> I also just tried booting v3.17.3 and logged in to kde and switched the
> compositor to OpenGL (which obviously never worked before on this machine).
The nv30 GL driver is pretty crappy, sorry. Especially for actual nv3x cards (vs nv4x ones). Lots of ways to mess things up. Also note that this card was released in 2003-2004 -- its hw capabilities (even with a hypothetical well-written GL driver) won't be a good match for software written for 2014.
In any case, my recommendation is to tackle one issue at a time. Mouse cursor trumps GL compositors in my mind. When that's resolved, you can file more bugs for your other issues.
Thanks for the help. I got the cursor back, and for the first time in this machine, acceleration is also working. The solution was to compile amd64-agpgart as a module (not built-in). So unless you consider that a bug you can close this bug. Btw, it also requires and SMP enabled kernel for me even though it's a single core. If I disable SMP it hangs as soon as the module is loaded.
I also compiled the VIA AGP driver as a module (which according to the documentation for CONFIG_AGP_AMD64 is required) but apparently I don't need it cause it's not getting loaded.
(In reply to Fernando Rodriguez from comment #10)
> Thanks for the help. I got the cursor back, and for the first time in this
> machine, acceleration is also working. The solution was to compile
> amd64-agpgart as a module (not built-in). So unless you consider that a bug
> you can close this bug.
Hmmmm.... very odd. I have no idea why that would happen. Mind providing a boot log with that? In your current 3.17.3 log it says:
[ 0.449093] agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
[ 0.449104] agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
[ 0.449146] nouveau 0000:01:00.0: putting AGP V3 device into 8x mode
[ 0.449222] [TTM] Zone kernel: Available graphics memory: 1022436 kiB
[ 0.449224] [TTM] Initializing pool allocator
[ 0.449231] [TTM] Initializing DMA pool allocator
[ 0.449250] nouveau [ DRM] VRAM: 127 MiB
[ 0.449252] nouveau [ DRM] GART: 128 MiB
[Hm, that "available graphics memory" thing seems high... 1GB? Is that how much system ram you have?]
> Btw, it also requires and SMP enabled kernel for me
> even though it's a single core. If I disable SMP it hangs as soon as the
> module is loaded.
Known issue. Patch available. Everyone keeps thinking someone else will merge it.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/157.