Distorted screen on MacBook Air 3,2 (GT216 10de:08a3)

Bug #898784 reported by Peter Hedlund
56
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
Nouveau Xorg driver
Fix Released
Medium
Fedora
Won't Fix
High
xserver-xorg-video-nouveau (Ubuntu)
Fix Released
High
Maarten Lankhorst

Bug Description

The internal display is distorted with vertical bands of different colors separated by black and white noise.

The the good news is that an external monitor now works perfectly through the mini displayport.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1
ProcVersionSignature: Ubuntu 3.2.0-2.5-generic 3.2.0-rc3
Uname: Linux 3.2.0-2-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.90-0ubuntu1
Architecture: amd64
CasperVersion: 1.292
CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,gnomecompat,grid,imgpng,mousepoll,move,place,regex,resize,session,snap,unitymtgrabhandles,vpswitch,wall,animation,expo,ezoom,fade,scale,unityshell,workarounds]
CompositorRunning: compiz
Date: Thu Dec 1 19:21:56 2011
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 nVidia Corporation Device [10de:08a3] (rev a2) (prog-if 00 [VGA controller])
   Subsystem: Apple Computer Inc. Device [106b:00d3]
LiveMediaBuild: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
MachineType: Apple Inc. MacBookAir3,2
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/hostname.seed boot=casper quiet splash --
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/18/10
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBA31.88Z.0061.B01.1011181342
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-942C5DF58193131B
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookAir3,2
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-942C5DF58193131B
dmi.modalias: dmi:bvnAppleInc.:bvrMBA31.88Z.0061.B01.1011181342:bd11/18/10:svnAppleInc.:pnMacBookAir3,2:pvr1.0:rvnAppleInc.:rnMac-942C5DF58193131B:rvrMacBookAir3,2:cvnAppleInc.:ct10:cvrMac-942C5DF58193131B:
dmi.product.name: MacBookAir3,2
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu7
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.27-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu4
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu4
version.xserver-xorg-core: xserver-xorg-core 2:1.10.4-1ubuntu5
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Ben (ben-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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?

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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?

Revision history for this message
In , Ben (ben-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

Created attachment 461031
dmesg with nouveau debug

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

Created attachment 461032
vbios rom file

Revision history for this message
In , Marcus (marcus-redhat-bugs) wrote :

Hi all.

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

Kind Regards
Marcus

Revision history for this message
In , Marcus (marcus-redhat-bugs) wrote :

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

Revision history for this message
In , Jan (jan-redhat-bugs) wrote :

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.

Revision history for this message
In , Rob (rob-redhat-bugs) wrote :

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.

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

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

Revision history for this message
In , Rob (rob-redhat-bugs) wrote :

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

Revision history for this message
In , Rob (rob-redhat-bugs) wrote :

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

Revision history for this message
In , Matěj (matj-redhat-bugs) wrote :

Isn't this actually a duplicate of bug 650949?

Revision history for this message
In , Matthew (matthew-redhat-bugs) wrote :

Given that this *is* bug 650949...

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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.

Revision history for this message
In , Papadeas (papadeas-redhat-bugs) wrote :

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.

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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*

Revision history for this message
In , Papadeas (papadeas-redhat-bugs) wrote :

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

Revision history for this message
In , Matthew (matthew-redhat-bugs) wrote :

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

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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.

Revision history for this message
In , Papadeas (papadeas-redhat-bugs) wrote :

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

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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.

Revision history for this message
In , Ben (ben-redhat-bugs) wrote :

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 :)

Revision history for this message
In , Papadeas (papadeas-redhat-bugs) wrote :

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.

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

Please attach a photo of the screen showing the corruption.

Also, does the corruption occur all the time, or only when an external monitor is attached?

Did you notice this immediately on installing Precise or has it regressed only recently?

Changed in xserver-xorg-video-nouveau (Ubuntu):
status: New → Incomplete
Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Screenshot looks normal.

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

A photo of the screen shows the distortion. It does not matter if an external monitor is attached or not. The internal monitor works fine in Oneiric. A live CD with Fedora 16 shows the same regression.

Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

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

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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.

Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

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

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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.

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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.

Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

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

Revision history for this message
In , Chris (chris-redhat-bugs) wrote :

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

Revision history for this message
In , Matthew (matthew-redhat-bugs) wrote :

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.

Bryce Harrington (bryce)
Changed in xserver-xorg-video-nouveau (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
Revision history for this message
In , Adam (adam-redhat-bugs) wrote :

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

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Still present in daily build for 20120111.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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.

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Forwarding this bug from Ubuntu reporter Peter Hedlund:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/898784

[Problem]
The internal display is distorted with vertical bands of different colors separated by black and white noise. This worked in Ubuntu 11.10 (kernel 3.0).

The the good news is that an external monitor now works perfectly through the mini displayport, which did not work in Ubuntu 11.10.

DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1
Uname: Linux 3.2.0-2-generic x86_64
CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,gnomecompat,grid,imgpng,mousepoll,move,place,regex,resize,session,snap,unitymtgrabhandles,vpswitch,wall,animation,expo,ezoom,fade,scale,unityshell,workarounds]
CompositorRunning: compiz
Date: Thu Dec 1 19:21:56 2011
GraphicsCard:
 nVidia Corporation Device [10de:08a3] (rev a2) (prog-if 00 [VGA controller])
   Subsystem: Apple Computer Inc. Device [106b:00d3]
LiveMediaBuild: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
MachineType: Apple Inc. MacBookAir3,2
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/hostname.seed boot=casper quiet splash --
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/18/10
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBA31.88Z.0061.B01.1011181342
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-942C5DF58193131B
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookAir3,2
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-942C5DF58193131B
dmi.modalias: dmi:bvnAppleInc.:bvrMBA31.88Z.0061.B01.1011181342:bd11/18/10:svnAppleInc.:pnMacBookAir3,2:pvr1.0:rvnAppleInc.:rnMac-942C5DF58193131B:rvrMacBookAir3,2:cvnAppleInc.:ct10:cvrMac-942C5DF58193131B:
dmi.product.name: MacBookAir3,2
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu7
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.27-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu4
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu4
version.xserver-xorg-core: xserver-xorg-core 2:1.10.4-1ubuntu5
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created attachment 55885
DSC03982.JPG

Photo of screen showing corruption.

The background is supposed to be a purple gradient (ala https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/898784/+attachment/2616711/+files/Screenshot%20at%202011-12-02%2017%3A17%3A49.png)

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created attachment 55886
BootDmesg.txt

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created attachment 55887
XorgLog.txt

Bryce Harrington (bryce)
summary: - Distorted screen on MacBook Air 3,2
+ Distorted screen on MacBook Air 3,2 (GT216 10de:08a4)
summary: - Distorted screen on MacBook Air 3,2 (GT216 10de:08a4)
+ Distorted screen on MacBook Air 3,2 (GT216 10de:08a3)
Revision history for this message
Bryce Harrington (bryce) wrote :

You have a nVidia Corporation Device [10de:08a3], which is a GT216 (GeForce 320M), however the nvidia 290.10 driver's README only lists that it supports the 10de:08a5 version of the GT216, so I wonder if that could be part of the problem. However that doesn't explain why it would work on oneiric and then fail on precise.

I see they have a beta 290.53 driver but it's windows only, and I don't see mention of any fixes for GeForce 3xxM series hardware.

Revision history for this message
Bryce Harrington (bryce) wrote :

Of course my last comment might make sense if you were running -nvidia, which you aren't!
So, nevermind that.

I'll forward this to the nouveau guys.

Changed in xserver-xorg-video-nouveau (Ubuntu):
importance: Medium → High
Revision history for this message
Bryce Harrington (bryce) wrote :

Peter Hedlund - I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=45017 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

Revision history for this message
Bryce Harrington (bryce) wrote :

You may also want to doublecheck that the new development kernel still shows the bug. If not, there might be a patch to be backported:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/

Changed in nouveau:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Peter Hedlund (peter-peterandlinda) wrote :

Since this is a regression I am interested in trying to walk backwards to try to identify the problem. Is it likely that the problem is in xf86-video-nouveau or someplace else? Is cgit.freedesktop.org down or where do I browse the code? I would appreciate any hints on how to go about this.

Revision history for this message
In , Mads (mads-redhat-bugs) wrote :

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.

Revision history for this message
zEn (der-eremit) wrote :

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/

problem is fixed when running this kernel

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

I can also confirm that the issue is fixed in kernel 3.3. I am running rc7 from mainline. There appears to be confirmation from Fedora also https://bugzilla.redhat.com/show_bug.cgi?id=650949.

Any chance we can see relevant parts backported to precise?

Revision history for this message
In , Peter Hedlund (peter-peterandlinda) wrote :

Fixed for me in linux kernel 3.3.

Revision history for this message
zEn (der-eremit) wrote :

sorry if i ask this in this bug-report, but Peter, do you have working wifi with the mainline kernel,
at the moment i can choose between graphics corruption or no wireless...

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Yes, wireless works fine. For an earlier kernel (3.0 I believe) I had blacklisted the bcma module. For 3.3 I removed the blacklisting and wireless started working.

Revision history for this message
Chris McClimans (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlr-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o6) wrote :

This distortion is similar to what I'm having, and I've noticed it's not limited to X, it's on console as well....

Revision history for this message
Chris McClimans (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlr-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o6) wrote :

Corruption happens even if you do not start X...

Revision history for this message
Chris McClimans (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlr-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o6) wrote :
Revision history for this message
Chris McClimans (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlr-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o6) wrote :

https://help.ubuntu.com/community/UEFIBooting#Tested_configurations now includes a link to this bug and a note to use a 3.3 kernel to fix this issue.

Revision history for this message
Chris McClimans (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlr-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o6) wrote :

I'm guessing running 3.3 kernel isn't going to be very stable for a while... no chance of the driver changes included in 3.3 to make it into a 3.2 kernel that will be supported by 12.04 LTS 8( I'm having a fair bit of kernel panics, and inability to mount btrfs from 3.3, which I can from the 3.2 included with 12.04.

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

The good times did not last, the bug is back in kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/.

Revision history for this message
In , Peter (peter-redhat-bugs) wrote :

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.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Soulnafein (soulnafein) wrote :

I've just downloaded Ubuntu 12.04 64bit. I've booted my Macbook Air 3,2 from external drive and I've noticed the same graphic corruption. It starts from the ubuntu progress bar.
Is there a workaround for this problem? Do I need to cope with it only during the installation?

Revision history for this message
Soulnafein (soulnafein) wrote :

This page https://help.ubuntu.com/community/MacBookAir3-2/Pangolin says I can cope with it during installation and fix it afterward upgrading kernel.

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Still present in 3.4-rc5.

Revision history for this message
Maarten Lankhorst (mlankhorst) wrote :

If it's back in v3.4-rc3-precise, did it work with v3.4-rc2-precise?

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

No, I have now tested rc1 and rc2. None of them work.

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Still present in 3.4-rc6.

Revision history for this message
Soulnafein (soulnafein) wrote :

Do you reckon this bug will be fixed in time for the release of 12.04.1 ?

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Well, 12.04 runs fine with a 3.3 kernel. The real problem is that the bug is back in the 3.4 kernel including the final release and there has been no fix during the entire rc-cycle. Also, so far no comment from an involved developer.

Revision history for this message
Maarten Lankhorst (mlankhorst) wrote :

This looks suspicious:

[ 4.607278] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
[ 4.607298] Console: switching to colour dummy device 80x25
It

The dummy device is not connected to anything, it should say say 'frame buffer device' or something.
Can you post a dmesg of the working kernel?

Judging from xrandr it can detect all outputs fine, so it seems to be a bug in handoff.

Also can you try to boot linux with 'noefi' on v3.4 to see if that works around the bug? I would like dmesg from that as well. :)

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

I think 3.4 is a lost cause. The problem is fixed in 3.5-rc1 although I have had some instability issues that I hope will improve. The drm pull request for 3.5 (http://lists.freedesktop.org/archives/dri-devel/2012-May/023395.html) contains this comment which I think is the relevant part:

drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks

Revision history for this message
Maarten Lankhorst (mlankhorst) wrote :

Well if reverting that patch breaks things again I would assume you could build the 3.4 kernel with it and have it working. :)

Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

Yes, assuming that is the relevant patch. I have not done any compilation, but the code is in a file called nouveau_connector.c and 3.4 and 3.5 are similar enough to do a backport. In the Precise kernel 3.2 the code is very different.

However, right now I don't really see the point. Precise works fine with a 3.3 kernel and I assume Quantal will use 3.5 or 3.6. We just have to make sure there are no further regressions.

Revision history for this message
Maarten Lankhorst (mlankhorst) wrote :

I'll try to get all the patches in through the upstream stable kernel.

Changed in xserver-xorg-video-nouveau (Ubuntu):
assignee: nobody → Maarten Lankhorst (mlankhorst)
tags: added: qa-kernel-lts-testing
Revision history for this message
Maarten Lankhorst (mlankhorst) wrote :
Changed in xserver-xorg-video-nouveau (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
In , Maarten (maarten-redhat-bugs) wrote :

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

Revision history for this message
In , Maarten Lankhorst (mlankhorst) wrote :

Fix is backported from 3.5rc to 3.4.3 and 3.2.21

Changed in nouveau:
status: Confirmed → Fix Released
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/898784

tags: added: package-qa-testing
Revision history for this message
Peter Hedlund (peter-peterandlinda) wrote :

I can confirm that the latest Ubuntu kernel 3.2.0-27 works on my MacBook Air 3,2. Thank you!

Changed in xserver-xorg-video-nouveau (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

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.

Changed in fedora:
importance: Unknown → High
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.