Greeting Groovy Gorilla Kubuntu 20.10

[NoWorries]

Hi
No Worries posted about Kontact breaking and QT at the same time. . . . . . .

Kontact is of PARAMOUNT importance to me, giving the breakneck speed of things occuring with the college closing for the pandemic, now opening for a "nose up into the air"...me having two quarrantined students on day one, both fortunately, now out of quarrantine...soooooooo I have thought that the better part of valour FOR NOW is just to "stay with an OS that ain't broke"...

Any comments on this... in this thread or maybe another thread started by someone to address QT and "whatever" ?

woodjustthinkingsmoke.

I only had trouble with Kontact for a short period of time back at post #15 on 19/05/20. Since then it has been working like a charm and has been extremely stable.

A new version of QT might or might not get in before the release date, but I am sure that the developers will make sure that it will not compromise the performance of Groovy when it finally does become available.

The only problem I have with Groovy, and you could say I am not very happy about it, is that I cannot use the Kernel Version 5.8.0 as it does not correctly recognize my Intel CPU and my system runs at 800MHz instead of 3.1GHz or more. This makes my system extremely sluggish. So I boot my system with Kernel 5.4 which does know about the speed of my Intel CPU.

So glad that your students are now out of quarantine and hope you can continue to keep up your good work.

[woodsmoke]

Hi
No Worries posted about Kontact breaking and QT at the same time.

There has been mention of me not being able to access "as a pre-installed" folder in the left panel of Dolphin that the reason is that my install, which goes back to before Ermine on the Kparadigmshift machine does not play well with the new QT apps.

Kontact is of PARAMOUNT importance to me, giving the breakneck speed of things occuring with the college closing for the pandemic, now opening for a "nose up into the air"...me having two quarrantined students on day one, both fortunately, now out of quarrantine...soooooooo I have thought that the better part of valour FOR NOW is just to "stay with an OS that ain't broke"...

Any comments on this... in this thread or maybe another thread started by someone to address QT and "whatever" ?

woodjustthinkingsmoke.

[Radcliff]

20200904 iso

I did a fresh install on Saturday of the September 4th daily ISO, as usual for many weeks now, there was no incidences.

Kernel 5.8 and KDE 5.19.5 are in the box. Groovy is almost set to go and chances that Qt 5.15 will be in is low now (freeze phase is next door).

Last week was perfect again, KDE remains stable and fast here.

All the best,

Operating System: Kubuntu 20.10
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.73.0
Qt Version: 5.14.2
Kernel Version: 5.9.0-050900rc4-generic
OS Type: 64-bit
Processors: 8 × AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx
Memory: 7.5 GiB of RAM
Graphics Processor: AMD RAVEN

***

For the speed issue that OP encounters, re-enabling a few services (last week) did not introduce the CPU problem mention above. It is not related to a background service(s), at least for our AMD mobo.

sysbench --test=cpu run
Threads started!

CPU speed:
  events per second:  1806.02

General statistics:
  total time:                          10.0006s
  total number of events:              18065

Latency (ms):
       min:                                    0.53
       avg:                                    0.55
       max:                                    1.25
       95th percentile:                        0.58
       sum:                                 9930.23

Threads fairness:
  events (avg/stddev):           18065.0000/0.00
  execution time (avg/stddev):   9.9302/0.00

[NoWorries]

I decided to try booting Groovy into recovery mode and then entered the console. I found that cat/proc/cpuinfo | grep "MHz" gave the correct results. I decided to double check my Laptop CPU at: https://www.notebookcheck.net/HP-Spe....289806.0.html and found that it's CPU is rated between 3100 and 4100 MHz. So the system gave a value in this range. I took a photo of it and this is what it shows:



When I reboot, it then shows the CPU info with a string of 800MHz, ie

[FONT=monospace][COLOR=#000000]:~$ uname -r [/COLOR]
5.8.0-18-generic 
root@basil:~$ cat /proc/cpuinfo | grep "MHz" 
cpu MHz         : 800.072 
cpu MHz         : 800.012 
cpu MHz         : 800.123 
cpu MHz         : 800.196 
cpu MHz         : 800.009 
cpu MHz         : 800.143 
cpu MHz         : 800.062 
cpu MHz         : 800.086
[/FONT]

I am not sure how much of the Kernel is loaded at the recovery stage, but it appears that the problem with not getting the correct CPU Info occurs both before and after this point.

For those who are more familiar with the boot sequence, I am wondering if this helps locate the source of the problem. Is it the Kernel of some other installed software?

In order to get some action on this problem, I found a related bug in Launchpad and my comments have been added. You will find this at: https://bugs.launchpad.net/ubuntu/+s...ls/+bug/334577

[NoWorries]

IMO;
1. Report your findings as a bug.
2. Boot to the 5.4 by default kernel instead
3. Then try and figure out which kernel parameters are causing the problem and then build your own 5.8 kernel or just wait for the upgrade/bug fixes to work it out.

Thank-you for that advice. I unfortunately have to now use Kernel Version 5.4.0-42 to get useable desktop response and I don't disappoint my wife when she wants to do a Zoom session and she has to resort to using her iPad.

For the first time I have done a bug report on bugzilla. I am a newbie at this, so I hope I have done it correctly to get someone to take notice of it.

My bug report is at: https://bugzilla.kernel.org/show_bug.cgi?id=209085

[oshunluvr]

IMO;
1. Report your findings as a bug.
2. Boot to the 5.4 by default kernel instead
3. Then try and figure out which kernel parameters are causing the problem and then build your own 5.8 kernel or just wait for the upgrade/bug fixes to work it out.

[NoWorries]

Because I could not get any performance improvements from my system that I reported previously I did yet another download and installation of Groovy. This time it had the Kernal 5.8 and even with this, my system was still slow.

Because of this, I decided to select the pre-released updates and was updated with the 5.8.0-18-generic kernel. This made no difference to the speed.

I have another Laptop with Grovy installed and the same Kernel as well. This shows no sign of being slow. The important feature of this Laptop is that it was bought in 2012 and is an ASUS R501VM Core i7 3610QM. On the off-chance that my problems with my HP Spectre x360 15-ch004ng are because of the hidden files in my home directory. I copied them onto my ASUS. This did not affect the performance of the ASUS. However I had to adjust quite a few parameters on the ASUS because of the differnet screen resolutions and video driver.

I will also add that I have Kubuntu 20.04 LTS on the same drive as Kubunto 20.10. The LTS does not show any slow down even though it is using the same CPU but it has the 5.4 series kernel. I ran the sysbench tool on my LTS and got the following result:

sysbench --test=cpu run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
events per second:  1341.66

General statistics:
total time:                          10.0006s
total number of events:              13419

Latency (ms):
    min:                                    0.74
    avg:                                    0.75
    max:                                    1.27
    95th percentile:                        0.77
    sum:                                 9998.78

Threads fairness:
events (avg/stddev):           13419.0000/0.00
execution time (avg/stddev):   9.9988/0.00

On my Groovy system I got

sysbench --test=cpu run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
events per second:   277.08

General statistics:
total time:                          10.0008s
total number of events:              2773

Latency (ms):
    min:                                    3.53
    avg:                                    3.60
    max:                                    5.31
    95th percentile:                        3.75
    sum:                                 9995.59

Threads fairness:
events (avg/stddev):           2773.0000/0.00
execution time (avg/stddev):   9.9956/0.00

After doing all this, my impression is that the Kernel Version 5.8 series does not correctly access the parameters for my CPU, which is an 8xIntel Core i7-8705G CPU @ 3.10GHz. If I am correct, what is the best way to get this fixed?

[acheron]

KDE PIM 20.08 should have landed. Please test.

[Radcliff]

New Kernel Proposed Correction

A correction was made for the upgrade packages. Thanks!

sudo apt update && sudo apt upgrade -y
...
30 packages can be upgraded. Run 'apt list --upgradable' to see them.

[sudo] password

The following package was automatically installed and is no longer required:
libffi7
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
linux-headers-5.8.0-18 linux-headers-5.8.0-18-generic linux-image-5.8.0-18-generic
linux-modules-5.8.0-18-generic linux-modules-extra-5.8.0-18-generic
The following packages will be upgraded:
apport apport-kde cups cups-bsd cups-client cups-common cups-core-drivers cups-daemon
cups-ipp-utils cups-ppdc cups-server-common dictionaries-common libcups2 libcupsimage2
libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libflite1
libp11-kit0 linux-generic linux-headers-generic linux-image-generic nano python3-apport 
python3-problem-report sbsigntool usb.ids
...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.9.0-050900rc2-generic
Found initrd image: /boot/initrd.img-5.9.0-050900rc2-generic
Found linux image: /boot/vmlinuz-5.8.0-18-generic
Found initrd image: /boot/initrd.img-5.8.0-18-generic
Found linux image: /boot/vmlinuz-5.8.0-16-generic
Found initrd image: /boot/initrd.img-5.8.0-16-generic
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings
done
reboot

There is a rendering issue in Synaptic for long now (missing icons):

Commit Log for Thu Aug 27 08:30:23 2020

Completely removed the following packages:
linux-headers-5.8.0-16
linux-image-5.8.0-16-generic
linux-modules-5.8.0-16-generic

Removed the following packages:
linux-headers-5.8.0-16-generic
linux-modules-extra-5.8.0-16-generic

Commit Log for Thu Aug 27 08:31:00 2020

Completely removed the following packages:
gnustep-base-runtime
gnustep-common
linux-modules-extra-5.8.0-16-generic
unar

There is nothing wrong with speed, cpus or the underline parameter above that varies from one check to the other. For glmark, it is always very close to the 3000 mark. No printer.

All the best,

[Snowhog]

I don't think so.

proc file system in Linux

Proc file system (procfs) is virtual file system created on fly when system boots and is dissolved at time of system shut down.

[NoWorries]

I still have not activated my pre-released updates and yesterday I was updated with the Kernel Version 5.8.0-16-generic. After this I encountered a slow system response. The speed from lshw once again showed a size: 800MHz. When I encounter this, I run glmark2 to see what it gives. Normally it is so slow I kill it in disgust. This time I let it run to completion and got the result of 263!!! As I have an AMD video card, I normally expect a value about 2700. So on this result my system is now a little more that 10 times slower.

Is there anything that I can do to provide a temporary fix to this problem?

I have another Laptop with pre-released updates enabled and it does not show any slow response. This other Laptop has an Nvidia video card with a system that has not been recently re-installed.

Another option that I am considering is changing the content of the file /proc/cpuinfo. I could get the file from the LTS on same disk and use its contents to replace those in the Groovy /proc/cpuinfo. Is this a viable option to fix Groovy's slowness?

[NoWorries]

On my main Laptop, I had to do a re-install. I found that when the pre-released updates were selected, the HP Printer setup failed and the response of my system was over 5 times slower. Glmark2 was giving performance values in the mid 100's rather than in the mid 1000's.

So I had another go at installing Groovy and this time I did not select the pre-released updates. This time my HP printer setup worked and Glmark2 working to my satisfaction. To avoid problems with an older version of Thunderbird, I selected the pre-released option and installed Thunderbird then disabled the pre-release.

I think that there is something in the pre-released files that when I do

[FONT=monospace][COLOR=#000000]sudo lshw -c cpu[/COLOR][/FONT]

I get a size value of 800MHz instead of 3810MHz which is the reason for the slow desktop response that I was experiencing.

Before I decided to do the new installation with the latest ISO, I was getting a slow response which is illustrated below with the output from the LTS which is installed in a separate partition on my SSD

[B]Kubuntu 20.10[/B]
sudo lshw -c cpu                              
*-cpu                      
    description: CPU 
    product: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz 
    vendor: Intel Corp. 
    physical id: 17 
    bus info: cpu@0 
    version: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz 
    serial: To Be Filled By O.E.M. 
    slot: U3E1 
    [U]size: 800MHz [/U]
    capacity: 4100MHz 
    width: 64 bits 
    clock: 100MHz 

[B]Kubuntu 20.04[/B]
sudo lshw -c cpu 
*-cpu                      
    description: CPU 
    product: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz 
    vendor: Intel Corp. 
    physical id: 17 
    bus info: cpu@0 
    version: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz 
    serial: To Be Filled By O.E.M. 
    slot: U3E1 
   [U] size: 2795MHz [/U]
    capacity: 4100MHz 
    width: 64 bits 
    clock: 100MHz

I will be interested to know if anyone else has found this problem with the current pre-released updates.

[Radcliff]

Testing new packages is a challenge, debugging update manager is another ball game. Here, they're adding new packages just to add them. When the end result is a no end loop, the install becomes at risk.

All in Proposed this morning and back to normal:

The following packages will be upgraded:
gir1.2-freedesktop gir1.2-glib-2.0 gstreamer1.0-gl gstreamer1.0-plugins-base gstreamer1.0-x libasound2 libasound2-data
libatopology2 libcap2 libcap2-bin libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libglib2.0-data libgstreamer-gl1.0-0
libgstreamer-plugins-base1.0-0 libgstreamer1.0-0 libpam-cap libpython3.8 libpython3.8-minimal libpython3.8-stdlib
libwayland-client0 libwayland-cursor0 libwayland-egl1 libwayland-server0 python3-gi python3.8 python3.8-minimal sbsigntool
ubuntu-advantage-tools
30 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Edit: I guess removing Muon is a bad idea, won't do it again. Shutting down the computer a full night is, most of the time, a miraculous therapy.

For the rest, since the arrival of KDE Frameworks 5.73, Groovy runs very, very well. +1

[acheron]

Packages are in proposed because either they cause breakage, or have not yet been proven to not cause breakage, so yes you will see such things.

[NoWorries]

Sorry that you had so much trouble with Muon with the latest updates. I sometimes think that when the updates are going to do damage, it is best to wait for the source repositories to be finalized and come back later.

I just did the updates on one Laptop and all went through without a hitch. Even got an update to Firefox which is now at Version 81.0b1. On my other Laptop which I did earlier, there were a few problems that were easily fixed and I have one package which is causing trouble with Discover but not Muon. The command line error is:

The following NEW packages will be installed
libffi8ubuntu1
0 to upgrade, 1 to newly install, 0 to remove and 0 not to upgrade.
34 not fully installed or removed.
Need to get 0 B/20.0 kB of archives.
After this operation, 66.6 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 330954 files and directories currently installed.)
Preparing to unpack .../libffi8ubuntu1_3.4~20200819gead65ca871-0ubuntu3_amd64.deb ...
Unpacking libffi8ubuntu1:amd64 (3.4~20200819gead65ca871-0ubuntu3) ...
dpkg: error processing archive /var/cache/apt/archives/libffi8ubuntu1_3.4~20200819gead65ca871-0ubuntu3_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libffi.so.8.1.0', which is also in package libffi8.1.0:amd64 3.4~20200819gead65ca871-0ubuntu1
Errors were encountered while processing:
/var/cache/apt/archives/libffi8ubuntu1_3.4~20200819gead65ca871-0ubuntu3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is one of the hazards we have to cope with when using the Pre-released updates. To me, the benefits outshine the occasional problems encountered.