This could be a BIOS bug, a kernel bug, a hardware bug, an XFree86 bug,
or one of many other things.  It's next to impossible to begin to debug
without the actual hardware.

Please attach your X server logs and config file, as well as your
/var/log/messages so there is further data to look at that might
provide clues.

The problem does not arise under KDE, nor does it arise under GNOME when using
WindowMaker as Windows Manager, so my guess now is that we should probably
suspect SawFish to have something to do with this

I can confirm the same issue with Sawfish/gnome on a Dell Latitude CS400 with
default packages.  After a suspend mouse events act strangely (left button can
select menus but can no longer move windows).

Nothing changed, in ralation to this bug, in RH 7.3

*** Bug 63913 has been marked as a duplicate of this bug. ***

confirmed as a sawfish issue (work around which works for me is 'killall
sawfish; sawfish&'

On my dell laptop : 

The problem is on apmd resume scripts :
 while syncing the sys clock, hwclock make the left button mouse dysfunction

We can reproduce the the problem with "date" or "setclock" commands too, 
providing an anterior date.

This bug is really annoying !!

I haven't tried to recompile the kernel.

agreed, sawfish was a red herring, switching window managers didn't help

*** Bug 64466 has been marked as a duplicate of this bug. ***

Thinkpad 600E notebook.
RH 7.3: apmd, XFree 4 (neomagic), WindowMaker
The same problem after apm -s / resume or pressing 'suspend' button on 
notebook.
Restarting WindowMaker does not help.

Workaround: in /etc/sysconfig/apmd set CLOCK_SYNC="no", this cures the problem
for me - I can live without my clock getting synced

Thanks!
FYI: bug #65407 looks similar

*** Bug 65407 has been marked as a duplicate of this bug. ***

No thanks ! What can i do when my laptops (dell and compaq) resume whith 
wrong time and date !

When i sync the sys date to the hw date, the mouse goes crazy.

may be a path : sometimes this method can help.
One suppose  the date is 06061200 (hardware clock). The resume state shows 
06061430.
# hwclock --hctosys
# date 06061430
# hwclock --hctosys

nota : when i enter the date command, my X11 screen seems to do dpms things.

I can confirm the above effects on my IBM TP R30, RH 7.3. The effect was not
present in RH 7.2. Without X11 (init state 3), the mouse events in gpm are OK
after suspend, which is indeed hinting at the 4.2.0 X server rather than the
kernel. One thing to note:
the X server's timer is screwed up after suspend. This has the effects the first
comment describes. If you do a ButtonPress and move (a.k.a. dragging, like when
movin a window), usually the X server generates a ButtonPress , several
MotionNotify and finally a ButtonRelease event. Now, after the timer being
screwed up, I noticed a different order: first no ButtonPress event, then the
usual MotionNotify's, and on release the ButtonPress *and* ButtonRelease event.
The corresponding xev log is this:

MotionNotify event, serial 22, synthetic NO, window 0x1a00001,
    root 0x3a, subw 0x0, time 2150638522, (145,153), root:(175,215),
    state 0x0, is_hint 0, same_screen YES

MotionNotify event, serial 22, synthetic NO, window 0x1a00001,
    root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214),
    state 0x0, is_hint 0, same_screen YES

ButtonPress event, serial 22, synthetic NO, window 0x1a00001,
    root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214),
    state 0x0, button 1, same_screen YES

ButtonRelease event, serial 22, synthetic NO, window 0x1a00001,
    root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214),
    state 0x100, button 1, same_screen YES

Note that the time-in-ms is always the same, so X's internal timer is screwed
up. That's probably the reason for the wrong event order. Before suspend, the
event order is correct and the timer is ever increasing, as expected. (Funny
thing is, event order is always fine for Button2, but not Button1 or 3. Probably
a race condition).

mharris, is there any more information you would need? Anything else we can try?

If the time goes backward at all on the machine, X is hosed.

Why backward? Assuming GMT+0 timezone, by waking up from sleep the system time
does a step forward, because the system time didn't advance in sleep mode
whereas the hwclock did. Timezone offsets may make the matter more complicated,
depending on when the timezone is taken into account. If the hwclock does not
honor the TZ which then has be by adjusted by the system, the there actuelly may
be a short period when the time has gone backwards. But this sounds like a
general X issue, whereas the problem of this bug was (at least in my case)
introduced by RH 7.3 and was definitely no present in RH 7.2.

Experimented the same problems on a Dell Inspiron 4100 with RH 7.3/XFree 4.2.0.

I will add my guesses to nils_un comments :
- by default the X server connects to "/dev/apm" in order to some clean up
  job before/after suspend (lnx_apm.c)
- this option is on by default (option "NoPM" "no" by default)
- when resuming, the X server is waken 'too fast', i.e. prior to apmscript
  finishing his job
- so before the apmcontinue has performed its hwclock job, the XServer
  will peek an incorrect time, and will be stuck with it as long as the wallclock
  hasn't catched up with it (the difference is 7200 secs on my machine, just
  the delta from my timezone to UTC)

This may explain why some application relying on the 'time' set in XEvent have
problems (gtk related ones I guess).

The problem seems to disapear (except for keyboard repeat mode ?) if you add
Option "NoPM" "yes". But in this case I experimented the same problem with
jerky mouse that I had in 4.1.x - the one that forced me to switch back to vt 
before toying with apm suspend.

Another hint could be to have the hardware clock set to UTC time. But this
may not be possible if your are using dual boot with another OS.

To me, the problem is with APM resuming : when is the system ready ?
Currently this should be "after apmd scripts have done their job"
Unfortunately, the XFree server doesn't rely on this hypothesis.

HTH

After some private mail with pedro on the subject, we both came up with the idea
of stopping the X server at suspend and only continuing it in the apmcontinue
script after the clock has been synched. This can only be considered a
workaround as the real bug resides in XFree. But it works. For the benefit of
others, I'll attach my apmcontinue script here. Two things to note: if your're
not interested in logging the progress, you can shorten the script
substantially. Also, for most laptops there's no reason to distinguish between
standby and suspend, which can make the script even shorter. BTW, the reloading
of usb-uhci has nothing to do with this bug.

Created attachment 68424 [details]
/etc/sysconfig/apm-scripts/apmcontinue to stop X in suspend/standy

I experience the same problems and have seen the same things with xev as Nils 
Ellmenreich <nils_un@infosun.fmi.uni-passau.de>

This only appears in RH 7.3 and not in 7.2!

My system is a Dell Inspiron 5000 notebook.

- my remark on option "NoPM" didn't work
- Nils' script works fine for me
- since kill -SIGSTOP / kill -SIGCONT on the XServer prior and after suspending
is a good workaround, this means that the problem remains in the XServer waking
up prior the system is really ready to continue (in this case it is stopped
until the system clock has been properly set)
- I don't need the usb stuff, but I still need a : "kbdrate -r 10 <
/dev/console" to restore keyboard repeat (in either X or console mode).

I guess we need a mechanism ` la init.d to suspend and wake the system. This
will allow more flexibility instead of hacking in one or two scripts
(apmcontinue or apmscript).

The apmscript also works for me. Did someone already test to use the Red Hat 
7.2 XFree86-* packages on their Red Hat 7.3 system? This might prove that the 
actual problem is not in something else than XFree.

BTW. I reported the problem to XFree also. No response yet, but I don't expect 
one :-)

Problem confirmed with following setup: 
 
IBM T30 w/ Radeon Mobility M7 LW 
Redhat 7.3 
KDE 3.0.0 
KDE 3.0.1 
KDE 3.0.2 
XFree86 4.2.0-8 
 
How to reproduce: 
 
1. Suspend while in X 
 
Effects: 
 
1. Causes mouse to double/triple click or something funky. 
 
Breaks: 
 
1. Window resize 
2. Window move (even Alt-left mouse click) 
3. Shade 
4. Icon hold-click 
5. Highlight text 
6. Chromium play sucks (most annoying) 
 
I know I didn't provide any help to fix the problem -- just wanted to say, 
"Hey! Me too!" 
 
Thanks for the apmcontinue script.  That's a little better than kill.  
However, SIGKILL didn't always work for me even on my Linux-only GMT based 
laptop.  Go figure...  hopefully something can be found soon.

A little more blabbing and then I'll shut up.    
    
It's broken on a Toshiba Tecra 8100 too. And basically I provide nothing new   
here except to modify the steps to reproduce:  
  
1. Run X  
2. Execute date with a new time.  
  
No need to suspend.  
  
Also, the apmcontinue script didn't work.  Yes, I did see 'logger' in  
/var/log/messages.  So, the SIGSTOP and SIGCONT were getting executed.  
  
Even funnier, I changed the computer clock to non-GMT and vice versa, and this  
causes a hard crash on my systems when restoring from a suspend.  You can sync  
the disk with SysRq-S, but SysRq-R doesn't get you a terminal -- the system is  
a goner.  
  
Again, this comment did nothing to contribute to the discussion... just chalk  
up another system and note that hacking these apm scripts will not cleanly fix  
the problem.  Can you open X in DDD? ;-)  I admire those guys.  
  
PS. While we are on the topic is there a FAQ somewhere that describes why 
timezones 8 hours *ahead* of GMT is TZ=GMT-8 ?  That always struck me as 
funny. 
 
PSS.  This bugtracker is going to be full of duplicates in a few weeks when 
the U.S. goes back to standard time!!  HA HA!  Poor guys.

I have duplicated this problem on Red Hat Linux 8.0, with the default of  
XFree86-4.2.0-72, and a Dell Latitude CPx J.  Setting the time back causes the 
PS/2 mouse to fail to respond to anything requiring a "drag" operation - 
moving a scrollbar, moving windows, etc.  However, this problem does NOT 
affect a USB mouse.  It only affects the PS/2 mouse (either as an external 
mouse or the touchpad, which appear to be treated equally by Linux).   I'm not 
sure if this is helpful or not, but I thought I would comment. 
 
The USB mouse is configured per RHL default: 
 
Section "InputDevice" 
        Identifier  "Mouse1" 
        Driver      "mouse" 
        Option      "Device" "/dev/input/mice" 
        Option      "Protocol" "IMPS/2" 
        Option      "Emulate3Buttons" "no" 
        Option      "ZAxisMapping" "4 5" 
EndSection 
 
The PS/2 mouse (touchpad) is configured as follows: 
 
Section "InputDevice" 
        Identifier  "Mouse0" 
        Driver      "mouse" 
        Option      "Protocol" "PS/2" 
        Option      "Device" "/dev/psaux" 
        Option      "ZAxisMapping" "4 5" 
        Option      "Emulate3Buttons" "yes" 
EndSection 
 
Hope this helps!

Comment #jeremyp@pobox.com :

Running RHL 8.0 on an IBM ThinkPad A30p :
I experience the problem on RHL 7.3/8.0 after a suspend/resume cycle both with
the internal PS/2 mouse driver (TrackPoint) and with an external USB mouse.

> Did someone already test to use the Red Hat 7.2
> XFree86-* packages on their Red Hat 7.3 system?
> This might prove that the actual problem is not
> in something else than XFree.

I've downgraded the XFree86 packages on my laptop's Red Hat 7.3 installation to
those from Red Hat 7.2 updates (XFree86-4.1.0-25 and co.), and the
(GlidePointPS/2) trackpad remains useable over suspend/resume cycles. With the
4.2.0 packages I had to log out, restart X and log back in again after a resume.
From this I'd conclude that the bug was introduced somewhere between 4.1.0 and
4.2.0.

I tried a recent rawhide build (XFree86-4.2.0-65), but that still exhibits the
bug. I'm not going to risk upgrading to Red Hat 8.0 until this is resolved,
because I'm not sure I'll still be able to downgrade to XFree86 4.1.0.

This bug is the same as bug #77247

Awaiting user to attach files to that report before closing it as a dupe,
just so we have more info.

Created attachment 84907 [details]
Updated apmcontinue - multiple X servers supported

Since kernel 2.4.18-10, I also had the problem that the screen didn't restore 
after suspend without the script. This appeared when the script didn't work 
anymore when I configured multiple X servers (:0 and :1) in gdm.conf

I've extended the script to send signals to ALL X servers. Now suspend works 
OK again.

bruthasj@yahoo.com) Well... for the record, bugzilla did not get filled
up with bug reports when the daylight savings time changed.

I've built a set of RPMs based on the XFree86-4.2.0-8 distribution, with the
addition of this patch:

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Io.c.diff?r1=3.49&r2=3.50

and this seems to resolve the problem. The comment from the commit log for that
revision is:

 290. Fixed GetTimeInMillis() to use deltas instead of absolute time
      returend by gettimeofday(). This ensures time is monotonic in X
      (Egbert Eich).

or at least I assume it's that revision. It's part of a single commit containing
lots of separate fixes, but the comment looks right. I also don't know if other
files were affected by this change. I don't know XFree86's source management
strategy well enough to find the original changeset.

The good news is that this is on the trunk of the tree heading towards
XFree86-4.3, so we can at least hope that things will improve when 4.3 is released.

I have binary packages of 4.2.0-8 with this patch that other people could try,
but they take up 54Mb and I don't have access to an FTP server with that kind of
space free on it.

I've got packages of 4.1.0 for RHL 7.[12], 4.2.1 for 8.0 and CVS XFree86
for rawhide with this already included currently.  I do not have packages
for 7.3 for testing, nor would it be very easy for me to provide them
currently, but if any of the people CC'd on this bug report can confirm
that this works for them, I can ensure the fix goes into 7.3 also.

Test fix packages are available at:

ftp://people.redhat.com/mharris/testing/7.2/XFree86 (for 7.1, 7.2 - get latest
build of 4.1.0-43 or later)
ftp://people.redhat.com/mharris/testing/8.0/XFree86 (for RHL 8.0, get latest
build of 4.2.1-10 or later)

Or use the rawhide XFree86 on RHL 8.0 as well.  Please give as much feedback
of your testing as possible to let me know if this fixes the issues.

Thanks.

I've been running with the patched version for over a week and it's working just
great; X after a restore which changes the time behaves properly.  I'm now
seeing occasional complete system lock-ups when restoring (probably one time in
every 20) but I don't think this is related.

*** Bug 62678 has been marked as a duplicate of this bug. ***

*** Bug 64782 has been marked as a duplicate of this bug. ***

*** Bug 77189 has been marked as a duplicate of this bug. ***

*** Bug 77064 has been marked as a duplicate of this bug. ***

*** Bug 76126 has been marked as a duplicate of this bug. ***

My test result notes:

(1) This appears to fix the loss of key repeat when the clock goes back (can't
recall which bug that is).

(2) Re: Bug 64782.  The behavior has changed but is not fixed.  On resume from
APM suspend-to-disk, the X screen is completely frozen and does not respond to
mouse or keyboard (where I used to be able to move the mouse cursor but not
click or keyboard).  There is intermittent disk activity (where I don't recall
having any before).  I can ssh to  the machine and see that X has run away and
is taking almost 100% of CPU.

So far nothing but good reports back, so I'm closing this bug as fixed in
RAWHIDE.  After upgrading to the latest release(s) of everything, if people
still experience problems, please open new bug reports for them with
full details.

*** Bug 77189 has been marked as a duplicate of this bug. ***

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2003-067.html