Kernel kernel-2.6.40.1-1.fc15.x86_64 from koji indeed fixes the suspend problem.

However, on resume, all gnome-terminals are gone. I still don't know why that is.

Kernel 2.6.40.1-2.fc15.x86_64 is not much better. On resume, nautius died this time. On second resume/suspend cycle, gnome-panel died and was automatically restarted (i.e. I can see a different PID for it).

So, something is still very wrong on suspend/resume here.

Not sure of this is an oversight, or deliberate since this bug is still being worked on, but judging from the kernel spec changelog , this patch has not been added to F-16, I guess we want it there too?

(In reply to comment #3)
> Not sure of this is an oversight, or deliberate since this bug is still being
> worked on, but judging from the kernel spec changelog , this patch has not been
> added to F-16, I guess we want it there too?

I'm having a feeling upstream is working on a different, more complicated fix for this. So, maybe that will go into F-16 when upstream finalises it?

Anyway, as I said before, even with the fix, I'm losing processes on resume, so things are still not as good as on .38.

Just tried 2.6.40.2-0.fc15.x86_64. Still no good. It comes back from suspend and a whole lot of stuff dies. I'll attach a screenshot of what popped up, but Evo died, gnome-terminals did too and more.

Created attachment 518164 [details]
Programs die on resume in Gnome

kernel-2.6.40.3-0.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.40.3-0.fc15

Package kernel-2.6.40.3-0.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-2.6.40.3-0.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/kernel-2.6.40.3-0.fc15
then log in and leave karma (feedback).

kernel-2.6.40.3-0.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Reopening, changing what the problem actually is.

Note that with kernel-2.6.40.3-0.fc15 the problem is less severe, but it still happens. I have seen gnome-panel and nautilus die on resume thus far. The widespread process death (as seen in the screenshots) is not happening any more, but there is no doubt that the problem still persists.

please attach a dmesg from after the resume when things have been killed.

Created attachment 518969 [details]
dmesg on resume when processes die

Note that in this particular case, I had gnome-terminal, nautilus, gnome-panel and a whole bunch of applets die.

I don't see anything obvious in that log to explain why things are dying.

abrtd[968]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'

You might want to fix that up, to see if that makes abrt start catching the crashes, perhaps that'll give some clues.

(In reply to comment #15)
> I don't see anything obvious in that log to explain why things are dying.
> 
> abrtd[968]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
> 
> You might want to fix that up, to see if that makes abrt start catching the
> crashes, perhaps that'll give some clues.

Haven't touched this file. Didn't even know I had one there, to be honest.

BTW, abrt does work for me. I logged plenty of bugs with it. Will look a bit more.

I just tried kernel-2.6.40.3-2.fc15.x86_64 from koji. I know I'm going to regret saying this, but haven't seen any crashes/restarts except for pidgin, which appears to be reloaded on resume. Note sure whether anything from stable queue should make a difference here.

Will keep testing...

(In reply to comment #17)
> I know I'm going to regret saying this

Yup. Resumed after the machine has been asleep overnight and many Gnome apps are gone, including nautilus, gnome-panel etc. Back to square one.

From ~/.xsession-errors:
----------------------------------------
(gnome-terminal:1915): Gdk-WARNING **: The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 10608 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(gnome-power-manager:1845): Gdk-WARNING **: The program 'gnome-power-manager' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 1540 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(gnome-panel:1781): Gdk-WARNING **: The program 'gnome-panel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 6140 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(nautilus:1863): Gdk-WARNING **: The program 'nautilus' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 1724 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area
----------------------------------------

This _only_ happens with 3.0.x (i.e. 2.6.40.x) kernels. Looks like other folks are seeing this too, in bug #720792.

Maybe we need the latest Intel graphics drivers (http://intellinuxgraphics.org/2011Q3.html) with kernel 3.0? If there is a build for F-15 floating around, I wouldn't mind trying it.

I'm going to reassign this to X to see if those guys have any insight.
It may still be a kernel change that causes the problem, but X should be able to handle devices coming and going without apps caring.

X folks,

Any ideas here? Look from comment #19 onwards.

Well, I would guess more data could help.

Please attach

* your X server config file (/etc/X11/xorg.conf, if available), and
* X server log file (/var/log/Xorg.*.log*; check with grep Backtrace /var/log/Xorg* which logs might be the most interesting ones, send us at least Xorg.0.log)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

That grep doesn't match anything in any of the files, so I'm just going to attach Xorg.0.log and Xorg.0.log.old (this is with the .38 kernel), for comparison. I will also attach the latest .xession-errors file, for reference.

It took 3 suspend/resume cycles this time to trigger this. Kernel was kernel-2.6.40.4-5.fc15.x86_64.

Created attachment 521414 [details]
X session errors

Created attachment 521415 [details]
X11 log of the session where programs die on resume (kernel 2.6.40)

Created attachment 521416 [details]
X11 log of the session where programs do not die on resume (kernel 2.6.38)

Oh, and I don't have /etc/X11/xorg.conf file. It's all configured automatically.

(In reply to comment #15)
> abrtd[968]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
> 
> You might want to fix that up, to see if that makes abrt start catching the
> crashes, perhaps that'll give some clues.

FYI - it's a bug #715456.

And now that I have new abrt, the darn thing won't crash on me. Will keep trying.

(In reply to comment #30)
> And now that I have new abrt, the darn thing won't crash on me. Will keep
> trying.

Just happened again. As usual, I got:
-----------------------------
Window manager warning: Log level 8: meta_window_focus: assertion `!window->override_redirect' failed

(nm-applet:1866): Gdk-WARNING **: The program 'nm-applet' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 53493 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(nautilus:1932): Gdk-WARNING **: The program 'nautilus' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 3083 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

** (notification-daemon:1918): DEBUG: Adding id 3
** (notification-daemon:1918): DEBUG: Bubble destroyed
** (notification-daemon:1918): DEBUG: No queued notifications
-----------------------------

Nothing significant in the Xorg.0.log. Nothing significant in /var/log/messages. New abrt didn't pick up the crashes at all.

What do I do next?

One more piece of info here. I tried stracing the apps that crash and I even tried debugging them with GDB on other VTs. Found nothing from strace and they wouldn't crash when being debugged with GDB.

Some more FYI, I switched to xorg-x11-drv-intel-2.16.0-2.fc15.x86_64, which I built locally form the F-16 RPM. Also running xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64. We'll see how that combo goes.

(In reply to comment #33)
> Some more FYI, I switched to xorg-x11-drv-intel-2.16.0-2.fc15.x86_64, which I
> built locally form the F-16 RPM. Also running
> xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64. We'll see how that combo goes.

Didn't help.

since I got an arrandale 
[    91.820] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
[    91.820] (--) intel(0): Chipset: "Arrandale"

I don't had any of this problems , with F15 updated (in kde).

(In reply to comment #35)
> since I got an arrandale 
> [    91.820] (II) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale
> [    91.820] (--) intel(0): Chipset: "Arrandale"
> 
> I don't had any of this problems , with F15 updated (in kde).

Then this must be a Gnome specific problem. Just resumed and lost gnome-terminal this time:

(gnome-terminal:27963): Gdk-WARNING **: The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 42085 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Assigning back to xorg-x11-server. Maybe folks will have some more pointers for me.

It just occurred to me that I run an unusual bit of configuration: Gnome fallback mode with Mutter as a window manager (which obviously was not a problem before 2.6.40 kernel).

Could it be that I'm hitting some bugs in Mutter that otherwise never show (i.e. because it's normally run under gnome-shell)?

I'll bet this fixed it:

http://pkgs.fedoraproject.org/gitweb/?p=libXi.git;a=commitdiff;h=e9e6be20f0f57a75c8a70eb52b40a005af1afac9

Rebooting in a few...

(In reply to comment #35)

> I don't had any of this problems , with F15 updated (in kde).

Or, maybe you just have different input devices.

In the meantime, I had an X crash on resume (got gdm login screen again). Not sure whether it's related to this in any way. Nothing useful in the logs, abrt didn't pick anything up either.

(In reply to comment #39)
> I'll bet this fixed it:
> 
> http://pkgs.fedoraproject.org/gitweb/?p=libXi.git;a=commitdiff;h=e9e6be20f0f57a75c8a70eb52b40a005af1afac9
> 
> Rebooting in a few...

Nope:
------------------------------
(notification-daemon:1890): Gdk-WARNING **: The program 'notification-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 11024 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(gnome-panel:1825): Gdk-WARNING **: The program 'gnome-panel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 45770 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(gnome-screensaver:1892): Gdk-WARNING **: The program 'gnome-screensaver' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 11026 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
------------------------------

Back to square one.

No progress, so let's see what libXi people think of this.

Anyone has any idea on how to debug and eventually fix this?

This must be something in one of the libraries. For the first time I had Evo die as well:
--------------------------
(evolution:1995): Gdk-WARNING **: The program 'evolution' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 236980 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
--------------------------

And again, X crash on resume. Nothing worth reporting in the log. Abrt didn't catch anything.

Ditto with 2.6.40.6-0.fc15.x86_64.

Not sure whether this is a fluke, but I cannot replicate this with F-16 Beta Live on the same hardware. Suspended/resumed many times. Hmm...

(In reply to comment #46)
> And again, X crash on resume. Nothing worth reporting in the log. Abrt didn't
> catch anything.

Another crash of X on resume, this time with no Gnome sessions opened (i.e. at GDM login screen).

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I'm just going to reassign this to gtk for now. XI_BadDevice is the standard error clients will get when they use an invalid device parameter for an X Input extension request. Even if there's a bug in the server or libXi, since devices can disappear at any time, any client must expect such an error to happen and handle it appropriately.

(In reply to comment #45)
> This must be something in one of the libraries. For the first time I had Evo
> die as well:
> --------------------------
> (evolution:1995): Gdk-WARNING **: The program 'evolution' received an X Window
> System error.
> This probably reflects a bug in the program.
> The error was 'XI_BadDevice (invalid Device parameter)'.
>   (Details: serial 236980 error_code 149 request_code 141 minor_code 48)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
> --------------------------


Can you do what GTK+ is asking you to do in those messages you posted ?

(In reply to comment #52)

> Can you do what GTK+ is asking you to do in those messages you posted ?

I actually tried this (although some programs that are crashing were not aware of --sync option), but was unable to replicate the problem. I'll try again.

nautilus: doesn't understand --sync
gnome-terminal: doesn't understand --sync
gnome-panel: doesn't understand --sync

These crash most often. Any other ideas?

Oh bummer. Looks like that error message is outdated in gdk.

You can set the GDK_SYNCHRONIZE env var to achieve the same, nowadays.

Running things like that now. I set break gdk_x_error() in gdb instances that are tracing several binaries that usually crash. Of course, now they won't crash - isn't it always like this? :-(

Will keep running my system like this in the hope that they do eventually crash. Keep you posted.

I think I'm hitting this bug on my Thinkpad T510 with F15 and gnome. It happens frequently after resuming from suspend, sometimes the whole Xorg session crashes while some others just some program gets terminated.

Excerpt from my .xsession-errors:

(gnome-power-manager:12475): Gdk-WARNING **: The program 'gnome-power-manager' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 24339 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


(gnome-screensaver:12420): Gdk-WARNING **: The program 'gnome-screensaver' received an X Window System error.
This probably reflects a bug in the program.
The error was 'XI_BadDevice (invalid Device parameter)'.
  (Details: serial 25521 error_code 149 request_code 141 minor_code 48)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

gnome-session[12202]: WARNING: Detected that screensaver has left the bus

(gnome-settings-daemon:12366): media-keys-plugin-WARNING **: Unable to get default sink
** (deja-dup-monitor:12421): DEBUG: monitor.vala:263: Invalid next run date.  Not scheduling a backup.
Error getting primary device: GDBus.Error:org.gnome.PowerManager.Failed: There is no primary device to reflect system state (don't show any UI)
gnome-session[12202]: WARNING: Detected that screensaver has left the bus
gnome-session[12202]: WARNING: Detected that screensaver has left the bus
gnome-session[12202]: WARNING: Detected that screensaver has left the bus

Please let me know if there is anything I can do to help identifying the root cause of the issue.

I was tracing notification area applet in gdb with that environment variable set to 1, but got nothing - the program did not break on gdk_x_error() function at all - just existed. No stack.

No idea what to do next.

I meant to say, just exited, not just existed.

Hans de Goede forwarded me to this problem, I am not sure if this is related.

On RHEL 6.2 Beta I have had a few incidents that after a resume I immediately get a complaint of Gnome that was XKB related. The window reappears immediately after close for about 15 times.

Meanwhile, any Gnome application complains about unable to write (eg. LibreOffice etc...). While inside a terminal window there are no I/O related issues, all file systems are mounted r/w and I can still perform writes to disk. So it's as if the gnome-vfs back-end died or something ?

If there's anything I can do to increase verbosity in order to analyse this better next time, let me know. If this deserves another bug report, I'll do that as well.

PS Looking at .xsession-errors.old I find (among others) the below, but I am not entirely sure that this was a direct result from the problem (ie. it might have been due to a shutdown). The fact that this file has no timestamps makes it hard to relate it with incidents after the fact:

----

 (polkit-gnome-authentication-agent-1:2627): polkit-gnome-1-WARNING **: Error enumerating temporary authorizations: Remote Exception invoking  org.freedesktop.PolicyKit1.Authority.EnumerateTemporaryAuthorizations() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.Po licyKit1: org.freedesktop.PolicyKit1.Error.Failed: Cannot determine session the caller is in
 gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gdu-notification-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 local:  fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0"
 polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 seapplet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 applet.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 abrt-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
 Stopping Bluetooth ObexFTP server failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the  message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
----

While trying to find this bug for Dag, I did a google search and I also found this archlinux bug, which almost certainly is the same issue, and which *may* contain relevant info:

https://bugs.archlinux.org/task/24096

(In reply to comment #61)
> While trying to find this bug for Dag, I did a google search and I also found
> this archlinux bug, which almost certainly is the same issue, and which *may*
> contain relevant info:
> 
> https://bugs.archlinux.org/task/24096

Yeah, that looks like the same thing.

Dag's RHEL 6.2 problem, don't think so.

I upgraded my laptop to F-16 now. Didn't have this problem on resume yet, but it might be just a fluke.

PS. I am running metacity again, because of bug #750476. As we've seen from other people's reports here, it shouldn't matter, but just for the record.

Hi.

I had a similar issue:
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956

(see https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956/comments/4)

I could resolve it by unloading kernel modules before suspend. That removes X input devices. After wakeup, I just load modules again.

Regards.

(In reply to comment #64)
> Hi.
> 
> I had a similar issue:
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956
> 
> (see
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/882956/comments/4)
> 
> I could resolve it by unloading kernel modules before suspend. That removes X
> input devices. After wakeup, I just load modules again.

Thanks for the tips. These sound like workarounds more than solutions to me, to be honest.

Anyhow, I'm now on Fedora 16 and I haven't had this happen once. So, maybe there is hope. :-)

(In reply to comment #65)
 
> Anyhow, I'm now on Fedora 16 and I haven't had this happen once. So, maybe
> there is hope. :-)

Still haven't seen this in F-16. I know I'm going to regret saying this, but it looks like it's been fixed there.

(In reply to comment #66)
> I know I'm going to regret saying this, but it
> looks like it's been fixed there.

I knew I'd eat my words here. Yeah, it happened - essentially everything went down and I got logged off. I'll attach .xsession-errors form F-16.

Created attachment 532925 [details]
X session errors from F-16 (got completely logged out)

Unfortunately, all those xsession-errors, and X logs are of no use here. I really need a stack trace from a crashing client, to show which X request is triggering the BadDevice.

(In reply to comment #69)
> Unfortunately, all those xsession-errors, and X logs are of no use here. I
> really need a stack trace from a crashing client, to show which X request is
> triggering the BadDevice.

As you can see from comment #58 and above, I tried. Got absolutely nothing in gdb. No idea what to do next.

Just FYI, new Intel X graphics drivers didn't make a difference here.

No, it's a input device. Does the computer has a fingerprint reader?

(In reply to comment #72)
> No, it's a input device. Does the computer has a fingerprint reader?

It does.

Created attachment 537274 [details]
Kernel divide error when trying to replicate this problem in F-16

This happened probably after about 50 suspend/resume cycles. The box hung. 3.1.2-1.fc16.x86_64. Just FYI.

I get this regularly with F16.  It may be be aggravated by the fact that I'm suspending it while docked and resuming without.  The laptop has a fingerprint reader, but it isn't supported, so that's most likely not relevant.

(In reply to comment #74)
> Created attachment 537274 [details]
> Kernel divide error when trying to replicate this problem in F-16
> 
> This happened probably after about 50 suspend/resume cycles. The box hung.
> 3.1.2-1.fc16.x86_64. Just FYI.

And again. Looks like newer kernel are even more rotten on this hardware.

The only thing that will help fix this bug is an actual stacktrace...

I have no idea what to get a stacktrace on.  The last time this happened there was no indication in any of the logs to suggest what happened.

(In reply to comment #77)
> The only thing that will help fix this bug is an actual stacktrace...

Been running nautilus, gnome-terminal and gnome-panel like this for a while, under the gdb, with GDK_SYNCHRONIZE=1. It either doesn't happen (did suspend/resume in the vicinity of 300 times like that) or when it does, there is no usable trace.

Will keep trying...

(In reply to comment #79)

> Will keep trying...

For instance, I just switched user a few times, which crashed my X session. Got no usable traces from that.

Upstream bug for the chipset I have:
https://bugs.freedesktop.org/show_bug.cgi?id=40625

gtk3-3.2.2-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/gtk3-3.2.2-2.fc16

Package gtk3-3.2.2-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gtk3-3.2.2-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16634/gtk3-3.2.2-2.fc16
then log in and leave karma (feedback).

Thank you for pushing this update. Of course, it will take a while to verify that the problem is fixed. Will keep you posted.

gtk3-3.2.2-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.