Bug 492686 - Evolution hangs in uninterruptible sleep state and grinds the machine to a halt
Evolution hangs in uninterruptible sleep state and grinds the machine to a halt
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-28 06:00 EDT by Kjartan Maraas
Modified: 2010-12-05 01:58 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:58:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
syslog output (100.88 KB, text/plain)
2009-03-28 12:59 EDT, Kjartan Maraas
no flags Details
output from sysrq-t (211.33 KB, text/plain)
2009-03-31 12:15 EDT, Kjartan Maraas
no flags Details
output from sysrq-t + sysrq-w (20.36 KB, application/x-compressed)
2009-08-13 10:18 EDT, Kjartan Maraas
no flags Details
dmesg output with a lot of backtraces from the kernel (80.99 KB, text/plain)
2009-09-23 13:23 EDT, Kjartan Maraas
no flags Details

  None (edit)
Description Kjartan Maraas 2009-03-28 06:00:15 EDT
Description of problem:

For some time now (weeks, maybe a month or more) I've been seeing random hangs which most of the time start with evolution getting stuck in uninterruptible sleep mode. I have seen other processes in the same state but I'm not sure that's a side-effect of evolution getting stuck or if the same problem hit more programs at the same time. I *think* I've seen this happening without having run evolution in the session as well, but I can't remember for sure.

The reason I'm filing this against the kernel is that I've now run successfully for days without any hangs and the machine has survived several suspend/resume cycles with all programs running and the only change I did was adding nosmp to the boot command line.

This is a Centrino Duo system with intel chipset.

I've seen errors like "stuck on cpu0" when trying to shut down after the program hung, but before the whole machine locks up. These may well be just a result of the machine not being able to shut down cleanly though. Also any errors shown on the console during shutdown never made it to syslog for some reason.

What can I do to get more information when this occurs? Anything I can do through sysrq or other means?

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Kjartan Maraas 2009-03-28 12:59:42 EDT
Created attachment 337117 [details]
syslog output

Tried again with the latest kernel from rawhide with the same result. Evolution hung in D state after just a few minutes.

Got some information through alt+sysrq+[m,l,w] and will be attaching the syslog from that session.
Comment 2 Chuck Ebbert 2009-03-31 00:43:01 EDT
We're still waiting for output of alt-sysrq-t...
Comment 3 Kjartan Maraas 2009-03-31 12:15:04 EDT
Created attachment 337333 [details]
output from sysrq-t

Here's the output from sysrq-t. Looks like it's truncated at the start for some reason? Didn't syslog catch it all?
Comment 4 Kjartan Maraas 2009-03-31 14:58:15 EDT
Right after I produced this output I got a hard lockup and the last indicator of something happening was a pop in the speaker similar to what I hear when logging in and sound is initialized.
Comment 5 Kjartan Maraas 2009-04-03 06:31:24 EDT
Been running for a while with maxcpus=1 now and everything is stable. The laptop has survived many suspend/resume cycles and moving between lots of different wireless networks.
Comment 6 Kjartan Maraas 2009-04-29 05:33:56 EDT
Still seeing this from time to time with rawhide kernels unless I pass maxcpus=1 on the boot command line.
Comment 7 Chuck Ebbert 2009-05-06 22:40:48 EDT
i915 is hitting a circular locking problem, maybe that causes the lockup:

Mar 28 11:58:28 localhost kernel: =======================================================
Mar 28 11:58:28 localhost kernel: [ INFO: possible circular locking dependency detected ]
Mar 28 11:58:28 localhost kernel: 2.6.29-16.fc11.i686.PAE #1
Mar 28 11:58:28 localhost kernel: -------------------------------------------------------
Mar 28 11:58:28 localhost kernel: Xorg/2737 is trying to acquire lock:
Mar 28 11:58:28 localhost kernel: (&mm->mmap_sem){----}, at: [<c049a1f6>] might_fault+0x48/0x85
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: but task is already holding lock:
Mar 28 11:58:28 localhost kernel: (&dev->struct_mutex){--..}, at: [<f8213b55>] i915_gem_execbuffer+0xd6/0xa0f [i915]
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: which lock already depends on the new lock.
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: the existing dependency chain (in reverse order) is:
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: -> #1 (&dev->struct_mutex){--..}:
Mar 28 11:58:28 localhost kernel:       [<c0459164>] __lock_acquire+0x96e/0xacc
Mar 28 11:58:28 localhost kernel:       [<c045931d>] lock_acquire+0x5b/0x81
Mar 28 11:58:28 localhost kernel:       [<c0700b9f>] __mutex_lock_common+0xdd/0x338
Mar 28 11:58:28 localhost kernel:       [<c0700ea1>] mutex_lock_nested+0x33/0x3b
Mar 28 11:58:28 localhost kernel:       [<f81bc6a5>] drm_gem_mmap+0x36/0xfe [drm]
Mar 28 11:58:28 localhost kernel:       [<c04a13cc>] mmap_region+0x269/0x3fb
Mar 28 11:58:28 localhost kernel:       [<c04a17b3>] do_mmap_pgoff+0x255/0x2a5
Mar 28 11:58:28 localhost kernel:       [<c040c60c>] sys_mmap2+0x5f/0x80
Mar 28 11:58:28 localhost kernel:       [<c04094eb>] sysenter_do_call+0x12/0x3f
Mar 28 11:58:28 localhost kernel:       [<ffffffff>] 0xffffffff
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: -> #0 (&mm->mmap_sem){----}:
Mar 28 11:58:28 localhost kernel:       [<c0459031>] __lock_acquire+0x83b/0xacc
Mar 28 11:58:28 localhost kernel:       [<c045931d>] lock_acquire+0x5b/0x81
Mar 28 11:58:28 localhost kernel:       [<c049a213>] might_fault+0x65/0x85
Mar 28 11:58:28 localhost kernel:       [<c054dd73>] copy_from_user+0x32/0x119
Mar 28 11:58:28 localhost kernel:       [<f8213ce8>] i915_gem_execbuffer+0x269/0xa0f [i915]
Mar 28 11:58:28 localhost kernel:       [<f81bb7fc>] drm_ioctl+0x1b7/0x236 [drm]
Mar 28 11:58:28 localhost kernel:       [<c04bec1a>] vfs_ioctl+0x5c/0x76
Mar 28 11:58:28 localhost kernel:       [<c04bf1ba>] do_vfs_ioctl+0x483/0x4bd
Mar 28 11:58:28 localhost kernel:       [<c04bf23a>] sys_ioctl+0x46/0x66
Mar 28 11:58:28 localhost kernel:       [<c04094eb>] sysenter_do_call+0x12/0x3f
Mar 28 11:58:28 localhost kernel:       [<ffffffff>] 0xffffffff
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: other info that might help us debug this:
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: 1 lock held by Xorg/2737:
Mar 28 11:58:28 localhost kernel: #0:  (&dev->struct_mutex){--..}, at: [<f8213b55>] i915_gem_execbuffer+0xd6/0xa0f [i915]
Mar 28 11:58:28 localhost kernel:
Mar 28 11:58:28 localhost kernel: stack backtrace:
Mar 28 11:58:28 localhost kernel: Pid: 2737, comm: Xorg Not tainted 2.6.29-16.fc11.i686.PAE #1
Mar 28 11:58:28 localhost kernel: Call Trace:
Mar 28 11:58:28 localhost kernel: [<c06ffa1f>] ? printk+0x14/0x1d
Mar 28 11:58:28 localhost kernel: [<c04585e1>] print_circular_bug_tail+0x5d/0x68
Mar 28 11:58:28 localhost kernel: [<c0459031>] __lock_acquire+0x83b/0xacc
Mar 28 11:58:28 localhost kernel: [<c049a1f6>] ? might_fault+0x48/0x85
Mar 28 11:58:28 localhost kernel: [<c045931d>] lock_acquire+0x5b/0x81
Mar 28 11:58:28 localhost kernel: [<c049a1f6>] ? might_fault+0x48/0x85
Mar 28 11:58:28 localhost kernel: [<c049a213>] might_fault+0x65/0x85
Mar 28 11:58:28 localhost kernel: [<c049a1f6>] ? might_fault+0x48/0x85
Mar 28 11:58:28 localhost kernel: [<c054dd73>] copy_from_user+0x32/0x119
Mar 28 11:58:28 localhost kernel: [<f8213ce8>] i915_gem_execbuffer+0x269/0xa0f [i915]
Mar 28 11:58:28 localhost kernel: [<c0456b4a>] ? lock_release_holdtime+0x2b/0x123
Mar 28 11:58:28 localhost kernel: [<c049a231>] ? might_fault+0x83/0x85
Mar 28 11:58:28 localhost kernel: [<c054dd73>] ? copy_from_user+0x32/0x119
Mar 28 11:58:28 localhost kernel: [<f81bb7fc>] drm_ioctl+0x1b7/0x236 [drm]
Mar 28 11:58:28 localhost kernel: [<f8213a7f>] ? i915_gem_execbuffer+0x0/0xa0f [i915]
Mar 28 11:58:28 localhost kernel: [<c04bec1a>] vfs_ioctl+0x5c/0x76
Mar 28 11:58:28 localhost kernel: [<c04bf1ba>] do_vfs_ioctl+0x483/0x4bd
Mar 28 11:58:28 localhost kernel: [<c0456b4a>] ? lock_release_holdtime+0x2b/0x123
Mar 28 11:58:28 localhost kernel: [<c0474b1b>] ? audit_filter_syscall+0xcc/0xed
Mar 28 11:58:28 localhost kernel: [<c0474b2f>] ? audit_filter_syscall+0xe0/0xed
Mar 28 11:58:28 localhost kernel: [<c0475cee>] ? audit_syscall_entry+0x163/0x185
Mar 28 11:58:28 localhost kernel: [<c04bf23a>] sys_ioctl+0x46/0x66
Mar 28 11:58:28 localhost kernel: [<c04094eb>] sysenter_do_call+0x12/0x3f
Comment 8 Kjartan Maraas 2009-05-07 08:59:07 EDT
Tried with today's kernel from rawhide and still see the same issue. I don't have any backtraces from i915 in my syslog so that doesn't look like the issue here?
Comment 9 Kjartan Maraas 2009-05-15 07:45:13 EDT
Tried again with the 2.6.29.3-140.fc11.i686.PAE kernel and it still behaves the same. I'm back with 'maxcpus=1' for now. When I tried to shut down it got stuck halfways through and ended up spewing something about a soft lockup which didn't make it into the logs.
Comment 10 Adam Williamson 2009-06-01 15:10:34 EDT
we had quite a few cases of the circular locking dependency in i915 during f11 cycle...I'm not sure we ever pinned down exactly what was causing it or whether _it_ actually caused the problems it was observed in association with (which all tended to be different...)

here's one bug for e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=488633

be nice if kristian has any ideas here...
Comment 11 Kjartan Maraas 2009-06-02 15:17:59 EDT
Got a new hang like this with the current -167 kernel today. It happened after quitting a game and pressing ctrl+d to close the terminal tab where I had opened the game - angband a rouge like text based adventure game...
Comment 12 Kjartan Maraas 2009-06-02 16:00:38 EDT
Here's the lspci data for the graphics controller if that helps:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 30ad
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f4600000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 4000 [size=8]
        Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at f4680000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915
Comment 13 Adam Williamson 2009-06-03 16:33:06 EDT
'lspci -nn' is usually the most useful output, as it gives us the actual PCI ID.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Kjartan Maraas 2009-06-04 03:38:04 EDT
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 01)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 01)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 [8086:27d6] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.2 SATA controller [0106]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller [8086:27c5] (rev 01)
02:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
04:06.0 CardBus bridge [0607]: Texas Instruments PCIxx12 Cardbus Controller [104c:8039]
04:06.2 Mass storage controller [0180]: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD) [104c:803b]
04:06.3 SD Host controller [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller [104c:803c]
04:06.4 Communication controller [0780]: Texas Instruments PCIxx12 GemCore based SmartCard controller [104c:803d]
Comment 15 Bug Zapper 2009-06-09 08:45:54 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Kjartan Maraas 2009-07-27 12:13:42 EDT
Still seeing this in rawhide from a couple of days ago.
Comment 17 Kjartan Maraas 2009-08-09 05:40:56 EDT
I still have to pass maxcpus=1 on the boot command line here to get a working system. Last time I tried without it hung while booting halfways through filling in the fedora logo on the boot splash. Anything else I can do to get more info?
Comment 18 Adam Williamson 2009-08-10 13:56:20 EDT
I don't know of any. The devs likely haven't worked their way around to this bug yet :(

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 19 Kjartan Maraas 2009-08-13 10:18:25 EDT
Created attachment 357326 [details]
output from sysrq-t + sysrq-w
Comment 20 Kjartan Maraas 2009-08-13 10:22:15 EDT
Still seeing this with today's kernel from rawhide. Same thing happens - evolution freezes first and ends up in D state and after a while the whole system freezes.
Comment 21 Kjartan Maraas 2009-08-27 07:25:30 EDT
This happened today again. This time I ended up with terminals and console logins hanging when I typed commands and eventually I got a soft lockup but somehow the trace didn't make it to the syslog...

Also, booting with nomodeset fails and just stops with a black screen when it's supposed to be starting X.
Comment 22 Kjartan Maraas 2009-09-02 08:08:11 EDT
I tried reinstalling my laptop from scratch and saw the same problem in F11. After yum updating to rawhide again it still persists. I reformatted the harddisk and switched from ext3 to ext4 in the process so there shouldn't be any old cruft left at least.
Comment 23 Kjartan Maraas 2009-09-10 07:47:41 EDT
Still seeing this with current rawhide versions of the kernel/intel driver/Xorg
Comment 24 Ralf Ertzinger 2009-09-15 06:49:18 EDT
FWIW, I do _not_ see this on three machines, all running some version of the G45 chipset (two running F11, one running rawhide)
Comment 25 Ralf Ertzinger 2009-09-15 06:50:21 EDT
All use KMS, all have multiple CPUs (Core2Duos, in 32 and 64 bit, but actual 3D is hardly, if ever used.
Comment 26 Kjartan Maraas 2009-09-16 02:37:53 EDT
Filed a bug upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=23969
Comment 27 Kjartan Maraas 2009-09-23 13:20:20 EDT
Looks like this should be attributed to evolution and possibly some part of the kernel after all and not intel/KMS. Renaming this back to the original subject of evolution hanging in uninterruptible sleep state and grinding the machine to a halt. I've got dmesg output from when this happens now :-)
Comment 28 Kjartan Maraas 2009-09-23 13:23:00 EDT
Created attachment 362332 [details]
dmesg output with a lot of backtraces from the kernel

This has a lot of backtraces showing evolution exceeding the hung task timeout by blocking for more than 120 seconds
Comment 29 Kjartan Maraas 2009-09-23 13:24:18 EDT
The important part:

PM: resume devices took 2.579 seconds
PM: Finishing wakeup.
Restarting tasks ... done.
usb 2-1: reset full speed USB device using uhci_hcd and address 2
[drm] TV-16: set mode NTSC 480i 0
btusb 2-1:1.0: no reset_resume for driver btusb?
btusb 2-1:1.1: no reset_resume for driver btusb?
[drm] TV-16: set mode NTSC 480i 0
usb 3-1: reset full speed USB device using uhci_hcd and address 2
tg3 0000:08:00.0: wake-up capability disabled by ACPI
tg3 0000:08:00.0: PME# disabled
tg3 0000:08:00.0: irq 29 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc
Registered led device: iwl-phy0::RX
Registered led device: iwl-phy0::TX
ADDRCONF(NETDEV_UP): wlan0: link is not ready
psmouse serio5: ID: 10 00 64
wlan0: authenticate with AP 00:0d:54:f7:4d:9c
wlan0: authenticated
wlan0: associate with AP 00:0d:54:f7:4d:9c
wlan0: RX AssocResp from 00:0d:54:f7:4d:9c (capab=0x431 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
INFO: task evolution:16847 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
evolution     D e78fc140  4992 16847      1 0x00000080
 e7979e64 00200082 68583c9f e78fc140 e78fc3dc c0b153c0 c0c5a020 e78fc3dc
 e78fc680 c0c5a020 c0c5a020 c0839db5 c0de0d08 00000110 00000000 2906ae9f
 000008a7 c4c0a020 e78fc140 00000000 68583c9f 00200046 00000000 68583c9f
Call Trace:
 [<c0839db5>] ? wait_for_common+0x41/0xfc
 [<c083a02c>] schedule_timeout+0x27/0xbf
 [<c040f6e1>] ? sched_clock+0x9/0xd
 [<c083bbd9>] ? _spin_unlock_irq+0x35/0x50
 [<c0477ab5>] ? trace_hardirqs_on_caller+0x122/0x155
 [<c0477b01>] ? trace_hardirqs_on+0x19/0x2c
 [<c0839e21>] wait_for_common+0xad/0xfc
 [<c0447426>] ? default_wake_function+0x0/0x35
 [<c0839f84>] wait_for_completion+0x26/0x39
 [<c0460b39>] flush_work+0xb6/0xd8
 [<c04606d0>] ? wq_barrier_func+0x0/0x32
 [<c0839db5>] ? wait_for_common+0x41/0xfc
 [<c0460f4c>] schedule_on_each_cpu+0xb0/0xef
 [<c04d361e>] ? lru_add_drain_per_cpu+0x0/0x2e
 [<c04d3406>] lru_add_drain_all+0x20/0x33
 [<c04e530c>] sys_mlock+0x34/0xdb
 [<c04099cb>] sysenter_do_call+0x12/0x38
no locks held by evolution/16847.
Comment 30 Chuck Ebbert 2009-09-24 10:15:43 EDT
Does this happen regardless of whether you suspend and resume the system?
Comment 31 Kjartan Maraas 2009-09-24 15:45:09 EDT
I've been battling two different hangs now I realize so I'm actually not 100% sure. Looking at the logs I have both cases seem to have been after suspend/resume, so we have to assume that s+r plays a part in this...
Comment 32 Kjartan Maraas 2009-09-29 05:50:44 EDT
Similar hangs have been mentioned on the linux-kernel mailing list and there's a suggested solution somewhere in the tty layer. According to Alan Cox there's no TTY maintainer though so we shouldn't hold our breath I guess.

Maybe someone ought to implement the suggested fix and see if it helps?

I can probably dig up the mail where Linus described what he thought would do the trick...
Comment 34 Kjartan Maraas 2009-10-05 05:14:42 EDT
Looks like the fix for that TTY related problem was released in 2.6.32-rc3 today. I've built a local kernel with that fix, but since suspend/resume stopped working for me I can't really test whether the fix is good :-/
Comment 35 Kjartan Maraas 2009-10-05 05:17:51 EDT
Btw, wrt the hangs I see these in my syslog that might be related:
messages:Oct  5 00:31:03 localhost kernel: npviewer.bin[2285]: segfault at b787e000 ip 00c4062c sp aeafde7c error 6 in libc-2.10.90.so[bc6000+176000]
messages-20091004:Sep 28 08:43:47 localhost kernel: readahead[344]: segfault at 0 ip 00810350 sp bf9e0f38 error 4 in libc-2.10.90.so[797000+176000]
messages-20091004:Sep 30 09:16:23 localhost kernel: readahead[335]: segfault at 0 ip 00810350 sp bf9251d8 error 4 in libc-2.10.90.so[797000+176000]
messages-20091004:Sep 30 14:27:33 localhost kernel: npviewer.bin[26551]: segfault at ff99cd48 ip ff99cd48 sp bfe4e82c error 14
messages-20091004:Oct  1 13:22:40 localhost kernel: readahead[352]: segfault at 0 ip 00c3f350 sp bf9873d8 error 4 in libc-2.10.90.so[bc6000+176000]
messages-20091004:Oct  2 15:31:27 localhost kernel: readahead[323]: segfault at 0 ip 00c3f350 sp bfcd51b8 error 4 in libc-2.10.90.so[bc6000+176000]
messages-20091004:Oct  2 20:42:49 localhost kernel: readahead[330]: segfault at 0 ip 00c3f350 sp bfc62a68 error 4 in libc-2.10.90.so[bc6000+176000]
messages-20091004:Oct  4 02:07:59 localhost kernel: npviewer.bin[2887]: segfault at ff99cd48 ip ff99cd48 sp bfff7fbc error 14
Comment 36 Kjartan Maraas 2009-10-11 06:20:33 EDT
Now that I've gotten suspend/resume to work I can continue checking whether evolution will behave itself. I have a suspicion that this is tightly coupled to the xorg intel driver related hangs I've reported upstream.

There was someone else confirming the same problem there so maybe we can get to the bottom of that there.
Comment 37 Bug Zapper 2009-11-16 04:53:07 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 38 melondrift 2010-04-02 19:09:36 EDT
Have a similar issue.  I do not have a problem with the OS going to minimal-sleep-mode and back.  Computers have had a long term problem with going into and returning from "deep-sleep-mode", so I avoid it like the plague.

Still, evolution hangs while in minimal-sleep-mode when it attempts to retrieve mail on the re-bound.

Should I attempt anything from prompt the next time this happens?  I am able to issue a few commands before the entire system locks up without committing a force quit to evolution.  Yes, when evolution fails, I have to force quit the app before the entire system seizes.

Melon
Comment 39 melondrift 2010-04-02 19:12:56 EDT
(In reply to comment #38)

You'll love this, I just thought of something.  Is there a way to tell the Evolution app to wait a minute after resume from sleep before it tries to fetch mail?

Melon
Comment 40 Bug Zapper 2010-11-04 07:24:39 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 41 Bug Zapper 2010-12-05 01:58:16 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.