Hi I've filed 6853286 for this. It doesn't contain a stack backtrace, but it does contain a truss for the gnome application. The truss shows hundreds of port_getn() event notifications received (several batches of 64 events). This is followed by lots of stat() checks for monitored files, followed by port_associate() calls.
There also is a dtrace script and dtrace script output included that should show that file time attributes have changed in the sub-microsecond part, and this should result in the file event notification events. Btw. I also had the problem with the flashing start menu. It's the same root cause. gnome panel is receiving lots of file attribute change notifications and is rescanning and rebuilding the menu entries over and over again. 2009/6/22 Darren Kenny <Darren.Kenny at sun.com>: > Hi Rod / J?rgen, > > Looks like you are both seeing the same issue here... > > On 20/06/2009 09:30, J?rgen Keil wrote: >> I'm not 100% sure what exactly is broken, but since a day or two (after I >> bfu'ed my system >> from current onnv-gate sources), the idle gnome desktop has started to >> consume *lots* of >> cpu time. ?The system is a SX:CE snv_111, bfu'ed with current onnv-gate bits. >> I've never noticed such a problem with bfu of older onnv-gate bits (onnv >> before 2009-6-16). >> >> I see several gnome processes (gnome-settings-daemon, nautilus, gnome-panel) >> each trying >> to consume 100% cpu time; the processes perform stat system calls all over >> the place >> (e.g. in /etc/xdg/, my home directory, ~/.local/, ...), and they are reading >> /etc/mnttab >> quite often. >> >> >> Looking through the change log for the last 2-3 days I noticed the putback >> for bug 6539657 >> "touch(1) does not set the nanosecond timestamp of a file correctly". >> >> >> When I disable the stat microsecond workaround[*] that was added to the >> kernel with the >> putback for 6539657, the gnome desktop returns to sane behaviour; the idle >> gnome desktop >> does not consume lots of cpu time any more. >> > > That's good to know... > >> >> I suspect that gnome is detecting bogus file system changes and is >> re-scanning start menu >> entries, folder contents, local setting files, etc. > > Yes, that is likely to be the case. > >> >> Can anyone else reproduce this? ?Is this a known problem? >> > > I'm afraid I've not seen it, but we are using the GAMIN, to monitor file > changes, and this is using the File Event Mechanism in solaris which is > similar > to inotify on Linux - so from what you're seeing it would seem that events are > being fired at that level first. which then triggers GAMIN, and then the GNOME > apps to react. > > It would probably be very useful to get some stack traces from the offending > processes to see if this can confirm where it's all happening. Also, take a > look > at the gam_server process which is the one monitoring using FEN and > dispatching > events over D-Bus. > > Darren. > > > > > ---------- Weitergeleitete Nachricht ---------- > From:?Rod Evans <Rod.Evans at Sun.COM> > To:?desktop-discuss at opensolaris.org > Date:?Fri, 19 Jun 2009 14:12:00 -0700 > Subject:?[desktop-discuss] gnome-setting > For some reason, starting some time last night, this process has been > going nuts on my desktop, taking significant cpu cycles: > > ?2551 rie ? ? ? ?84M ? 20M cpu1 ? ?40 ? ?0 ? 0:02:23 ?25% gnome-settings-/2 > > I kill it and it restarts pretty much the same. > > In concert I have nautilus going nuts too: > > ? 2560 rie ? ? ? 212M ? 89M cpu2 ? ?59 ? ?0 ? 0:01:23 ?13% nautilus/5 > > and this is thrashing my home directory server with stat's of my home > directory. > > I've tried pulling up my application control panel - where you start > FireFox/Thunderbird etc. ?but this just keeps flashing and won't let me > select anything, or drill down to a sub-menu. > > I even tried removing .gnome .gnome2 .gconf .gconfd .metacity. > > I have truss output of gnome-settings and nautilus if anyone is interested, > but my primary desire is to get these processes to go to sleep. > > Any advise? > > -- > > Rod. > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org > >
