linux-kernel - Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Jul 2012 01:42:27 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Andreas Heider <andreas@...tr.de>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Arun Raghavan <arun.raghavan@...labora.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] apple-gmux: Restore switch registers on suspend/resume

On Wed, 2012-07-11 at 02:25 +0200, Andreas Heider wrote:
> Thanks for adding me, seeing the gmux driver progress is always great.
> 
> Regarding the original patch: This is probably only useful when the gmux 
> was switched in GRUB  and there's already a solution for the resume 
> problem in userspace 
> (http://ubuntuforums.org/showpost.php?p=10695119&postcount=261). Maybe 
> the same could be achieved a bit cleaner by simply using a few parts of 
> the switching patch?
> 
> Regarding the gmux switching patch: The patch itself should work and 
> hopefully doesn't break stuff that wasn't broken before. But without 
> additional fixes to i915/nouveau/etc. It won't be too useful either, 
> although it should fix the resume issue.
> 
> I'll look into how well it works with the current kernel on the weekend, 
> but I don't want to promise too much since time is still a bit of an 
> issue for me.

Using the patches from http://www.codon.org.uk/~mjg59/tmp/radeon_efi/
and http://www.codon.org.uk/~mjg59/tmp/gmux_switcheroo.diff I can almost
get this working on my MBP8,3, chainloading the kernel from grub1-efi.

I have to fix pci_map_rom() to return pdev->rom even if the resource has
the IORESOURCE_ROM_SHADOW flag (Matthew's patch still returned 0xC0000),
and I have to fix a bug in vga_switcheroo_enable() where it uses
client->id before actually setting it.

And then, if I hack head64.c to switch the mux over to IGD but leave the
Radeon powered up: ("outb(1, 0x728); outb(2, 0x710); outb(2, 0x740);")

... and on the occasions that it doesn't crash in fbcon_event_notify()
as shown at http://david.woodhou.se/vga-switcheroo-oops.txt

... it boots with a blank screen but I can log in over the network and I
*can* actually switch between displays. After switching to 'DIS' and
back to 'IGD' it does actually start working, and I seem to have both X
and fbcon working sanely on both. Although on an earlier boot I don't
think fbcon was working on the Radeon but X *did* work on both. So maybe
that's not 100% repeatable. Hard to say... I've only managed to get it
to boot twice; mostly it oopses as shown above.

If I don't hack it to switch the mux to IGD at boot time, I never manage
to get a sane picture out of the Intel device after switching to it.
It's late now, but I'll try to get a proper debug log of the working and
failing cases tomorrow. 

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)