SLED 12 - USB Mouse and Keyboard Freeze Issue after upgrade

SUSE Product Topics SLED Hardware
1

Hardware:
Intel NUC DCCP84DYE
2GB RAM
30GB Intel Mini-Sata SSDM
Microsoft Wireless Keyboard 800
Microsoft Wireless Mouse 1000
All hardware tests fine - all of the above is less than 3 months old.

Issue:
This unit was previously running a fully patched minimum SLED 11 SP3 Gnome Configuration. We several dozen of these units in the exact same configuration used primarily as thin clients for xfreerdp with absolutely no issues. For about two weeks I have been running minimum SLED 12 x64 Gnome Configuration as a test of SLED 12. This unit was upgraded to save as much of the SLED 11 configuration as possible - it was not a clean install. Beyond some nagging basic Gnome configuration issues (like: why can’t I change the colors of the bottom panel???) the mouse and keyboard randomly freeze using xfreerdp, or firefox (typing this message it happened twice) or anything at all. It can run for hours with no issues or it can happen three times in five minutes. I unplug the MS Model 1461 Wireless USB Receiver/Transmitter and plug it back in and all is fine. Before someone asks, just added new batteries today and the issue persists. I have been trying to capture the log files at the time of freeze, but I have not been successful in capturing enough to understand what is actually causing the freezing. (On a side note we also inplace upgraded two previously working HP DL360/160 G6’s from SLES 11 SP3 X64 to SLES 12 and we are seeing the same issue with completely different hardware. I will post appropriately). I was hopeful someone else may have either experienced this and might have an idea what the root cause is, or can give us a method to start troubleshooting it.

Thanks,

Kevin

2

So you have the same problemwith both SLED 12 after upgrading from SLED 11 and SLES 12 after upgrading from SLES 11 and on different hardware. Is there any common configuration that you apply to both SLED and SLES installs?

First thing I’d do would be be a clean install of SLED 12 on one of the machines to see if the issue occurs.

Is it just keyboard/mouse input freezing? I.e. can you ssh in to the machine whilst the input is frozen?

When the keyboard/mouse input freezes, does it remain frozen indefinitely until you unplug the USB receiver and plug it back in again, or does it unfreeze of it’s own accord? (If the latter, If you run System Monitor, does the CPU usage history show any spikes corresponding to the input freeze?)

Does the issue occur with a wired keyboard and mouse?

Because GNOME 3 provide the same level of customisation that GNOME 2 did.

3

Mike,

Thanks for the reply.

Q. So you have the same problemwith both SLED 12 after upgrading from SLED 11 and SLES 12 after upgrading from SLES 11 and on different hardware. Is there any common configuration that you apply to both SLED and SLES installs?

A. Both were upgraded. Both are from SLE 11 SP3 x64 and are now SLE 12 x64. That’s it.

Q. First thing I’d do would be be a clean install of SLED 12 on one of the machines to see if the issue occurs.

A. Already in progress by another tech. Would like to understand what exactly this issue is however - why even offer an upgrade path if it really isn’t supported? An upgrade on the rest of our hardware will save us a lot of time messing with clean installs/migrations.

Q. Is it just keyboard/mouse input freezing? I.e. can you ssh in to the machine whilst the input is frozen?

A. Yes, ssh works fine as does VNC. Just the input from keyboard/mouse stops.

Q. When the keyboard/mouse input freezes, does it remain frozen indefinitely until you unplug the USB receiver and plug it back in again, or does it unfreeze of it’s own accord? (If the latter, If you run System Monitor, does the CPU usage history show any spikes corresponding to the input freeze?)

A. I suspect it will come back as when we leave these units on overnight after lockup, they are fine in the morning. I will try to run system monitor to see if there is a spike when this occurs and how long it really lasts.

Q. Does the issue occur with a wired keyboard and mouse?

A. Yes.

Q. Because GNOME 3 provide the same level of customisation that GNOME 2 did.[/QUOTE]

A. If that is the case, then I am either asking the question incorrectly or I am missing something painfully obvious. I did not specify, but I am actually using SLE Classic, but is Suse’s combination of the “two versions of gnome” from a usability stand point I suppose. In SLE 11 I can right click the gnome-panel “task bar” and set transparency, background color, images, etc. With SLE 12 - I can not. Perhaps I am missing a gnome-control-panel option or something (perhaps I need to install a missing RPM or something that is not included in the base install) - but even the Gnome “global dark theme” will not change the color of the gnome-panel “task bar”. I can’t seem to find the correct gnome tweak configuration file to set the colors at all…

Thanks,

Kevin

4

To clarify:

Q. When the keyboard/mouse input freezes, does it remain frozen indefinitely until you unplug the USB receiver and plug it back in again, or does it unfreeze of it’s own accord? (If the latter, If you run System Monitor, does the CPU usage history show any spikes corresponding to the input freeze?)

A. Yes, for at least 60 seconds it is “frozen” until we unplug/plug in the usb. I suspect it will come back as when we leave these units on overnight after lockup, they are fine in the morning. I will try to run system monitor to see if there is a spike when this occurs and how long it really lasts.

5

[QUOTE=salisburyk;25646]Would like to understand what exactly this issue is however - why even offer an upgrade path if it really isn’t supported? An upgrade on the rest of our hardware will save us a lot of time messing with clean installs/migrations.
[/QUOTE]
It would certainly be interesting to know what the issue is, especially given the scope of it. I’m afraid I’m stumped as to what it could be though. Something USB related maybe, given that it happens with different keyboard/mouse and ssh sessions are OK.

If what you descibe is a problem inherent in SLE 12 installs that have been upgraded from SLE 11 that seems like something SUSE should be aware of by now. Are you able to raise a Service Request with SUSE?

Where are you getting that an upgrade “really isn’t supported” from? The SLED 12 deployment guide describes two supported methods of upgrading the SLED 11 SP3 - did you use one of those?
https://www.suse.com/documentation/sled-12/book_sle_deployment/data/sec_update_sle12.html

You are not asking the question incorrectly. I think maybe what you’re missing is that SLE Classic is GNOME 3 with some SUSE customisation and possibly also that GNOME 3 is a completely new thing with very little in common with GNOME 2. GNOME 3 simply does not allow anywhere near the same amount of appearance configuration options that GNOME 2 did. (A very great deal has been written about this and other aspects of GNOME 3 since it’s initial release.)

I can’t just see it explained in the SLED 12 documentation anywhere, but there are three variants of GNOME 3 available in SLED 12.

GNOME - This is the full GNOME 3 ‘experience’.

GNOME Classic - This is an upstream variant of GNOME 3 that was introduced in response to (a lot) of (negative) feedback regarding GNOME 3. It is essentially of collection of extensions put together and supported by GNOME that provides things like the bottom panel and the Application and Places menus. It removes the ‘Huh?’ factor of logging in and having nothing familiar on screen.

SLE Classic - This is unique to SLED and the default on SLED 12. It’s the result of SUSE hacking on GNOME Classic to remove the top panel because evidently they thought it was better to do that than simply making GNOME Classic the default. It provides a very thin veneer of consistency with GNOME 2 on SLED 11, where SUSE similarly removed the top panel that is present in the default upstream configuration.

I briefly looked at changing the colour of the panel in SLE Classic a while back. It can be done by hacking the CSS files in /usr/share/gnome-shell/theme but that’s obviously a long way from ideal and any changes will be lost when the package the file you’ve hacked gets upgraded. I suspect it’s possible to change it as part of a theme, but I’ve not got around to trying. If it can be changed via a theme the Global Dark Theme evidently doesn’t include the necessary configuration.

6

Mike,

A1. Just to add to this - VNC is also fine. I agree that this points to the USB as well, but I see no errors in any logs that indicates what the issue actually is. There doesn’t appear to be more than a 10% spike in CPU, but I did not have top running to see what the culprit was only system monitor. (I am running it now and will report the process list back if it locks up before I wipe it later today.) The Intel NUC and HP DL360/160 series are very common hardware however, and one would think others would be seeing the same issues on an upgrade to SLE 12. Perhaps we’re the only ones who were silly enough to try a direct upgrade from 11 SP3. So far, the other tech has had no issues on the clean install for both SLES/SLED 12, which means we will just plan to migrate our services SLES/SLED to new hardware/new SLES. Yes we could raise an SR, but at this point if we have no issues with the clean install we won’t bother - to us this shows a general lack of quality in the upgrade testing and who knows what other issues are going to crop up on us (which makes sense - I would spend my testing dollars mostly on clean installs too as there are too many hardware platforms to seriously test upgrades on). So with this in mind, at this point, I think I am done testing the direct upgrades anyway.

A2. Since I’ve been testing, I have read a lot of negatives on Gnome 3 on many distros. Off and on I played with various versions of openSuSE and did not think it was all that bad (but I never used it seriously). The Gnome 3.10+ releases seemed to reach some user consensus that it was better and resolved many issues. To date, it’s been OK for me using SLE Classic on the desktop and although I’m not too fond of it on the server, I can get used to it. The general usability issues are arguable (see all the Windows 8 fun), but eliminating basic features like the ability to easily change colors in core gnome UI features seems ridiculous for a daily desktop OS. It also makes it very difficult to use it for speciality uses like Thin Clients or Kiosk PCs. Gnome was never the best choice for our xfreerdp thin clients anyway due to it’s memory footprint (it just seemed to be the best documented for customization and automation under SLE 11 - all things that are now gone under SLE 12). Is there a good, SUSE supported alternative we should try for SLE 12 thin client builds?

On a side note, generally speaking, SUSE has been great for us and we have high hopes for SLE 12. :slight_smile:

Thanks for listening,

Kevin

7

I wouldn’t upgrade productions from SLED 11 to SLED 12, I’d do a clean install of SLED 12. I’d do the same for any major version update of any distro. I find it the easiest course. I want all the machines I manage to be set up the same. New machines that arrive and have SLED 12 put on them should be set up the same as machines that once had SLED 12 on them. The easiest way to ensure that when migrating to a new major version is to re-install the existing machines. With installation automated using AutoYaST re-installing a machine is negligible effort.

Apart from the aforementioned GNOME variants, the only other Desktop Environment included in SLED 12 is IceWM. It has many themes included. Though on both the machines I’ve just tried IceWM on the mouse pointer is invisible, thus rendering it pretty much unusable. It was OK when I tried it during the Beta phase. :confused:

The panel colour in SLE Classic is not affected by per-user themes* because the panel background colour is specified as !important. Lines 8-9 of /usr/share/gnome-shell/theme/sle-classic.css

#panel { background-color: #e9e9e9 !important;
It’s the same in gnome-classic.css. (sle-classic and gnome-classic are actually identical except for one change to deal with SUSE removing the top panel). Removing ‘!important’ causes the panel colour to be affected by user themes and the Global Dark Theme. If you really want to change the panel colour you can hack sle-classic.css and then put something in place to ensure that your modifications get re-applied in the event that the gnome-shell-classic package gets updated. Obviously this isn’t a per-user thing though, it affects all users. (To test changes to sle-classic.css press Alt-F2 then run the command ‘r’ to reload GNOME Shell.)

8

Looks like this a known issue that doesn’t affect all setups. A workaround is

$ gsettings set org.gnome.settings-daemon.plugins.cursor active false

It is possible to get an xterm window up to type that even in the absence of a mouse pointer because right clicking anywhere on the background in IceWM brings up the IceWM menu.

9

Mike,

This worked, and it appears IceWM will work quite nicely for a thin client Window Manager.

Thanks for the assistance,

Kevin