[opensuse] X (?) hangs after upgrade to 42.2
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? -- 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 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. I haven't tried the text console, but I could connect with ssh. 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. 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.
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.
-- 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: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 5 March 2017 at 22:28, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> wrote:
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.
Yes, it has happened again and Ctrl-Alt-Backspace worked. 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. -- 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 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 00:43, Carlos E. R. <robin.listas@telefonica.net> 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? -- 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. <robin.listas@telefonica.net> 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))
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 03/05/2017 02:08 PM, Mikhail Ramendik wrote:
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 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... FWIW, give this a shot the next time, and there are lots of reports about the problem if you Google it.... HTHs Marc Chamberlin -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6 March 2017 at 01:44, Marc Chamberlin <marc@marcchamberlin.com> 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:53, 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...
Then try XFCE. It handles USB drives automatically. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
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
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
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
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) Gruß Jan -- Expenditures rise to meet available income. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
Gruß Jan I have a "Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller", with i915 driver.
-- 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 Tuesday, 7 March 2017 21:12:59 CET Jan Ritzerfeld wrote:
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.
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. there are lots to pick from on the arch page and perhaps the more experienced on this forum could give you more specific guidence. i added the bug report since you all seem to develop the problem on 42.2 (the bug is a problem for newer kernels, i.e. mine was listed as requiring the fix but worked without on 42.1) -- 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 <ndcunliffe@gmail.com> 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 6 March 2017 at 19:38, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> wrote:
Yes, Intel i915 here: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
Intel here too! Looks like we have the same issue, possibly *not* the plasmashell issue. -- 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
If this happens again, try pressing Alt+F2 to bring up KRunner. If it comes up, you'll need to start plasmashell again. If not, I suspect this is an issue with KWin -- I think I've experienced this issue before and you need to run something like: kwin_x11 --replace in a terminal to reset it. It may need "DISPLAY=:0" in front of the command if it fails. I'm still not sure what is causing it or why it occurs though. -- 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
* James Knott <james.knott@rogers.com> [03-06-17 08:54]:
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.
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). -- (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 03/06/2017 09:10 AM, Patrick Shanahan wrote:
* James Knott <james.knott@rogers.com> [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
* James Knott <james.knott@rogers.com> [03-06-17 09:19]:
On 03/06/2017 09:10 AM, Patrick Shanahan wrote:
* James Knott <james.knott@rogers.com> [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.
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". -- (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 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
* James Knott <james.knott@rogers.com> [03-06-17 10:35]:
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.
I am sure it is being looked at. I had the same problem for quite a while in Tw, but not in the last several weeks. Hopefully you will see it soon. -- (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 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@rogers.com> [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 03/08/2017 12:42 PM, Patrick Shanahan wrote:
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.
* James Knott <james.knott@rogers.com> [03-08-17 12:25]: 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. -- 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 <james.knott@rogers.com> 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
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., "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 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. -- 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
* David C. Rankin <drankinatty@suddenlinkmail.com> [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
On 11 March 2017 at 21:47, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
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).
The fact is that on my system (originally Leap 42.1, upgraded to 42.2) Ctrl-Alt-F1 does switch to a text terminal, and Ctrl-Alt-F7 brings back the graphics. WIth the hang, it still does bring back the graphics, but hung as before. I have now had another hang. Chrome was active but not maximized; I was not able to switch to the window under it, a terminal, by clicking on it. Yakuake was already installed, but F12 did not bring it up. So this is probably NOT the plasmashell issue. Next, I will try UXA. And after that I will try not using Chrome. (Give a try to Midori, probably, with Firefox as a backup). If UXA and "no Chrome" do not help I will try noaccel and modesetting, but if either of these work, I can't accept the workaround. I need to run a 3D game from time to time. So if these work, I will have to try and find the kernel from 42.1 (4.1.12) built for 42.2. A last resort is to go to tumbleweed or else back to 42.1 (the latter is probably a fresh install?) Or perhaps noaccel does not affect 3D? Some sources say "disable acceleration" but others say "disable 2D acceleration" - I'll have to check this one out. I don't terribly need 2D acceleration, it's not like I'm using a ton of desktop effects.
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
you know you are running on tty7, otherwise you should see tty1.
13977 tty7 Ssl+ 0:13 /usr/bin/X -nolisten tcp -auth /run/sddm/{97f3d208-96f6-4020-9211-664783763cfa} -background none -noreset -displayfd 19 vt7 -- 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 11 March 2017 at 23:36, Mikhail Ramendik <mr@ramendik.ru> 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 looked around in "Configure Desktop" and in Hardware > Display and Monitor found Compositor. The Rendering backend was set to OpenGL 2.0. I changed it to XRender and the blinking was fixed. Putting it here in case someone googles. As the hang was associated with Chrome, I now suspect that the hang, too, was linked to this incompatibility between Chrome (likely Chromium too) and OpenGL compositing. I will see if this current configuration can produce the hang over a good few hours of use. If it does not produce the hang, I will perhaps try bringing back SNA but keeping XRender compositing. UXA does not sem to affect 3D performance negatively. I do not see tearing in videos. Perhaps I'll benchmark 3D in UXA vs SNA one day. 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? -- 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
Am Sonntag, 12. März 2017, 01:07:34 CET schrieb Mikhail Ramendik:
On 11 March 2017 at 23:36, Mikhail Ramendik <mr@ramendik.ru> 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
I have submitted a bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1030043 I would appreciate if Jan and anyone else who also experiences the issue would leave notes in the bug confirming it. On 18 March 2017 at 14:19, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> wrote:
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
-- 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 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
On 03/11/2017 07:05 PM, Felix Miata wrote:
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.
+1 No complaint with the way Leap 42.2 maintained the traditional vt7 for the display. kdm/kde3 has been flawless, lightning fast and stable allowing you to concentrate on one thing only -- getting work done -- as it should be... -- 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
On 6 March 2017 at 14:10, Patrick Shanahan <paka@opensuse.org> 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? -- 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
* Mikhail Ramendik <mr@ramendik.ru> [03-06-17 11:38]:
On 6 March 2017 at 14:10, Patrick Shanahan <paka@opensuse.org> 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
On 03/06/2017 01:03 PM, Patrick Shanahan wrote:
* Mikhail Ramendik <mr@ramendik.ru> [03-06-17 11:38]:
On 6 March 2017 at 14:10, Patrick Shanahan <paka@opensuse.org> 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.
I created a script to run, instead of having to remember that command. -- 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 <james.knott@rogers.com> 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
On 03/05/2017 04:08 PM, Mikhail Ramendik wrote:
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.
What model ATI card? -- 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
participants (11)
-
Carlos E. R. -
David C. Rankin -
Felix Miata -
James Knott -
Jan Ritzerfeld -
John Andersen -
Karl Cheng -
Marc Chamberlin -
Mikhail Ramendik -
nicholas -
Patrick Shanahan