Bug 597778

This has happened to me also.  Also nothing in the log files at the time it happened.  Had woken up from suspend perhaps 15-20 minutes prior to this event.  Not sure if this happens only after being suspended, but will check into it.

Smolt profile:  uuid=pub_f55b7281-e0b9-4e98-a688-2ea63e825672

Also had this happen more frequently under FC12.  Since I had recently purchesed this, I just waited and installed FC13 a few days later.

This has been fairly consistent after resuming from suspend.  I've also had it do this after a rebooting from an event (ssh login then "reboot").

I've also gotten a kernel crash notice when resuming.

From ABRT:

WARNING: at fs/fs-writeback.c:597 writeback_inodes_wb+0x202/0x30e()
Hardware name: A5000
Modules linked in: nls_utf8 udf vfat fat crc_itu_t fuse sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel arc4 snd_hda_codec snd_hwdep snd_seq snd_seq_device ecb ath9k ath9k_common snd_pcm mac80211 ath9k_hw ath uvcvideo videodev v4l1_compat cfg80211 forcedeth snd_timer snd rfkill i2c_nforce2 soundcore microcode snd_page_alloc wmi usb_storage nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: scsi_wait_scan]
Pid: 14105, comm: flush-253:2 Not tainted 2.6.33.4-95.fc13.i686.PAE #1
Call Trace:
[<c043d629>] warn_slowpath_common+0x65/0x7c
[<c04e6dd9>] ? writeback_inodes_wb+0x202/0x30e
[<c043d64d>] warn_slowpath_null+0xd/0x10
[<c04e6dd9>] writeback_inodes_wb+0x202/0x30e
[<c04e6fe8>] wb_writeback+0x103/0x162
[<c0482e6d>] ? call_rcu+0x8/0xa
[<c04e70c4>] ? wb_clear_pending+0x6a/0x6f
[<c04e712e>] wb_do_writeback+0x65/0x128
[<c04e7219>] bdi_writeback_task+0x28/0x84
[<c04b0aed>] ? bdi_start_fn+0x0/0xa3
[<c04b0b42>] bdi_start_fn+0x55/0xa3
[<c04b0aed>] ? bdi_start_fn+0x0/0xa3
[<c045271f>] kthread+0x5f/0x64
[<c04526c0>] ? kthread+0x0/0x64
[<c0408dfe>] kernel_thread_helper+0x6/0x10

This appears to be a duplicate bug of bug 528312.

(In reply to comment #3)
> This appears to be a duplicate bug of bug 528312.    

Does the computer gets it acts together in a minute or two? What's your graphic adapter.

(In reply to comment #0)
> Xorg just started to use 100% CPU without touching the computer at all. There
> is nothing in /var/log/messages or /var/log/Xorg.0.log around the time that is
> started to use CPU.

Why do you think it is Xorg? The backtrace in the comment 2 doesn't look like from graphic drivers.

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

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.

Created attachment 418743 [details]
xorg.conf in use when X exhibited the behavior described in comment #0

(In reply to comment #5)
> (In reply to comment #0)
> > Xorg just started to use 100% CPU without touching the computer at all. There
> > is nothing in /var/log/messages or /var/log/Xorg.0.log around the time that is
> > started to use CPU.
> 
> Why do you think it is Xorg? The backtrace in the comment 2 doesn't look like
> from graphic drivers.

Comment 2 wasn't from me.

I think it was Xorg because the X process was using 100% cpu. Even restarting X with ctrl+alt+bksp didn't fix it (and I did verify that it was a new instance of X with a new start time after the ctrl+alt+bksp). 


> Please add drm.debug=0x04 to the kernel command line, restart computer, and
> attach
> 
> * your X server config file (/etc/X11/xorg.conf, if available),
> * X server log file (/var/log/Xorg.*.log)
> * output of the dmesg command, and
> * system log (/var/log/messages)

I have attached xorg.conf

I have yet to reproduce this bug, but will report when I have. One suspend/resume cycle hasn't produced the behavior I was seeing before.

(In reply to comment #5)
> (In reply to comment #0)
> > Xorg just started to use 100% CPU without touching the computer at all. There
> > is nothing in /var/log/messages or /var/log/Xorg.0.log around the time that is
> > started to use CPU.
> 
> Why do you think it is Xorg? The backtrace in the comment 2 doesn't look like
> from graphic drivers.
> 
> Please add drm.debug=0x04 to the kernel command line, restart computer, and
> attach
> 
> * your X server config file (/etc/X11/xorg.conf, if available),
> * X server log file (/var/log/Xorg.*.log)
> * output of the dmesg command, and
> * system log (/var/log/messages)
> 
> 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.    

I logged in via ssh and ran top.  It reported Xorg as using 98% of the CPU.  The backtrace I included above was from a kernel crash that happened a bit before Xorg started using all of the cpu.  I'm not sure if it's directly related or not.

I've let the computer run for a while in this state and it does not go back to normal.  The graphics adapter is an nVidia C79 (GeForce 9200M G).

Just as I posted that last comment, about a minute or two later X started to use 100% CPU again. The system was up for approximately 1 hour 20 minutes. A pm-suspend /resume cycle was done about 5 minutes after boot.

Graphics is an S3 SuperSavage IXC:

01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) (prog-if 00 [VGA controller])
        Subsystem: IBM ThinkPad T23
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
        Memory at c0100000 (32-bit, non-prefetchable) [size=512K]
        Memory at e8000000 (32-bit, prefetchable) [size=64M]
        Memory at e4000000 (32-bit, prefetchable) [size=64M]
        Memory at e0000000 (32-bit, prefetchable) [size=32M]
        [virtual] Expansion ROM at e2000000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [80] AGP version 2.0
        Kernel modules: savagefb

First time this happened, I let the system sit for an hour and it never recovered. It's been sitting for about 10 minutes now and it's still using up all cpu.

Created attachment 418762 [details]
log file after X starts to use 100% CPU

Created attachment 418764 [details]
dmesg after X starts using 100% cpu

Created attachment 418765 [details]
/var/log/messages after X starts to use 100% cpu

One more update. System has been up for ~45 minutes and X is again using 100% CPU with nothing else running (that would be using any display cycles). This is without a suspend/resume cycle, so I think we can rule that out as a cause.

There is absolutely nothing different in any of the logs or dmesg output from before.

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

(In reply to comment #14)
> *** Bug 597780 has been marked as a duplicate of this bug. ***    

Also after this happens, it is not possible anymore to switch to VT2. Xorg.0.log then contains error messages like

[  8450.434] Failed to switch from vt01 to vt03: Input/output error
[  8453.789] Failed to switch from vt01 to vt06: Input/output error

Xorg has been stable for me for the last couple of weeks. Either this is just spite, or some recent update to something fixed whatever it was.

Now running:
kernel-PAE-2.6.33.5-112.fc13.i686
xorg-x11-server-Xorg-1.8.0-12.fc13.i686

I will report back if I see this happend again.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.