Bug 734600 - nouveau GF108 [Quadro 1000M] graphics totally corrupted with noaccel=0
Summary: nouveau GF108 [Quadro 1000M] graphics totally corrupted with noaccel=0
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-30 21:26 UTC by Mikko Tiihonen
Modified: 2018-04-11 07:58 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-09-09 03:10:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
corrupted gnome shell desktop (17.52 KB, image/png)
2011-08-30 21:26 UTC, Mikko Tiihonen
no flags Details
Xorg.0.log (no errors shown) (50.50 KB, text/plain)
2011-08-30 21:28 UTC, Mikko Tiihonen
no flags Details
system log messages (87.09 KB, text/plain)
2011-08-30 21:41 UTC, Mikko Tiihonen
no flags Details

Description Mikko Tiihonen 2011-08-30 21:26:18 UTC
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):
kernel-3.1.0-0.rc4.git0.0.fc16.x86_64
xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16.x86_64

http://smolts.org/show?uuid=pub_3c6a9593-e12a-439c-92ed-be0c246da1ab

How reproducible:
Happens always

Steps to Reproduce:
1. boot 3.1.0-rc4 kernel with nouveau.noaccel=0
  
Actual results:
gnome shell starts but screen is completely corrupted

Expected results:
gnome shell starts without corruptions

Additional info:

Comment 1 Mikko Tiihonen 2011-08-30 21:28:10 UTC
Created attachment 520696 [details]
Xorg.0.log (no errors shown)

Comment 2 Mikko Tiihonen 2011-08-30 21:41:23 UTC
Created attachment 520697 [details]
system log messages

Comment 3 Matěj Cepl 2011-09-05 15:34:46 UTC
Obvious question: and what happens when you run just with plain settings without any nouveau.* parameters?

Comment 4 Mikko Tiihonen 2011-09-06 06:50:39 UTC
I get gnome fallback shell without noaccel=0 because there is no glx nor other required features for gnome3 to work.

Comment 5 Matěj Cepl 2011-09-06 15:25:49 UTC
(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.

Comment 6 Mikko Tiihonen 2011-09-06 18:40:13 UTC
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

Comment 7 Ben Skeggs 2011-09-09 03:10:57 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.