MacBook Pro 10,1 with Retina Display and NVE0. The screen blanks for about half a second every 9 seconds. The following error is printed to dmesg when this occurs: [ 14.695940] [drm] nouveau 0000:01:00.0: INIT_AUXCH: rd auxch fail -6 I will attach the dmesg output with auxch debugging enabled (dmesg.auxch) as well as full debugging (dmesg.debug). I will also include the vbios and lspci output. Possibly related, nouveau does not report any attached connectors. I've forced eDP-1 enabled on the kernel commandline: video=eDP-1:2880x1800@45e.
Created attachment 64089 [details] dmesg with auxch debugging
Created attachment 64090 [details] dmesg with full debug
Created attachment 64091 [details] vbios
Created attachment 64092 [details] output of lspci -v
Created attachment 64094 [details] drm.debug=0x04 during screen reset I've attached the output of dmesg during a screen reset with drm.debug=0x04. It looks like DRM is receiving a hotplug event indicating that the connector eDP-2 has been unplugged. This disconnects the display. Then nouveau, seeing that eDP-2 has been force enabled, reconnects the display. So now I'm fairly certain that solving the disconnected connector issue will fix the every-9-seconds screen blanking. The fun starts at line 1504: [ 1860.869890] [drm:output_poll_execute], [CONNECTOR:15:eDP-2] status updated from 1 to 2 [ 1860.900386] [drm:output_poll_execute], [CONNECTOR:17:DP-1] status updated from 2 to 2 [ 1860.930656] [drm:output_poll_execute], [CONNECTOR:20:DP-2] status updated from 2 to 2 [ 1860.931886] [drm:output_poll_execute], [CONNECTOR:23:HDMI-A-1] status updated from 2 to 2 [ 1860.932011] [drm:drm_fb_helper_hotplug_event], [ 1860.932013] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:15:eDP-2] [ 1860.932016] [drm] nouveau 0000:01:00.0: nouveau_connector_native_mode:583 - native mode from largest: 0x0@0 [ 1860.932023] [drm:drm_mode_debug_printmodeline], Modeline 25:"2880x1800" 0 325842 2880 3088 3400 3920 1800 1801 1804 1847 0x0 0x6 [ 1860.932026] [drm:drm_mode_prune_invalid], Not using 2880x1800 mode -3 [ 1860.932028] [drm:drm_mode_debug_printmodeline], Modeline 32:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa [ 1860.932030] [drm:drm_mode_prune_invalid], Not using 1024x768 mode 15 [ 1860.932032] [drm:drm_mode_debug_printmodeline], Modeline 31:"848x480" 0 33750 848 864 976 1088 480 486 494 517 0x40 0x5 [ 1860.932034] [drm:drm_mode_prune_invalid], Not using 848x480 mode 15 [ 1860.932035] [drm:drm_mode_debug_printmodeline], Modeline 30:"800x600" 0 40000 800 840 968 1056 600 601 605 628 0x40 0x5 [ 1860.932038] [drm:drm_mode_prune_invalid], Not using 800x600 mode 15 [ 1860.932039] [drm:drm_mode_debug_printmodeline], Modeline 29:"800x600" 0 36000 800 824 896 1024 600 601 603 625 0x40 0x5 [ 1860.932041] [drm:drm_mode_prune_invalid], Not using 800x600 mode 15 [ 1860.932042] [drm:drm_mode_debug_printmodeline], Modeline 28:"640x480" 0 25175 640 656 752 800 480 489 492 525 0x40 0xa [ 1860.932044] [drm:drm_mode_prune_invalid], Not using 640x480 mode 15 [ 1860.932046] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DP-1] [ 1860.962546] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DP-1] disconnected [ 1860.962549] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:20:DP-2] [ 1860.992829] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:20:DP-2] disconnected [ 1860.992830] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:HDMI-A-1] [ 1860.994059] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:23:HDMI-A-1] disconnected [ 1860.994060] [drm:drm_setup_crtcs], [ 1860.994062] [drm:drm_enable_connectors], connector 15 enabled? yes [ 1860.994063] [drm:drm_enable_connectors], connector 17 enabled? no [ 1860.994064] [drm:drm_enable_connectors], connector 20 enabled? no [ 1860.994066] [drm:drm_enable_connectors], connector 23 enabled? no [ 1860.994067] [drm:drm_target_preferred], looking for cmdline mode on connector 15 [ 1860.994070] [drm:drm_target_preferred], found mode 2880x1800 [ 1860.994071] [drm:drm_setup_crtcs], picking CRTCs for 8192x8192 config [ 1860.994073] [drm:drm_setup_crtcs], desired mode 2880x1800 set on crtc 11 [ 1860.994076] [drm:drm_crtc_helper_set_config], [ 1860.994077] [drm:drm_crtc_helper_set_config], [CRTC:11] [FB:27] #connectors=1 (x y) (0 0) [ 1860.994081] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch [ 1860.994083] [drm:drm_crtc_helper_set_config], [CONNECTOR:15:eDP-2] to [CRTC:11] [ 1860.994084] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [ 1860.994085] [drm:drm_mode_debug_printmodeline], Modeline 26:"2880x1800" 0 325842 2880 3088 3400 3920 1800 1801 1804 1847 0x0 0x6 [ 1860.994089] [drm:drm_crtc_helper_set_mode], [CRTC:11]
I've tracked this connector issue down to the nouveau_probe_i2c_addr call returning false as a result of the i2c_transfer call returning -ENXIO. I'm attempting at the moment to determine if the address is correct. I've run the nvidia blob and it detects the connectors and EDID correctly. I've turned up I2C debugging and will see if I can find out what address it's using.
I've discovered something new. After loading and unloading the nVidia blob driver the nouveau driver is able to retrieve EDID from the eDP-2 connector and sets it as connected. So it appears the nVidia blob is doing something to initialize the connectors that nouveau isn't. Even though nouveau is able to enable the connector, get the EDID, and configure the mode, it still doesn't work right. It appears the mode isn't entirely correct as the screen is still messed up. Here is the modeline that nouveau retrieves: Modeline 42:"2880x1800" 60 337750 2880 2928 2960 3040 1800 1803 1809 1852 0x48 0x9
I've reverse engineered the ACPI calls the nVidia blob makes during the process of loading and unloading. None of them are helpful in enabling the panel's I2C. I've even gone so far as to reproduce the calls and run them via a script outside of the nVidia blob, followed by a load of the nouveau driver. They have no effect. I'll continue pounding away at this.
Thanks to the guys on #nouveau, I've moved a little further. Loading nouveau with force_post=1 allows the driver to retrieve the EDID information. I'm trying to figure out what piece of code is being run during post that's doing the enabling, but I've had no luck so far. I've generated so much debugging fluff that I'm not sure what's relevant to upload at this point. Ask and ye shall receive.
I've gotten the connectors working and it pulls the correct EDID from the monitor. I'll have a patch that will fix this _only_ for the MacBook Pro 10,1 as it's probably unsuitable for anything else. It doesn't seem to be loading the EDID correctly, though. When in efifb everything works fine. When nouveau loads and sets the 2880x1800 modeline, it looks as if the mode is incorrect. Setting different refresh rates does not effect the situation - the crtc fixup replaces it with the builtin preferred modeline. Disabling that code and forcing a different refresh corrupts the screen further, so I doubt that's a good idea.
Created attachment 64226 [details] [review] Patch to call nouveau_gpio_reset outside of vbios post. This patch calls nouveau_gpio_reset at the end of nouveau_run_vbios_init when the vbios post isn't run. I don't know if this is an appropriate place to put the call or not, or even if it will cause it to break on other devices, but it works on the Retina.
Created attachment 65367 [details] [review] Patch to force bpc to 6 There's work going on with the Intel card. It was discovered that when they forced BPC to 8 they were able to display to the Retina display properly. I added some debug into the section of code that determines the correct bpc and found that it was already choosing 8. I force it to 6 and all of a sudden it works. I've attached the patch that fixes that. Of course, like the other patch, the fix only applies to the MBP Retina. I don't yet know the proper way to override this on a per-device basis.
I confirm that kernel 3.6-rc1 with 2 last patch working.
I quite disappointed, I cleaned up my kernel install, removed old modules/kernel from my system, them rebuilt the patched kernel, then issue is back. Do run proprietary driver before can be the reason ? Ryan do you had same issue ?
No, the proprietary driver is not run first. Make sure you have both patches installed - the GPIO reset patch and the force BPC patch. Both of those issues causes what looks like screen corruption. Without the first the wrong modeline is used. Without the second the wrong color depth is used.
Back, I made a fresh install and everything is ok with kernel 3.5.1 with this 2 patch. Sorry for disturbing this thread :) I do not figure out what I did wrong, I double checked every step, but seems to be not enough. Than again for this patches :)
I was not totally wrong, there is a bug :) When you switch to intel and them switch back to nvidia with OS X, video output is broken again. To solve issue reboot in OS X, setup video to nvidia turn off from mac, then power on. Best regards
Based on how I'm reading it that makes sense...if you're running the Intel card without the Intel patches for the Retina it's not going to work. But that's not a problem with nouveau.
I didn't explain well :) 0. boot linux with nouveau patched kernel, work well 1. boot OS X switch to intel. 2. boot linux, work well with intel patched kernel 3. boot OS X switch to nvidia 4. boot linux with nouveau patched kernel(same kernel as 0.), you get garbage on screen :) I hope this is more precise. Best regards
I'm guessing the whole vbios isn't posting properly. Do that again, but this time boot with the following kernel commandline option: nouveau.force_post=1 This will force the NVIDIA vbios to post when the driver loads.
Yes, this solve this minor issue, I followed this step : 0. boot OS X switch to nvidia 1. boot linux, get garbage 2. boot linux with nouveau.force_post=1, no more garbage. :)
Fixes for both the GPIO and panel depth issues are in nouveau kernel git now. I'll be backporting them for kernel 3.6 too.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.