iMac 10,1 with Ubuntu 16.04: black screen after suspend

iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]

Hi everyone,

I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
with the most recent HWE stack (kernel 4.8), the display stays black after
suspend. I can ssh into the machine, so wakeup is OK, but the display is
entirely black (backlight stays off).

Note: this appears to be entirely unrelated to the TDM stuff I posted about
earlier. Interestingly, when I enable TDM, even after suspend, the display works
while TDM is active. Once I disable TDM, it's back to black (unintentional song
reference there).

I've noted that in /sys/class/backlight, there are two different control
interfaces, apple_backlight and radeon_bl0. Before suspend, I can control the
screen brightness from system settings, even if only one of them is loaded, so
both brightness interfaces work.

What I've already tried without success:

- Blindly switching to the console and back.
- Calling DISPLAY=:0.0 xrandr --output eDP1 --auto via ssh.
- Restarting X via ssh.
- Blacklist apple_bl on the kernel cmdline (modprobe.blacklist=apple_bl).
- Disabling the radeon backlight on the kernel cmdline (radeon.backlight=0).
- Using radeontool to turn the backlight back on after suspend.
- Directly using the interface in /sys/class/backlight/ to turn it back on.

I'm starting to run out of ideas... any hints?

Regards, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

[cc += dri-devel, amd-gfx]

On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
> with the most recent HWE stack (kernel 4.8), the display stays black after
> suspend. I can ssh into the machine, so wakeup is OK, but the display is
> entirely black (backlight stays off).
> 
> Note: this appears to be entirely unrelated to the TDM stuff I posted about
> earlier. Interestingly, when I enable TDM, even after suspend, the display works
> while TDM is active. Once I disable TDM, it's back to black (unintentional song
> reference there).

Sounds like a radeon issue to me.

The LCD_PANEL_PWR and LCD_BKL_ON_MUX pins are coming from a mux.

In TDM mode, the pins are muxed to the SMC, so it can turn the panel on
and off.  If TDM is not in use, the pins are muxed to the ATI card.

The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins.  Those must be
enabled for the panel to light up.  Perhaps radeon needs to be extended
to do that.  One theory is that this is done via ACPI, but perhaps
only if a certain operating system is running.  Dump the ACPI tables
and search DSDT and SSDT* tables for methods relating to the ATI card
and/or backlight.  If you find checks for OSDW there (e.g. in _PS0,
i.e. on resume), it means the AML code is only executed on Darwin.
Conversely !OSDW means the code is only executed on Windows (Boot Camp).
Linux masquerades as Darwin, but this can be disabled with
acpi_osi=!Darwin on the command line.  It's worth trying if that changes
the behaviour.  If it does, then macOS likely sets those pins on resume
and we need to do the same in radeon.

HTH,

Lukas

> 
> I've noted that in /sys/class/backlight, there are two different control
> interfaces, apple_backlight and radeon_bl0. Before suspend, I can control the
> screen brightness from system settings, even if only one of them is loaded, so
> both brightness interfaces work.
> 
> What I've already tried without success:
> 
> - Blindly switching to the console and back.
> - Calling DISPLAY=:0.0 xrandr --output eDP1 --auto via ssh.
> - Restarting X via ssh.
> - Blacklist apple_bl on the kernel cmdline (modprobe.blacklist=apple_bl).
> - Disabling the radeon backlight on the kernel cmdline (radeon.backlight=0).
> - Using radeontool to turn the backlight back on after suspend.
> - Directly using the interface in /sys/class/backlight/ to turn it back on.
> 
> I'm starting to run out of ideas... any hints?
> 
> Regards, Florian
> -- 
> SENT FROM MY DEC VT50 TERMINAL
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1626 bytes --]

On 26.05.2017 23:03, Lukas Wunner wrote:
> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
>> with the most recent HWE stack (kernel 4.8), the display stays black after
>> suspend. I can ssh into the machine, so wakeup is OK, but the display is
>> entirely black (backlight stays off).
>>
> The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins.  Those must be
> enabled for the panel to light up.  Perhaps radeon needs to be extended
> to do that.  One theory is that this is done via ACPI, but perhaps
> only if a certain operating system is running.  Dump the ACPI tables
> and search DSDT and SSDT* tables for methods relating to the ATI card
> and/or backlight.  If you find checks for OSDW there (e.g. in _PS0,
> i.e. on resume), it means the AML code is only executed on Darwin.
I've already had a look at the ACPI tables; there seem to be no references to
the "official" backlight/display control functions (no _BL? or _DO? methods).

> Conversely !OSDW means the code is only executed on Windows (Boot Camp).
> Linux masquerades as Darwin, but this can be disabled with
> acpi_osi=!Darwin on the command line.  It's worth trying if that changes
> the behaviour.  If it does, then macOS likely sets those pins on resume
> and we need to do the same in radeon.
There are OSDW checks present, however, booting with acpi_osi=!Darwin doesn't
make a difference to the backlight behaviour.

I'd be grateful for other suggestions...

Best regards, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
> On 26.05.2017 23:03, Lukas Wunner wrote:
> > On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
> >> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
> >> with the most recent HWE stack (kernel 4.8), the display stays black after
> >> suspend. I can ssh into the machine, so wakeup is OK, but the display is
> >> entirely black (backlight stays off).
> >>
> > The ATI card has MXM_PNL_PWR_EN and MXM_PNL_BL_EN pins.  Those must be
> > enabled for the panel to light up.  Perhaps radeon needs to be extended
> > to do that.  One theory is that this is done via ACPI, but perhaps
> > only if a certain operating system is running.  Dump the ACPI tables
> > and search DSDT and SSDT* tables for methods relating to the ATI card
> > and/or backlight.  If you find checks for OSDW there (e.g. in _PS0,
> > i.e. on resume), it means the AML code is only executed on Darwin.
> I've already had a look at the ACPI tables; there seem to be no references to
> the "official" backlight/display control functions (no _BL? or _DO? methods).
> 
> > Conversely !OSDW means the code is only executed on Windows (Boot Camp).
> > Linux masquerades as Darwin, but this can be disabled with
> > acpi_osi=!Darwin on the command line.  It's worth trying if that changes
> > the behaviour.  If it does, then macOS likely sets those pins on resume
> > and we need to do the same in radeon.
> There are OSDW checks present, however, booting with acpi_osi=!Darwin doesn't
> make a difference to the backlight behaviour.

So, just to confirm, if you never plug in an external DP source and the iMac
comes out of sleep, the display stays black?

If you log in via ssh and look at dmesg, was radeon able to train the DP
link again?  No error messages, nothing?

Is the panel off or is it on but merely with 0% brightness?

There's a block of pins on the GPU for "system management" which contains
a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
the panel when it's switched to the radeon card:
pin 23	   PNL_PWR_EN
pin 25	   PNL_BL_EN
pin 27	   PNL_BL_PWM

Basically you'd need to know what these are set to before and after sleep.
I don't know how to access them, presumably via a BAR register.  A quick
look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
yield anything useful, but someone at AMD may be able to find this out.

Maybe these registers are supposed to be modified by the OS when coming
out of sleep, or they're modified by video BIOS but the OS has to trigger
this somehow.

HTH,

Lukas

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 3183 bytes --]

On 30.05.2017 12:54, Lukas Wunner wrote:
> On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
>> On 26.05.2017 23:03, Lukas Wunner wrote:
>>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>>>> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
>>>> with the most recent HWE stack (kernel 4.8), the display stays black after
>>>> suspend. I can ssh into the machine, so wakeup is OK, but the display is
>>>> entirely black (backlight stays off).
> 
> So, just to confirm, if you never plug in an external DP source and the iMac
> comes out of sleep, the display stays black?

Correct, verified this just now.

> If you log in via ssh and look at dmesg, was radeon able to train the DP
> link again?  No error messages, nothing?

Here are the relevant dmesg lines after wakeup:

[  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[  157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000).
[  157.626094] radeon 0000:02:00.0: WB enabled
[  157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr
0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00
[  157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr
0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c
[  157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr
0x000000000005c598 and cpu addr 0xffffbc3081c1c598
[  157.672183] [drm] ring test on 0 succeeded in 1 usecs
[  157.672187] [drm] ring test on 3 succeeded in 2 usecs
[  157.847098] [drm] ring test on 5 succeeded in 1 usecs
[  157.847102] [drm] UVD initialized successfully.
[  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
[  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
[  158.524061] [drm] ib test on ring 5 succeeded

And this is logged in Xorg.0.log after wakeup:

[   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
[   229.956] (II) RADEON(0): VRAM usage limit set to 219596K

xrandr still shows the eDP output as connected and active with 2560x1440 resolution.

> Is the panel off or is it on but merely with 0% brightness?

The backlight is definitely off. I've tried to shine a torch onto the panel and
see if any content is visible, but it looks like the panel itself is off, too.

> There's a block of pins on the GPU for "system management" which contains
> a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
> the panel when it's switched to the radeon card:
> pin 23	   PNL_PWR_EN
> pin 25	   PNL_BL_EN
> pin 27	   PNL_BL_PWM
> 
> Basically you'd need to know what these are set to before and after sleep.
> I don't know how to access them, presumably via a BAR register.  A quick
> look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
> yield anything useful, but someone at AMD may be able to find this out.

Can I perhaps use radeontool for this? I.e. dump registers before and after
sleep and see if there's a difference? Or is radeontool too old to know about
the correct registers?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
> On 30.05.2017 12:54, Lukas Wunner wrote:
> > On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
> >> On 26.05.2017 23:03, Lukas Wunner wrote:
> >>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
> >>>> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
> >>>> with the most recent HWE stack (kernel 4.8), the display stays black after
> >>>> suspend. I can ssh into the machine, so wakeup is OK, but the display is
> >>>> entirely black (backlight stays off).
> > 
> > So, just to confirm, if you never plug in an external DP source and the iMac
> > comes out of sleep, the display stays black?
> 
> Correct, verified this just now.
> 
> > If you log in via ssh and look at dmesg, was radeon able to train the DP
> > link again?  No error messages, nothing?
> 
> Here are the relevant dmesg lines after wakeup:
> 
> [  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [  157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000).
> [  157.626094] radeon 0000:02:00.0: WB enabled
> [  157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr
> 0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00
> [  157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr
> 0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c
> [  157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr
> 0x000000000005c598 and cpu addr 0xffffbc3081c1c598
> [  157.672183] [drm] ring test on 0 succeeded in 1 usecs
> [  157.672187] [drm] ring test on 3 succeeded in 2 usecs
> [  157.847098] [drm] ring test on 5 succeeded in 1 usecs
> [  157.847102] [drm] UVD initialized successfully.
> [  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
> [  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
> [  158.524061] [drm] ib test on ring 5 succeeded

Hm, try booting with drm.debug=0xf to see if link training for the
eDP connector succeeds.  If the link cannot be trained, it would
explain that the screen stays black.  Should this indeed be the
case, one possible explanation would be that the panel is muxed
to the external port on resume and an appropriate command needs to
be sent to the SMC to switch the mux to the radeon card.  This could
be done in the ->resume_early hook of your APP000C platform driver.
The apple-gmux driver contains something similar to power the discrete
GPU down if it was off before suspend (because the BIOS always powers
it up on resume).

Another possible explanation would be that panel power needs to be
enabled by writing to the registers which control the pins mentioned
below.


> And this is logged in Xorg.0.log after wakeup:
> 
> [   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
> [   229.956] (II) RADEON(0): VRAM usage limit set to 219596K
> 
> xrandr still shows the eDP output as connected and active with 2560x1440 resolution.
> 
> > Is the panel off or is it on but merely with 0% brightness?
> 
> The backlight is definitely off. I've tried to shine a torch onto the panel and
> see if any content is visible, but it looks like the panel itself is off, too.
> 
> > There's a block of pins on the GPU for "system management" which contains
> > a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
> > the panel when it's switched to the radeon card:
> > pin 23	   PNL_PWR_EN
> > pin 25	   PNL_BL_EN
> > pin 27	   PNL_BL_PWM
> > 
> > Basically you'd need to know what these are set to before and after sleep.
> > I don't know how to access them, presumably via a BAR register.  A quick
> > look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
> > yield anything useful, but someone at AMD may be able to find this out.
> 
> Can I perhaps use radeontool for this? I.e. dump registers before and after
> sleep and see if there's a difference? Or is radeontool too old to know about
> the correct registers?

*shrug*  Unfortunately I'm not familiar at all with radeontool. :-(

Best regards,

Lukas

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
>> On 30.05.2017 12:54, Lukas Wunner wrote:
>> > On Tue, May 30, 2017 at 11:34:17AM +0200, Florian Echtler wrote:
>> >> On 26.05.2017 23:03, Lukas Wunner wrote:
>> >>> On Fri, May 26, 2017 at 02:13:29PM +0200, Florian Echtler wrote:
>> >>>> I'm running Ubuntu 16.04.2 on a 27" unibody iMac 10,1 from 2009. However, even
>> >>>> with the most recent HWE stack (kernel 4.8), the display stays black after
>> >>>> suspend. I can ssh into the machine, so wakeup is OK, but the display is
>> >>>> entirely black (backlight stays off).
>> >
>> > So, just to confirm, if you never plug in an external DP source and the iMac
>> > comes out of sleep, the display stays black?
>>
>> Correct, verified this just now.
>>
>> > If you log in via ssh and look at dmesg, was radeon able to train the DP
>> > link again?  No error messages, nothing?
>>
>> Here are the relevant dmesg lines after wakeup:
>>
>> [  157.622950] [drm] enabling PCIE gen 2 link speeds, disable with
>> radeon.pcie_gen2=0
>> [  157.626077] [drm] PCIE GART of 1024M enabled (table at 0x000000000014C000).
>> [  157.626094] radeon 0000:02:00.0: WB enabled
>> [  157.626097] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr
>> 0x0000000010000c00 and cpu addr 0xffffa1242dfd6c00
>> [  157.626098] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr
>> 0x0000000010000c0c and cpu addr 0xffffa1242dfd6c0c
>> [  157.626315] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr
>> 0x000000000005c598 and cpu addr 0xffffbc3081c1c598
>> [  157.672183] [drm] ring test on 0 succeeded in 1 usecs
>> [  157.672187] [drm] ring test on 3 succeeded in 2 usecs
>> [  157.847098] [drm] ring test on 5 succeeded in 1 usecs
>> [  157.847102] [drm] UVD initialized successfully.
>> [  157.847121] [drm] ib test on ring 0 succeeded in 0 usecs
>> [  157.847136] [drm] ib test on ring 3 succeeded in 0 usecs
>> [  158.524061] [drm] ib test on ring 5 succeeded
>
> Hm, try booting with drm.debug=0xf to see if link training for the
> eDP connector succeeds.  If the link cannot be trained, it would
> explain that the screen stays black.  Should this indeed be the
> case, one possible explanation would be that the panel is muxed
> to the external port on resume and an appropriate command needs to
> be sent to the SMC to switch the mux to the radeon card.  This could
> be done in the ->resume_early hook of your APP000C platform driver.
> The apple-gmux driver contains something similar to power the discrete
> GPU down if it was off before suspend (because the BIOS always powers
> it up on resume).
>
> Another possible explanation would be that panel power needs to be
> enabled by writing to the registers which control the pins mentioned
> below.
>
>
>> And this is logged in Xorg.0.log after wakeup:
>>
>> [   229.956] (II) RADEON(0): Allocate new frame buffer 320x200 stride 384
>> [   229.956] (II) RADEON(0): VRAM usage limit set to 219596K
>>
>> xrandr still shows the eDP output as connected and active with 2560x1440 resolution.
>>
>> > Is the panel off or is it on but merely with 0% brightness?
>>
>> The backlight is definitely off. I've tried to shine a torch onto the panel and
>> see if any content is visible, but it looks like the panel itself is off, too.
>>
>> > There's a block of pins on the GPU for "system management" which contains
>> > a bunch of GPIO, OEM and reserved pins.  Three of these are used to control
>> > the panel when it's switched to the radeon card:
>> > pin 23         PNL_PWR_EN
>> > pin 25         PNL_BL_EN
>> > pin 27         PNL_BL_PWM
>> >
>> > Basically you'd need to know what these are set to before and after sleep.
>> > I don't know how to access them, presumably via a BAR register.  A quick
>> > look at the RV730-specific registers in drivers/gpu/drm/radeon/*.h did not
>> > yield anything useful, but someone at AMD may be able to find this out.
>>
>> Can I perhaps use radeontool for this? I.e. dump registers before and after
>> sleep and see if there's a difference? Or is radeontool too old to know about
>> the correct registers?
>
> *shrug*  Unfortunately I'm not familiar at all with radeontool. :-(

You can use the radeonreg tool to dump the display registers:
https://cgit.freedesktop.org/~agd5f/radeontool/
radeonreg regs dce3
replace dce3 with whatever dce version your card has.

Alex

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1690 bytes --]

On 31.05.2017 14:57, Alex Deucher wrote:
> On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@wunner.de> wrote:
>> On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
>>
>> Hm, try booting with drm.debug=0xf to see if link training for the
>> eDP connector succeeds.  If the link cannot be trained, it would
>> explain that the screen stays black.  Should this indeed be the
>> case, one possible explanation would be that the panel is muxed
>> to the external port on resume and an appropriate command needs to
>> be sent to the SMC to switch the mux to the radeon card.  This could
>> be done in the ->resume_early hook of your APP000C platform driver.
>> The apple-gmux driver contains something similar to power the discrete
>> GPU down if it was off before suspend (because the BIOS always powers
>> it up on resume).

Here's the (substantial) dmesg output, with drm.debug=0xf:
http://floe.butterbrot.org/external/radeon/dmesg_after_suspend

I haven't been able to find any references to link training, though.

>> *shrug*  Unfortunately I'm not familiar at all with radeontool. :-(
> 
> You can use the radeonreg tool to dump the display registers:
> https://cgit.freedesktop.org/~agd5f/radeontool/
> radeonreg regs dce3
> replace dce3 with whatever dce version your card has.

AFAICT the RV730 indeed has dce3, so I created a register dump before and after
suspend:
http://floe.butterbrot.org/external/radeon/regs_before_suspend.txt
http://floe.butterbrot.org/external/radeon/regs_after_suspend.txt

The diff, however, is quite large, I have no idea which registers to look for.

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler <floe@butterbrot.org> wrote:
> On 31.05.2017 14:57, Alex Deucher wrote:
>> On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@wunner.de> wrote:
>>> On Wed, May 31, 2017 at 10:48:37AM +0200, Florian Echtler wrote:
>>>
>>> Hm, try booting with drm.debug=0xf to see if link training for the
>>> eDP connector succeeds.  If the link cannot be trained, it would
>>> explain that the screen stays black.  Should this indeed be the
>>> case, one possible explanation would be that the panel is muxed
>>> to the external port on resume and an appropriate command needs to
>>> be sent to the SMC to switch the mux to the radeon card.  This could
>>> be done in the ->resume_early hook of your APP000C platform driver.
>>> The apple-gmux driver contains something similar to power the discrete
>>> GPU down if it was off before suspend (because the BIOS always powers
>>> it up on resume).
>
> Here's the (substantial) dmesg output, with drm.debug=0xf:
> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
>
> I haven't been able to find any references to link training, though.

I need your dmesg from boot to confirm the display topology, but eDP
with r7xx asics was pretty rare.  I suspect your system just uses
LVDS; as such there is no link training involved.

Alex

>
>>> *shrug*  Unfortunately I'm not familiar at all with radeontool. :-(
>>
>> You can use the radeonreg tool to dump the display registers:
>> https://cgit.freedesktop.org/~agd5f/radeontool/
>> radeonreg regs dce3
>> replace dce3 with whatever dce version your card has.
>
> AFAICT the RV730 indeed has dce3, so I created a register dump before and after
> suspend:
> http://floe.butterbrot.org/external/radeon/regs_before_suspend.txt
> http://floe.butterbrot.org/external/radeon/regs_after_suspend.txt
>
> The diff, however, is quite large, I have no idea which registers to look for.
>
> Best, Florian
> --
> SENT FROM MY DEC VT50 TERMINAL
>

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 3198 bytes --]

On 01.06.2017 19:53, Alex Deucher wrote:
> On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler <floe@butterbrot.org> wrote:
>> On 31.05.2017 14:57, Alex Deucher wrote:
>>> On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@wunner.de> wrote:
>>
>> Here's the (substantial) dmesg output, with drm.debug=0xf:
>> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
>>
>> I haven't been able to find any references to link training, though.
> 
> I need your dmesg from boot to confirm the display topology, but eDP
> with r7xx asics was pretty rare.  I suspect your system just uses
> LVDS; as such there is no link training involved.

I've updated the trace with increased log_buf_len so nothing is truncated:

http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt

(trace now contains a full boot including suspend and wakeup)

However, what I'm seeing now does sound like the internal connection is indeed eDP:

[  166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0]
[  166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1]
[  166.816167] [drm:drm_crtc_helper_set_config]
[  166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54]
#connectors=1 (x y) (0 0)
[  166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
[  166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4)
[  166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode switch
[  166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[  166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to
[CRTC:34:crtc-0]
[  166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from
userspace
[  166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560
2608 2640 2720 1440 1443 1448 1481 0x0 0x9
[  166.816180] [drm:radeon_encoder_set_active_device] setting active device to
00000002 from 00000002 00000002 for encoder 3
[  166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0]
[  166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices
00000008, active_devices 00000000
[  166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, devices
00000010, active_devices 00000000
[  166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816237] [drm:radeon_compute_pll_avivo] 360000 - 360000, pll dividers -
fb: 80.0 ref: 2, post 3
[  166.824475] done.

... and a bit later:

[  166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0
pre-emphasis 0
[  166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Fri, Jun 2, 2017 at 3:35 AM, Florian Echtler <floe@butterbrot.org> wrote:
> On 01.06.2017 19:53, Alex Deucher wrote:
>> On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler <floe@butterbrot.org> wrote:
>>> On 31.05.2017 14:57, Alex Deucher wrote:
>>>> On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner <lukas@wunner.de> wrote:
>>>
>>> Here's the (substantial) dmesg output, with drm.debug=0xf:
>>> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
>>>
>>> I haven't been able to find any references to link training, though.
>>
>> I need your dmesg from boot to confirm the display topology, but eDP
>> with r7xx asics was pretty rare.  I suspect your system just uses
>> LVDS; as such there is no link training involved.
>
> I've updated the trace with increased log_buf_len so nothing is truncated:
>
> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt
>
> (trace now contains a full boot including suspend and wakeup)
>
> However, what I'm seeing now does sound like the internal connection is indeed eDP:
>
> [  166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0]
> [  166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1]
> [  166.816167] [drm:drm_crtc_helper_set_config]
> [  166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54]
> #connectors=1 (x y) (0 0)
> [  166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
> [  166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4)
> [  166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode switch
> [  166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch
> [  166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to
> [CRTC:34:crtc-0]
> [  166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from
> userspace
> [  166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560
> 2608 2640 2720 1440 1443 1448 1481 0x0 0x9
> [  166.816180] [drm:radeon_encoder_set_active_device] setting active device to
> 00000002 from 00000002 00000002 for encoder 3
> [  166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
> [  166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
> [  166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0]
> [  166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
> [  166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices
> 00000008, active_devices 00000000
> [  166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, devices
> 00000010, active_devices 00000000
> [  166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816237] [drm:radeon_compute_pll_avivo] 360000 - 360000, pll dividers -
> fb: 80.0 ref: 2, post 3
> [  166.824475] done.

Yes it is eDP:

[    3.197364] [drm] Radeon Display Connectors
[    3.197365] [drm] Connector 0:
[    3.197365] [drm]   DP-1
[    3.197366] [drm]   HPD1
[    3.197367] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
0x7e4c 0x7e4c
[    3.197367] [drm]   Encoders:
[    3.197368] [drm]     DFP1: INTERNAL_UNIPHY
[    3.197369] [drm] Connector 1:
[    3.197369] [drm]   eDP-1
[    3.197370] [drm]   HPD2
[    3.197371] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58
0x7e5c 0x7e5c
[    3.197371] [drm]   Encoders:
[    3.197372] [drm]     LCD1: INTERNAL_UNIPHY
[    3.197372] [drm] Connector 2:
[    3.197372] [drm]   VGA-1
[    3.197373] [drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18
0x7f1c 0x7f1c
[    3.197374] [drm]   Encoders:
[    3.197374] [drm]     CRT2: INTERNAL_KLDSCP_DAC2


>
> ... and a bit later:
>
> [  166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0
> pre-emphasis 0
> [  166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0
>

Yes, the link training appears to complete fine.  I guess it's
something to do with the proprietary mux or backlight controls.

Alex

> Best, Florian
> --
> SENT FROM MY DEC VT50 TERMINAL
>

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --]

On 02.06.2017 17:12, Alex Deucher wrote:
> On Fri, Jun 2, 2017 at 3:35 AM, Florian Echtler <floe@butterbrot.org> wrote:
>>
>> [  166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0
>> pre-emphasis 0
>> [  166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support
>> [  166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 pre-emphasis 0
> 
> Yes, the link training appears to complete fine.  I guess it's
> something to do with the proprietary mux or backlight controls.

OK, so back to square... well, not one, but definitely back to the registers
(SMC and GPU).

As mentioned, the diff for the GPU registers before/after suspend is huge,
there's 117 register values that have changed. I assume that most of them are
actually internal frame pointers, but which ones? I tried to find some of that
information in drivers/gpu/drm/radeon/, but quickly got lost :-/

Regarding the SMC, there's actually only one key that consistently seems to have
a different value whether the display is on or off:

--- blank	2017-05-05 08:40:53.694565045 +0200
+++ non_blank	2017-05-05 08:40:53.702565066 +0200
@@ -143,7 +143,7 @@
   MSWR  [ui8 ]  0 (bytes 00)
   MVBO  [hex_]  (bytes ff ff)
   MVDC  [bin_]  (bytes 00)
-  MVDS  [bin_]  (bytes 08)
+  MVDS  [bin_]  (bytes 0a)
   MVE1  [si8 ]  (bytes 0d)
   MVE5  [si8 ]  (bytes 0b)
   MVHR  [flag]  (bytes 01)

However, even with my modified SmcDumpKeys.c which I can use to enable TDM, I
cannot write to that key. Since other MV__ keys control the display, too, it
would make sense that that is related to the display state, but it seems to be a
read-only key :-/

Running out of ideas again... any suggestions?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
> Regarding the SMC, there's actually only one key that consistently seems to have
> a different value whether the display is on or off:
> 
> --- blank	2017-05-05 08:40:53.694565045 +0200
> +++ non_blank	2017-05-05 08:40:53.702565066 +0200
> @@ -143,7 +143,7 @@
>    MSWR  [ui8 ]  0 (bytes 00)
>    MVBO  [hex_]  (bytes ff ff)
>    MVDC  [bin_]  (bytes 00)
> -  MVDS  [bin_]  (bytes 08)
> +  MVDS  [bin_]  (bytes 0a)
>    MVE1  [si8 ]  (bytes 0d)
>    MVE5  [si8 ]  (bytes 0b)
>    MVHR  [flag]  (bytes 01)
> 
> However, even with my modified SmcDumpKeys.c which I can use to enable TDM, I
> cannot write to that key. Since other MV__ keys control the display, too, it
> would make sense that that is related to the display state, but it seems to be a
> read-only key :-/
> 
> Running out of ideas again... any suggestions?

Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
landed in Linus' tree last week and is included in 4.13-rc1.  It is
supposed to fix black screen issues with the iMac10,1 that you're also
using, though in Mario's case they seem to occur upon boot, rather than
on suspend, still might be worth a try:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=564d8a2cf3abf16575af48bdc3e86e92ee8a617d

Thanks,

Lukas

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1233 bytes --]

Hello Lukas,

On 17.07.2017 11:02, Lukas Wunner wrote:
> On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
> 
> Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
> landed in Linus' tree last week and is included in 4.13-rc1.  It is
> supposed to fix black screen issues with the iMac10,1 that you're also
> using, though in Mario's case they seem to occur upon boot, rather than
> on suspend, still might be worth a try:

thanks for the hint. I've applied this patch to the v4.12 tree I'm currently
running, and it didn't seem to make any difference (i.e. display stays black
after suspend).

Without the patch, when I plug in an external display (via MiniDP-to-DVI), then
the internal panel stays black when booting, only the external display works.

Actually, the patch then makes things slightly worse in my case: with the patch
applied, not even the external sink works anymore. When I log in remotely and
run "DISPLAY=:0.0 xrandr", both DP connections are shown as active, but neither
does actually show an image.

I'd be grateful about a bit of background information here, I'd really like to
help fix this.

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Mario Kleiner]

[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]

On 07/24/2017 03:45 PM, Florian Echtler wrote:
> Hello Lukas,
> 
> On 17.07.2017 11:02, Lukas Wunner wrote:
>> On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
>>
>> Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
>> landed in Linus' tree last week and is included in 4.13-rc1.  It is
>> supposed to fix black screen issues with the iMac10,1 that you're also
>> using, though in Mario's case they seem to occur upon boot, rather than
>> on suspend, still might be worth a try:

Hi,

> 
> thanks for the hint. I've applied this patch to the v4.12 tree I'm currently
> running, and it didn't seem to make any difference (i.e. display stays black
> after suspend).
> 

That's the same here with my patch applied. After a suspend -> resume, 
the internal panel stays black, the patch doesn't help for that. 
Somethig i didn't notice btw., apparently i never suspend->resumed it.

> Without the patch, when I plug in an external display (via MiniDP-to-DVI), then
> the internal panel stays black when booting, only the external display works.

That's different for me:

The internal panel always works during boot, until the radeon kms driver 
loads and modesetting gets initialized, then the panel goes dark.

With my patch, the panel then lights up properly immediately, and 
external output to dvi/hdmi works as well if i connect anything. 
External Displayport panel doesn't work though - stays dark, although it 
is reported connected+active in xrandr.

However this is something i got when connecting the external Displayport 
panel:

Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344792] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344819] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Jul  7 04:18:07 kleinerm-MaxtorLinux kernel: [ 1559.770783] 
drm_dp_i2c_do_msg: 20 callbacks suppressed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143406] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143439] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356173] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356205] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed

So link training failed, because drm_dp_dpcd_read_link_status() already 
failed to read from the dp aux channel.

Without my patch the internal panel stays dark, but plugging in an 
external hdmi/dvi display gets both internal+external to light up.

Another way i was able to force the internal panel to stay on without my 
patch and without an external display connected is to use the kernel 
cmdline option "video=DP-1:2560x1440D" to force the external output on, 
although nothing is connected.

The patch is just the result of trial and error, following hunches, 
based on reading through the radeon modesetting code. Unfortunately no 
real insight into why stuff goes wrong. I also remember disassembling 
bits of the dumped atombios a year ago and not finding anything that 
looked suspicious to me, but then i'm not experienced at that.

> 
> Actually, the patch then makes things slightly worse in my case: with the patch
> applied, not even the external sink works anymore. When I log in remotely and
> run "DISPLAY=:0.0 xrandr", both DP connections are shown as active, but neither
> does actually show an image.
> 

So the same machine model behaves differently with the same patch, and 
worse in your case than without it? Maybe different hardware or firmware?

Apples website lists two models of late 2009 iMac10,1 and Radeon HD 
4670, to which the patch should apply. One 21.5 inch model without TDM 
and a 27 inch model with TDM. Mine is the 27 inch one. I assume yours as 
well due to TDM? Attached is the output of dmidecode on mine, not sure 
what to look for for differences?

Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.

> I'd be grateful about a bit of background information here, I'd really like to
> help fix this.

Lukas idea that some hardware mux gets switched into the wrong position 
on models with TDM sounds pretty appealing to me, but how to test?

-mario

> 
> Best, Florian
> 

[-- Attachment #2: iMac_2009_dmidecode.txt --]
[-- Type: text/plain, Size: 17114 bytes --]

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.
49 structures occupying 2670 bytes.
Table at 0xBFEC3000.

Handle 0x0000, DMI type 4, 35 bytes
Processor Information
	Socket Designation: U2E1
	Type: Central Processor
	Family: Other
	Manufacturer: Intel(R) Corporation
	ID: 7A 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 23, Stepping 10
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM)2 Duo CPU     E7600  @ 3.06GHz
	Voltage: 1.6 V
	External Clock: 266 MHz
	Max Speed: 3060 MHz
	Current Speed: 3060 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x0002
	L2 Cache Handle: Not Provided
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Unknown
	Part Number: Not Specified

Handle 0x0001, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0002, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0003, DMI type 4, 35 bytes
Processor Information
	Socket Designation: U2E1
	Type: Central Processor
	Family: Other
	Manufacturer: Intel(R) Corporation
	ID: 7A 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 23, Stepping 10
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM)2 Duo CPU     E7600  @ 3.06GHz
	Voltage: 1.6 V
	External Clock: 266 MHz
	Max Speed: 3060 MHz
	Current Speed: 3060 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x0005
	L2 Cache Handle: Not Provided
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Unknown
	Part Number: Not Specified

Handle 0x0004, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0006, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0007, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Array Handle: 0x0006
	Partition Width: 4

Handle 0x0008, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0006
	Error Information Handle: No Error
	Total Width: Unknown
	Data Width: 65506 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1067 MHz
	Manufacturer: 0x0000
	Serial Number: 0x00000000
	Asset Tag: Unknown
	Part Number: 0x000000000000000000000000000000000000

Handle 0x0009, DMI type 130, 186 bytes
OEM-specific Type
	Header and Data:
		82 BA 09 00 08 00 00 00 B0 00 92 10 0B 03 02 11
		00 09 03 52 01 08 0F 00 1E 00 69 78 69 3C 69 11
		2C 95 70 03 3C 3C 01 2C 82 05 80 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 0F 11 05 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 98 D0 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00

Handle 0x000A, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0006
	Error Information Handle: No Error
	Total Width: Unknown
	Data Width: 65506 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK 1
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1067 MHz
	Manufacturer: 0x0000
	Serial Number: 0x00000000
	Asset Tag: Unknown
	Part Number: 0x000000000000000000000000000000000000

Handle 0x000B, DMI type 130, 186 bytes
OEM-specific Type
	Header and Data:
		82 BA 0B 00 0A 00 00 00 B0 00 92 10 0B 03 02 11
		00 09 03 52 01 08 0F 00 1E 00 69 78 69 3C 69 11
		2C 95 70 03 3C 3C 01 2C 82 05 80 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 0F 11 05 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 98 D0 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00

Handle 0x000C, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0006
	Error Information Handle: No Error
	Total Width: Unknown
	Data Width: 65508 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM1
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1067 MHz
	Manufacturer: 0x80CE
	Serial Number: 0x959DEB10
	Asset Tag: Unknown
	Part Number: 0x4D34373142353637334548312D4346382020

Handle 0x000D, DMI type 130, 186 bytes
OEM-specific Type
	Header and Data:
		82 BA 0D 00 0C 00 00 00 B0 00 92 10 0B 03 02 11
		00 09 03 52 01 08 0F 00 1C 00 69 78 69 3C 69 11
		2C 95 70 03 3C 3C 01 2C 83 01 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 0F 11 45 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
		CE 02 09 45 95 9D EB 10 5D 2E 4D 34 37 31 42 35
		36 37 33 45 48 31 2D 43 46 38 20 20 00 00 80 CE
		00 00 00 55 47 42 31 38 30 36 01 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 06

Handle 0x000E, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0006
	Error Information Handle: No Error
	Total Width: Unknown
	Data Width: 65508 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM1
	Bank Locator: BANK 1
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1067 MHz
	Manufacturer: 0x80CE
	Serial Number: 0x959DEAA9
	Asset Tag: Unknown
	Part Number: 0x4D34373142353637334548312D4346382020

Handle 0x000F, DMI type 130, 186 bytes
OEM-specific Type
	Header and Data:
		82 BA 0F 00 0E 00 00 00 B0 00 92 10 0B 03 02 11
		00 09 03 52 01 08 0F 00 1C 00 69 78 69 3C 69 11
		2C 95 70 03 3C 3C 01 2C 83 01 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 0F 11 45 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
		CE 02 09 45 95 9D EA A9 5D 2E 4D 34 37 31 42 35
		36 37 33 45 48 31 2D 43 46 38 20 20 00 00 80 CE
		00 00 00 55 47 42 31 38 30 36 01 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 07

Handle 0x0010, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x0008
	Memory Array Mapped Address Handle: 0x0007
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0011, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x000A
	Memory Array Mapped Address Handle: 0x0007
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 1

Handle 0x0012, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x000C
	Memory Array Mapped Address Handle: 0x0007
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0013, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 4 GB
	Physical Device Handle: 0x000E
	Memory Array Mapped Address Handle: 0x0007
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 1

Handle 0x0014, DMI type 0, 24 bytes
BIOS Information
	Vendor: Apple Inc.
	Version:    IM101.88Z.00CC.B00.0909031926
	Release Date: 09/03/09
	ROM Size: 4096 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		ACPI is supported
		IEEE 1394 boot is supported
		Smart battery is supported
		Function key-initiated network boot is supported
	BIOS Revision: 0.1

Handle 0x0015, DMI type 1, 27 bytes
System Information
	Manufacturer: Apple Inc.
	Product Name: iMac10,1
	Version: 1.0
	Serial Number: VM950DK95PM
	UUID: 142D0E89-CDCA-D145-AE66-BC80E8BFEB0F
	Wake-up Type: Power Switch
	SKU Number: System SKU#
	Family: Mac

Handle 0x0016, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: Apple Inc.
	Product Name: Mac-F2268DC8
	Version: Not Specified
	Serial Number: Base Board Serial#
	Asset Tag: Base Board Asset Tag
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Part Component
	Chassis Handle: 0x0017
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0017, DMI type 3, 21 bytes
Chassis Information
	Manufacturer: Apple Inc.
	Type: All In One
	Lock: Not Present
	Version: Mac-F2268DC8
	Serial Number: VM950DK95PM
	Asset Tag: Asset Tag#
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Other
	Security Status: Other
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: Unspecified
	Contained Elements: 0

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: Other
	External Reference Designator: Mini DisplayPort
	External Connector Type: None
	Port Type: Other

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: Other
	External Reference Designator: FireWire 800
	External Connector Type: None
	Port Type: Other

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: Ethernet
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: USB0
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x001C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: USB1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x001D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: USB2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x001E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: USB3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x001F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: Audio Line In
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0020, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: Audio Line Out
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0021, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: SATA Port A
	Internal Connector Type: On Board IDE
	External Reference Designator: None
	External Connector Type: None
	Port Type: Other

Handle 0x0022, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: SATA Port B
	Internal Connector Type: On Board IDE
	External Reference Designator: None
	External Connector Type: None
	Port Type: Other

Handle 0x0023, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: None
	Internal Connector Type: None
	External Reference Designator: Airport Mini PCI Express
	External Connector Type: Other
	Port Type: Other

Handle 0x0024, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: Speaker
	Internal Connector Type: Other
	External Reference Designator: None
	External Connector Type: None
	Port Type: Other

Handle 0x0025, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: FHB
	Internal Connector Type: Other
	External Reference Designator: None
	External Connector Type: None
	Port Type: Other

Handle 0x0026, DMI type 9, 13 bytes
System Slot Information
	Designation: AirPort
	Type: x1 PCI Express
	Current Usage: Available
	Length: Short
	ID: 3
	Characteristics:
		3.3 V is provided
		Hot-plug devices are supported
		SMBus signal is supported

Handle 0x0027, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Enabled
	Description: nVidia Video Adapter

Handle 0x0028, DMI type 10, 6 bytes
On Board Device Information
	Type: Sound
	Status: Enabled
	Description: Azalia Audio Codec

Handle 0x0029, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Yukon Ultra Ethernet Controller

Handle 0x002A, DMI type 10, 6 bytes
On Board Device Information
	Type: Other
	Status: Enabled
	Description: SATA

Handle 0x012B, DMI type 12, 5 bytes
System Configuration Options

Handle 0x012C, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 1
		<BAD INDEX>
	Currently Installed Language: Not Specified

Handle 0x012D, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x012E, DMI type 131, 6 bytes
OEM-specific Type
	Header and Data:
		83 06 2E 01 01 03

Handle 0x012F, DMI type 128, 88 bytes
OEM-specific Type
	Header and Data:
		80 58 2F 01 03 00 00 00 03 14 00 C0 FF 7F 00 C0
		01 02 03 00 00 00 00 00 00 00 C0 FF FF FF C3 FF
		00 40 CB FF FF BF FF FF 00 00 C8 FF FF 3F CA FF
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00

Handle 0xFFFD, DMI type 127, 4 bytes
End Of Table


[-- Attachment #3: iMac_2009_dmesg_snippet.txt --]
[-- Type: text/plain, Size: 6495 bytes --]

Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] efi: EFI v1.10 by Apple
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] efi:  ACPI=0xbfeee000  ACPI 2.0=0xbfeee014  SMBIOS=0xbfec4000
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] SMBIOS 2.4 present.
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] DMI: Apple Inc. iMac10,1/Mac-F2268DC8, BIOS    IM101.88Z.00CC.B00.0909031926 09/03/09
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] tsc: Fast TSC calibration using PIT
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] e820: last_pfn = 0x240000 max_arch_pfn = 0x400000000
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] MTRR default type: write-back
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] MTRR fixed ranges enabled:
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   00000-9FFFF write-back
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   A0000-FFFFF uncachable
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] MTRR variable ranges enabled:
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   0 base 0C0000000 mask FC0000000 uncachable
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   1 base 0BFF00000 mask FFFF00000 uncachable
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   2 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   3 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   4 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   5 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   6 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000]   7 disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] e820: last_pfn = 0xbfef9 max_arch_pfn = 0x400000000
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] Scanning 1 areas for low memory corruption
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] Base memory trampoline at [ffff9bc040099000] 99000 size 24576
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x7119e000, 0x7119efff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x7119f000, 0x7119ffff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a0000, 0x711a0fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a1000, 0x711a1fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a2000, 0x711a2fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a3000, 0x711a3fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a4000, 0x711a4fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a5000, 0x711a5fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a6000, 0x711a6fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a7000, 0x711a7fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a8000, 0x711a8fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] BRK [0x711a9000, 0x711a9fff] PGTABLE
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] Secure boot could not be determined
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] RAMDISK: [mem 0x0da04000-0x22cf9fff]
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: Early table checksum verification disabled
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: RSDP 0x00000000BFEEE014 000024 (v02 APPLE )
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: XSDT 0x00000000BFEEE1C0 00007C (v01 APPLE  Apple00  000000CC      01000013)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: FACP 0x00000000BFEEC000 0000F4 (v04 APPLE  Apple00  000000CC Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: DSDT 0x00000000BFEDF000 005EB9 (v01 APPLE  iMac     00100001 INTL 20061109)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: FACS 0x00000000BFECD000 000040
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: FACS 0x00000000BFECD000 000040
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: HPET 0x00000000BFEEB000 000038 (v01 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: APIC 0x00000000BFEEA000 000068 (v01 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: APIC 0x00000000BFEE9000 000068 (v02 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: MCFG 0x00000000BFEE8000 00003C (v01 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: ASF! 0x00000000BFEE7000 0000A5 (v32 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: SBST 0x00000000BFEE6000 000030 (v01 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: ECDT 0x00000000BFEE5000 000053 (v01 APPLE  Apple00  00000001 Loki 0000005F)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: SSDT 0x00000000BFECA000 0002B7 (v01 APPLE  SataAhci 00001000 INTL 20061109)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: SSDT 0x00000000BFEC9000 0000B1 (v01 APPLE  SmcDppt  00001000 INTL 20061109)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: SSDT 0x00000000BFEC5000 0004DC (v01 APPLE  CpuPm    00003000 INTL 20061109)
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: If "acpi_apic_instance=2" works better, notify linux-acpi@vger.kernel.org
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: DMI detected to setup _OSI("Darwin"): Apple hardware
Jul  7 03:52:49 kleinerm-MaxtorLinux kernel: [    0.000000] ACPI: Local APIC address 0xfee00000

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 3295 bytes --]

On 25.07.2017 07:14, Mario Kleiner wrote:
> On 07/24/2017 03:45 PM, Florian Echtler wrote:
> 
> That's the same here with my patch applied. After a suspend -> resume, the
> internal panel stays black, the patch doesn't help for that. Somethig i didn't
> notice btw., apparently i never suspend->resumed it.

OK - I'm guessing if the panel/connector mess gets properly sorted out in
general, then it will probably also start working after suspend/resume...

> The internal panel always works during boot, until the radeon kms driver loads
> and modesetting gets initialized, then the panel goes dark.

Weirdly enough, this is now the behaviour I'm getting, too, no matter if I use
the patched driver or the original one. So there's definitely some bit of
persistent state somewhere that got flipped during experimentation, probably
inside that stupid SMC.

> Without my patch the internal panel stays dark, but plugging in an external
> hdmi/dvi display gets both internal+external to light up.
> 
> Another way i was able to force the internal panel to stay on without my patch
> and without an external display connected is to use the kernel cmdline option
> "video=DP-1:2560x1440D" to force the external output on, although nothing is
> connected.

None of the video options, either with "DP" or "eDP", made a difference in my
case. The one scenario where I suddenly got the internal panel to turn on was
when I plugged in a DP _source_ (my laptop). Also caused the same DP link train
error messages to appear in dmesg.

> So the same machine model behaves differently with the same patch, and worse in
> your case than without it? Maybe different hardware or firmware?
> 
> Apples website lists two models of late 2009 iMac10,1 and Radeon HD 4670, to
> which the patch should apply. One 21.5 inch model without TDM and a 27 inch
> model with TDM. Mine is the 27 inch one. I assume yours as well due to TDM?
> Attached is the output of dmidecode on mine, not sure what to look for for
> differences?

Yes, also 27 inch. I've compared the dmidecode output, only notable differences
are data from RAM modules, so it's the same machine and same FW versions.

> Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.

Nearly everything identical, except my dmesg doesn't show the following lines:

-[    0.000000] efi: EFI v1.10 by Apple
-[    0.000000] efi:  ACPI=0xbfeee000  ACPI 2.0=0xbfeee014  SMBIOS=0xbfec4000

I'm booting Linux via rEFIt, so I would have assumed that it's a "regular" EFI
boot, but apparently not. What's your boot configuration?

> Lukas idea that some hardware mux gets switched into the wrong position on
> models with TDM sounds pretty appealing to me, but how to test?

I'm using TDM regularly; interestingly enough, this works completely reliably,
even if the panel was dark before. My code is at
https://github.com/floe/smc_util if you want to give it a try, but apparently
there's more to it than just the two keys (MVMR/MVHR) which I'm currently using.

Maybe you can run smc_dump_linux.sh on your machine (should be safe, only reads
keys) and see if there's some difference between keys depending on what state
the panel is in?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Lukas Wunner]

On Tue, Jul 25, 2017 at 07:14:23AM +0200, Mario Kleiner wrote:
> On 07/24/2017 03:45 PM, Florian Echtler wrote:
> > thanks for the hint. I've applied this patch to the v4.12 tree I'm
> > currently running, and it didn't seem to make any difference (i.e.
> > display stays black after suspend).
> 
> That's the same here with my patch applied. After a suspend -> resume, the
> internal panel stays black, the patch doesn't help for that. Somethig i
> didn't notice btw., apparently i never suspend->resumed it.
[...]
> Lukas idea that some hardware mux gets switched into the wrong position on
> models with TDM sounds pretty appealing to me, but how to test?

If all else fails, with a multimeter / oscilloscope. :-)  The board
schematics are available by googling for the right terms, such as
the drawing number "051-7863" and internal codename "K23".

Of interest is the eDP connector on the mainboard, page 90.  Notice
there are two power rails going into it, 3.3V (pin 31) and 12V (pins
27 - 30).  Florian obtained dmesg output of the machine coming out
of suspend by ssh'ing into it and it showed that the eDP link could
be trained properly upon system resume.  Still the panel stayed black.

My guess is that the panel's DisplayPort transceiver is powered via the
3.3V rail.  This rail is powered permanently when the system is in S0,
it cannot be switched off at runtime.  So, the Radeon card can talk to
the DisplayPort transceiver (which has power) but the 12V rail, which
presumably powers the LED backlight, is off.  You could test this theory
by attaching a multimeter after coming out of suspend:  You should see
a voltage difference of 3.3V between pins 31 and 32 (ground) and 0V
between pins 27 - 30 and 32.

The logic for the 12V rail is somewhat complicated, first there's
pin 21 ("VIDEO_ON"), this seems to come *from* the panel and presumably
signals that the link is trained. This should go high after resume.
If it does not then maybe a write to a custom DPCD register is necessary
to make it go high.  If this pin stays low then the 12V rail is not
powered.

Next there's a 74LVC157A mux (page 95 top-left).  Datasheet:
https://assets.nexperia.com/documents/data-sheet/74LVC157A.pdf
The mux can switch four wires, but Apple only needed three.
I guess all outputs (pins 7, 9, 12) must be high for the backlight
to go on.  The mux is under the control of the SMC and is presumably
switched by issuing appropriate commands to the SMC.  It's unclear
to me if the SMC has switched it to the Radeon or to the TDM source
after resume.

Assuming that the mux is switched to the Radeon card, follow input
pins 5, 10 and 14 (MXM_PNL_BL_PWM, MXM_PNL_BL_EN, MXM_PNL_PWR_EN).
They are coming from a "system management" block on the Radeon card
(pins 25, 27, 23, page 85).  Apparently these are GPIO pins for
OEM use and I guess they can be controlled by writing to the PCI BAR
of the Radeon card, but I've no idea at what address their registers
might be located.  I'll try to look at the macOS Radeon drivers with
a disassembler but this is like looking for a needle in a haystack.


> However this is something i got when connecting the external Displayport
> panel:
> 
> Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344792]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344819]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> Jul  7 04:18:07 kleinerm-MaxtorLinux kernel: [ 1559.770783]
> drm_dp_i2c_do_msg: 20 callbacks suppressed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143406]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143439]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356173]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356205]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> 
> So link training failed, because drm_dp_dpcd_read_link_status() already
> failed to read from the dp aux channel.

The AUX channel can be terminated in either of two modes under the control
of the SMC:  100k source termination or weak sink termination (page 94/95).
Failure to communicate over AUX may be explained by being in the incorrect
mode.

HTH,

Lukas