Bug 711452

I confirm the behavior as described in the attached table for T410 running 6.1.

I believe we've covered enough of these cases in the 6.2 rebase to consider it ackable.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Sure.  I'll take the internal group requirement off.

I'm pretty convinced of this being fixed in kernel -184 and later, moving to MODIFIED

Installed RHEL6 in on LVM logical volume, upgraded it to the latest 6.2 workstation snapshot.
Removing one external monitor (in suspended state) out of two made caused no problems, the builtin LCD took over its role.
Will repeat with both external monitors removed.

No luck with both monitors removed - a mouse cursor was visible on the builtin LCD, but nothing more. Reconnecting both external monitor made the system working again. 
In other words, it is a step in the right direction, but I presume we are not at finish line yet. 8-)

(In reply to comment #12)
> No luck with both monitors removed - a mouse cursor was visible on the builtin
> LCD, but nothing more. Reconnecting both external monitor made the system
> working again. 
> In other words, it is a step in the right direction, but I presume we are not
> at finish line yet. 8-)

I'm sorry, which hardware was this with?

I tested on my laptop, and I hope this identification infomation will be helpful: 
Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.24
Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: ThinkPad BIOS 6IET74WW (1.34 ), EC 6IHT38WW-1.13
Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: Lenovo ThinkPad T410, model 2537CT4
I use a 22 inch wide monitor on the digital interface and a dell 17 inch on VGA connector when I am docked.
The kernel I used is 2.6.32-193.el6.x86_64.
Do you need any more details?

(In reply to comment #14)
> I tested on my laptop, and I hope this identification infomation will be
> helpful: 
> Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.24
> Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
> Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: ThinkPad BIOS 6IET74WW (1.34
> ), EC 6IHT38WW-1.13
> Sep 13 10:37:59 dhcp-2-230 kernel: thinkpad_acpi: Lenovo ThinkPad T410, model
> 2537CT4
> I use a 22 inch wide monitor on the digital interface and a dell 17 inch on VGA
> connector when I am docked.
> The kernel I used is 2.6.32-193.el6.x86_64.
> Do you need any more details?

When this happens (and you move the mouse and can see the cursor), if you type your password in blindly, does the screen unlock? If it does, I'm reasonably sure this is a screensaver issue not an X issue.

Quite reasonable to suspect the screensaver here. I will clarify, whether is this a screensaver issue or not, and move this bug to verified if the cause is the screensaver, not the kernel.

I had to reconnect both monitors again - someone is loosing his head when I disconnected both external monitors. The issue is NOT screen-saver only, as after unlocking I remained alone with the mouse cursor. (As I wasn't sure I successfully unlocked the screen,so  I typed in my password a few more times, which appeared in my xterm window after reconnecting the monitors.)  The situation looks like we still have a kernel issue here.

The issue is not screensaver, because if you SSH to the host and kill gnome-screensaver, the screen stays black.

Ugh, lovely.

Okay, so, I'm going to treat _this_ bug as being about the screensaver interaction on resume.  If there are _any_ other suspend-related issues, please open new bugs for them.  Otherwise this'll get bogged down forever.

No fix ready for 6.2.  Any fix would likely require changes to core drm, which is an unacceptable regression risk for radeon and nouveau at this point in the 6.2 cycle.  I believe I'd found a workaround but it escapes me at the moment, will update when I rediscover it.

Moving to 6.3 accordingly.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0995.html