I was still busy today with the #766943 so I've only had limited time for this.
What I just tried now was re-enabling openafs-client,... rebooting and then opening these images/text again. The issue doesn't re-appear as extreme as it did last time (where the system froze for 30s-1m)... but even now it still happens,... e.g. I open an image.... then I see that the change from the clock applet from one to the next second takes too long (roughly 2 secs than 1)... but it continues counting for 3-5 seconds then and then it jumps over one second (i.e. the one that was lost). The same happens again reproducibly with eog, evince, gedit and friends.... Since I suspsect gvfs is somehow involved, I've tried killing it, but as soon as I start eog/evince/etc, a new gvfsd is spawned (any way to prevent this?) Next (with a gvfsd running again) I've umounted /afs... after that, no delay in the clock occurs anymore, when I start eog/evince/etc. So wildly guessing,... gvfs or something like that tries to be smart and listens/polls/queries on places where it shouldn't (in this case AFS)... when something goes wrong there,... gvfs freezes,... and this in turn lead eog/cinnamon and friends to freeze? Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
