Description of problem:high cpu usage of gvfs-gdu-volume-monitor over than 20%. in my laptop msi-gx623 this process eat over than 20% of cpu time.and sometime it is go to eat 90% of cpu time and cause system to be crashed. it is my cpu usage of gvfs-gdu-volume process: 18315 mahdi 20 0 66436 26m 2752 R 95.9 0.7 10:44.27 gvfs-gdu-volume Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I see this on F14 too, and with one instance per logged-in user, this is a real CPU hog. Tasks: 645 total, 4 running, 641 sleeping, 0 stopped, 0 zombie Cpu(s): 41.3%us, 3.6%sy, 0.0%ni, 54.7%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 12328580k total, 10130464k used, 2198116k free, 562460k buffers Swap: 8388600k total, 772512k used, 7616088k free, 1563356k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3002 helen 20 0 365m 216m 2148 R 99.8 1.8 347:45.69 gvfs-gdu-volume 4767 paul 20 0 365m 214m 1972 R 99.8 1.8 353:51.09 gvfs-gdu-volume 31796 bingning 20 0 366m 216m 2144 R 99.8 1.8 347:46.67 gvfs-gdu-volume 5473 qemu 20 0 1315m 975m 1456 S 22.7 8.1 1105:36 qemu-kvm 7956 paul 20 0 1432m 345m 17m S 20.8 2.9 521:43.40 firefox 5498 qemu 20 0 3377m 2.5g 1516 S 17.1 21.5 1799:26 qemu-kvm 4395 root 20 0 188m 31m 12m S 3.3 0.3 89:22.09 Xorg 168 root 15 -5 0 0 0 S 2.0 0.0 29:11.60 kslowd000 4259 root 20 0 591m 10m 2044 S 1.3 0.1 108:00.46 libvirtd 5115 paul 20 0 448m 6056 3940 S 1.3 0.0 156:35.79 multiload-apple 31745 bingning 20 0 675m 28m 3996 S 1.3 0.2 4:11.60 gnome-settings- 2955 helen 20 0 534m 13m 3772 S 1.0 0.1 1:27.87 gnome-settings- 4700 paul 20 0 551m 29m 3628 S 1.0 0.2 5:45.34 gnome-settings- 5169 paul 20 0 548m 14m 5696 S 0.7 0.1 9:14.50 gnome-terminal 19369 paul 20 0 15576 1592 868 R 0.7 0.0 0:00.19 top
Can you please grab backtraces of those processes? http://fedoraproject.org/wiki/StackTraces
I killed them for now but I'm sure they'll show up again in the next few days so I'll grab traces then.
(In reply to comment #3) > I killed them for now but I'm sure they'll show up again in the next few days > so I'll grab traces then. Usually this happens when udisks daemon is not running or with system dbus issues.
i install fedora 14 and problem is solved
(In reply to comment #4) > (In reply to comment #3) > > I killed them for now but I'm sure they'll show up again in the next few days > > so I'll grab traces then. > Usually this happens when udisks daemon is not running or with system dbus > issues. udisks is running here; any other tell-tale signs of system dbus issues? (In reply to comment #5) > i install fedora 14 and problem is solved Not for me it isn't (see Comment #1).
Created attachment 462286 [details] Stack trace from CPU-eating process Here's a stack trace from gvfs-gdu-volume-monitor currently gobbling up CPU on my machine. I think this behaviour started in the last 24 hours and might be related to burning a DVD, which I did yesterday. The written DVD has since been ejected. $ top -n 1 | head top - 09:50:14 up 13 days, 18:05, 13 users, load average: 3.73, 3.66, 3.37 Tasks: 665 total, 5 running, 660 sleeping, 0 stopped, 0 zombie Cpu(s): 3.8%us, 2.4%sy, 0.0%ni, 93.0%id, 0.8%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 12328580k total, 12112812k used, 215768k free, 469188k buffers Swap: 8388600k total, 1209640k used, 7178960k free, 3977424k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17921 paul 20 0 370m 220m 1636 R 95.4 1.8 340:52.76 gvfs-gdu-volume 25302 bingning 20 0 372m 222m 1616 R 95.4 1.8 343:43.35 gvfs-gdu-volume 7467 root 20 0 241m 11m 4804 R 18.7 0.1 0:00.11 yum
I now believe that this issue is triggered on my system when /etc/cron.weekly/99-raid-check runs (I have a bunch of RAID1 arrays). Every Tuesday when I get up, each gvfs-gdu-volume process is pegged at nearly 100% and I have to kill them all to quieten everything down (literally - the fans are running full speed to keep the CPUs cool). I just then tried running /etc/cron.weekly/99-raid-check manually this morning and the one gvfs-gdu-volume process running as a result of my son logging in this morning went to nearly 100% straight away.
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
Still happens with Fedora 14.
Still happens with Fedora 15.
Seeing this in rawhide
gvfs-gdu-volume eats CPU when a RAID resync happens too, as I found out this morning after replacing a drive.
I experience this bug in Fedora 16 x86_64, adjusting release and platform.
while I do use RAID, my disks are currently not in resync $ cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [raid1] md1 : active raid5 sda2[0] sdb2[1] sdc2[3] 1952494592 blocks super 1.1 level 5, 512k chunk, algorithm 2 [3/3] [UUU] bitmap: 2/8 pages [8KB], 65536KB chunk md0 : active raid1 sda1[0] sdb1[1] sdc1[2] 511988 blocks super 1.0 [3/3] [UUU] unused devices: <none>
I'm on RHEL 6.2, and I just used Rhythmbox for the first time on this machine to rip a CD to ogg. Coincidentally, today is the first day I've ever had this problem. I can't say they are related, but the timing is within minutes of each other. Now that I've ejected the disk, udevd is now taking up CPU time. I'll log out and log back in to see if that helps.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.