Am Sonntag, 5. März 2017, 17:16:01 CET schrieb James Knott:

On 03/05/2017 05:08 PM, Mikhail Ramendik wrote:

...

Suddenly, things on the graphical screen stop responding. The mouse cursor moves but nothing can be clicked. In both cases so far, Google Chrome was the visible application and was maximized; neither Chrome nor the task bar would respond to any clicks, and there was no response to keyboard actions on the graphical screen.

I have also experienced this with 42.2.

Me too.

I haven't tried the text console, but I could connect with ssh.

Text Console worked here.

The only way to clear it was press Ctrl-Alt-Backspace a few times, until the desktop shut down and took me to the login screen.

Two times in a row were enough here.

I have also seen the desktop become very sluggish, where typed characters only appear after a few seconds, no response to the mouse wheel etc.

Maybe, I am not sure...

...

After the second hang, when the system booted up first and I logged on (KDE 5 Plasma as usual), there was apparently no WM. WIndows appeared without a header, minimize/maximize/close buttons, etc. After another reboot the windows are normal. This might or might not be the same issue - describing it in case it shows a clue.

I have seen this too. I don't have to reboot, just logout & in.

IIRC I never had this problem. Gruß Jan -- There are white lies, damn lies and statistics. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-03-06 01:36, Mikhail Ramendik wrote:

Could any of you remember what programs were active? I wonder if this can be linked to Chrome, as all three times I got it, Chrome was on the screen, maximized. If it happens one more with Chrome I'll try changing to Firefox or Midori temporarily.

Try not to maximize it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On 6 March 2017 at 01:44, Marc Chamberlin wrote:

I will throw in my two cents worth because I too have been experiencing a lot of freezes in Leap 42.2 as well on my laptop, but not on my desktops. The solution I have found, but only works for awhile before I get another freeze up, is to leave a Konsole window open at all times. When the freeze occurs, for me any open windows remain responsive, can be minimized and moved about, but the kicker bar and all plasma related things freeze. I go to the Konsole shell and do a - "killall plasmashell" and then restart the plasmashell as a background process - "plasmashell &" I do this under my own user account (does not work under root) which gets me back up and running. At first I thought it might be related to Firefox and Thunderbird because I use those apps all the time, but now I don't think so because I have seen it happen when I only had OpenOffice or Eclipse up and running...

Thanks! So it might be a plasmashell issue. This means one way of geting out of it is just not using Plasma. I could go back to IceWM, which was my favourite for years on Debian before I got tired of Debian's release cycle and configuration style and went OpenSUSE. But then I can keep OpenSUSE - yast and all - just switch back to IceWM; not sure how the USB drive would be handled, though... And next time this happens, I'll try killall plasmashell from the text console. I will also check if a window can be minimised; I don't think I checked that much. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-03-06 03:55, Mikhail Ramendik wrote:

On 6 March 2017 at 00:43, Carlos E. R. wrote:

...

...

Could any of you remember what programs were active? I wonder if this can be linked to Chrome, as all three times I got it, Chrome was on the screen, maximized. If it happens one more with Chrome I'll try changing to Firefox or Midori temporarily.

Try not to maximize it.

What would that change?

Dunno. Just a hunch. Applications get more control of the desktop when maximized. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

On Sunday, 5 March 2017 23:08:32 CET Mikhail Ramendik wrote:

Hello,

After upgrading to Leap 42.2 I have experienced a weird hang twice already. It never happened over a few months of running Leap 42.1.

Suddenly, things on the graphical screen stop responding. The mouse cursor moves but nothing can be clicked. In both cases so far, Google Chrome was the visible application and was maximized; neither Chrome nor the task bar would respond to any clicks, and there was no response to keyboard actions on the graphical screen.

I can still press Ctrl-Alt-F1 to switch to a text console. I used the text console, as root, to do "killall -9 chrome". But even with "chrome" gone from the output of "top", nothing changed on the graphics screen when I changed back to it with Ctrl-Alt-F7.

There was nothing in /var/log/Xorg.log.0 when I looked at it. The boot sequence and then, after a long time, "AIGLX: Suspending AIGLX clients for VT switch" - obviously a reaction to pressing Ctrl-Alt-F1 when the hang was already in progress. I could not find any way out except "shutdown -r now" on the root terminal screen.

After the second hang, when the system booted up first and I logged on (KDE 5 Plasma as usual), there was apparently no WM. WIndows appeared without a header, minimize/maximize/close buttons, etc. After another reboot the windows are normal. This might or might not be the same issue - describing it in case it shows a clue.

Is there anything I can do to troubleshoot further, either now or if the hang strikes again? to ask the obvious - this sounds similair to intel graphics issue?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/06/2017 04:13 AM, Karl Cheng wrote:

If this happens again, try pressing Alt+F2 to bring up KRunner. If it comes up, you'll need to start plasmashell again.

Although I can't say for certain, I don't think it's possible to do that. The desktop is completely locked up and the only thing I found to clear the desktop is to shut it down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/06/2017 09:10 AM, Patrick Shanahan wrote:

* James Knott [03-06-17 08:54]:

...

...

If this happens again, try pressing Alt+F2 to bring up KRunner. If it comes up, you'll need to start plasmashell again. Although I can't say for certain, I don't think it's possible to do

On 03/06/2017 04:13 AM, Karl Cheng wrote: that. The desktop is completely locked up and the only thing I found to clear the desktop is to shut it down. IF you have an active instance of konsole and can access it, you can restart plasmashell: kquitapp5 plasmashell && kstart5 plasmashell & disown

konsole is not frozen when plasmashell freezes. I use yakuake which is a special instance of konsole and used to restart plasmashell on freezes and other anomolies on Tw, which no longer occur (or I haven't observed for several months).

Open or not, I can't switch to it when the problem happens. I can click on open windows all I want but can't switch to them. The desktop is frozen. I can move the mouse pointer around, but nothing else. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/06/2017 09:36 AM, Patrick Shanahan wrote:

try yakuake, it responds with default <f12>, becomes active with mouse above and uses konsole instance. it may be that your mouse settings are causing a problem, mine are "focus follows mouse".

I'll give those a try, but it would be better if a fix could be found, rather than work arounds. Desktops shouldn't just lock up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On March 6, 2017 5:52:27 AM PST, James Knott wrote:

On 03/06/2017 04:13 AM, Karl Cheng wrote:

...

If this happens again, try pressing Alt+F2 to bring up KRunner. If it comes up, you'll need to start plasmashell again.

Although I can't say for certain, I don't think it's possible to do that. The desktop is completely locked up and the only thing I found to clear the desktop is to shut it down.

Well I suspect it will work. This bug worked its way through Manjaro some months ago and was eventually tracked down and fixed in a KDE upgrade or something related to sddm. I haven't had it occur on my Manjaro machine since installing lightdm, and enabling lightdm via systemd, and disabling sddm, and eventually uninstalling it. But when this lockup was happening it was possible to clear it with an ssh connection or alt-f2. I could probably post links to forum threads if it would be helpful. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Mikhail Ramendik [03-06-17 11:38]:

On 6 March 2017 at 14:10, Patrick Shanahan wrote:

...

IF you have an active instance of konsole and can access it, you can restart plasmashell: kquitapp5 plasmashell && kstart5 plasmashell & disown

Will this work from a text terminal? A terminal is definitely accessible via Ctrl+Alt+F1 and I could log on with the same user.

Also if this is proven to be plasmashell, leaving KDE for IceWM or Gnome seems to be the most reliable workaround?

I doubt it, but it would be very simple for *you* to try. it appears the terminal needs to be konsole and i have konsole available via yakuake. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Sonntag, 5. März 2017, 17:44:42 CET schrieb Marc Chamberlin:

[...] When the freeze occurs, for me any open windows remain responsive, can be minimized and moved about, [...]

Then at we do not have the same issue. I can move the mouse cursor but the UI is completely unresponsive. Gruß Jan -- If you understand what you're doing, you're not learning anything. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Montag, 6. März 2017, 00:36:48 CET schrieb Mikhail Ramendik:

[...] Could any of you remember what programs were active? I wonder if this can be linked to Chrome, as all three times I got it, Chrome was on the screen, maximized. If it happens one more with Chrome I'll try changing to Firefox or Midori temporarily.

Now that you mention it, I do not remember any hang without a maximized chromium! Gruß Jan -- No other person has the right to decide what is moral (right or wrong) for you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Monday, 6 March 2017 20:43:54 CET James Knott wrote:

On 03/06/2017 02:38 PM, Jan Ritzerfeld wrote:

...

Am Montag, 6. März 2017, 08:39:25 CET schrieb nicholas:

...

[...] to ask the obvious - this sounds similair to intel graphics issue?

Yes, Intel i915 here: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

I have a "Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller", with i915 driver.

if 3rd gen is baytrail then intel_idle.max_cstate=1 (https:// bugzilla.kernel.org/show_bug.cgi?id=109051) and the problem is not resolved by using modesetting or changing to uxa, Accel=False, and all the other tricks? https://wiki.archlinux.org/index.php/ intel_graphics -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Dienstag, 7. März 2017, 13:16:04 CET schrieb nicholas:

On Monday, 6 March 2017 20:43:54 CET James Knott wrote:

...

On 03/06/2017 02:38 PM, Jan Ritzerfeld wrote:

...

Am Montag, 6. März 2017, 08:39:25 CET schrieb nicholas:

...

[...] to ask the obvious - this sounds similair to intel graphics issue?

Yes, Intel i915 here: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

I have a "Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller", with i915 driver.

if 3rd gen is baytrail then intel_idle.max_cstate=1 (https:// bugzilla.kernel.org/show_bug.cgi?id=109051) [...]

Are you sure? James and my system are more likely Sandy Bridge of the Core Architecture. Bay Trail are Atoms: https://bugzilla.kernel.org/show_bug.cgi?id=109051#c700 This one is about Sandy Bridge: https://bugzilla.kernel.org/show_bug.cgi?id=193261 But I do not experience total hard lockups, my mouse cursor still moves, I can switch to vt1 or just kill the X and then login again. Gruß Jan -- Investment in reliability will increase until it exceeds the probable cost of errors, or until someone insists on getting some useful work done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 7 March 2017 at 20:44, nicholas wrote:

no im not sure but i had problems on 2 systems with intel and the had similair symptoms, (i was more asking if you had eliminated the usual subjects). changing to uxa on previous laptop worked for me, new skylake laptop works better with modesetting.

Thanks! My desktop where the problem happens is Ivy Bridge. And I actually need 3D acceleration, as I run a 3D application, so modesetting and other ways to disable acceleration are not acceptable. I can try uxa. (The two freezes so far happened when the application was NOT running). -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/05/2017 08:53 PM, Mikhail Ramendik wrote:

So it might be a plasmashell issue. This means one way of geting out of it is just not using Plasma. I could go back to IceWM, which was my favourite for years on Debian before I got tired of Debian's release cycle and configuration style and went OpenSUSE. But then I can keep OpenSUSE - yast and all - just switch back to IceWM; not sure how the USB drive would be handled, though...

And next time this happens, I'll try killall plasmashell from the text console. I will also check if a window can be minimised; I don't think I checked that much.

I'm not sure about that. I used plasma shell (current with git) and my laptop would run for weeks without reboot or slowdown (on Arch). On openSuSE Leap 42.2, I also run for weeks at a time without slowdown or need to switch to console (but running kdm/kde3). I am current running the nouveau after having switched to the nvidia proprietary driver, I had to switch back due to loss of backlight control. (the nvidia driver removed all backlight control from /sys/class/backlight) nouveau provides control through /sys/class/backlight/nv_backlight -- acpi_video0 is also present but it has no functionality. But with both nvidia and nouveau there is no slowdown experienced. Currently: $ uptime 00:36am up 8 days 13:11, 2 users, load average: 0.10, 0.14, 0.11 No issues. Based on this experience, the only thing I can discern is that if the common problem is plasma shell for all reporting slowdowns, and it cannot be limited to either ATI or Intel graphics, then my only guess would be an issue in the Leap build of plasma shell. Because on this hardware, running the current git release for FW5/plasma showed no slowdown on Arch, and I've experienced none on Leap with kde3. (or fluxbox or i3) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* James Knott [03-08-17 12:25]:

On 03/06/2017 10:33 AM, James Knott wrote:

...

On 03/06/2017 09:36 AM, Patrick Shanahan wrote:

...

try yakuake, it responds with default <f12>, becomes active with mouse above and uses konsole instance. it may be that your mouse settings are causing a problem, mine are "focus follows mouse". I'll give those a try, but it would be better if a fix could be found, rather than work arounds. Desktops shouldn't just lock up.

It just happened again and I was not able to run yakuake with F12.

then *probably* your problem was not plasma5 ???? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 8 March 2017 at 18:04, James Knott wrote:

...

...

It just happened again and I was not able to run yakuake with F12. then *probably* your problem was not plasma5 ????

I never said it was, just that the desktop locks up. When it did that today, I verified I was still able to ssh in, so it's just the desktop and not the entire system.

Happened again on my end. Chrome maximized again. Screen stopped updating, except the mouse pointer was moving. Music from Chrome kept playing. Killing plasmashell from the Ctrl-Alt-F1 terminal did not change anything. Had to restart X with Ctrl-Alt-Backspace. Yakuake was not installed at that moment. I have now installed it and also switched Chrome from maximized to just taking up most of the screen. Will see how this goes. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* David C. Rankin [03-11-17 16:49]:

On 03/11/2017 01:28 PM, Mikhail Ramendik wrote:

...

Killing plasmashell from the Ctrl-Alt-F1 terminal did not change anything. Had to restart X with Ctrl-Alt-Backspace.

You have to understand that with the new Wayland/Plasma desktop setup, the default configuration requires the desktop run on the login terminal (tty1) not as a virtual terminal (traditionally vt7). It can be configured either way, but the new default is to run the desktop on the login terminal. (I'm not exactly sure what drove the change other than differences with systemd and its effect on user session tracking) You need to confirm what your configuration is. If your desktop is running on the login terminal, doing Ctrl-Alt-F1 would not be expected to do anything. E.g.,

my tumbleweed logon session is active in vt6 and the graphical running in vg7. other vt# are available as long as I am in graphical, and available but text does not appear when I drop to multi-user.

"You are running on tty1 and telling the desktop to change to tty1 and expecting to see something happen?"

I haven't used plasma on openSuSE, just with Arch, and there the desktop does run on tty1. That may explain why you only see a change when killing the desktop. It is also why, depending on what form your upgrade took, you may have some lingering config issues. With the desktop running, open konsole (or xterm) and do 'ps ax | grep vt', if you see something like:

$ ps ax | grep vt tty7 Rs+ 11:12 /usr/bin/Xorg -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-vW7g8H

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 81 0.0 0.0 0 0 ? S Mar10 0:00 \_ [kdevtmpfs] root 10389 0.9 0.3 327944 124320 tty7 Ssl+ Mar10 10:23 \_ /usr/bin/X -nolisten tcp -auth //run/sddm/{63ffd863-371c-47d7-bc21-99b8476b7848} -background none //-noreset -displayfd 18 vt7

you know you are running on tty7, otherwise you should see tty1.

This is also another reason why I don't do upgrades. (and also why having a separate 'home' partition helps) I preserve home and any parts of /etc, /var and /srv I need, then do a fresh using existing partition for /home and restore any config tweaks, and there is no chance of any change in how 'component X' is configured between the new version and the last version.

have separate home, always, and upgrade every day :o) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David C. Rankin composed on 2017-03-11 15:47 (UTC-0600):

Mikhail Ramendik wrote:

...

Killing plasmashell from the Ctrl-Alt-F1 terminal did not change anything. Had to restart X with Ctrl-Alt-Backspace.

You have to understand that with the new Wayland/Plasma desktop setup, the default configuration requires the desktop run on the login terminal (tty1) not as a virtual terminal (traditionally vt7). It can be configured either way, but the new default is to run the desktop on the login terminal. The default in openSUSE (at least with Plasma, TDE and KDE3) remains where it has been since before my first exposure to SuSE early in the century:

The GUI login manager ([k|light|sd|t|x|?]dm) still runs on vtty7. Other distros, led by the systemd people at Fedora, moved it to vtty1, where it obliterates the login messages that can be allowed to stay in place, which I do (Plymouth not; and --noclear) and openSUSE did if not still does if Plymouth doesn't interfere, until and unless logging in there. What is now different in openSUSE, as in distros that did move the login manager to vtty1, is that without a login manager running, opening an X session from any of vtty[1-6] (e.g. startx), will run the X session on that same vtty, rather than on vtty7 as in the past. Running the display manager on vtty1 means that one less than the traditional quantity of 6 vttys remains available for other purposes. Without changing defaults, vtty[7-9] on others present nothing but black screens, while in openSUSE that only happens with 8 & 9. What those that moved the greeter to vtty1 should do is reconfigure so that all of vtty[2-9] present login screens, since additional X sessions run on the login vtty, maximizing the available vttys. I am happy openSUSE has so far chosen to maintain the tradition as much as it has, so that Ctrl-Alt-F1 presents a login prompt, and (Ctrl-)Alt-F7 returns to the GUI, as GUI troubleshooting has been directing since before my time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Sonntag, 12. März 2017, 01:07:34 CET schrieb Mikhail Ramendik:

On 11 March 2017 at 23:36, Mikhail Ramendik wrote:

...

So this is probably NOT the plasmashell issue. Next, I will try UXA. And after that I will try not using Chrome.

So I went onto UXA and found that Chrome, and apparently only Chrome, was getting some annoying blinking of the window header and tabs.

I have seen these since the update to 42.2, i.e., with SNA. I thought it was a Chromium bug [0] and tried some command line options (--disable-gpu-driver- bug-workarounds --enable-native-gpu-memory-buffers --force-gpu-rasterization) mentioned there with no effect. I removed them and since then I had no hangs again. So, according to chrome://gpu/ erverything in the first section is "Hardware accelerated" except "Native GpuMemoryBuffers" and "Rasterization", now.

[...] I have copied Jan Ritzerfeld as he seemed to have the same issue as I had. Jan - could you try changing Compositor to XRender and see if the issue goes away, too?

Thank you! I will try if the hangs come back. Or if I find a web site again that causes that blinking/flickering. [0]https://bugs.chromium.org/p/chromium/issues/detail?id=606152 Gruß Jan -- If at first you don't succeed, try someone else. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Sonntag, 12. März 2017, 10:52:19 CET schrieb Jan Ritzerfeld:

[...] Thank you! I will try if the hangs come back. Or if I find a web site again that causes that blinking/flickering.

Hangs came back. So I switched to XRender and no hangs since then and no blinking in Chromium. Thanks! Jan -- Law, without force is impotent. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org