|Summary:||BIOS compatibility boot produces corrupted graphics on Macs with NVIDIA GeForce 320M video adapters (Macbook Air 3,1,1 and 3,2)|
|Product:||[Fedora] Fedora||Reporter:||Jan Wildeboer <jwildebo>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||airlied, ajax, awilliam, bskeggs, bugzilla, jason, jfeeney, jreiser, mads, marcus.moeller, m.b.lankhorst, mcepl, peter, ppapadeas, radford, rwilmoth, satellitgo, s.schwandter, the.ridikulus.rat, zach.lute|
|Target Milestone:||---||Keywords:||CommonBugs, Triaged|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-17 13:27:43 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jan Wildeboer 2010-11-08 13:26:25 UTC
Description of problem: Find smolt profile of this machine at: http://www.smolts.org/client/show/pub_01375d10-2b7a-4d39-a71e-89d7f4789d55 Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-11.20100826git065576d.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. Try to boot Fedora 14 x86_64 2. Watch funny distorted graphics 3. That's it Actual results: No normal function Expected results: working graphics Additional info: The new Macbook Air3,1,1 is based on nVidia MCP89 chipset. Some other problems too, in separate BZs. I also tried booting with 'nomodeset' to no avail. I am not interested in 3D graphics ATM, just plain simple 2D. According to nouveau pages the chip in question should work. So either Apple made some special stuff or there is a bigger problem hidden here. Booting with vesa works, but cannot use the native display resolution of 1366x768 so screen looks ugly. Using the nvidia proprietary drivers from rpmfusion seems to work a bit better.
Comment 1 Ben Skeggs 2010-11-08 22:48:17 UTC
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.
Comment 2 Jan Wildeboer 2010-11-09 08:14:06 UTC
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.
Comment 3 Jan Wildeboer 2010-11-09 08:15:40 UTC
Created attachment 459028 [details] X.org.0.log - using nouveau on a MBA3,1,1 - using VESA not native resolution
Comment 4 Jan Wildeboer 2010-11-09 08:56:30 UTC
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.
Comment 5 Jan Wildeboer 2010-11-09 09:58:20 UTC
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.
Comment 6 Jan Wildeboer 2010-11-09 09:59:46 UTC
Created attachment 459060 [details] The X.org.0.log of the MBA311 running with modeset resulting in garbled screen
Comment 7 Jan Wildeboer 2010-11-09 10:00:19 UTC
Created attachment 459061 [details] dmesg of the MBA311 running with modeset resulting in garbled screen
Comment 8 Jan Wildeboer 2010-11-09 10:02:47 UTC
Created attachment 459063 [details] Screenshot of garbled console when using nouveau on MBA311
Comment 9 Jan Wildeboer 2010-11-09 10:03:27 UTC
Created attachment 459065 [details] Screenshot of garbled X when using nouveau on MBA311
Comment 10 Jan Wildeboer 2010-11-09 11:58:16 UTC
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.
Comment 11 Jan Wildeboer 2010-11-09 13:37:12 UTC
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?
Comment 12 Jan Wildeboer 2010-11-16 11:57:02 UTC
I have updated to kernel-126.96.36.199-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?
Comment 13 Ben Skeggs 2010-11-16 21:20:28 UTC
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.
Comment 14 Jan Wildeboer 2010-11-17 09:51:11 UTC
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.
Comment 15 Jan Wildeboer 2010-11-17 09:51:55 UTC
Created attachment 461031 [details] dmesg with nouveau debug
Comment 17 Marcus Moeller 2010-12-14 13:52:22 UTC
Hi all. I have tried out the provided nouveau updated but the screen resolution is still not detected correctly. Kind Regards Marcus
Comment 18 Marcus Moeller 2010-12-14 13:53:28 UTC
Created attachment 468611 [details] edid information retreived from nvidia-settings on a macbook air 3.1 11.6'
Comment 19 Jan Wildeboer 2010-12-20 13:02:38 UTC
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.
Comment 20 Rob Wilmoth 2011-02-21 16:26:38 UTC
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.
Comment 21 Matěj Cepl 2011-02-22 15:34:09 UTC
*** Bug 662735 has been marked as a duplicate of this bug. ***
Comment 22 Rob Wilmoth 2011-02-22 15:53:20 UTC
Created attachment 480163 [details] Updated fedora-gfx-test-week build /var/log/messages
Comment 23 Rob Wilmoth 2011-02-22 15:53:57 UTC
Created attachment 480164 [details] Updated fedora-gfx-test-week build Xorg.0.log
Comment 26 Chris Murphy 2011-04-30 22:35:07 UTC
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.
Comment 27 Papadeas Pierros 2011-05-10 19:16:42 UTC
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.
Comment 28 Chris Murphy 2011-05-10 20:13:16 UTC
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*
Comment 29 Papadeas Pierros 2011-05-10 20:19:09 UTC
Chris is there anyway we can be sure it is our lack of info for CSM BIOS that is blocking this?
Comment 30 Matthew Garrett 2011-05-10 20:27:30 UTC
Nobody's worked out what the problem is, so assigning it to Apple's CSM implementation is premature.
Comment 31 Chris Murphy 2011-05-10 20:32:51 UTC
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.
Comment 32 Papadeas Pierros 2011-05-10 20:37:47 UTC
So does it makes sense to assign that to Ben, or flag that as "info needed" from him?
Comment 33 Chris Murphy 2011-05-10 20:45:02 UTC
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.
Comment 34 Ben Skeggs 2011-05-10 22:02:18 UTC
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 :)
Comment 35 Papadeas Pierros 2011-05-11 12:54:22 UTC
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.
Comment 36 Adam Williamson 2011-12-02 21:00:17 UTC
*** Bug 751147 has been marked as a duplicate of this bug. ***
Comment 37 Peter Hedlund 2011-12-02 23:54:53 UTC
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.
Comment 38 Adam Williamson 2011-12-06 00:56:43 UTC
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
Comment 39 Chris Murphy 2011-12-06 01:30:03 UTC
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.
Comment 40 Chris Murphy 2011-12-06 01:32:25 UTC
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.
Comment 41 Adam Williamson 2011-12-06 01:42:52 UTC
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
Comment 42 Chris Murphy 2011-12-06 02:00:36 UTC
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
Comment 43 Matthew Garrett 2011-12-06 02:46:17 UTC
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.
Comment 44 Adam Williamson 2011-12-07 17:32:31 UTC
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
Comment 45 Peter Hedlund 2012-01-20 17:17:27 UTC
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.
Comment 46 Mads Kiilerich 2012-03-12 16:38:00 UTC
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.
Comment 47 Peter Hedlund 2012-04-19 16:01:57 UTC
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.
Comment 48 Maarten Lankhorst 2012-06-28 11:34:32 UTC
Fixed is backported from 3.5rc to 3.4.3+ and 3.2.21+
Comment 49 Fedora End Of Life 2013-04-03 18:30:30 UTC
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
Comment 50 Fedora End Of Life 2015-01-09 16:25:17 UTC
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.
Comment 51 Fedora End Of Life 2015-02-17 13:27:43 UTC
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.