Bug 770197

Summary: Gnome Shell corrupted on nVidia cards with low VRAM
Product: [Fedora] Fedora Reporter: Ben Schwartz <bens>
Component: gnome-sessionAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: airlied, ajax, antonio.montagnani, awilliam, benjavalero, bskeggs, jmccann, kparal, robatino, rstrode, tflink
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: mesa-8.0.2-8.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 23:15:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 752650    
Description Flags
Startup screenshot. (Notice the two small curvy bits in the upper corners)
Example bugginess
More example bugginess
Output of dmesg, showing nouveau TTM failures
Output of glxinfo, for good measure
Output of xdpyinfo, why not none

Description Ben Schwartz 2011-12-23 21:57:20 EST
Created attachment 549408 [details]
Startup screenshot.  (Notice the two small curvy bits in the upper corners)

Description of problem:
Nouveau loads on my Geforce2 MX, resulting in the Fedora 16 livecd selecting gnome-shell with 3D accel.  Unfortunately, Nouveau is sufficiently buggy that the desktop is absolutely unusable.

Version-Release number of selected component (if applicable):
Fedora 16 standard desktop Live CD

How reproducible:

Additional info:
Fallback mode, using the VESA driver, works fine.
Comment 1 Ben Schwartz 2011-12-23 21:58:32 EST
Created attachment 549409 [details]
Example bugginess
Comment 2 Ben Schwartz 2011-12-23 21:59:19 EST
Created attachment 549410 [details]
More example bugginess
Comment 3 Ben Schwartz 2011-12-23 22:00:09 EST
Created attachment 549411 [details]
Output of dmesg, showing nouveau TTM failures
Comment 4 Ben Schwartz 2011-12-23 22:00:43 EST
Created attachment 549412 [details]
Output of glxinfo, for good measure
Comment 5 Ben Schwartz 2011-12-23 22:01:16 EST
Created attachment 549413 [details]
Output of xdpyinfo, why not
Comment 6 Ben Skeggs 2012-01-02 21:13:49 EST
This issue is known (it effects all chips with very little vram), and requires significant surgery on all userspace driver components to fix properly.  This work is in progress upstream, and I hope to make it in time for F17.

I'm not entirely convinced you'll ever have a decent experience with gnome-shell on this chipset however, it's very very old.  But, the behaviour you're seeing still shouldn't happen regardless.  I highly recommend selecting forced fallback mode.
Comment 7 Ben Schwartz 2012-01-03 00:45:42 EST
Thanks for replying; I'm impressed that you're even thinking about this issue at all.

I wasn't expecting this issue to really be addressed at all, so I didn't specify a desired remedy.  I should clarify that, if I were asking for any actual change, it would be to blacklist this hardware in Nouveau (until it's fixed).  That way Gnome would automatically fall back, and the system wouldn't boot into crazy-pills mode by default.
Comment 8 Kamil Páral 2012-03-15 08:44:39 EDT
Similarly to bug 802069, I propose this as a F17 Beta/Final blocker. It doesn't have to get fixed per say, but we should at least ensure nouveau acceleration (or gnome-shell itself) is blacklisted for this particular graphics card / its family.
Comment 9 Adam Williamson 2012-03-15 13:50:30 EDT
The Shell blacklist is /usr/share/gnome-session/hardware-compatibility in gnome-session, so re-assigning to that package. Ben, what would the OpenGL renderer strings for affected hardware look like?

Fedora Bugzappers volunteer triage team
Comment 10 Adam Williamson 2012-03-15 13:51:42 EDT
btw, is a renderer-string based blacklist potentially a problem when there could be cards with the same GPU but differing amounts of VRAM? (Say, a 16MB NV11 would be bad, but a 32MB NV11 might work...)
Comment 11 Ben Schwartz 2012-03-15 14:07:09 EDT
The attached glxinfo says "OpenGL renderer string: Mesa DRI nv11 ".  I don't know anything about this stuff, so I have no idea if that's the string you're looking for.
Comment 12 Adam Williamson 2012-03-15 14:18:32 EDT
It is, but that's for your chip specifically. There are probably others that we would also want to blacklist. I would guess it would be a range from NV1 up to, say, NV20, but I'm not 100% sure. And I think they throw an 'x' in there every so often, to keep us on guard.

Fedora Bugzappers volunteer triage team
Comment 13 Adam Williamson 2012-03-16 13:47:20 EDT
Discussed at 2012-03-16 blocker review meeting.

This is a 'breadth of impact' bug: it clearly breaks the criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. The web browser must be able to download files, load extensions, and log into FAS" (the desktop isn't really usable), in the case of using old NVIDIA hardware; for the purposes of this bug we're talking NV<20 generation with low VRAM.

We agreed that the breadth of impact is appropriate for this to be a Final blocker but not a Beta blocker. It is accepted as NTH for Beta, blocker for Final. We think it's acceptable to release-but-document for Beta, but not for Final.

Fedora Bugzappers volunteer triage team
Comment 14 Adam Williamson 2012-03-23 14:11:46 EDT
Ben, if you're around and have time, could you test http://koji.fedoraproject.org/koji/buildinfo?buildID=309217 quickly? We believe it should 'address' this, by preventing cards with 64MB of VRAM or less from running Shell. Thanks!

Fedora Bugzappers volunteer triage team
Comment 15 Kamil Páral 2012-03-28 04:55:00 EDT
My NV43 with supposedly 64MB VRAM (see bug 802069 comment 12) still start in gnome-shell mode and the screen is corrupted.
Comment 16 Adam Williamson 2012-03-28 16:19:12 EDT
Kamil: with that build from #14?

Fedora Bugzappers volunteer triage team
Comment 17 Adam Williamson 2012-03-28 19:59:58 EDT
https://admin.fedoraproject.org/updates/mesa-8.0.1-9.fc17 should work around this by blacklisting <64MB NVIDIA adapters. However, this isn't really a fix - Ben thinks he can make it works better on low VRAM, so we should leave the bug open.

Can people please test if it blacklists their cards? I don't know if it's been changed since the scratch build which Kamil reported failure on, but it's worth checking again.

Fedora Bugzappers volunteer triage team
Comment 18 Kamil Páral 2012-03-29 10:46:59 EDT
mesa 8.0.1-9 doesn't change anything, comment 15 still applies.
Comment 19 Adam Williamson 2012-04-03 20:23:15 EDT
ajax, seems like your attempted mesa blacklist for this doesn't work. I think one other person besides kparal reported the same thing to me.

Fedora Bugzappers volunteer triage team
Comment 20 Tim Flink 2012-05-01 18:13:52 EDT
Do we know which Nvidia cards this is still causing problems for? Is a blacklist still the route we want to take in order to get rid of the corruption?
Comment 21 Adam Jackson 2012-05-03 15:34:19 EDT
It would be interesting to know if the remaining broken devices start working after applying the mutter patches mentioned in:


Since I believe some of the affected chips are in the "NV_texture_rectangle but not ARB_texture_non_power_of_two" set.

But beyond that, I'm not entirely sure why the blacklist wouldn't be working.
Comment 22 Adam Williamson 2012-05-04 09:11:07 EDT
Well, I'm pretty sure it isn't, based on feedback.

I think we were planning to have Ben's solution for final, right? IIRC, he said he can make it so low VRAM cards can render Shell, at the cost of something of a performance hit. Of course, if we do that, I suppose we should tell Phoronix so they don't go around yelling about regressions...

Fedora Bugzappers volunteer triage team
Comment 23 Adam Williamson 2012-05-08 02:20:01 EDT

Fedora Bugzappers volunteer triage team
Comment 24 Adam Williamson 2012-05-08 02:20:29 EDT
Ben said today he will attempt to implement his fix for this. Ben, if you could keep us up to date that'd be great. Thanks.
Comment 25 Ben Skeggs 2012-05-09 08:20:57 EDT
(In reply to comment #24)
> Ben said today he will attempt to implement his fix for this. Ben, if you could
> keep us up to date that'd be great. Thanks.

I'm about to make an attempt at the hack for GeForce 6/7 boards, but, last I checked mutter/gnome-shell is still broken in other ways for earlier chipsets..
Comment 26 Ben Skeggs 2012-05-09 10:14:17 EDT
Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4065028

Again, if you're on a board <= GeForce FX and you don't have window contents at all.  That's a different, not nouveau, bug (https://bugzilla.redhat.com/813648).
Comment 27 Kamil Páral 2012-05-09 11:06:48 EDT
(In reply to comment #26)
> Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4065028

This has fixed the problem for my NV43. Gnome Shell runs fine, no visible text corruption (or any other corruption). It's a bit slow, but it's usable. glxinfo reports "Gallium 0.4 on NV43" so I guess it uses hardware acceleration, and no software rendering. glxgears prints 450fps.

I don't see any missing window contents, Nautilus, Firefox, Terminal displays just fine.
Comment 28 Fedora Update System 2012-05-11 01:04:15 EDT
mesa-8.0.2-7.fc17 has been submitted as an update for Fedora 17.
Comment 29 Ben Skeggs 2012-05-11 01:06:00 EDT
The update above has the NVFX patches from the scratch build, as well as some additional NV3x fixes backported from the new driver that's upstream (they don't fix the text issue on NV34 however).

I've also added the lowmem workaround to vieux (the NV04/NV1x/NV2x) driver and it appears to work okay on a 64MiB NV18 I tested.
Comment 30 Kamil Páral 2012-05-11 07:06:30 EDT
I can't access my test machine with NV43 today. But my colleague Josef Skladanka installed mesa-8.0.2-7.fc17 on it and says the display is corrupted again (missing letters). I can re-test personally on Monday.

That would mean:
1. the scratch build mesa-8.0.2-5.1.fc17 fixed the problem on NV43
2. the proposed update mesa-8.0.2-7.fc17 re-introduced that problem
Comment 31 Fedora Update System 2012-05-11 17:52:02 EDT
Package mesa-8.0.2-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mesa-8.0.2-7.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 32 Kamil Páral 2012-05-14 08:09:48 EDT
I can confirm my colleague's findings mentioned in comment 30. I also tested mesa-8.0.2-6.fc17 and it is broken as well. That means mesa 8.0.2-5.1 fixed the problem and 8.0.2-6 broke it again.
Comment 33 Adam Williamson 2012-05-14 22:06:21 EDT
So we diagnosed this one: the small hunk of code that actually tells nouveau to use the 'hack' that works around this bug on nvfx adapters somehow dropped out of the second version of the patch. Ben will send through a fixed build soon.

Note that 'mesa-8.0-nvfx-horrific-hack.patch' - the version in the 5.1 build - sets screen->hack = TRUE in nvfx_screen.c , but 'mesa-8.0-nouveau-vieux-nvfx-lowmem.patch' in the 7 build does nothing equivalent. It does set nctx->hack = GL_TRUE for nv1x/nv2x adapters in nouveau_context.c, which is why things are okay on those cards.

Fedora Bugzappers volunteer triage team
Comment 34 Fedora Update System 2012-05-15 23:15:49 EDT
mesa-8.0.2-8.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.