Re: Hanging plasmashell
Sandro Knauß - 15.06.18, 12:59: > You will find a solution in using KIO, as it was one of the design > goals of KIO to keep applications reactive, when a server breaks > away. KIO solves this by set up a connection only when > reading/writing is needed. In contrast to fusefs that simulate a > "normal filesystem", so you will face the hanging plasmashell also > for sshfs or samba... But I have no more deeper insight in KIO, so I > can't give good links... Yes. I read about some Plasma / KDE developers wanting to go FUSE way tough, cause KIO is Plasma/KDE only and other applications like LibreOffice do not understand it. In the end it is all about non blocking I/O on network filesystems. Also: Is there an NFS kio slave? I think there is only a CIFS one. In addition to File in shell (fish://) or SFTP (sftp://) and all the other non traditional network filesystem ones. Thanks, -- Martin
Re: Hanging plasmashell
Alex DEKKER - 14.06.18, 23:46: > On 13/06/18 15:55, Jiri Kanicky wrote: > > Any mounted system which looses connection will completely hang > > plasmashell. > > > > For example I mount NFS, close lid and take laptop to work and when > > I > > open it plasmashell is hanged. > > I haven't had this setup for a while but when I had an NFS export > mounted on /home/alex/alex_on_server/ I found a fix for the hanging > was to mount it one step away from ~/, ie /home/alex/server/alex/ > which meant I was less likely to trip over this problem. Yes. Thats why I stuffed all network filesystems under a directory like /mnt/ network/ instead of directly into /mnt. Thanks, -- Martin
Re: Hanging plasmashell
Hey, You will find a solution in using KIO, as it was one of the design goals of KIO to keep applications reactive, when a server breaks away. KIO solves this by set up a connection only when reading/writing is needed. In contrast to fusefs that simulate a "normal filesystem", so you will face the hanging plasmashell also for sshfs or samba... But I have no more deeper insight in KIO, so I can't give good links... hefee On Mittwoch, 13. Juni 2018 20:20:07 CEST Martin Steigerwald wrote: > Jiri Kanicky - 13.06.18, 16:55: > > Any mounted system which looses connection will completely hang > > plasmashell. > > > > For example I mount NFS, close lid and take laptop to work and when I > > open it plasmashell is hanged. > > > > This has been issue for ages. > > Any process which accesses a file from an NFS mount with the > corresponding NFS server not reachable will by default hang for as long > as the NFS server is not reachable. > > This is how Linux filesystems work. Read accesses are usually in-process > and applications waiting for those to be fulfilled will hang unless they > use asynchronous (out of process) I/O. > > The only way around would be to do all separate all filesystem accesses > and the GUI painting into different threads or processes or use > asynchronous I/O with its complexities in error handling everywhere. > This has not been done for Plasma and I doubt it has been done for any > other major desktop environment for Linux. > > Of course for the plasmashell process itself the question would be: Why > does it access the NFS mount anyway? Do you have some widget in the > plasmashell that accesses anything from the NFS mount? If so, you would > have to remove it. Most widgets run inside the plasmashell process. This > indeed is a limitation of Plasma as it mostly has a all in one process > architecture. Only KRunner and KWin window manager are separate. Most > KRunner runners run in process… but there has been some work to > background some costly operations recently if I remember correctly. > > If plasmashell accesses the NFS mount while it would have no reason to… > then that would be something for a upstream bug report. > > I always thought a multi-process / multi-threading architecture for the > desktop would be more suitable – especially in order to make Plasmashell > more crash resistant with buggy widgets –, but according to what I > remember what Plasma developers said, it is challenging to obtain an > integrated graphical experience this way. I do not remember the details > tough. I think I opened an upstream bug report years ago about this. > Plasmashell uses some threads, but it does not appear that it uses > different threads for filesystem accesses of widgets and so on. > > Differently on AmigaOS. Even if the whole operating system filesystem > was gone (i.e. by just killing the filesystem and device tasks for it > which you could just do on AmigaOS as it is single user without memory > protection, at least upto AmigaOS 3.x) the GUI was still responsive. At > least those parts of the GUI that did not access the filesystem. And > once running the GUI did not do many filesystem accesses anymore unless > you triggered some. > > So in summary: In order to achieve a responsive desktop with an > unreachable NFS you´d either have to completely rewrite the architecture > of the current Plasma desktop… or change the way the Linux kernel I/O > subsystems works (and alongside of it probably also all the applications > that use it). I´d really love to see a desktop that is always > responsive. But so far I think sadly no integrated desktop environment > with the functionality like Plasma has on Linux or any other Unix > operating system is even close to that. > > There is still something to be learned from operating system and GUI > approaches of other operating systems like AmigaOS. > > Thanks, signature.asc Description: This is a digitally signed message part.
Re: Hanging plasmashell
On 13/06/18 15:55, Jiri Kanicky wrote: Any mounted system which looses connection will completely hang plasmashell. For example I mount NFS, close lid and take laptop to work and when I open it plasmashell is hanged. I haven't had this setup for a while but when I had an NFS export mounted on /home/alex/alex_on_server/ I found a fix for the hanging was to mount it one step away from ~/, ie /home/alex/server/alex/ which meant I was less likely to trip over this problem. alexd
Re: Hanging plasmashell
On Thu, Jun 14, 2018 at 09:11:40PM +0200, Martin Steigerwald wrote: > Jiri Kanicky - 14.06.18, 16:50: > > Whatever you say does not make it right. If network is lost and you > > have remote filesystems mounted, apps should keep working including > > plasmashell. > > I did not say anything about right or wrong. > > And I think I expressed that I do not really agree with this design > either. > > Anyway, this is not about right or wrong anyway. > > Thanks. > -- > Martin > > In my experience NFS has never been good fit for roaming laptops. Even a force unmount before suspend hook doesn't solve this, and IIRC will fail because file descriptors are kept open and NFS does the safe thing. I've never trusted Windows' disconnected mapped drive support, so have never tested it. Does sshfs or syncthing work for your usecase? I haven't been able to hang plasmashell when the ssh server disappears due to changing networks/locations. Ideally I think that it would be neat if KDE could use something like a combination of sshfs with a fuse overlayfs to handle writes to an upper region when disconnected, and then sync then back to the lower region (on the SSH server) once the correct network returns. Easier than learning about Coda FS which was designed for this ;-) Cheers, Nicholas signature.asc Description: PGP signature
Re: Hanging plasmashell
Jiri Kanicky - 14.06.18, 16:50: > Whatever you say does not make it right. If network is lost and you > have remote filesystems mounted, apps should keep working including > plasmashell. I did not say anything about right or wrong. And I think I expressed that I do not really agree with this design either. Anyway, this is not about right or wrong anyway. Thanks. -- Martin
Re: Hanging plasmashell
Hi, Whatever you say does not make it right. If network is lost and you have remote filesystems mounted, apps should keep working including plasmashell. I don't see a reason why menu and panel should hang if NFS is not accessible. If it so its just bad design. Windows does not hang either if you loose access to cifs share. -J On 14/06/18 04:20, Martin Steigerwald wrote: Jiri Kanicky - 13.06.18, 16:55: Any mounted system which looses connection will completely hang plasmashell. For example I mount NFS, close lid and take laptop to work and when I open it plasmashell is hanged. This has been issue for ages. Any process which accesses a file from an NFS mount with the corresponding NFS server not reachable will by default hang for as long as the NFS server is not reachable. This is how Linux filesystems work. Read accesses are usually in-process and applications waiting for those to be fulfilled will hang unless they use asynchronous (out of process) I/O. The only way around would be to do all separate all filesystem accesses and the GUI painting into different threads or processes or use asynchronous I/O with its complexities in error handling everywhere. This has not been done for Plasma and I doubt it has been done for any other major desktop environment for Linux. Of course for the plasmashell process itself the question would be: Why does it access the NFS mount anyway? Do you have some widget in the plasmashell that accesses anything from the NFS mount? If so, you would have to remove it. Most widgets run inside the plasmashell process. This indeed is a limitation of Plasma as it mostly has a all in one process architecture. Only KRunner and KWin window manager are separate. Most KRunner runners run in process… but there has been some work to background some costly operations recently if I remember correctly. If plasmashell accesses the NFS mount while it would have no reason to… then that would be something for a upstream bug report. I always thought a multi-process / multi-threading architecture for the desktop would be more suitable – especially in order to make Plasmashell more crash resistant with buggy widgets –, but according to what I remember what Plasma developers said, it is challenging to obtain an integrated graphical experience this way. I do not remember the details tough. I think I opened an upstream bug report years ago about this. Plasmashell uses some threads, but it does not appear that it uses different threads for filesystem accesses of widgets and so on. Differently on AmigaOS. Even if the whole operating system filesystem was gone (i.e. by just killing the filesystem and device tasks for it which you could just do on AmigaOS as it is single user without memory protection, at least upto AmigaOS 3.x) the GUI was still responsive. At least those parts of the GUI that did not access the filesystem. And once running the GUI did not do many filesystem accesses anymore unless you triggered some. So in summary: In order to achieve a responsive desktop with an unreachable NFS you´d either have to completely rewrite the architecture of the current Plasma desktop… or change the way the Linux kernel I/O subsystems works (and alongside of it probably also all the applications that use it). I´d really love to see a desktop that is always responsive. But so far I think sadly no integrated desktop environment with the functionality like Plasma has on Linux or any other Unix operating system is even close to that. There is still something to be learned from operating system and GUI approaches of other operating systems like AmigaOS. Thanks,
Re: Hanging plasmashell
Le mercredi 13 juin 2018, 20:20:07 CEST Martin Steigerwald a écrit : > Jiri Kanicky - 13.06.18, 16:55: > > Any mounted system which looses connection will completely hang > > plasmashell. > > > > For example I mount NFS, close lid and take laptop to work and when I > > open it plasmashell is hanged. > > > > This has been issue for ages. > > Any process which accesses a file from an NFS mount with the > corresponding NFS server not reachable will by default hang for as long > as the NFS server is not reachable. > > This is how Linux filesystems work. Read accesses are usually in-process > and applications waiting for those to be fulfilled will hang unless they > use asynchronous (out of process) I/O. > > The only way around would be to do all separate all filesystem accesses > and the GUI painting into different threads or processes or use > asynchronous I/O with its complexities in error handling everywhere. > This has not been done for Plasma and I doubt it has been done for any > other major desktop environment for Linux. > > Of course for the plasmashell process itself the question would be: Why > does it access the NFS mount anyway? Do you have some widget in the > plasmashell that accesses anything from the NFS mount? If so, you would > have to remove it. Most widgets run inside the plasmashell process. This > indeed is a limitation of Plasma as it mostly has a all in one process > architecture. Only KRunner and KWin window manager are separate. Most > KRunner runners run in process… but there has been some work to > background some costly operations recently if I remember correctly. > > If plasmashell accesses the NFS mount while it would have no reason to… > then that would be something for a upstream bug report. I have exactly the same problem : No widget, Plasma hang because it try to access a NFS directory. For various reasons the NFS server is not answering. The KMenu hangs first, then Dolphin, then KRunner. What about on-demand user mount with x-systemd.automount option in /etc/fstab? I thought it would prevent Plasma hanging, but it looks like Plasma try to access it even if it's not yet mounted. > I always thought a multi-process / multi-threading architecture for the > desktop would be more suitable – especially in order to make Plasmashell > more crash resistant with buggy widgets –, but according to what I > remember what Plasma developers said, it is challenging to obtain an > integrated graphical experience this way. I do not remember the details > tough. I think I opened an upstream bug report years ago about this. > Plasmashell uses some threads, but it does not appear that it uses > different threads for filesystem accesses of widgets and so on. > > Differently on AmigaOS. Even if the whole operating system filesystem > was gone (i.e. by just killing the filesystem and device tasks for it > which you could just do on AmigaOS as it is single user without memory > protection, at least upto AmigaOS 3.x) the GUI was still responsive. At > least those parts of the GUI that did not access the filesystem. And > once running the GUI did not do many filesystem accesses anymore unless > you triggered some. > > So in summary: In order to achieve a responsive desktop with an > unreachable NFS you´d either have to completely rewrite the architecture > of the current Plasma desktop… or change the way the Linux kernel I/O > subsystems works (and alongside of it probably also all the applications > that use it). I´d really love to see a desktop that is always > responsive. But so far I think sadly no integrated desktop environment > with the functionality like Plasma has on Linux or any other Unix > operating system is even close to that. It works much better on Gnome . If the NFS server is not reachable, Nautilus opens very slowly, but except this, everything work. > > There is still something to be learned from operating system and GUI > approaches of other operating systems like AmigaOS. Amiga is still the Graal. Try Haiku, may be ... Regards, Xavier -- Librement, Xavier Brochard « La liberté est à l'homme ce que les ailes sont à l'oiseau » (Jean-Pierre Rosnay)
Re: Hanging plasmashell
Jiri Kanicky - 13.06.18, 16:55: > Any mounted system which looses connection will completely hang > plasmashell. > > For example I mount NFS, close lid and take laptop to work and when I > open it plasmashell is hanged. > > This has been issue for ages. Any process which accesses a file from an NFS mount with the corresponding NFS server not reachable will by default hang for as long as the NFS server is not reachable. This is how Linux filesystems work. Read accesses are usually in-process and applications waiting for those to be fulfilled will hang unless they use asynchronous (out of process) I/O. The only way around would be to do all separate all filesystem accesses and the GUI painting into different threads or processes or use asynchronous I/O with its complexities in error handling everywhere. This has not been done for Plasma and I doubt it has been done for any other major desktop environment for Linux. Of course for the plasmashell process itself the question would be: Why does it access the NFS mount anyway? Do you have some widget in the plasmashell that accesses anything from the NFS mount? If so, you would have to remove it. Most widgets run inside the plasmashell process. This indeed is a limitation of Plasma as it mostly has a all in one process architecture. Only KRunner and KWin window manager are separate. Most KRunner runners run in process… but there has been some work to background some costly operations recently if I remember correctly. If plasmashell accesses the NFS mount while it would have no reason to… then that would be something for a upstream bug report. I always thought a multi-process / multi-threading architecture for the desktop would be more suitable – especially in order to make Plasmashell more crash resistant with buggy widgets –, but according to what I remember what Plasma developers said, it is challenging to obtain an integrated graphical experience this way. I do not remember the details tough. I think I opened an upstream bug report years ago about this. Plasmashell uses some threads, but it does not appear that it uses different threads for filesystem accesses of widgets and so on. Differently on AmigaOS. Even if the whole operating system filesystem was gone (i.e. by just killing the filesystem and device tasks for it which you could just do on AmigaOS as it is single user without memory protection, at least upto AmigaOS 3.x) the GUI was still responsive. At least those parts of the GUI that did not access the filesystem. And once running the GUI did not do many filesystem accesses anymore unless you triggered some. So in summary: In order to achieve a responsive desktop with an unreachable NFS you´d either have to completely rewrite the architecture of the current Plasma desktop… or change the way the Linux kernel I/O subsystems works (and alongside of it probably also all the applications that use it). I´d really love to see a desktop that is always responsive. But so far I think sadly no integrated desktop environment with the functionality like Plasma has on Linux or any other Unix operating system is even close to that. There is still something to be learned from operating system and GUI approaches of other operating systems like AmigaOS. Thanks, -- Martin
Re: Hanging plasmashell
Any mounted system which looses connection will completely hang plasmashell. For example I mount NFS, close lid and take laptop to work and when I open it plasmashell is hanged. This has been issue for ages. Regards J On 30/05/18 16:58, Frank Mehnert wrote: Hi all, since some days I experience arbitrary hangs of plasmashell. When this happens, neither the application menu, the task bar nor any systray application respond to any mouse click. Alt+F2 doesn't work either and there is nothing else than "killall plasmashell && kstart plasmashell" to fix the problem. This is Debian/Sid, all packages up-to-date. Does anybody else experience similar problems? Frank
Re: Hanging plasmashell
So, the bug is fixed #900149 and yet still opened #900352. Looking at the dependencies of xserver-xorg-core package, I'm quite unsure of the correct mesa packages to install. There is this one: libegl1 (1.0.0+git20180308-3 and others), which doesn't seem very new, and therefore cannot be the one which has been recently fixed. There is this one: libegl1-mesa (18.0.5-1 and others), which is a transitional dummy package; which if I understand correctly just installs the previous one. And there is libegl-mesa0 (18.0.5-1), which is in the dependency of libegl1, and could be the one subjected to recent fix. I've always had X11 working without my doing anything about it (for instance I've got xserver-xorg-video-all installed, though since I *think* I'm using modesetting, it might be that I'm using none of them): Is there a good place where to look about what xorg components should be installed on a debian system? On Tuesday, June 5, 2018 10:59:33 AM CEST Jérôme Fix wrote: > > FYI, mesa 18.0.5-1 in Sid contains a fix for #900149: > > "Fixes compositor freezes with XServer 1.20" > > > > I didn't test the new packages myself yet. > > I installed it early this morning and I don't have any new freeze with > plasmashell or the menu. > > ii libegl-mesa0:amd64 18.0.5-1 >amd64free implementation of the EGL API > -- Mesa vendor library ii libegl1-mesa:amd64 >18.0.5-1amd64 > transitional dummy package ii libgl1-mesa-dev:amd64 >18.0.5-1amd64free > implementation of the OpenGL API -- GLX development files ii > libgl1-mesa-dri:amd64 18.0.5-1 > amd64free implementation of the OpenGL API > -- DRI modules ii libgl1-mesa-glx:amd64 >18.0.5-1amd64transitional dummy > package ii libglapi-mesa:amd64 > 18.0.5-1amd64free implementation of > the GL API -- shared library ii libgles2-mesa:amd64 > 18.0.5-1amd64 > transitional dummy package ii xserver-common >2:1.20.0-2 all common > files used by various X servers ii xserver-xephyr > 2:1.20.0-2 amd64 > nested X server ii xserver-xorg-core > 2:1.20.0-2 amd64Xorg X server - > core server > > Jérôme.
Re: Hanging plasmashell
Le mardi 5 juin 2018, 10:59:33 CEST Jérôme Fix a écrit : > > FYI, mesa 18.0.5-1 in Sid contains a fix for #900149: > > "Fixes compositor freezes with XServer 1.20" > > > > I didn't test the new packages myself yet. > > I installed it early this morning and I don't have any new freeze with > plasmashell or the menu. > > ii libegl-mesa0:amd64 18.0.5-1 >amd64free implementation of the EGL API > -- Mesa vendor library ii libegl1-mesa:amd64 >18.0.5-1amd64 > transitional dummy package ii libgl1-mesa-dev:amd64 >18.0.5-1amd64free > implementation of the OpenGL API -- GLX development files ii > libgl1-mesa-dri:amd64 18.0.5-1 > amd64free implementation of the OpenGL API > -- DRI modules ii libgl1-mesa-glx:amd64 >18.0.5-1amd64transitional dummy > package ii libglapi-mesa:amd64 > 18.0.5-1amd64free implementation of > the GL API -- shared library ii libgles2-mesa:amd64 > 18.0.5-1amd64 > transitional dummy package ii xserver-common >2:1.20.0-2 all common > files used by various X servers ii xserver-xephyr > 2:1.20.0-2 amd64 > nested X server ii xserver-xorg-core > 2:1.20.0-2 amd64Xorg X server - > core server > > Jérôme. +1 Philippe Merlin
Re: Hanging plasmashell
> FYI, mesa 18.0.5-1 in Sid contains a fix for #900149: > > "Fixes compositor freezes with XServer 1.20" > > I didn't test the new packages myself yet. > I installed it early this morning and I don't have any new freeze with plasmashell or the menu. ii libegl-mesa0:amd64 18.0.5-1 amd64free implementation of the EGL API -- Mesa vendor library ii libegl1-mesa:amd64 18.0.5-1 amd64transitional dummy package ii libgl1-mesa-dev:amd64 18.0.5-1 amd64free implementation of the OpenGL API -- GLX development files ii libgl1-mesa-dri:amd64 18.0.5-1 amd64free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-glx:amd64 18.0.5-1 amd64transitional dummy package ii libglapi-mesa:amd64 18.0.5-1 amd64free implementation of the GL API -- shared library ii libgles2-mesa:amd64 18.0.5-1 amd64transitional dummy package ii xserver-common 2:1.20.0-2 all common files used by various X servers ii xserver-xephyr 2:1.20.0-2 amd64nested X server ii xserver-xorg-core 2:1.20.0-2 amd64Xorg X server - core server Jérôme. signature.asc Description: This is a digitally signed message part.
Re: Hanging plasmashell
On Donnerstag, 31. Mai 2018 09:44:45 CEST Martin Steigerwald wrote: > Rainer Dorsch - 30.05.18, 23:20: > > On Mittwoch, 30. Mai 2018 13:38:43 CEST Miguel A. Vallejo wrote: > > > The problem is so annoying and frequent I moved (temporarily?) to > > > stable just to get work done. > [...] > > apt-listbugs does not trigger at all here. > > It happily just installed xserver-xorg-core anyway. Maybe because the bug > marked as critical is against src:xserver-xorg. I´d think it would affect > all of its binary packages then, but maybe apt-listbugs does not get this. > > I made the following similarly to how apt-listbugs does it: > > %:/etc/apt/preferences.d> cat xorg > Explaination: #900333 xserver-xorg-core: flickering, black screen and > modeset driver error: flip queue failed: Cannot allocate memory > Explaination: #900352 new xorg-server version causes a random freezes in > plasmashell Explaination: #900145 plasma-workspace: plasmashell freezes > every few times it appears Explaination: #900149 xserver-xorg: plasmashell FYI, mesa 18.0.5-1 in Sid contains a fix for #900149: "Fixes compositor freezes with XServer 1.20" I didn't test the new packages myself yet. > freezes after upgrade xserver-xorg Package: xserver-xorg-core > Pin: version 2:1.19.6-1 > Pin-Priority: 3 Kind regards, Frank
Re: Hanging plasmashell
On Donnerstag, 31. Mai 2018 09:44:45 CEST Martin Steigerwald wrote: > Rainer Dorsch - 30.05.18, 23:20: > > On Mittwoch, 30. Mai 2018 13:38:43 CEST Miguel A. Vallejo wrote: > > > The problem is so annoying and frequent I moved (temporarily?) to > > > stable just to get work done. > > > > In this case testing would have been enough, the bug is marked > > critical, xorg- server 1.20 will not enter testing before this issue > > is addressed ;-) Also apt-listbugs is your friend when running > > testing... > > apt-listbugs does not trigger at all here. > > It happily just installed xserver-xorg-core anyway. Maybe because the bug > marked as critical is against src:xserver-xorg. I´d think it would affect > all of its binary packages then, but maybe apt-listbugs does not get this. > > I made the following similarly to how apt-listbugs does it: > > %:/etc/apt/preferences.d> cat xorg > Explaination: #900333 xserver-xorg-core: flickering, black screen and > modeset driver error: flip queue failed: Cannot allocate memory > Explaination: #900352 new xorg-server version causes a random freezes in > plasmashell Explaination: #900145 plasma-workspace: plasmashell freezes > every few times it appears Explaination: #900149 xserver-xorg: plasmashell > freezes after upgrade xserver-xorg Package: xserver-xorg-core > Pin: version 2:1.19.6-1 > Pin-Priority: 3 > So far testing does a good job: rd@b370:~$ rmadison xserver-xorg-core|cut -f 1-2 -d '|' xserver-xorg-core | 2:1.12.4-6+deb7u6 xserver-xorg-core | 2:1.16.4-1 xserver-xorg-core | 2:1.16.4-1+deb8u2 xserver-xorg-core | 2:1.19.1-4 xserver-xorg-core | 2:1.19.2-1+deb9u2 xserver-xorg-core | 2:1.19.6-1 xserver-xorg-core | 2:1.20.0-2 rd@b370:~$ and as far as I understand #900316 holds it back. https://tracker.debian.org/pkg/xorg-server rd@b370:~$ rmadison xserver-xorg-core xserver-xorg-core | 2:1.12.4-6+deb7u6 | oldoldstable | amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc xserver-xorg-core | 2:1.16.4-1| oldstable-kfreebsd | kfreebsd-amd64, kfreebsd-i386 xserver-xorg-core | 2:1.16.4-1+deb8u2 | oldstable | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x xserver-xorg-core | 2:1.19.1-4| unstable | kfreebsd-amd64, kfreebsd-i386 xserver-xorg-core | 2:1.19.2-1+deb9u2 | stable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x xserver-xorg-core | 2:1.19.6-1| testing| amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x xserver-xorg-core | 2:1.20.0-2| unstable | amd64, arm64, armel, armhf, hurd-i386, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x rd@b370:~$ Certainly, testing relies on some users running unstable, otherwise testing would not work. I did not want to imply that apt-listbugs would have helped you here, I just gave it a recommendation for a tool which helped me sometimes in the past (certainly not always). Kind regards Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Hanging plasmashell
Yes, apt-listbugs didn't alert me neither. If you have the bad luck to upgrade/update before someone open the bug, you will eat it without any warning. apt-listbugs is not bullet-proof, only helpful. Anyway I will stay in stable some time, I need to get some job done.
Re: Hanging plasmashell
Rainer Dorsch - 30.05.18, 23:20: > On Mittwoch, 30. Mai 2018 13:38:43 CEST Miguel A. Vallejo wrote: > > The problem is so annoying and frequent I moved (temporarily?) to > > stable just to get work done. > > In this case testing would have been enough, the bug is marked > critical, xorg- server 1.20 will not enter testing before this issue > is addressed ;-) Also apt-listbugs is your friend when running > testing... apt-listbugs does not trigger at all here. It happily just installed xserver-xorg-core anyway. Maybe because the bug marked as critical is against src:xserver-xorg. I´d think it would affect all of its binary packages then, but maybe apt-listbugs does not get this. I made the following similarly to how apt-listbugs does it: %:/etc/apt/preferences.d> cat xorg Explaination: #900333 xserver-xorg-core: flickering, black screen and modeset driver error: flip queue failed: Cannot allocate memory Explaination: #900352 new xorg-server version causes a random freezes in plasmashell Explaination: #900145 plasma-workspace: plasmashell freezes every few times it appears Explaination: #900149 xserver-xorg: plasmashell freezes after upgrade xserver-xorg Package: xserver-xorg-core Pin: version 2:1.19.6-1 Pin-Priority: 3 Thanks -- Martin
Re: Hanging plasmashell
On Mittwoch, 30. Mai 2018 13:38:43 CEST Miguel A. Vallejo wrote: > The problem is so annoying and frequent I moved (temporarily?) to stable > just to get work done. In this case testing would have been enough, the bug is marked critical, xorg- server 1.20 will not enter testing before this issue is addressed ;-) Also apt-listbugs is your friend when running testing... Rainer -- Rainer Dorsch http://bokomoko.de/
Re: Hanging plasmashell
> Hi all, > since some days I experience arbitrary hangs of plasmashell. When this > happens, neither the application menu, the task bar nor any systray > application respond to any mouse click. Alt+F2 doesn't work either and > there is nothing else than "killall plasmashell && kstart plasmashell" > to fix the problem. This is Debian/Sid, all packages up-to-date. > Does anybody else experience similar problems? Yes, same problem here. plasmashell hangs just opening the main menu, clicking on the taskbar or even only hovering the mouse over the taskbar. I looked in logs and I could not find any related error message. The only way to get the system back again is to run killall plasmashell && kstart plasmashell. The problem is so annoying and frequent I moved (temporarily?) to stable just to get work done.
Re: Hanging plasmashell
On 30/05/2018 12:28, Frank Mehnert wrote: Hi all, since some days I experience arbitrary hangs of plasmashell. When this happens, neither the application menu, the task bar nor any systray application respond to any mouse click. Alt+F2 doesn't work either and there is nothing else than "killall plasmashell && kstart plasmashell" to fix the problem. This is Debian/Sid, all packages up-to-date. Does anybody else experience similar problems? Frank Hi, I have the same experience, I don't see messages from xorg as reported in #900145, all I see are sddm messages: " QObject: Cannot create children for a parent that is in a different thread. (Parent is SDDM::GreeterApp(0x7ffd8b6444e0), parent's thread is QThread(0x55eda32d1070), current thread is QThread(0x55eda34fd860) [0;1;39m^[[0;1;39mQObject: Cannot create children for a parent that is in a different thread. (Parent is SDDM::GreeterApp(0x7ffd8b6444e0), parent's thread is QThread(0x55eda32d1070), current thread is QThread(0x55eda34fd860) QObject: Cannot create children for a parent that is in a different thread. (Parent is SDDM::GreeterApp(0x7ffd8b6444e0), parent's thread is QThread(0x55eda32d1070), current thread is QThread(0x55eda34fd860) QObject: Cannot create children for a parent that is in a different thread. (Parent is SDDM::GreeterApp(0x7ffd8b6444e0), parent's thread is QThread(0x55eda32d1070), current thread is QThread(0x55eda34fd860) QObject::installEventFilter(): Cannot filter events for objects in a different thread. QObject: Cannot create children for a parent that is in a different thread. (Parent is SDDM::GreeterApp(0x7ffd8b6444e0), parent's thread is QThread(0x55eda32d1070), current thread is QThread(0x55eda34fd860) " The freeze appears every new session, as soon as there is a notification of some sort displayed. Plasma and applets freeze, taskbar is unresponsive, but other programs are unaffected (krunner works, yakuake (a drop-down terminal) works, ...etc). Mouse works but right-click doesn't. Interestingly if I kill xorg when on sddm greeter screen once, before logging in (with key combination [ctrl]+[alt]+[backspace]), the freeze never reoccurs. I suspected sni-qt related issue, but purging that didn't help, so since I cannot find any meaningful message in any log it is hard to report a bug or even pinpoint the issue. Will try downgrading xorg. I am on Sid amd64, AMD graphic card (amdgpu driver).
Re: Hanging plasmashell
Hi, yes, it could be the problem, with new X server 1.20, even SDDM was freezing for me. I downgraded back to 1.19 on same day it appeared in unstable :) Libor On středa 30. května 2018 10:10:21 CEST MERLIN Philippe wrote: > Le mercredi 30 mai 2018, 10:02:35 CEST Frank Mehnert a écrit : > > Hi Libor, > > > > > > My problems started a few days ago and I don't remember changing my > > configuration during these days. > > > > Thanks, > > > > Frank > > look at Bug#900145. > Philippe Merlin
Re: Hanging plasmashell
Le mercredi 30 mai 2018, 10:02:35 CEST Frank Mehnert a écrit : > Hi Libor, > > > My problems started a few days ago and I don't remember changing my > configuration during these days. > > Thanks, > > Frank look at Bug#900145. Philippe Merlin
Re: Hanging plasmashell
Hi Libor, On Mittwoch, 30. Mai 2018 09:19:55 CEST Libor Klepáč wrote: > i have observed simillar behaviour with autofs mounted samba. > I connect to them at home and when I forget to unmount them and go to work > (I have laptop and use suspend to RAM), my plasmashell sometime freezes. > But krunner is always ok. > > > Also, sometimes, my screen starts to flicker at random places, when i switch > tabs in browser, old tab flashes back for few seconds, mouse clicks doesn't > propagate, this is also fixable by restarting plasmashell. I have not find > root cause of this behaviour. > Recently, i switched compositor from OpenGL 3.1 to OpenGL 2.0, it lowered > frequency of this events, but it can still happen. all that doesn't sound related to my problem. I don't do any suspend to RAM and I don't use any auto-mounted shares. My problems started a few days ago and I don't remember changing my configuration during these days. Thanks, Frank
Re: Hanging plasmashell
Hi, i have observed simillar behaviour with autofs mounted samba. I connect to them at home and when I forget to unmount them and go to work (I have laptop and use suspend to RAM), my plasmashell sometime freezes. But krunner is always ok. Also, sometimes, my screen starts to flicker at random places, when i switch tabs in browser, old tab flashes back for few seconds, mouse clicks doesn't propagate, this is also fixable by restarting plasmashell. I have not find root cause of this behaviour. Recently, i switched compositor from OpenGL 3.1 to OpenGL 2.0, it lowered frequency of this events, but it can still happen. Libor On středa 30. května 2018 8:58:47 CEST Frank Mehnert wrote: > Hi all, > > since some days I experience arbitrary hangs of plasmashell. When this > happens, neither the application menu, the task bar nor any systray > application respond to any mouse click. Alt+F2 doesn't work either and > there is nothing else than "killall plasmashell && kstart plasmashell" > to fix the problem. This is Debian/Sid, all packages up-to-date. > > Does anybody else experience similar problems? > > Frank
