On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
On Mon, Feb 25, 2013 at 3:52 PM, Greg KH gregkh@linuxfoundation.org wrote:
Hi Ben,
My Macbook Pro Retina fails to resume properly on 3.8. I tracked this down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: move link training helpers into core as display methods)
Anything I can try to help solve this?
Note, I'm using the Intel driver as the main controller for this laptop, well, I think I am, my xorg log is attached.
No you are using the nvidia, the efi always boots nvidia enabled now.
Really? When did that change? I thought I wanted to be using the Intel chip to save battery life.
btw I just tested my drm-next tree on mine and it resumed the display fine, something oopsed a few seconds later that I haven't tracked down
git://git.freedesktop.org/~airlied/linux drm-next
I'll be sending it to Linus this evening or tomorrow morning, once I fix my tree.
Ok, I'll test again when it hits Linus's tree, and if that works, it would be good to try to work out what patch fixes it to get them into the 3.8-stable series so that others don't run into the same problem.
I've tested Linus's tree now (I'm guessing it has all of your changes in it), and it works!
I see a bunch of patches marked for the stable branch, so I'll try those out and see if they fix the problem. If not, I'll let you and Ben know.
I've applied the radeon patches tagged for -stable and tested that on 3.8.0, but that doesn't solve the resume problem. Any ideas of anything else I can do to test this? Doing a "backwards" git-bisect is a pain, but I guess I can do that to try to track down what patch fixed this, if that's the only idea people have...
Ok, after getting my brain warped by doing a reverse 'git bisect', I tracked it down to commit ac8cc241a81941932da44993242e68c62e115ec7 (drm/nv50/devinit: reverse the logic for running encoder init scripts) as the patch that solves the problem.
So, I tried applying that patch on 3.8.1-rc1, but ran into the efifb bug that Dave fixed already, which took me a while, so I've queued that up for 3.8.1. Then I determined that it really also needs commit f3ed1048715f2edc10c4dda6148b60e93f6282ed (drm/nouveau/bios: parse external transmitter type if off-chip) and commit 8e992c8d9eebc2bd3246252ee5c0422dbbbce7ae (drm/nouveau/bios: store a type/mask hash in parsed dcb data) in order to build properly.
With those three patches, plus the efifb fix, I can now properly boot, and suspend and resume my macbook on 3.8.1-rc1. Just like I can on Linus's tree.
So, Ben, Dave, any objection to me including these 3 nouveau patches in the 3.8.1-final release?
Thanks for taking the time to track down exactly what's needed here. I believe those three should be safe to apply.
Ben.
thanks,
greg k-h