* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend [not found] ` <30380cb3-0f26-8aea-2689-d4886879129c-H5Ww8s0cz1NjHglVgfe8mg@public.gmane.org> @ 2017-05-26 21:03 ` Lukas Wunner 2017-05-30 9:34 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Lukas Wunner @ 2017-05-26 21:03 UTC (permalink / raw) To: Florian Echtler Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW [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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-26 21:03 ` iMac 10,1 with Ubuntu 16.04: black screen after suspend Lukas Wunner @ 2017-05-30 9:34 ` Florian Echtler 2017-05-30 10:54 ` Lukas Wunner 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-05-30 9:34 UTC (permalink / raw) To: Lukas Wunner; +Cc: linux-acpi@vger.kernel.org, dri-devel, amd-gfx [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-30 9:34 ` Florian Echtler @ 2017-05-30 10:54 ` Lukas Wunner 2017-05-31 8:48 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Lukas Wunner @ 2017-05-30 10:54 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi@vger.kernel.org, dri-devel, amd-gfx 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-30 10:54 ` Lukas Wunner @ 2017-05-31 8:48 ` Florian Echtler 2017-05-31 9:21 ` Lukas Wunner 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-05-31 8:48 UTC (permalink / raw) To: Lukas Wunner; +Cc: linux-acpi@vger.kernel.org, dri-devel, amd-gfx [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-31 8:48 ` Florian Echtler @ 2017-05-31 9:21 ` Lukas Wunner 2017-05-31 12:57 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Lukas Wunner @ 2017-05-31 9:21 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi@vger.kernel.org, dri-devel, amd-gfx 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-31 9:21 ` Lukas Wunner @ 2017-05-31 12:57 ` Alex Deucher 2017-06-01 8:27 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2017-05-31 12:57 UTC (permalink / raw) To: Lukas Wunner Cc: Florian Echtler, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-05-31 12:57 ` Alex Deucher @ 2017-06-01 8:27 ` Florian Echtler 2017-06-01 17:53 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-06-01 8:27 UTC (permalink / raw) To: Alex Deucher, Lukas Wunner Cc: linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-06-01 8:27 ` Florian Echtler @ 2017-06-01 17:53 ` Alex Deucher 2017-06-02 7:35 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2017-06-01 17:53 UTC (permalink / raw) To: Florian Echtler Cc: Lukas Wunner, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-06-01 17:53 ` Alex Deucher @ 2017-06-02 7:35 ` Florian Echtler 2017-06-02 15:12 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-06-02 7:35 UTC (permalink / raw) To: Alex Deucher Cc: Lukas Wunner, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-06-02 7:35 ` Florian Echtler @ 2017-06-02 15:12 ` Alex Deucher 2017-06-02 16:47 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2017-06-02 15:12 UTC (permalink / raw) To: Florian Echtler Cc: Lukas Wunner, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-06-02 15:12 ` Alex Deucher @ 2017-06-02 16:47 ` Florian Echtler 2017-07-17 9:02 ` Lukas Wunner 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-06-02 16:47 UTC (permalink / raw) To: Alex Deucher Cc: Lukas Wunner, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-06-02 16:47 ` Florian Echtler @ 2017-07-17 9:02 ` Lukas Wunner 2017-07-24 13:45 ` Florian Echtler 0 siblings, 1 reply; 16+ messages in thread From: Lukas Wunner @ 2017-07-17 9:02 UTC (permalink / raw) To: Florian Echtler Cc: Alex Deucher, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers, Mario Kleiner 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-07-17 9:02 ` Lukas Wunner @ 2017-07-24 13:45 ` Florian Echtler 2017-07-25 5:14 ` Mario Kleiner 0 siblings, 1 reply; 16+ messages in thread From: Florian Echtler @ 2017-07-24 13:45 UTC (permalink / raw) To: Lukas Wunner Cc: Alex Deucher, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers, Mario Kleiner [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-07-24 13:45 ` Florian Echtler @ 2017-07-25 5:14 ` Mario Kleiner 2017-07-25 7:53 ` Florian Echtler 2017-07-25 10:37 ` Lukas Wunner 0 siblings, 2 replies; 16+ messages in thread From: Mario Kleiner @ 2017-07-25 5:14 UTC (permalink / raw) To: Florian Echtler, Lukas Wunner Cc: Alex Deucher, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers [-- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-07-25 5:14 ` Mario Kleiner @ 2017-07-25 7:53 ` Florian Echtler 2017-07-25 10:37 ` Lukas Wunner 1 sibling, 0 replies; 16+ messages in thread From: Florian Echtler @ 2017-07-25 7:53 UTC (permalink / raw) To: Mario Kleiner, Lukas Wunner Cc: Alex Deucher, linux-acpi@vger.kernel.org, amd-gfx list, Maling list - DRI developers [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend 2017-07-25 5:14 ` Mario Kleiner 2017-07-25 7:53 ` Florian Echtler @ 2017-07-25 10:37 ` Lukas Wunner 1 sibling, 0 replies; 16+ messages in thread From: Lukas Wunner @ 2017-07-25 10:37 UTC (permalink / raw) To: Mario Kleiner Cc: Florian Echtler, Alex Deucher, amd-gfx list, Maling list - DRI developers, linux-acpi 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-07-25 10:37 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <30380cb3-0f26-8aea-2689-d4886879129c@butterbrot.org>
[not found] ` <30380cb3-0f26-8aea-2689-d4886879129c-H5Ww8s0cz1NjHglVgfe8mg@public.gmane.org>
2017-05-26 21:03 ` iMac 10,1 with Ubuntu 16.04: black screen after suspend Lukas Wunner
2017-05-30 9:34 ` Florian Echtler
2017-05-30 10:54 ` Lukas Wunner
2017-05-31 8:48 ` Florian Echtler
2017-05-31 9:21 ` Lukas Wunner
2017-05-31 12:57 ` Alex Deucher
2017-06-01 8:27 ` Florian Echtler
2017-06-01 17:53 ` Alex Deucher
2017-06-02 7:35 ` Florian Echtler
2017-06-02 15:12 ` Alex Deucher
2017-06-02 16:47 ` Florian Echtler
2017-07-17 9:02 ` Lukas Wunner
2017-07-24 13:45 ` Florian Echtler
2017-07-25 5:14 ` Mario Kleiner
2017-07-25 7:53 ` Florian Echtler
2017-07-25 10:37 ` Lukas Wunner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox