MX Linux Forum

Paul.. wrote: Thu Dec 06, 2018 8:48 pm

Code: Select all

 I'm using the 4.15.5-antix.1-amd64-smp and I checked CONFIG_RCU_NOCB_CPU=y

If the Typical Current Idle works the way its supposed to do, a rcu_nocbs-parameter should not be necessary.

@richb Thank you richb. I know just enough to be dangerous.

paulfsams wrote: Thu Dec 06, 2018 9:37 pm @richb Thank you richb. I know just enough to be dangerous.

Don't worry I am in the same boat.

I am trying to install the 4.19.4-antix.1-amd64-smp kernel with the MX Package installer.
This may be useful as it was the 4.15 antix kernel that was stable. I think as caprea wrote, the antix kernels have another rcu parameter set so the rcu_nocbs=0-11 fix for Ryzen crashing. There may also be some new BIOS fixes that Paul is testing that may make the parameter un-necessary. Though reading on AMD boards, some report that it is still necessary. I think it is way too complex, and may depend on the motherboard, the BIOS, the kernel, and on maybe even the power supply !

But it hangs up with this message
:

Nomacs image viewer stopped following system theme in my system sometime between yesterday and today. I'm Mx18b1

The MX Welcome window cannot be minimized. Okay, but... after closing it, a brand new user would need to hunt for it.
If a desktop icon for it isn't amenable, please at least consider listing it among the WhiskerMenu "favorites".

Quick access to MX User Manual is a standout feature. IIRC, what tripped me up while wearing my "noob user" tester hat:
When MXUM is launched from the welcome dialog, the welcome dialog autohides (and no taskbar item for it).
Please consider using nohup or disown in the Welcome--}MXUM launchstring, as well as for a select few other launchers presented within the Welcome dialog.

_________________

The panel icon contains a paperclip icon. No mouseover "hint" is provided for that item (suggest adding hint text).
Left click on paperclip icon does nothing. Upon right click, we discover it is the "clipit" clipboard manager utility.
While attempting to check whether the pre-assigned clipit "Hot Key" keybinds conflict with the predefined firefox shortcut keybinds, I discovered a clipit bug.
-=-
When the clipit preferences window is open (but not necessarily focused), pressing Ctrl+Alt+h causes clipit to hang // becomes unresponsive & must be killed.
Launched from commandline, we can note the details of the "gtk:Critical" error. I reckon this is something that must be fixed by the upstream maintainer.
-=-
Separately, upon entering a fresh session, I noted that htop indicates THREE clipit processes are running.
After "killall clipit" and launching from commandline, yep, three clipit processes (hmm, or are they just multiple "threads" of one precess?)

__________________

noticed: Volume Label of the LiveUSB is "antiXlive". Maybe you'll want to replace that with "MXlive"?

skidoo wrote: Fri Dec 07, 2018 2:10 am The panel icon contains a paperclip icon. No mouseover "hint" is provided for that item (suggest adding hint text).
Left click on paperclip icon does nothing. Upon right click, we discover it is the "clipit" clipboard manager utility.
While attempting to check whether the pre-assigned clipit "Hot Key" keybinds conflict with the predefined firefox shortcut keybinds, I discovered a clipit bug.
-=-
When the clipit preferences window is open (but not necessarily focused), pressing Ctrl+Alt+h causes clipit to hang // becomes unresponsive & must be killed.
Launched from commandline, we can note the details of the "gtk:Critical" error. I reckon this is something that must be fixed by the upstream maintainer.

(Checked on 2xMX-18 installs.)

Both L-click and R-click do exactly the same thing here - open the ClipIt dialogue. That's not new behaviour; ClipIt has always been like that.

With ClipIt Preferences open, Ctrl-Alt-h just flashes the currently open tab. It performs normally afterwards, with no need to kill it.

I agree a tool-tip would be a useful addition.

Chris

skidoo wrote: Fri Dec 07, 2018 2:10 am Separately, upon entering a fresh session, I noted that htop indicates THREE clipit processes are running.
After "killall clipit" and launching from commandline, yep, three clipit processes (hmm, or are they just multiple "threads" of one precess?)

htop here only shows one instance of ClipIt on boot. If I launch it from the terminal, it starts with a message about the Ctrl-Alt-H keybinding failing. A second instance starts, as shown by two icons on the panel. htop then shows two running instances. That is expected behaviour.

Not sure what is going on with your install, but it's not happening here.

Chris

caprea wrote: Thu Dec 06, 2018 9:34 pm

Paul.. wrote: Thu Dec 06, 2018 8:48 pm

Code: Select all

 I'm using the 4.15.5-antix.1-amd64-smp and I checked CONFIG_RCU_NOCB_CPU=y

If the Typical Current Idle works the way its supposed to do, a rcu_nocbs-parameter should not be necessary.

Ran all night with no problems using: Typical Current Idle + rcu_nocbs + 4.15.5-antix.1-amd64-smp

Will remove rcu_nocbs today and see...

Thanks caprea!!

How can I place a screensaver? The option does not appear and neither Grub-customizer.