Bug 87469 - [NV34] Invisible cursor on Xorg
Summary: [NV34] Invisible cursor on Xorg
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-19 01:08 UTC by Fernando Rodriguez
Modified: 2019-12-04 08:53 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (44.43 KB, text/plain)
2014-12-19 01:08 UTC, Fernando Rodriguez
no flags Details
Xorg log (26.93 KB, text/plain)
2014-12-19 01:09 UTC, Fernando Rodriguez
no flags Details
dmesg from 3.17.2 (44.69 KB, text/plain)
2014-12-19 02:43 UTC, Fernando Rodriguez
no flags Details
Xorg log 3.17.2 (30.23 KB, text/plain)
2014-12-19 02:44 UTC, Fernando Rodriguez
no flags Details

Description Fernando Rodriguez 2014-12-19 01:08:15 UTC
Created attachment 111018 [details]
dmesg

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 1.16.2.901 (1.16.3 RC 1).
Comment 1 Fernando Rodriguez 2014-12-19 01:09:25 UTC
Created attachment 111019 [details]
Xorg log
Comment 2 Ilia Mirkin 2014-12-19 01:17:03 UTC
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?
Comment 3 Fernando Rodriguez 2014-12-19 01:53:09 UTC
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.
Comment 4 Ilia Mirkin 2014-12-19 02:00:43 UTC
(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
> nouveau.

Xorg log + dmesg from 3.17.2 would be fine.
Comment 5 Fernando Rodriguez 2014-12-19 02:43:40 UTC
Created attachment 111026 [details]
dmesg from 3.17.2

There you go.
Comment 6 Fernando Rodriguez 2014-12-19 02:44:13 UTC
Created attachment 111027 [details]
Xorg log 3.17.2
Comment 7 Ilia Mirkin 2014-12-19 02:57:15 UTC
(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
Comment 8 Fernando Rodriguez 2014-12-19 04:20:11 UTC
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?
Comment 9 Ilia Mirkin 2014-12-19 05:03:39 UTC
(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.
Comment 10 Fernando Rodriguez 2014-12-19 07:43:46 UTC
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.
Comment 11 Ilia Mirkin 2014-12-20 00:55:34 UTC
(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.
Comment 12 Martin Peres 2019-12-04 08:53:09 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.