[opensuse-factory] Random desktop lockups with kernel 5.9.x
Hi! Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else. Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver. Adrian
Hi Adrian I observed similar behavior. rather randomly. Using integrated graphics HD 530 of my i7-6700K CPU (normal PC) After switching to KDE-wayland the issue disappears, so it seems to be X11 related? best regards Christian Am 25.11.20 um 11:33 schrieb John Paul Adrian Glaubitz:
Hi!
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else.
Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Hi Christian! On 11/25/20 11:38 AM, Christian Mahr wrote:
I observed similar behavior. rather randomly. Using integrated graphics HD 530 of my i7-6700K CPU (normal PC)
After switching to KDE-wayland the issue disappears, so it seems to be X11 related?
Well, yes and no. You're right that the problem goes away switching to Wayland. However, downgrading the kernel to 5.8 helps as well - although don't know how to install older kernel versions in openSUSE since from the top of my head right now as the last reboot into kernel 5.9.x finally purged the last 5.8.x kernel image off my disk. As for Wayland, it's still very rough for me. For example, moving an icon in the taskbar crashes Plasma completely, returning to the the display manager. So Wayland isn't an alternative either. Adrian
El mié, 25 nov 2020 a las 8:58, John Paul Adrian Glaubitz (<adrian.glaubitz@suse.com>) escribió:
Hi Christian!
On 11/25/20 11:38 AM, Christian Mahr wrote:
I observed similar behavior. rather randomly. Using integrated graphics HD 530 of my i7-6700K CPU (normal PC)
After switching to KDE-wayland the issue disappears, so it seems to be X11 related?
Well, yes and no. You're right that the problem goes away switching to Wayland. However, downgrading the kernel to 5.8 helps as well - although don't know how to install older kernel versions in openSUSE since from the top of my head right now as the last reboot into kernel 5.9.x finally purged the last 5.8.x kernel image off my disk.
As for Wayland, it's still very rough for me. For example, moving an icon in the taskbar crashes Plasma completely, returning to the the display manager. So Wayland isn't an alternative either.
Did You mean "Plasma Wayland" or "Full Wayland"? Cheers, Juan
plasma wayland, not full (haven tried) Am 25.11.20 um 13:02 schrieb Juan Erbes:
El mié, 25 nov 2020 a las 8:58, John Paul Adrian Glaubitz (<adrian.glaubitz@suse.com>) escribió:
Hi Christian!
On 11/25/20 11:38 AM, Christian Mahr wrote:
I observed similar behavior. rather randomly. Using integrated graphics HD 530 of my i7-6700K CPU (normal PC)
After switching to KDE-wayland the issue disappears, so it seems to be X11 related? Well, yes and no. You're right that the problem goes away switching to Wayland. However, downgrading the kernel to 5.8 helps as well - although don't know how to install older kernel versions in openSUSE since from the top of my head right now as the last reboot into kernel 5.9.x finally purged the last 5.8.x kernel image off my disk.
As for Wayland, it's still very rough for me. For example, moving an icon in the taskbar crashes Plasma completely, returning to the the display manager. So Wayland isn't an alternative either.
Did You mean "Plasma Wayland" or "Full Wayland"?
Cheers, Juan _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Hi Adrian Well... wayland works for me, and does a better job on scaling programs on a high density screen. So I keep it. The other effect I observed is that when screen was frozen in x11: I still could switch to a console (Alt-F1) and restart the whole X11 by killing the process "startplasma-x11". Of course, the session is gone then... I also tried to identify some root cause in the /var/log/messages or other places but was not successful. keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running" So if you happen to have an 5.8 kernel on an older btrfs-snapshot, you might want to roll back and ask zypper to keep the 5.8 kernel, then zypper dup again? BR Christian Am 25.11.20 um 12:58 schrieb John Paul Adrian Glaubitz:
Hi Christian!
On 11/25/20 11:38 AM, Christian Mahr wrote:
I observed similar behavior. rather randomly. Using integrated graphics HD 530 of my i7-6700K CPU (normal PC)
After switching to KDE-wayland the issue disappears, so it seems to be X11 related? Well, yes and no. You're right that the problem goes away switching to Wayland. However, downgrading the kernel to 5.8 helps as well - although don't know how to install older kernel versions in openSUSE since from the top of my head right now as the last reboot into kernel 5.9.x finally purged the last 5.8.x kernel image off my disk.
As for Wayland, it's still very rough for me. For example, moving an icon in the taskbar crashes Plasma completely, returning to the the display manager. So Wayland isn't an alternative either.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Hi Christian! On 11/25/20 1:20 PM, Christian Mahr wrote:
Well... wayland works for me, and does a better job on scaling programs on a high density screen. So I keep it.
It never worked reliable enough for me, unfortunately. Both on Debian unstable and openSUSE Tumbleweed, I've been trying to switch for years but I always ended up with the desktop either crashing or things like the clipboard not working properly.
The other effect I observed is that when screen was frozen in x11: I still could switch to a console (Alt-F1) and restart the whole X11 by killing the process "startplasma-x11". Of course, the session is gone then... I also tried to identify some root cause in the /var/log/messages or other places but was not successful.
I haven't seen any log messages either. It just freezes for a second or sometimes longer, I can't type or move the mouse. Sound playback continues, so it's just X that locks up.
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest, latest-1,running"
Ok, thanks. I know now for the next time.
So if you happen to have an 5.8 kernel on an older btrfs-snapshot, you might want to roll back and ask zypper to keep the 5.8 kernel, then zypper dup again?
I unfortunately don't use btrfs as I stopped using the filesystem when I ran into serious balancing issues a few years ago. So I don't have the possibility to switch to an older snapshot. I think I have asked that before, but does openSUSE have something like snapshot.debian.org which keeps copies of older package versions or do I have to build a custom kernel now? Adrian
On Wed, 2020-11-25 at 14:04 +0100, John Paul Adrian Glaubitz wrote:
I think I have asked that before, but does openSUSE have something like snapshot.debian.org which keeps copies of older package versions or do I have to build a custom kernel now?
http://download.opensuse.org/history/ ? The last few snapshots are kept there Cheers, Dominique
On 11/25/20 2:28 PM, Dominique Leuenberger / DimStar wrote:
On Wed, 2020-11-25 at 14:04 +0100, John Paul Adrian Glaubitz wrote:
I think I have asked that before, but does openSUSE have something like snapshot.debian.org which keeps copies of older package versions or do I have to build a custom kernel now?
http://download.opensuse.org/history/ ?
The last few snapshots are kept there
Thank you! I wasn't aware of that. Exactly what I am looking for! Adrian
25.11.2020 16:04, John Paul Adrian Glaubitz пишет:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest, latest-1,running"
Ok, thanks. I know now for the next time.
Latest refers to most recent kernel which means that as soon as you have second 5.9 kernel previous are deleted, which likely is 5.8. You really want "oldest" - this allows keeping "last known good" indefinitely while still installing latest kernels to test them.
On 11/25/20 3:39 PM, Andrei Borzenkov wrote:
Latest refers to most recent kernel which means that as soon as you have second 5.9 kernel previous are deleted, which likely is 5.8.
You really want "oldest" - this allows keeping "last known good" indefinitely while still installing latest kernels to test them.
Thanks. I just added the explicit version number of the 5.8.x kernel as this should work according to the comments in the config file. Adrian
On Nov 25 2020, Christian Mahr wrote:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running"
Or disable the purge-kernels service. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On 11/25/20 5:32 PM, Andreas Schwab wrote:
On Nov 25 2020, Christian Mahr wrote:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running"
Or disable the purge-kernels service.
Yeah, I was thinking about that, too. Adrian
Andreas Schwab composed on 2020-11-25 17:32 (UTC+0100):
Christian Mahr wrote:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running"
Or disable the purge-kernels service.
Anyone know why with purge-kernels.service disabled the purge trigger file yet shows up in /boot/ after each new kernel is installed? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
* Felix Miata <mrmazda@earthlink.net> [11-25-20 15:42]:
Andreas Schwab composed on 2020-11-25 17:32 (UTC+0100):
Christian Mahr wrote:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running"
Or disable the purge-kernels service.
Anyone know why with purge-kernels.service disabled the purge trigger file yet shows up in /boot/ after each new kernel is installed?
I disabled "purge-kernels.service" some time ago as it removed all but current and last but was set to retain the last three. I saw comment that the service was faulty, and observed, but never that it had been fixed. I now do no trust it and do the action manually. but I have not noticed it showing on boot nor in my log files. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
On Wed, 25 Nov 2020, 19:49:41 +0100, Felix Miata wrote:
Andreas Schwab composed on 2020-11-25 17:32 (UTC+0100):
Christian Mahr wrote:
keeping old kernel versions: if you still have them on disk you can advise zypper not to purge it: add the kernel version explicitly tp the list in /etc/zypp/zypp.conf "multiversion.kernels = latest,latest-1,running"
Or disable the purge-kernels service.
Anyone know why with purge-kernels.service disabled the purge trigger file yet shows up in /boot/ after each new kernel is installed?
Every kernel you install creates it in a postinstall scriptlet: $ rpm -q kernel-default --scripts | grep -C 2 /boot/do_purge_kernels postinstall scriptlet (using /bin/sh): # Flag to trigger /etc/init.d/purge-kernels on next reboot (fate#312018) touch /boot/do_purge_kernels Cheers. l8er manfred
Hi Am 25.11.20 um 11:33 schrieb John Paul Adrian Glaubitz:
Hi!
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else.
Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver.
You may want to subscribe to https://bugzilla.suse.com/show_bug.cgi?id=1178474 https://bugzilla.suse.com/show_bug.cgi?id=1179092 We don't have a clear STR yet, so any information is welcome. Best regards Thomas
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Thomas Zimmermann schrieb:
You may want to subscribe to
https://bugzilla.suse.com/show_bug.cgi?id=1178474 https://bugzilla.suse.com/show_bug.cgi?id=1179092
We don't have a clear STR yet, so any information is welcome.
Thanks for those pointers. I'm a bit reluctant to comment in those as one says the lockups are temporary, while the other talks of screen going black, while for me, both screens freeze permanently, no way to get out of it other than killing the X server, and plasmashell (IIRC) even hangs around after X is being killed and also doesn't exist with a TERM signal (i.e. normal kill command). Also, when the screen is frozen, audio continues and the mouse still moves, even the mouse pointer changes according to elements that would be shown at the respective position right now, even if the screen shows a frozen state from a moment before. It feels like compositing is stuck at a certain frame and doesn't process new frames any more or something like that (not that I know the internals of the gfx flow). FWIW, I'm running on Intel UHD Graphics 630 (integrated in i7-8700K CPU). The issue seems to happen more likely to me when I have two videos running at the same time, e.g. a Twitch stream in Firefox on one stream and a different browser window on the second screen (or other tab on the same one that I temporarily switch to) also starting to (auto-)play a video, or I e.g. run VLC with a DVD in parallel to a stream as I just recently did for a watch-along. I'm putting this here because - as said above - the bugs feels like they talk of slightly different symptoms, but it may well be the same source issue underneath. Cheers, KaiRo
On 11/25/20 1:29 PM, Thomas Zimmermann wrote:
You may want to subscribe to
https://bugzilla.suse.com/show_bug.cgi?id=1178474 https://bugzilla.suse.com/show_bug.cgi?id=1179092
We don't have a clear STR yet, so any information is welcome.
Thanks, I have. I will try to bisect the issue as mentioned in my mail to Jiri. Adrian
On Wednesday 2020-11-25 11:33, John Paul Adrian Glaubitz wrote:
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Does anyone else see such lockups?
Recently I have experienced something of that kind, sort of. (It has not happened often enough yet that I could be bothered to look into it in more detail...) When the system gets "stuck", I am still able to switch to text console and issue `rcxdm restart` which resolves my particular issue. Do your system exhibit this behavior too?
On 11/25/20 1:35 PM, Jan Engelhardt wrote:
Recently I have experienced something of that kind, sort of. (It has not happened often enough yet that I could be bothered to look into it in more detail...) When the system gets "stuck", I am still able to switch to text console and issue `rcxdm restart` which resolves my particular issue. Do your system exhibit this behavior too?
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes. Adrian
On Wednesday 2020-11-25 14:06, John Paul Adrian Glaubitz wrote:
On 11/25/20 1:35 PM, Jan Engelhardt wrote:
Recently I have experienced something of that kind, sort of. (It has not happened often enough yet that I could be bothered to look into it in more detail...) When the system gets "stuck", I am still able to switch to text console and issue `rcxdm restart` which resolves my particular issue. Do your system exhibit this behavior too?
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse. Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so. Rebooting into a 5.8.x kernel made the issue go away, but zypper has purged the last 5.8.x off my disk now :-(. I will check whether OBS has any 5.10 RC kernel I can test. Adrian
On 25. 11. 20, 14:50, John Paul Adrian Glaubitz wrote:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes.
So you look to be a perfect victim to perform a kernel bisection. That would help us to move forward a _lot_. From my experience, i915 upstream mostly doesn't take care of bug reports (I reported tens, resolved were none). So are you be keen enough to do so? thanks, -- js suse labs
Hi Jiri! On 11/26/20 9:56 AM, Jiri Slaby wrote:
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes.
So you look to be a perfect victim to perform a kernel bisection. That would help us to move forward a _lot_. From my experience, i915 upstream mostly doesn't take care of bug reports (I reported tens, resolved were none).
I am doing regular kernel bisects for SuperH and other embedded architectures, so that wouldn't be a problem.
So are you be keen enough to do so?
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;). I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem. Adrian
On 26. 11. 20, 18:47, John Paul Adrian Glaubitz wrote:
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;).
Note: I would start with bisection of drivers/gpu. It should be rather quick (opposing to unrestricted bisection).
I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem.
You can use our kernel-vanilla. That's upstream kernel w/ few packaging patches only. In any way, our kernel-default is stable kernel tree + only few patches on top too. So I would say, it should reproduce in vanilla the very same. -- js suse labs
On 11/26/20 8:48 PM, Jiri Slaby wrote:
On 26. 11. 20, 18:47, John Paul Adrian Glaubitz wrote:
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;).
Note: I would start with bisection of drivers/gpu. It should be rather quick (opposing to unrestricted bisection).
Well, now I'm learning something new. I didn't know you could bisect sub-directories.
I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem.
You can use our kernel-vanilla. That's upstream kernel w/ few packaging patches only. In any way, our kernel-default is stable kernel tree + only few patches on top too. So I would say, it should reproduce in vanilla the very same.
I have checked out Linus' tree anyway on my disk. So, I'll just pull and start bisecting between v5.8 and v5.9. Adrian
I have the same issue System Info: Operating System: openSUSE Tumbleweed 20201124 KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.1 Kernel Version: 5.9.8-2-default OS Type: 64-bit Processors: 4 × Intel® Core™ i5-3570K CPU @ 3.40GHz Memory: 15.5 GiB of RAM Graphics Processor: AMD PITCAIRN Video Card: Radeon 7850 Motherboard: iGPU (Intel HD4000) OS was installed with Kernel 5.9 SYMPTOMS: Desktop will occasionally/intermittantly Freeze up Mouse *usually* will still move around - occasionally though even the mouse pointer will also freeze up In my particular case, my SSD (formatted as BTRFS) that has root on in will immediately go into full-bore activity (LED light on non-stop) Not sure is this is related/relevant: https://github.com/DisplayLink/evdi/issues/225 John Paul Adrian Glaubitz wrote:
On 11/26/20 8:48 PM, Jiri Slaby wrote:
On 26. 11. 20, 18:47, John Paul Adrian Glaubitz wrote:
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;). Note: I would start with bisection of drivers/gpu. It should be rather quick (opposing to unrestricted bisection). Well, now I'm learning something new. I didn't know you could bisect sub-directories.
I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem. You can use our kernel-vanilla. That's upstream kernel w/ few packaging patches only. In any way, our kernel-default is stable kernel tree + only few patches on top too. So I would say, it should reproduce in vanilla the very same. I have checked out Linus' tree anyway on my disk. So, I'll just pull and start bisecting between v5.8 and v5.9.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
On Fri, Nov 27, 2020 at 10:45 AM Joe <Enlightenment1@cock.li> wrote:
Desktop will occasionally/intermittantly Freeze up Mouse *usually* will still move around - occasionally though even the mouse pointer will also freeze up In my particular case, my SSD (formatted as BTRFS) that has root on in will immediately go into full-bore activity (LED light on non-stop)
Not sure is this is related/relevant:
I can also confirm the same issue. It has been happening to me since long ago (not only on 5.9 kernel). Usually it lasts for some seconds and then recovers and I have a full activity also on my SSD with btrfs. I'm not experiencing crashes but this temporary freeze which as soon as the disk LED goes off it recovers. I'm not on my Tumbleweed workstation now to post my specs but regarding GPU I'm with an AMD RX580.
Hello! On 11/26/20 8:57 PM, John Paul Adrian Glaubitz wrote:
On 11/26/20 8:48 PM, Jiri Slaby wrote:
On 26. 11. 20, 18:47, John Paul Adrian Glaubitz wrote:
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;).
Note: I would start with bisection of drivers/gpu. It should be rather quick (opposing to unrestricted bisection).
Well, now I'm learning something new. I didn't know you could bisect sub-directories.
I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem.
You can use our kernel-vanilla. That's upstream kernel w/ few packaging patches only. In any way, our kernel-default is stable kernel tree + only few patches on top too. So I would say, it should reproduce in vanilla the very same.
I have checked out Linus' tree anyway on my disk. So, I'll just pull and start bisecting between v5.8 and v5.9.
FWIW, this issue is still present in 5.10.7, so I guess I will finally have to start bisecting this. Sorry for not getting around doing this earlier, my TODO stack is simply too high. I will hopefully report back in the upcoming week with my bisect results. Adrian
Hi Am 26.11.20 um 18:47 schrieb John Paul Adrian Glaubitz:
Hi Jiri!
On 11/26/20 9:56 AM, Jiri Slaby wrote:
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes.
So you look to be a perfect victim to perform a kernel bisection. That would help us to move forward a _lot_. From my experience, i915 upstream mostly doesn't take care of bug reports (I reported tens, resolved were none).
I am doing regular kernel bisects for SuperH and other embedded architectures,
Somewhat offtopic: is there an effortable development board for SuperH? Specifically, I'm looking for hardware that allows me to test the DRM SH mobile driver. Best regards Thomas
so that wouldn't be a problem.
So are you be keen enough to do so?
Since you were so kind to enable Amiga partition support in the kernel for me, I will bisect that problem in the weekend ;).
I will first have a look whether it reproduces with the vanilla upstream kernel to make sure that's not any of the patches that introduces the problem.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Hi Thomas! On 11/27/20 8:44 AM, Thomas Zimmermann wrote:
I am doing regular kernel bisects for SuperH and other embedded architectures,
Somewhat offtopic: is there an effortable development board for SuperH? Specifically, I'm looking for hardware that allows me to test the DRM SH mobile driver.
There are two cheap alternatives: One is the LANDISK USL-5P which has a SH-7751R CPU clocked at 266 MHz, 64 MiB RAM and a CF card. The board boots a vanilla upstream kernel which is also actively maintained, also since I send Geert Uytterhoven a free board. And, secondly, there is the NextVoD, a Video-on-Demand multimedia box from Taiwan which has an ST-40 SH4 SoC clocked at 450 MHz with 256 MiB RAM and even u-boot. Support for the NextVoD is currently out-of-tree only [1] as Paul Mundt removed ST-40 support from arch/sh at some point. But we're planning to reintroduce ST-40 support in the near future which should also become easier once device tree support has been merged for arch/sh [2]. I have plenty of USL-5P and NextVoD devices at home which I brought from Japan and Taiwan, respectively and I'm happy to send either of them to any kernel developer willing to work on the SH port. I also have some development boards from Renesas which I got through personal contacts in Japan directly from Renesas but these are extremely rare which is why I will only provide remote access to these boxes but not give them away. So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome. Adrian
[1] https://github.com/system1357/pdk7105-3.4 [2] https://patchwork.kernel.org/project/linux-sh/patch/20160212041424.GA11747@b...
On 11/27/20 11:20 AM, John Paul Adrian Glaubitz wrote:
So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome.
PS: I also happen to be the port maintainer for sh4 in Debian. So in case you need support in this regard. Adrian
https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_... Linux 5.9-rc7 Is A Total Disaster On Machines With Intel Graphics Jump to navigation <https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_Intel_Graphics#column-one>Jump to search <https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_Intel_Graphics#searchInput> Tux.png The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the |i915| kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics. /written by 윤채경 (Yoon Chae-kyung) <https://linuxreviews.org/User:Chaekyung>./ /published 2020-09-28/ - /last edited 2020-09-29/ John Paul Adrian Glaubitz wrote:
On 11/27/20 11:20 AM, John Paul Adrian Glaubitz wrote:
So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome. PS: I also happen to be the port maintainer for sh4 in Debian. So in case you need support in this regard.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
* Joe <Enlightenment1@cock.li> [11-27-20 10:40]:
https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_...
Linux 5.9-rc7 Is A Total Disaster On Machines With Intel Graphics
Jump to navigation <https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_Intel_Graphics#column-one>Jump to search <https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_Intel_Graphics#searchInput>
Tux.png
The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the |i915| kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics.
/written by 윤채경 (Yoon Chae-kyung) <https://linuxreviews.org/User:Chaekyung>./ /published 2020-09-28/ - /last edited 2020-09-29/
John Paul Adrian Glaubitz wrote:
On 11/27/20 11:20 AM, John Paul Adrian Glaubitz wrote:
So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome. PS: I also happen to be the port maintainer for sh4 in Debian. So in case you need support in this regard.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
ODD, re 5.9 kernels I have two intel based video laptops and neither has a display problem via any of the Tw released 5.9.x-default kernels. But am willing to run tests but will need guidance. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Joe schrieb:
The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the |i915| kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics.
This doesn't sound true to me, I guess it's different for different setups. Haven't tried the RCs back then, but 5.9.1 does actually run a graphical environment fine most of the time - unless it, at some points, ends up freezing the whole screen and only killing the X server (Crtl+Alt+Bksp twice) and rebooting will reliably work to fix that (as after killing, plasmashell stays around in a state SIGTERM can't stop and while SIGKILL can, it seems like another freeze happens pretty fast again when launching plasma again afterwards, while it may go hours after a reboot). KaiRo
On Fri, Nov 27, 2020 at 8:57 PM Robert Kaiser <kairo@kairo.at> wrote:
Joe schrieb:
The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the |i915| kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics.
This doesn't sound true to me, I guess it's different for different setups. Haven't tried the RCs back then, but 5.9.1 does actually run a graphical environment fine most of the time - unless it, at some points, ends up freezing the whole screen and only killing the X server (Crtl+Alt+Bksp twice) and rebooting will reliably work to fix that (as after killing, plasmashell stays around in a state SIGTERM can't stop and while SIGKILL can, it seems like another freeze happens pretty fast again when launching plasma again afterwards, while it may go hours after a reboot).
I can't say I've tried this on openSUSE, but two of my laptops running Fedora 33 with kernel 5.9.10 works perfectly fine. No lockups or anything. And it's powered by Intel graphics. One has Intel 10th generation and the other has Intel 8th generation CPUs with integrated graphics. Both work flawlessly. One with GNOME and another with KDE Plasma. If there's something funky going on here, it'd have to be something patched in the openSUSE kernel specifically. -- 真実はいつも一つ！/ Always, there's only one truth!
On 2020-11-28 04:23, Neal Gompa wrote:
I can't say I've tried this on openSUSE, but two of my laptops running Fedora 33 with kernel 5.9.10 works perfectly fine
I downloaded Rawhide nightly. It has 5.10.0 (rc4-something). Rebooted a couple of times and ran it for 30 minutes. No problem with lockups. Normally lockups comes after some minutes. Main difference besides kernel is Wayland and Gnome. Normally I also have some problems with small glitches when I'm on full screen with ex. youtube but not with this. This is what I tested. Workstation live "Last known good" https://openqa.fedoraproject.org/nightlies.html -- /bengan
On 29/11/2020 16:03, Bengt Gördén wrote:
On 2020-11-28 04:23, Neal Gompa wrote:
I can't say I've tried this on openSUSE, but two of my laptops running Fedora 33 with kernel 5.9.10 works perfectly fine
I downloaded Rawhide nightly. It has 5.10.0 (rc4-something). Rebooted a couple of times and ran it for 30 minutes. No problem with lockups. Normally lockups comes after some minutes. Main difference besides kernel is Wayland and Gnome.
Normally I also have some problems with small glitches when I'm on full screen with ex. youtube but not with this.
This is what I tested. Workstation live "Last known good" https://openqa.fedoraproject.org/nightlies.html
Yesterday I upgraded TW with 5.9.10. No problem....until this morning it did exhibit the same lockups. It happened when I was generating many (keyboard) interrupts and heavy scrolling of text files using less. At other time I have noticed this also when I was rather busy with the keyboard and/or generating many mouse interrupts. Now, back to vanilla 5.8.15, did the same without problems. Nouvaeu or stack problem? --- Frans. -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?
On 29/11/2020 20:16, Frans de Boer wrote:
On 29/11/2020 16:03, Bengt Gördén wrote:
On 2020-11-28 04:23, Neal Gompa wrote:
I can't say I've tried this on openSUSE, but two of my laptops running Fedora 33 with kernel 5.9.10 works perfectly fine
I downloaded Rawhide nightly. It has 5.10.0 (rc4-something). Rebooted a couple of times and ran it for 30 minutes. No problem with lockups. Normally lockups comes after some minutes. Main difference besides kernel is Wayland and Gnome.
Normally I also have some problems with small glitches when I'm on full screen with ex. youtube but not with this.
This is what I tested. Workstation live "Last known good" https://openqa.fedoraproject.org/nightlies.html
Yesterday I upgraded TW with 5.9.10. No problem....until this morning it did exhibit the same lockups. It happened when I was generating many (keyboard) interrupts and heavy scrolling of text files using less.
At other time I have noticed this also when I was rather busy with the keyboard and/or generating many mouse interrupts.
Now, back to vanilla 5.8.15, did the same without problems. Nouvaeu or stack problem?
--- Frans.
Sorry, can't be a Nouveau problem because Intel graphics have the same behavior. --- Frans -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?
I think the right phrase would be: Intel Graphics are A Total Disaster On Machines With Linux 5.9.x With AMD Graphics and CPU, my computer has no problemas with kernel 5.9.x! El vie, 27 nov 2020 a las 12:40, Joe (<Enlightenment1@cock.li>) escribió:
https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_...
Linux 5.9-rc7 Is A Total Disaster On Machines With Intel Graphics
Jump to navigationJump to search
The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the i915 kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics.
written by 윤채경 (Yoon Chae-kyung). published 2020-09-28 - last edited 2020-09-29
John Paul Adrian Glaubitz wrote:
On 11/27/20 11:20 AM, John Paul Adrian Glaubitz wrote:
So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome.
PS: I also happen to be the port maintainer for sh4 in Debian. So in case you need support in this regard.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/
* Juan Erbes <jerbes@gmail.com> [11-29-20 17:41]:
I think the right phrase would be:
Intel Graphics are A Total Disaster On Machines With Linux 5.9.x
With AMD Graphics and CPU, my computer has no problemas with kernel 5.9.x!
El vie, 27 nov 2020 a las 12:40, Joe (<Enlightenment1@cock.li>) escribió:
https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_...
Linux 5.9-rc7 Is A Total Disaster On Machines With Intel Graphics
Jump to navigationJump to search
The latest Linux 5.9 release candidate won't even let you start the X display server on machines with integrated Intel graphics. Running Linux on machines with integrated Intel graphics has been problematic since Linux 5.0. All those problems remained an issue with Linux 5.9-rc6. Linux 5.9-rc7 takes it one step further, it won't even let you get into a graphical environment without crashing the i915 kernel display driver for Intel GPU chips. It is a complete and utter disaster for people using integrated Intel graphics.
written by 윤채경 (Yoon Chae-kyung). published 2020-09-28 - last edited 2020-09-29
John Paul Adrian Glaubitz wrote:
On 11/27/20 11:20 AM, John Paul Adrian Glaubitz wrote:
So, if you are interested in doing some SuperH development, let me know. In particular, getting a current kernel to boot on the NextVoD would be awesome.
PS: I also happen to be the port maintainer for sh4 in Debian. So in case you need support in this regard.
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
perhaps a better wording: "Intel Graphics are A Total Disaster *my* Machines With Linux 5.9.x" I have two laptops which have absolutely no problem with intel graphics and kernels 5.9.x-default. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
On 25. 11. 20, 14:50, John Paul Adrian Glaubitz wrote:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse.
Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so.
Looking at your prime post, you have HD Graphics 520. I have it in my Dell Latitude 7280 too: 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) But I don't experience it with 5.9.6-1.gfc52788-default with X and plasma (and modesetting). What settings do you have in Compositor (run systemsettings5 kwincompositing)? I have: scale m.: Accurate backend: ogl 3.1 vsync: auto thumbs: shown wins Does it happen if you disable compositor? Does it happen on A/C or only battery? Do you have tlp installed? Do you run w/ modesetting driver (check Xorg log)? thanks, -- js suse labs
Hi Jiri! On 11/26/20 10:06 AM, Jiri Slaby wrote:
Looking at your prime post, you have HD Graphics 520. I have it in my Dell Latitude 7280 too: 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07)
But I don't experience it with 5.9.6-1.gfc52788-default with X and plasma (and modesetting).
What settings do you have in Compositor (run systemsettings5 kwincompositing)? I have: scale m.: Accurate backend: ogl 3.1 vsync: auto thumbs: shown wins
scale method: Accurate backend: OpenGL 2.0 Tearing prevention (vsync): Automatic Keep windows thumbnails: Only for Shown Windows
Does it happen if you disable compositor?
Haven't tried that. Currently the box is ticked off, i.e. "Enable compositor on startup".
Does it happen on A/C or only battery?
It happens on both A/C and battery power.
Do you have tlp installed?
Not sure what TLP is in this context?
Do you run w/ modesetting driver (check Xorg log)?
No, I'm using the Intel driver since the modesetting driver often had graphics issues when I was using it. Adrian
Hi, On 26. 11. 20, 18:51, John Paul Adrian Glaubitz wrote:
Do you have tlp installed?
Not sure what TLP is in this context?
tlp package Summary : Tools to save battery power on laptops It's https://linrunner.de/tlp/
Do you run w/ modesetting driver (check Xorg log)?
No, I'm using the Intel driver since the modesetting driver often had graphics issues when I was using it.
Ah, so that would be likely it. And yes, modesetting indeed has issues here (and that's what I reported and were never resolved). However intel ddx used to be not much different here. thanks, -- js suse labs
Op 26-11-2020 om 18:51 schreef John Paul Adrian Glaubitz:
No, I'm using the Intel driver since the modesetting driver often had graphics issues when I was using it.
I have never tried to find the cause, but for years when trying plasma with opengl and the intel driver causes the system to freeze after a certain time, although mouse still useable and sound continuing. This does not happen with xrender and intel, neither with modesetting. Modesetting is what I use ATM. Just confirming what some see in this thread. Cor
Hi Am 25.11.20 um 14:50 schrieb John Paul Adrian Glaubitz:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse.
Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so.
Rebooting into a 5.8.x kernel made the issue go away, but zypper has purged the last 5.8.x off my disk now :-(.
I will check whether OBS has any 5.10 RC kernel I can test.
I can still reproduce the issue with 5.10-rc5. Best regards Thomas
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
I have taken the usual normal route of upgrading - I have been taken to Kernel 5.9.10-1-default So far, I have not personally experienced any of the X11 Server desktop lockups on my Intel PC However, i am wondering if - maybe - this second issue could be related ? I use the browser SeaMonkey, and while i often have at least 100 TABs open, and email checks running in the background on at least 10 different emails address'es - my ability to quickly close seamonkey down efficiency (window close button in top right-hand corner) has always been just fine however, on both kernel v5.9 and now 5.9.10-1-default is that Im getting the desktop effect called "Desaturate Unresponsive Applications" almost all the time, now whenever i close seamonkey, along with a small windows asking me if i want to quit or wait for the app to respond Seamonkey is constantly updated as well - so i do keep that in mind Im proposing the idea that maybe there is/are some issues of degraded efficiency withon code in either the kernel and/or some of the other system packages that get updated - inefficiencys that perhaps could cause these side effects of inefficiency of apps (in my case seamonkey) and a timing issue which ends up resulting in a desktop freeze Should what i have noticed be made a separate issue ? Either a separate issue here via email and/or me creating an official opensuse forum thread Feedback Required Thanks Ben Thomas Zimmermann wrote:
Hi
Am 25.11.20 um 14:50 schrieb John Paul Adrian Glaubitz:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse.
Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so.
Rebooting into a 5.8.x kernel made the issue go away, but zypper has purged the last 5.8.x off my disk now :-(.
I will check whether OBS has any 5.10 RC kernel I can test.
I can still reproduce the issue with 5.10-rc5.
Best regards Thomas
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Hi Am 28.11.20 um 20:57 schrieb Joe:
I have taken the usual normal route of upgrading - I have been taken to Kernel 5.9.10-1-default
So far, I have not personally experienced any of the X11 Server desktop lockups on my Intel PC However, i am wondering if - maybe - this second issue could be related ? I use the browser SeaMonkey, and while i often have at least 100 TABs open, and email checks running in the background on at least 10 different emails address'es - my ability to quickly close seamonkey down efficiency (window close button in top right-hand corner) has always been just fine
however, on both kernel v5.9 and now 5.9.10-1-default is that Im getting the desktop effect called "Desaturate Unresponsive Applications" almost all the time, now whenever i close seamonkey, along with a small windows asking me if i want to quit or wait for the app to respond
Seamonkey is constantly updated as well - so i do keep that in mind
Im proposing the idea that maybe there is/are some issues of degraded efficiency withon code in either the kernel and/or some of the other system packages that get updated - inefficiencys that perhaps could cause these side effects of inefficiency of apps (in my case seamonkey) and a timing issue which ends up resulting in a desktop freeze
Should what i have noticed be made a separate issue ?
I think so. There are already two separate issues discussed here. Best regards Thomas
Either a separate issue here via email and/or me creating an official opensuse forum thread
Feedback Required
Thanks
Ben
Thomas Zimmermann wrote:
Hi
Am 25.11.20 um 14:50 schrieb John Paul Adrian Glaubitz:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse.
Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so.
Rebooting into a 5.8.x kernel made the issue go away, but zypper has purged the last 5.8.x off my disk now :-(.
I will check whether OBS has any 5.10 RC kernel I can test.
I can still reproduce the issue with 5.10-rc5.
Best regards Thomas
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Made separate post regarding unresponsive issue on Kernel 5.9.10-1-default https://forums.opensuse.org/showthread.php/547662-Kernel-5-9-10-1-default-De... Ben Thomas Zimmermann wrote:
Hi
Am 28.11.20 um 20:57 schrieb Joe:
I have taken the usual normal route of upgrading - I have been taken to Kernel 5.9.10-1-default
So far, I have not personally experienced any of the X11 Server desktop lockups on my Intel PC However, i am wondering if - maybe - this second issue could be related ? I use the browser SeaMonkey, and while i often have at least 100 TABs open, and email checks running in the background on at least 10 different emails address'es - my ability to quickly close seamonkey down efficiency (window close button in top right-hand corner) has always been just fine
however, on both kernel v5.9 and now 5.9.10-1-default is that Im getting the desktop effect called "Desaturate Unresponsive Applications" almost all the time, now whenever i close seamonkey, along with a small windows asking me if i want to quit or wait for the app to respond
Seamonkey is constantly updated as well - so i do keep that in mind
Im proposing the idea that maybe there is/are some issues of degraded efficiency withon code in either the kernel and/or some of the other system packages that get updated - inefficiencys that perhaps could cause these side effects of inefficiency of apps (in my case seamonkey) and a timing issue which ends up resulting in a desktop freeze
Should what i have noticed be made a separate issue ?
I think so. There are already two separate issues discussed here.
Best regards Thomas
Either a separate issue here via email and/or me creating an official opensuse forum thread
Feedback Required
Thanks
Ben
Thomas Zimmermann wrote:
Hi
Am 25.11.20 um 14:50 schrieb John Paul Adrian Glaubitz:
On 11/25/20 2:15 PM, Jan Engelhardt wrote:
Well, if resolving means restarting the display manager then yes. But I don't want to restart my display manager every few minutes.
I am just trying to establish how hard the "lockup" is on your side.
It happens every few minutes. For example, I'm typing this email and all of a sudden, the whole desktop locks up and I won't be able to type or move the mouse.
Shortly after, it will just continue as if nothing happened. Sometimes the lock ups can be much longer and the desktop freezes for half a minute or so.
Rebooting into a 5.8.x kernel made the issue go away, but zypper has purged the last 5.8.x off my disk now :-(.
I will check whether OBS has any 5.10 RC kernel I can test.
I can still reproduce the issue with 5.10-rc5.
Best regards Thomas
Adrian _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
Since a few hours I've been running 5.9.10 with ahci.mobile_lpm_policy=1 and intel_idle.max_cstate=1. It seem to have worked for me so far. No lockups for 1h49m. My bug report. https://bugzilla.opensuse.org/show_bug.cgi?id=1178474#c9 -- /bengan
John Paul Adrian Glaubitz wrote:
Hi!
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else.
Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver.
Lenovo T460p here, Skylake 6820HQ with HD530 (SKL GT2) No issues for me with 5.9, running standard X and plasma.
El miércoles, 25 de noviembre de 2020 11:33:10 (CET) John Paul Adrian Glaubitz escribió:
Hi!
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else. Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver.
In my case, my screen gets garbled and after a while my laptop freezes. It also happens randomly. I'm running KDE Plasma/X11 on Tumbleweed 20201114 and my laptop has an UHD Graphics 600. I have the compositor enabled. On a desktop computer with Intel graphics (Z36xxx/Z37xxx Series Graphics & Display) and the same version of Tumbleweed, Plasma freezes (no screen garbled). This is also on X11. Solution: disabling composition. Greetings, -- Javier Llorente
On 26-11-2020 17:30, Javier Llorente wrote:
El miércoles, 25 de noviembre de 2020 11:33:10 (CET) John Paul Adrian Glaubitz escribió:
Hi!
Ever since my machine got upgraded to kernel 5.9.x, my Tumbleweed installation is randomly locking up (KDE, X11). Booting into the last 5.8.x kernel fixes the problem, so it's definitely related to the kernel and not anything else. Does anyone else see such lockups? This is on a Dell E7470 laptop with Intel Skylake graphics (Skylake GT2 [HD Graphics 520]), in case it might be related to bugs in the GPU driver. In my case, my screen gets garbled and after a while my laptop freezes. It also happens randomly. I'm running KDE Plasma/X11 on Tumbleweed 20201114 and my laptop has an UHD Graphics 600. I have the compositor enabled.
On a desktop computer with Intel graphics (Z36xxx/Z37xxx Series Graphics & Display) and the same version of Tumbleweed, Plasma freezes (no screen garbled). This is also on X11. Solution: disabling composition.
Greetings, -- Javier Llorente
I have seen some references to Intel graphics, but my system with an old 9600GT and having a Phenom II processor has the same issues. Most notably when I switch screens, they are lagging behind, doing partial screen moves and continue after a few seconds. Had the same also when editing text etc. It has made TW now unusable for some weeks. 15.2 as well as latest 5.8 kernel don't have this issue. --- Frans. -- A: Yes, just like that A: Ja, net zo Q: Oh, Just like reading a book backwards Q: Oh, net als een boek achterstevoren lezen A: Because it upsets the natural flow of a story A: Omdat het de natuurlijke gang uit het verhaal haalt Q: Why is top-posting annoying? Q: Waarom is Top-posting zo irritant?
participants (21)
-
Andreas Schwab -
Andrei Borzenkov -
Bengt Gördén -
Christian Mahr -
Cor Blom -
Dominique Leuenberger / DimStar -
Felix Miata -
Frans de Boer -
Jan Engelhardt -
Javier Llorente -
Jiri Slaby -
Joe -
John Paul Adrian Glaubitz -
Juan Erbes -
Manfred Hollstein -
Neal Gompa -
Patrick Shanahan -
Peter Suetterlin -
Robert Kaiser -
Stratos Zolotas -
Thomas Zimmermann