Good news, tested kernel-desktop-5.4.10-1 in 32 bits Pentium-M 740, it boots!

Whiteboard: (none) => MGA7-32-OK
CC: (none) => lists.jjorge

x64 : all ok with Intel Celeron 4600.

Host: difda Kernel: 5.4.10-desktop-1.mga7 x86_64
Quad Core: Intel Core i7-4790 type: MT MCP
OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 430.64

Updates OK, modules rebuilt OK, reboot OK.
stress tests ran fine, glmark2 failed.
VirtualBox launched Mageia guest without problems.

Good for this hardware.

CC: (none) => tarazed25

System:   Host: canopus Kernel: 5.4.10-desktop-1.mga7 x86_64 bits
CPU:      10-Core: Intel Core i9-7900X type: MT MCP speed: 1201 MHz 
Graphics  Device-1: NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nvidia v: 430.64

Updates OK.
Reboot hung.  Enforced cold boot still necessary for this hardware.  Cannot see anything in the BIOS settings which might occasion this behaviour.
stress tests OK.  glmark2 runs.
virtualbox running OK.  NFS shares mount.
Good to run on this hardware but the boot process is still defective.

Physical hardware - AMD A6 - R4 graphics - laptop running Xfce

The following 3 packages are going to be installed:

- cpupower-5.4.10-1.mga7.x86_64
- kernel-desktop-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-desktop-latest-5.4.10-1.mga7.x86_64

-- rebooted

$ uname -a
Linux localhost 5.4.10-desktop-1.mga7 #1 SMP Thu Jan 9 20:02:07 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux


Suspend Mode works correctly on battery.
WIFI working
Nextcloud Client working
Libreoffice working

so far so good

CC: (none) => brtians1

Host: belexeuli Kernel: 5.4.10-desktop-1.mga7 x86_64 bits
Quad Core: Intel Core i7-2600 type: MT MCP speed: 3691 MHz
OpenGL: renderer: GeForce GTX 555/PCIe/SSE2 v: 4.6.0 NVIDIA 390.132

Smooth reboot.
stress tests completed.
glmark2 runs.
345 scheduled updates.
virtualbox works fine.

OK for this hardware.

Dell Inspiron 5100, 32-bit P4, 2GB RAM, Radeon RV200 graphics, old Atheros wifi, 32-bit Xfce system.

Installed cpupower, kernel-desktop, and kernel-desktop-latest. All packages installed cleanly. Rebooted to a working desktop. Common apps work. Looks good on this hardware.

I commented for the last kernel update that this hardware seemed rather sluggish. That is to be expected to a certain extent because of its age, but I have rediscovered since then that this hardware runs a lot faster if unneeded cycle-stealing services like balloo and Tracker are not started at boot time. It's still slow compared to more modern equipment with them disabled, but at least it's usable.

CC: (none) => andrewsfarm

The following 3 packages are going to be installed:

- cpupower-5.4.10-1.mga7.i586
- kernel-server-5.4.10-1.mga7-1-1.mga7.i586
- kernel-server-latest-5.4.10-1.mga7.


--------rebooted --------------

$ uname -a
Linux localhost 5.4.10-server-1.mga7 #1 SMP Fri Jan 10 00:29:09 UTC 2020 i686 i686 i386 GNU/Linux


Nextcloud service is functional.
Samba services are functional.

Works for me.

Host: juza Kernel: 5.4.10-desktop-1.mga7 x86_64
Laptop System: LENOVO product: 9541 v: Lenovo IdeaPad Y500
Quad Core: Intel Core i7-3630QM type: MT MCP
NVIDIA GK107M [GeForce GT 650M] driver: nvidia v: 430.64

Installation went without a hitch.
Reboot OK.
stress tests ran to completion.
glmark2 runs.
Bluetooth connection to audio speaker worked immediately.
Virtualbox works.
Closed lid - session resumed on opening.
Fine for this machine.

AMD Phenom II X4 910, 8GB RAM, Radeon HD 8490 (Southern Islands) graphics, Atheros wifi, 64-bit Plasma system.

 Updated radeon-firmware, mesa-19.3.2-1, and kernel-desktop 5.4.10-1 in one operation. After a cold boot, everything appears to still work. Looks OK on this hardware.

Advisory, added to svn:

type: security
subject: Updated kernel packages fix security vulnerability
CVE:
 - CVE-2019-19037
src:
  7:
   core:
     - kernel-5.4.10-1.mga7
     - kmod-virtualbox-6.0.14-18.mga7
     - kmod-xtables-addons-3.7-8.mga7
     - wireguard-tools-1.0.20200102-1.mga7
description: |
  This update is based on upstream 5.4.10 and fixes atleast the following
  security issues:

  ext4_empty_dir in fs/ext4/namei.c in the Linux kernel through 5.3.12 allows
  a NULL pointer dereference because ext4_read_dirblock(inode,0,DIRENT_HTREE)
  can be zero. (CVE-2019-19037)

  It also fixes various potential security issues related to buffer overflows,
  double frees, NUll  pointer dereferences, improper / missing input
  validations and so on.

  Other fixes added in this update:
  - Revert 'drm/amdgpu: Set no-retry as default.', fixing amdgpu hang
    on Raven Ridge gpus (mga#25882)
  - drm/i915/gt: Detect if we miss WaIdleLiteRestore, fixes or atleast
    works around gpu hang (mga#25930)
  - 3rdparty/rtl8812au: update to v5.6.4.2 (mga#25982)
  - add support for RTL8117 ethernet
  - rtl8xxxu: Add support for Edimax EW-7611ULB
  - mountpoint_last(): fix the treatment of LAST_BIND
  - HID: intel-ish-hid: ipc: Add Comet Lake H PCI device ID
  - HID: intel-ish-hid: ipc: Add Tiger Lake PCI device ID
  - HID: wacom: Recognize new MobileStudio Pro PID
  - updates to the arm64 defconfigs:
    - Enable some EFI stuff on arm64 (mga#26003)
    - Enable a lot of missing things on arm64 kernels (including ACPI
       and Amazon network driver)
    - Disable debug info on arm64 (mga#26015)
    - reduce difference between arm64 and x86_64 defconfigs

  WireGuard kernel module has been updated to 0.0.20200105 and the tools
  has been updated to 1.0.20200102.

  For other fixes in this update, see the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=26049
 - https://bugs.mageia.org/show_bug.cgi?id=25882
 - https://bugs.mageia.org/show_bug.cgi?id=25930
 - https://bugs.mageia.org/show_bug.cgi?id=25982
 - https://bugs.mageia.org/show_bug.cgi?id=26003
 - https://bugs.mageia.org/show_bug.cgi?id=26015
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.7
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.8
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.9
 - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.10

Keywords: (none) => advisory

on mga7-64  kernel-desktop  plasma

Packages installed cleanly:
- cpupower-5.4.10-1.mga7.x86_64
- kernel-desktop-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-latest-5.4.10-1.mga7.x86_64
- kernel-desktop-latest-5.4.10-1.mga7.x86_64
- kernel-userspace-headers-5.4.10-1.mga7.x86_64
- virtualbox-kernel-5.4.10-desktop-1.mga7-6.0.14-18.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.14-18.mga7.x86_64

system re-booted normally:
$ uname -r
5.4.10-desktop-1.mga7

# dkms status
virtualbox, 6.0.14-2.mga7, 5.4.6-desktop-2.mga7, x86_64: installed 
virtualbox, 6.0.14-2.mga7, 5.4.10-desktop-1.mga7, x86_64: installed 
virtualbox, 6.0.14-2.mga7, 5.4.6-desktop-2.mga7, x86_64: installed-binary from 5.4.6-desktop-2.mga7
virtualbox, 6.0.14-2.mga7, 5.4.10-desktop-1.mga7, x86_64: installed-binary from 5.4.10-desktop-1.mga7

vbox and client launched normally

no regressions observed

looks OK for mga7-64 on this system:

Mobo: Dell model: 09WH54 v: UEFI [Legacy]: Dell v: 2.13.1 
CPU: Intel Core i7-6700
Graphics: Intel HD Graphics 530 (Skylake GT2)

CC: (none) => jim

on mga7-32  in a vbox VM  kernel-desktop586  plasma

packages installed cleanly:
- cpupower-5.4.10-1.mga7.i586
- kernel-desktop586-5.4.10-1.mga7-1-1.mga7.i586
- kernel-desktop586-devel-5.4.10-1.mga7-1-1.mga7.i586
- kernel-desktop586-devel-latest-5.4.10-1.mga7.i586
- kernel-desktop586-latest-5.4.10-1.mga7.i586
- kernel-userspace-headers-5.4.10-1.mga7.i586

VM started normally:

$ uname -r
5.4.10-desktop586-1.mga7

# dkms status
vboxadditions, 6.0.14-2.mga7, 5.4.6-desktop586-2.mga7, i586: installed 
vboxadditions, 6.0.14-2.mga7, 5.4.10-desktop586-1.mga7, i586: installed 

No regressions noted

OK for mga7-32 in a vbox VM

[rolf@z170i ~]$ uname -r
5.3.13-desktop-2.mga7

I have been able to get, at least, network (ethernet) running, with any 5.4 kernel, as described in my bug:  https://bugs.mageia.org/show_bug.cgi?id=25873#c4

As those upgrades were first done over ssh from the primary desktop on the LAN, I started on the Z170I on the connected monitor in the gui, to exclude something affected by this remote administration that has worked for some years.

Enabled "Core Updates Testing" but not as an Updates medium in rpmdrake.
Going by other reports and what was installed, still in the gui mcc software module, I selected the following:

The following 4 packages are going to be installed:

- cpupower-5.4.10-1.mga7.x86_64
- kernel-desktop-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-userspace-headers-5.4.10-1.mga7.x86_64

113MB of additional disk space will be used.

74MB of packages will be retrieved.

Is it ok to continue?
Yes
...
Warning
You should restart your computer for kernel...
OK

Disabled "Core Updates Testing".

Reboot.

The network does not come up, as in the other bug, spinning applet icon and "Connection System 'enp0s31f6' deactivated" message display over the applet about every 6 seconds.  Simple analytics exactly as before:

[rolf@z170i ~]$ sudo lsmod | grep e1
e1000e                286720  0
ptp                    20480  1 e1000e
[rolf@z170i ~]$ inxi -n
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e 
  IF: enp0s31f6 state: down mac: f8:32:e4:9f:2f:7a
[rolf@z170i ~]$

I'll let it run as is for a while, in case something can be extracted.

CC: (none) => rolfpedersen

Should read, "I have *not* been able to get, at least, network (ethernet) running, with any 5.4 kernel..."

Intel i5 2500 processor, 16GB RAM, Integrated Intel graphics, wired (Ethernet) Internet connection, 64-bit Plasma system.

I used the QA repo tool to get just the 64-bit packages on the list in Comment 0. The radeon firmware package has been updated, but the system doesn't to my knowledge have any radeon hardware. The mesa update has not been applied - yet.

The following 6 packages are going to be installed:

- cpupower-5.4.10-1.mga7.x86_64
- kernel-desktop-5.4.10-1.mga7-1-1.mga7.x86_64
- kernel-desktop-latest-5.4.10-1.mga7.x86_64
- kernel-userspace-headers-5.4.10-1.mga7.x86_64
- virtualbox-kernel-5.4.10-desktop-1.mga7-6.0.14-18.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.14-18.mga7.x86_64

All packages installed cleanly. After a warm boot, everything seems to work, including Dolphin, Okular, Libreoffice, VirtualBox, VLC, Thunderbird, and Firefox. Using it now to write this report.

FWIW, I have not experienced any problems with my Ethernet connection on this hardware, with any of the 5.4 series of kernels.

I grew impatient, never did reboot, but tried adding a wifi dongle, stopping/starting seemingly related network-related services modules in mcc > system > services, all of which failed.  Taking a hint from here:  https://stackoverflow.com/a/58725463 I removed around 20 connections in the mcc remove connection module.  I don't know why so many are there.  I've removed before but they just seem to build up independent of my actions.

Anyway, all connections removed, I re-configured the ethernet and have network again running 5.4.10-desktop-1.mga7
Thanks.

Same hardware and install as Comment 16, now with the mesa 19.3.2-1 update installed.

Still no issues to report.

(In reply to Rolf Pedersen from comment #17)
>  I removed around 20 connections in the
> mcc remove connection module.  I don't know why so many are there.  I've
> removed before but they just seem to build up independent of my actions.
> 
Rolf, you might want to check /etc/wpa_supplicant.conf to make sure any now-unwanted wifi connections have actually been removed. I've seen it where old wifi connection data seems to be gone, but is actually still there, waiting for the network to be detected again.

With kernel 5.4.6 and 5.4.10, VirtualBox is totally unstable and freezes after a few seconds. And after a few minutes, the whole system freezes, except the mouse which is still moving. But Ctrl+Alt+F2 and Ctrl+Alt+Backspace are ignored and have no effect. Rebooting with kernel 5.3.13 fixes the problem and VirtualBox seems stable again. I played with it for several minutes now without any problem (compared to immediate freeze after a few seconds with kernel 5.4.x).

The same problem seems to happen with Stellarium on Mageia (VirtualBox being off). After a few minutes, Stellarium freezes.

I excepted that updating Mesa to 19.3.2 would help, but it didn't. So the problem seems to be related to kernel 5.4.x.

My machine is:

Operating System: Mageia 7
KDE Plasma Version: 5.15.4
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.6
Kernel Version: 5.3.13-desktop-2.mga7
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz (Skylake)
Memory: 15,5 Gio

(In reply to Frédéric "LpSolit" Buclin from comment #20)
> I excepted that updating Mesa to 19.3.2 would help, but it didn't.

s/excepted/expected/

I rebooted again with kernel 5.4.10 but this time logging into LxQT instead of Plasma, and VirtualBox seems to be working fine. I logged out of LxQT and came back into Plasma. Now VirtualBox freezes again after a few seconds only. So no idea where the problem is exactly, but it seems to be a combination kernel 5.4.x + Plasma.

@ Frédéric, re comment 22:

My tests are invariably run under Mate and virtualbox has been stable.  Cannot remember if stellarium was tested but shall login later to check that, in Mate.

MGA7-64 Plasma on Lenovo B50
No installation issues
Tried different filetypes, newspaper site, access to NFS shares and DNS server in LAN, all OK.

CC: (none) => herman.viaene

Stellarium checks.
No problems under Mate on two machines running 5.4.10-desktop-1.mga7 kernel.  One of the partitions had Plasma installed - stellarium stayed up for as long as required.  stellarium-0.19.0-1.mga7, nvidia 430.64.

The only oddity with the 5.4 kernels here happens on one specific machine.  Warm reboots fail every time after a 5.4 kernel has been booted.  grub2 runs but the system freezes as soon as a selection is made - no keyboard response, no reset possible.  That is very different from your stellarium problem and does not affect the machine this is being reported on.

Have you tried looking at dmesg or the journal?

Enough tests, validating

Keywords: (none) => validated_update
Whiteboard: MGA7-32-OK => MGA7-64-OK, MGA7-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0036.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

(In reply to Thomas Andrews from comment #19)
> (In reply to Rolf Pedersen from comment #17)
> >  I removed around 20 connections in the
> > mcc remove connection module.  I don't know why so many are there.  I've
> > removed before but they just seem to build up independent of my actions.
> > 
> Rolf, you might want to check /etc/wpa_supplicant.conf to make sure any
> now-unwanted wifi connections have actually been removed. I've seen it where
> old wifi connection data seems to be gone, but is actually still there,
> waiting for the network to be detected again.

I use ethernet primarily and almost all the seemingly extraneous connections were of the wired variety.  BTW, onboard wifi is disabled as I've never been able to get it to work on this machine, just one of its several "quirks", imo.  I tried the dongle to see if it behaved differently but no joy.  wpa_supplicant.conf contains a couple of wireless connections that I've established in the past on the LAN for connectivity to various Pi machines but they don't seem to be creating an issue with my ethernet network, ATM.  Thanks.