After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
The problem computer is a Gateway NV79 laptop, with an Intel i3 CPU. lshw: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz 4 cores. Specifically, I'm happily using the "System Load" plasmoid on Debian 11 on another i3 (Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz) and just installed the "Individual Core Usage" plasmoid, which also works fine. But neither work on the NV79 after upgrading from Debian 11 to Debian 12. It seems they can't find the proper sensors. On the working i3, "Individual Core Usage" -> "Sensor Details" show CPU 1 CPU2 CPU3 CPU 4. On the non-working one, no amount of clicking on the "Sensors" field produce anything. On the non-working NV79, neither plasmoid produce any output. Debian 11, per aptitude (kde-full) reports 5:111 Debian 12, per aptitude (kde-full) reports 5:142 Another data point: On a Mac Pro, Debian 12 (kde-full 5:142) with 2 Intel(R) Xeon(R) CPUs E5320 @ 1.86GHz, 4 cores each: "Individual Core Usage" -> "Sensor Details" shows all 8 cores. "Individual Core Usage" works fine "System Load" produces no output. Any idea what the problem could be? I'm reluctant to upgrade my main system if things like this are going to break. Can I provide some spefic data that might help pinpoint the problem? Thanks. Augustine
Plasma freezes after login
Running Fedora 37/KDE/X11, latest update (5.27.6-2). When I log in to my regular user account, I see the plasma startup screen and the rotating gear on a black screen. After several seconds (longer than usual), a cursor is displayed and the gear stops rotating, but the screen remains blank and is unresponsive. All I can do is power off. When I log into a bare-bones account, after about 2 seconds the black screen is replaced by the wallpaper and everything looks OK. I have journalctl logs from the failing login and successful login, but I can’t see any errors or tell what the differences are. Are plasma errors logged somewhere else? I had this problem last week and recreated my login account from scratch and configured it as I had before, with virtual windows, display setting, etc. I was able to log into the newly created account without problem. It appears that I made some additional configuration change which has triggered this behavior, but I don’t know what it might be. http://eagerm.com/files/bad-kde – Failing login http://eagerm.com/files/good-kde – Successful login -- Michael Eagerea...@eagerm.com 1960 Park Blvd., Palo Alto, CA 94306
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tuesday September 12 2023 15:57:03 A. F. Cano wrote: >Another data point: On a Mac Pro, Debian 12 (kde-full 5:142) >with 2 Intel(R) Xeon(R) CPUs E5320 @ 1.86GHz, 4 cores each: >"Individual Core Usage" -> "Sensor Details" shows all 8 cores. > >"Individual Core Usage" works fine >"System Load" produces no output. > >Any idea what the problem could be? I'm reluctant to upgrade my main system >if things like this are going to break. Can I provide some spefic data that >might help pinpoint the problem? I don't know what backend your plasmoid uses, but 2 things you could try to see if more traditional utilities also have problems: 1) From a shell, run `sensors-detect` (as root, let it run all the tests it proposes) followed by `sensors`. 2) Also from a shell, run `solid-hardware list details` R.
Re: Plasma freezes after login
>the gear stops rotating, but the screen remains blank and is unresponsive. Can you switch to a virtual terminal (Ctrl-Alt-F1 for instance) or log in via ssh? (there are ssh apps for smartphones, in case you don't have another computer with them installed.) I've seen cases of full lock-out except from SSH as a result of a GPU freeze - the last one of those I had with my i915-driven eGPU was when trying out an Electron-based app that tried something a bit too fancy. (IOW, a modern desktop with all bells and whistles could have that same effect, I fear.) R.
Re: Plasma freezes after login
On 9/12/23 13:45, René J.V. Bertin wrote: the gear stops rotating, but the screen remains blank and is unresponsive. Can you switch to a virtual terminal (Ctrl-Alt-F1 for instance) or log in via ssh? (there are ssh apps for smartphones, in case you don't have another computer with them installed.) Ctrl-Alt-F1 is not responsive. I've seen cases of full lock-out except from SSH as a result of a GPU freeze - the last one of those I had with my i915-driven eGPU was when trying out an Electron-based app that tried something a bit too fancy. (IOW, a modern desktop with all bells and whistles could have that same effect, I fear.) I can try SSH. -- Michael Eager
Re: Plasma freezes after login
On 9/12/23 14:21, Michael Eager wrote: On 9/12/23 13:45, René J.V. Bertin wrote: the gear stops rotating, but the screen remains blank and is unresponsive. Can you switch to a virtual terminal (Ctrl-Alt-F1 for instance) or log in via ssh? (there are ssh apps for smartphones, in case you don't have another computer with them installed.) Ctrl-Alt-F1 is not responsive. I've seen cases of full lock-out except from SSH as a result of a GPU freeze - the last one of those I had with my i915-driven eGPU was when trying out an Electron-based app that tried something a bit too fancy. (IOW, a modern desktop with all bells and whistles could have that same effect, I fear.) I can try SSH. I can log in remotely using SSH, into the same account with the locked screen. There's essentially zero CPU usage. Plasmashell is running. Running "killall -u " brings the system back to the login window.
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tue, Sep 12, 2023 at 10:37:51PM +0200, René J.V. Bertin wrote: > On Tuesday September 12 2023 15:57:03 A. F. Cano wrote: > > >Another data point: On a Mac Pro, Debian 12 (kde-full 5:142) > >with 2 Intel(R) Xeon(R) CPUs E5320 @ 1.86GHz, 4 cores each: > >"Individual Core Usage" -> "Sensor Details" shows all 8 cores. > > > >"Individual Core Usage" works fine > >"System Load" produces no output. > > > >Any idea what the problem could be? I'm reluctant to upgrade my main system > >if things like this are going to break. Can I provide some spefic data that > >might help pinpoint the problem? > > I don't know what backend your plasmoid uses, but 2 things you could try to > see if more traditional utilities also have problems: > > 1) From a shell, run `sensors-detect` (as root, let it run all the tests it > proposes) followed by `sensors`. Mmm... This seems geared to temp sensors, but here's the output: $ sudo sensors-detect # sensors-detect version 3.6.0 # System: Gateway NV79 [V1.05] (laptop) # Kernel: 6.1.0-12-amd64 x86_64 # Processor: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz (6/37/2) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): yes Module cpuid loaded successfully. Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors...No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor...No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): yes Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): yes Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): yes Using driver `i2c-i801' for device :00:1f.3: Intel 3400/5 Series (PCH) Module i2c-dev loaded successfully. Next adapter: SMBus I801 adapter at 3000 (i2c-0) Do you want to scan it? (YES/no/selectively): yes Client found at address 0x50 Handled by driver `at24' (already loaded), chip type `spd' (note: this is probably NOT a sensor chip!) Client found at address 0x52 Handled by driver `at24' (already loaded), chip type `spd' (note: this is probably NOT a sensor chip!) Next adapter: i915 gmbus ssc (i2c-1) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus vga (i2c-2) Do you want to scan it? (yes/NO/selectively): yes Next adapter: i915 gmbus panel (i2c-3) Do you want to scan it? (yes/NO/selectively
Re: Plasma freezes after login
On Tuesday September 12 2023 14:35:19 Michael Eager wrote: >I can log in remotely using SSH, into the same account with the locked >screen. There's essentially zero CPU usage. Plasmashell is running. > >Running "killall -u " brings the system back to the login window. It's surprising that you can't get to a virtual console; the shortcuts for that are handled by ConsoleKit, and they have often been my salvation if the X11 mouse or keyboard input/control got messed up. /var/log/syslog may contain something useful, and there must be a logfile that has all the output from the startkde process that bootstraps your desktop and thus from every process that gets launched via the desktop shell. On my Trusty old system those logs live in ~/.cache/upstart, no idea where they are on a more modern system. R.
Re: Plasma freezes after login
On 9/12/23 15:23, René J.V. Bertin wrote: On Tuesday September 12 2023 14:35:19 Michael Eager wrote: I can log in remotely using SSH, into the same account with the locked screen. There's essentially zero CPU usage. Plasmashell is running. Running "killall -u " brings the system back to the login window. It's surprising that you can't get to a virtual console; the shortcuts for that are handled by ConsoleKit, and they have often been my salvation if the X11 mouse or keyboard input/control got messed up. CTRL-ALT-F1 displays the grub splash screen. I can get a virtual console with CTRL-ALT-F3. Oddly enough, I can log in on this virtual console, run startx, and get a plasma screen. /var/log/syslog may contain something useful, and there must be a logfile that has all the output from the startkde process that bootstraps your desktop and thus from every process that gets launched via the desktop shell. On my Trusty old system those logs live in ~/.cache/upstart, no idea where they are on a more modern system. /var/log/syslog no longer exists. Nothing in .cache which looks like a log file. -- Michael Eager
