Bug 650949

Can you please update to xorg-x11-drv-nouveau-0.0.16-13.20101010git8c8f15c.fc14 (http://koji.fedoraproject.org/koji/buildinfo?buildID=199899) as this problem *should* probably be fixed.

If it's still not after that, can you fetch me your dmesg output after the "funny" graphics appear please.

OK, tried that version. Short summary of findings.

When using modeset, garbled screen (like broken TV).

With nomodeset, boots into VESA resolution 1024x768, so does not recognize/use native resolution of screen, X.org.0.log attached.

Will go back to garbled screen and get you a clean dmesg in a few hours.

Created attachment 459028 [details]
X.org.0.log - using nouveau on a MBA3,1,1 - using VESA not native resolution

Using xorg-x11-drv-nouveau-0.0.16-13.20101010git8c8f15c.fc14 with nomodeset breaks the resume part of suspend/resume. This does work when using the proprietary nvidia driver from rpmfusion.

Using xorg-x11-drv-nouveau-0.0.16-13.20101010git8c8f15c.fc14 with modeset enabled in grub results in garbled screen (also console is garbled). I took two pictures that show console ,mode and X with garbled screen. I also took dmesg and X.org.0.log form the garbled setup and added them here.

Created attachment 459060 [details]
The X.org.0.log of the MBA311 running with modeset resulting in garbled screen

Created attachment 459061 [details]
dmesg of the MBA311 running with modeset resulting in garbled screen

Created attachment 459063 [details]
Screenshot of garbled console when using nouveau on MBA311

Created attachment 459065 [details]
Screenshot of garbled X when using nouveau on MBA311

Also noticed that with nouveau running (albeit in VESA 1024x768 mode only) seems to really heat up the MBA. The fan starts spinning at top speed after a few minutes of simply having the box sitting nest to me, with no load or applications running - not even a screensaver.

This does not happen with the proprietary nvidia drivers.

WRT suspend/resume breakage with nouveau - I followed the steps in http://fedoraproject.org/wiki/KernelCommonProblems#Suspend.2FResume_failure and came up with:

[    1.052877]   hash matches drivers/base/power/main.c:562

Again, when using the prorietary nvidia drivers by installing kmod-nvidia from rpmfusion suspend/resume Just Works.

Should this be seperated into a new Bugzilla or is it related to nouveau?

I have updated to kernel-2.6.35.8-59.fc14.x86_64 from koji, which fixes backlight control and a few other thing, see BZ #651019 for more details.

So ATM I only have two problems with nouveau on MBA3:

- No support of native resolution (seems to fallback to VESA)
- nouveau breaks the resume part of suspend/resume

Should I try rawhide version next?

To clarify, you are *not* using nouveau if you use "nomodeset.  And suspend/resume is *not* going to work with VESA.

Ok. Can i get a dmesg log of booting with "drm.debug=14 nouveau.reg_debug=0x0200 log_buf_len=1M", and also the vbios image.  While running nouveau it can be retrieved from /sys/kernel/debug/dri/0/vbios.rom, you may need to mount debugfs (mount -t debugfs none /sys/kernel/debug) first.

I suspect nouveau has some issue with the eDP panel.

OK. Done that. Note however I could only do it in runlevel 1. X doesn't start, screen is blank and I cannot switch to a VT in runlevel 5.

Attached both dmesg and vbios image.

Created attachment 461031 [details]
dmesg with nouveau debug

Created attachment 461032 [details]
vbios rom file

Hi all.

I have tried out the provided nouveau updated but the screen resolution is still not detected correctly.  

Kind Regards
Marcus

Created attachment 468611 [details]
edid information retreived from nvidia-settings on a macbook air 3.1 11.6'

So now we are 1.5 months later, we have provided all info asked for and this bus is still on status NEW and no progress to be seen. What can I do to help, speed things up? Send my MBA to someone willing to fix? I *want* to use Fedora, but this is a showstopper.

Hi, I'm experiencing this as well. I have a macbook air and am located in the Raleigh office. I've been working with different modesettings, and have had a bit of progress. The fact that everything seems to work reasonably well with nomodeset configured makes me wonder if a different modeset would work correctly. The nvidia drive does work, but kills quite a bit of functionality (regarding external displays. I plan to use this for presentation purposes when possible). 

If anybody in the raleigh office would like to take a look, please let me know. Also if you're in westford I'll be up there next month.

*** Bug 662735 has been marked as a duplicate of this bug. ***

Created attachment 480163 [details]
Updated fedora-gfx-test-week build /var/log/messages

Created attachment 480164 [details]
Updated fedora-gfx-test-week build Xorg.0.log

Isn't this actually a duplicate of bug 650949?

Given that this *is* bug 650949...

I don't see a clear indicator that any of these are EFI-based boot attempts, but rather CSM BIOS. This is disconcerting because I've already found EFI booting on Apple hardware to be nearly a dead end with all but newer hardware, and even with newer hardware it can be problematic. So if the CSM BIOS isn't adequate either on newer hardware, then we're really screwed.

I'm frustrated that Apple has not abandoned their proprietary Intel EFI 1.10 + GOP (UEFI 2.x) + some Apple stuff, in favor of full UEFI 2.x support. From my perspective this is more their domain and responsibility to fix.

Is there anything that we can do in order to have this fixed? (provide any more info etc?)

It is really sad to have proprietary drivers loaded.

I'd like to be wrong and see this work, but I remain suspicious that this is Apple's responsibility to provide adequate hardware information in their CSM BIOS, which they may not, therefore nouveau can't do the right thing. Or Apple needs to move to a standard implementation of UEFI with UEFI drivers which they may not be able to do depending on their licensing with Nvidea, or their own priorities - running anything other than Mac OS on Apple hardware I perceive to be a rather low priority for Apple. They tend to do the minimum required.

But it's an interesting point that the CSM BIOS is adequate for Windows Vista and 7 to get the necessary information in order to support this same hardware. *shrug*

Chris is there anyway we can be sure it is our lack of info for CSM BIOS that is blocking this?

Nobody's worked out what the problem is, so assigning it to Apple's CSM implementation is premature.

Need to hear from Ben Skeggs, or someone who knows what nouveau needs and what it's not getting. I know enough to get into trouble. 

There may be just enough info in the BIOS for the proprietary Windows Nvidia driver to function correctly, whereas it wouldn't surprise me if nouveau needs more information because it's not in as much a position to make assumptions about hardware as either Apple or Nvidia. Pure speculation on my part. But it is consistent with Apple's minimalist approach to supporting Windows, UEFI and even BIOS.

So does it makes sense to assign that to Ben, or flag that as "info needed" from him?

Not my area. Appears to already be assigned to Ben. Honestly at this point I'd consider downloading F15 beta and see if the problem is reproducible there, if anything has changed behavior wise, and then report back. Or wait for F15 final and test it there.

The status currently on these is that in an EFI boot, we can't even detect the display (Matthew Garrett confirmed recently the NVIDIA binary driver can't either).  With a BIOS boot, it ends up garbled.

It's likely I could fix the latter if I had physical access to one, the problem hasn't been obvious to me from logs and traces however.  It'd be a lot of trial and error to find the cause before fixing it.

As for the former problem, my guess is it can be solved somehow, might be tricky not being able to see how NVIDIA manage it, because, they can't :)

Ben, I am willing to be the guinea pig for testing it :) So far the latter is the only thing I managed to have. Please let me know what I can provide more on test results.

*** Bug 751147 has been marked as a duplicate of this bug. ***

You might be interested in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/898784 which also affects Fedora 16.

With the 320M there has been two steps forward; resume from suspend and external monitor now works, and one step backward; the laptop display is now corrupted.

Is there any newer news on this, Ben? Any prospect of support for these Macs in F17?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I think the title change is very confusing. I am only having problems with MacbookPro 4,1, (Nvidia Geforce 8600M GT) with EFI boot. I do not have problems with CSM/BIOS boot (except for the limitations that come with CSM/BIOS booting which is another matter).

Also, in the EFI boot case, at least the kernel is booting, and functioning so the title is misleading in that regard as well. It's just that when nouveau loads, the computer becomes (unintentionally) headless. But ssh works.

While the manifestation is different on the Macbook Pro 8,2 (this is a 2011 model with both Intel HD Graphics 3000 and AMD Radeon HD 6490M or 6750M), there is also a problem with EFI boot on this hardware, while CSM/BIOS boot appears to function as expected.

Oops, I got this bug confused with another one. Disregard complaint about title changing. Still, it needs to be more clear because my MBP4,1 is not experiencing garbled video with CSM/BIOS booting.

chris: well, the bug actually initially reported here is the corrupted video when booted CSM:

"Steps to Reproduce:
1. Try to boot Fedora 14 x86_64
2. Watch funny distorted graphics
3. That's it"

the issue with EFI booting only appears later. So if we were to treat them as separate bugs, if anything, this bug would be for the corruption-with-CSM-boot and we'd need a separate bug for EFI-boot-fails.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

If we are constraining the bug to that of the original poster, the hardware is a MacBookAir 3,1 which has Nvidia GeForce 320M graphics, and the boot method is CSM/BIOS.

I have a MacBookPro 4,1 (Nvidia Geforce 8600M GT graphics)  which is listed in the title of this bug, and I do not experience distorted graphics when booting CSM/BIOS.

I cannot vouch for the MacBookPro 3,1 but Wikipedia's extensive listing of specs says it too has Nvidia Geforce 8600M GT graphics.

FWIW, these are three completely distinct Apple models:
MacBook 3,1
MacBookPro 3,1
MacBookAir 3,1

Please separate these issues by GPU (vendor and model). The NVAF issue on the Macbook Air 3,1 and 3,2 is now fixed - there may be different issues with different models.

Okay. I'll un-dupe the other bug and make that the one for 8600M.

So: if you have a system with the GeForce 320M graphics - which we believe covers the Macbook Air 3,1,1 and 3,2 - stay with this bug (and mjg believes there's a fix in Rawhide?)

If you have a system with 8600M GT graphics - appears to include Macbook Pro 3,1 and Macbook Pro 4,1 - please go to https://bugzilla.redhat.com/show_bug.cgi?id=751147 .

Sorry for the confusion.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Now that I could finally boot a live CD of F17 I must unfortunately report that the screen corruption on GeForce 320M (MacBook Air 3,2) is still there.

For a photo of what it looks like see comment 4 in this bug report https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/898784.

F16 with 3.2.9-1.fc16.x86_64 on MacBookAir3,1 "NVIDIA NVaf" booted with EFI and grub2 now works for me - both graphics and wireless.

For me this bug is fixed in kernel 3.3, but has reappeared in kernel 3.4-rc3. Upstream report is at https://bugzilla.kernel.org/show_bug.cgi?id=42984.

Fixed is backported from 3.5rc to 3.4.3+ and 3.2.21+

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.