Created attachment 520695 [details]
corrupted gnome shell desktop
Description of problem:
When running kernel 3.1.0-0.rc4.git0.0.fc16 with nouveau.noaccel=0 the gnome shell screen is totally corrupted. The rc4 is the first kernel that did not ignore the noaccel=0 option, rc3 and older used the fallback gnome environment.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot 3.1.0-rc4 kernel with nouveau.noaccel=0
gnome shell starts but screen is completely corrupted
gnome shell starts without corruptions
Created attachment 520696 [details]
Xorg.0.log (no errors shown)
Created attachment 520697 [details]
system log messages
Obvious question: and what happens when you run just with plain settings without any nouveau.* parameters?
I get gnome fallback shell without noaccel=0 because there is no glx nor other required features for gnome3 to work.
(In reply to comment #4)
> I get gnome fallback shell without noaccel=0 because there is no glx nor other
> required features for gnome3 to work.
And gnome-shell doesn't recognize (even when running wihtout noaccel=0) that your GPU is not supported and tries (and fails) to run in 3G mode?
Or do you try to persuade gnome-shell by force to run in 3G even though it resists?
I am sorry, I probably just don't understand completely what's the point here.
I failed the bug report because of this instruction in the fedora nouveau instructions.
QA:Testcase_nouveau_gnome3 ALL GeForce cards should support Shell: if you get fallback mode, please report the test as a warn and file a bug
So. By default F16 on Quadro 1000M uses a fallback mode. I could have just reported that as a bug. But I thought I'll to force the acceleration on and report the results in the same bug. If you want I can split this bug in two.
1. no acceleration by default on Quadrom 1000M
2. forced acceleration causes screen corruption on Quadro 1000M
- but no crashes, so it seems to be just some off-by-n or coordinate bug
There's a very good reason you need to force acceleration on for that chipset, it's *not* supported, due to this very reason. You are seeing the behaviour that is expected.
It's not a simple "off-by-n" bug, some part of the hardware on NVC1 operates differently to every other Fermi chipset we've seen, and until we find out what/how, it'll remain broken.
In any case, not a fedora bug, this needs to be resolved upstream. I assure you, it'll hit fedora as soon as a solution is found.