El mié, 25 nov 2020 a las 8:58, John Paul Adrian Glaubitz () 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

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

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

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 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."

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/

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

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 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 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

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

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

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 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...

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_...Jump to search https://linuxreviews.org/Linux_5.9-rc7_Is_A_Total_Disaster_On_Machines_With_... 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 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 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 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?

* Juan Erbes [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 () 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

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

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

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

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

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?