This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

I am still seeing this bug in RC with
xorg-x11-server-Xorg-1.10.4-6.el6.x86_64
kernel-2.6.32-220.el6.x86_64

Chatted with Richard Hughes. He believes there is a regression.

Have reverted to previous X server.
xorg-x11-server-Xorg-1.7.7-29.el6_1.2.x86_64

Will run over the next couple of days to see if error still occurs.

Dear Grant please see bug 676866 (this issue is a duplicate of mentioned one).

I'm quite sure that it was postponed to 6.3, so I suppose other RC's will not fix that., just FYI.

Hi Tomas, not able to access the bug. 
Was hoping for a fix pre 6.2 GA or as post.

Aah I see It is not public, the reason why It was not included in to 6.2 was the fact that gnome-powermanager was not on ACL for 6.2. Should be fixed in z-stream I suppose.

Could we get an explanation of the regression and the plan for resolution in RHEL 6.3?

Richard do you know the plan, I don't think we have it yet.

As Richard suggested running the previous version of Xorg(xorg-x11-server-Xorg-1.7.7-29.el6_1.2.x86_64) on 6.2 without any issues.
Have not seen the blip, looks like a regression.

There's only two changes in the SYNC extension code between then and now that I'm suspicious of.  I've built several test packages without those changes:

http://people.redhat.com/~ajackson/748704/

The .bracket and .blockhandler packages have one patch reverted each; the .both packages have both reverted.  Please test all three and report which (if any) exhibit the bug.  Hopefully at least one of them does not.

Any updates on this?  I can't seem to reproduce this locally.

Adam I've got it on my RHEL6.2 couple days ago.

But I'm really not sure about reproducer, maybe something like:

1) fill most of RAM (not hard on my workstation with 2GB RAM)
2) try to suspend, always fail with almost crowded RAM
3) repeat 2) several times 

Got the power-management message. But again not 100% reproducer.

Should I change the component on this bug to xorg-x11-server-Xorg? I don't think this is a g-p-m problem, it just seems to be the component that is too vocal about the regression.

(In reply to comment #15)
> Should I change the component on this bug to xorg-x11-server-Xorg? I don't
> think this is a g-p-m problem, it just seems to be the component that is too
> vocal about the regression.

Reassign to xserver is fine.

Someone, please.  Run the packages in comment #12 and tell me which ones work reliably and which ones don't.  I've not been able to reproduce this so I really do need thatfeedback.

Still waiting for test results of the packages linked in comment #12.

Testing these packages now, sorry for the delay, will have an update in about a week.

Blockhandler - do not see the issue
Bracket - problem occurs.

Testing Both at this moment - is this the same as the production package?

Blockhandler - do not see the issue
Bracket - problem occurs
Both - problem occurs, confirmed today.

Clearing conditional-nak, clearly the bracket patch is to blame.

Actually, not.  It appears this is properly a bug in gnome-session.  See the upstream discussion here:

https://bugzilla.gnome.org/show_bug.cgi?id=627903

The patch therein is not present in the gnome-session in 6.3, afaict.  Reassigning to gnome-session on that basis.

I've built test packages with the referenced upstream patch here:

http://people.redhat.com/~rstrode/748704/

and would appreciate feedback.

I have installed
gnome-session-2.28.0-18.fixidle.el6.x86_64.rpm
gnome-session-xsession-2.28.0-18.fixidle.el6.x86_64.rpm


Whats the gnome-session-custom-session-2.28.0-18.fixidle.el6.x86_64.rpm for?

I have 
gnome-session-2.28.0-18.fixidle.el6.x86_64.rpm
gnome-session-xsession-2.28.0-18.fixidle.el6.x86_64.rpm

Installed, just noticed the applet again.

"Session active, not inhibited, screen idle. If you see this test, your display server is broken and you should notify your distributor."

did you log out and log back in after installing the package?

gnome-session-custom-session is a package that provides a UI for specialize workflows that some customers use, involving multiple saved sessions.  It's not something you need to install.

also, is the problem you're continuing to see just the lingering tooltip? or are you also seeing the other problems?

I installed/upgraded the package and then rebooted.

I rebooted my machine again yesterday and after suspend/resume this morning, the message shows again.

The tooltip is present yes, but if you are present when the tooltip appears there is a brief X server blip where the screen hangs for 1 second black then returns.

Thanks for the fast feedback, Grant.  I'm investigating the situation in greater detail now and will get back to you via this bug report.

To be clear, as we understand it, the bug can be characterized as:

1) User closes lid to suspend machine, screensaver activates, machine suspends
2) User stops using machine for some significant amount of time
3) User goes back to machine, opens lid and resumes machine
4) User unlocks screensaver
5) User sees desktop for a split second
6) User sees monitor turn off for 1 to 2 seconds
7) User sees monitor turn back on
8) User notices new icon in panel
9) User puts pointer over icon and sees the message:
"Session active, not inhibited, screen idle. If you see this test, your display
server is broken and you should notify your distributor.
Please see http://blogs.gnome.org/hughsie/2009/08/17/gnome-power-manager-and-blanking-removal-of-bodges/ for more information"

Does that seem pretty accurate?

I investigated this issue with Adam a bit today and I'm going to give a dump of our findings.  These notes are technical and not completely well formed.

gnome-power-manager sets up IDLETIME sync counter alarm which purpose is to fire 10 seconds after the user stops moving the mouse.  When this alarm fires, power manager sets up a 60 second "blank timeout". If the user moves the mouse or hits a key before that 60 seconds has elapsed, the timeout is removed, and nothing happens.  

After 60 seconds of more inactivity, though, (so 70 seconds since the user stopped moving the mouse) the timeout fires and gnome-power-manager turns off the screen and then shows the icon.  Note, the icon is only supposed to be visible when the screen is off and in a subsequent update of gnome-power-manager won't be shown ever.

One interesting point, is those 60 seconds are "real time" seconds.  If the machine is suspended for longer than 60 seconds, then power manager will potentially instantly dispatch the timeout, since 60 seconds expired while the machine was suspended. If screen locking is disabled (so comment 32 step 4 isn't applicable) then that could explain why the monitor turns off shortly after resume (command 32 step 6).  

There is an apparent bug in the X server introduced in 6.3.  This upstream patch:

http://cgit.freedesktop.org/xorg/xserver/commit/Xext/sync.c?id=b55bf248581dc66321b24b29f199f6dc8d02db1b

seemingly gets the Positive and Negative transition hunks backward.   Adam is going to revert that patch from the X server in 6.3 which will make this bug disappear for now.

Also, there is a race in the function IdleTimeWakeupHandler where it only updates the idletime counter when the idle time is in range of the registered alarms, but the idle time is queried immediately in that function and the range is old, based on a stale idle time.

The patch mentioned in comment 23 shouldn't be necessary after the X server is fixed, and we don't anymore think it's actually relevant for this particular bug. That patch is also non-ideal. It should set the negative transition value to 1, instead of trying to make it stay so close aligned with the positive transition value.  After all, the X server resets the idletime counter to 0 anytime there is user activity, so any small value will work.

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.

4168035 build (rhel-6.3-candidate, /rpms/xorg-x11-server:937f551bd639573a444959a305213162c0c5f57c) completed successfully

MODIFIED

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/RHSA-2012-0939.html