Please ignore if the # of packages not match unless you have issues with the list, I remove the kernel-linus packages

I have been running desktop 6.6.18-1 for several days without issues.
But I was thinking there will come a later iteration, no?

CC: (none) => fri

(In reply to Morgan Leijström from comment #2)
> I have been running desktop 6.6.18-1 for several days without issues.
> But I was thinking there will come a later iteration, no?

From the QA meeting yesterday
joeghi: MageiaTJ: we need to start bug for kernel-6.6.18, which was delayed last week after waydroid stuff.
MageiaTJ: joeghi: is there a bug ready for QA?
joeghi: MageiaTJ: no
MageiaTJ: Then that's what we need.

I take that as a signal to proceed

Real Hardware Mageia 9 x86_64

I use kernel 6.6.18 desktop since some time also, not regressions or new issues for this hardware.

(In reply to katnatek from comment #1)
> Please ignore if the # of packages not match unless you have issues with the
> list, I remove the kernel-linus packages

The lists shouldn't match this time. We have one more i586 kernel flavor, and there are no i586 kmods for VirtualBox because it isn't supported for that arch.

CC: (none) => andrewsfarm

(In reply to Thomas Andrews from comment #5)
> (In reply to katnatek from comment #1)
> > Please ignore if the # of packages not match unless you have issues with the
> > list, I remove the kernel-linus packages
> 
> The lists shouldn't match this time. We have one more i586 kernel flavor,
> and there are no i586 kmods for VirtualBox because it isn't supported for
> that arch.

Yes but I add a count in my script to get the list of packages, and as linus flavour is a separate bug I remove from the list linus packages but not make the same from the final count

Hmmmm. MGA9-64 Plasma, i5-7500, Nvidia Quadro K620 graphics(nvidia-current driver).

I have not rebooted yet. I used qarepo to download the packages, then used urpmi --auto-update so I could watch the progress of the nvidia driver. All of that proceeded normally, or so I thought.

At the end I was presented with a list of orphans that included the old kernels and kernel-devels still installed. That's a known problem, and there's a bug about it. The problem is that kernel-desktop-devel-6.6.18-1.mga9.x86_64 was on the list. 

Checking back, it appears that somehow, sometime, kernel-desktop-devel-latest got removed. That doesn't really surprise me - it could easily be something I did. What surprises me is that the new kernel-desktop-devel was installed and the nvidia driver built WITHOUT it being there.

It didn't used to be that way. When did things change?

VirtualBox didn't work. The "latest" rpms for the virtualbox and xtables-addons kmods were left off the list for qarepo, so those packages weren't updated.

(In reply to Thomas Andrews from comment #8)
> VirtualBox didn't work. The "latest" rpms for the virtualbox and
> xtables-addons kmods were left off the list for qarepo, so those packages
> weren't updated.

Fixed with just 2 more attempts :) , my filter skip that packages due to the versions, I need to remember that or find a better method to get the list

Sorry, but still not correct. The last list has virtualbox and xtables kmods for kernel versions other than the ones under test. Older, rejected versions by the look of it, kmods that should have been removed.

Your filter isn't compensating for poor housekeeping of the repos.

Same hardware as comment 7, different install. This install has desktop, server, and linus kernels installed, and the GPU can use the nvidia 470, 535, or 545 driver. VirtualBox is not installed.

Updated server and desktop kernels at the same time, under nvidia-current(535). No installation issues, and no issues after the reboot. 

Switched to the 470 driver, rebooted to each in turn, and again no issues.

Used qarepo to get the packages for the newfeature driver (bug 32565), rebooted into each once more, and again no issues to report.

In the install of comment 7, desktop kernel, nvidia-current, once the kmods were installed, VirtualBox worked as expected.

(In reply to Thomas Andrews from comment #12)
> Sorry, but still not correct. The last list has virtualbox and xtables kmods
> for kernel versions other than the ones under test. Older, rejected versions
> by the look of it, kmods that should have been removed.
> 
> Your filter isn't compensating for poor housekeeping of the repos.

Don't worry, I think I finally get a workflow for this kind of bugs, my tool still is far from be perfect and in some weird cases like the nodejs packages could be worst

Status comment: Packages in comment#10 => Packages in comment#14

Real Hardware Mageia 9 x86_64

Tested kernel server

Not issues found
Video OK
Network OK
Sound OK

i586:
bpftool-6.6.18-1.mga9.i586.rpm
cpupower-6.6.18-1.mga9.i586.rpm
cpupower-devel-6.6.18-1.mga9.i586.rpm
kernel-desktop-6.6.18-1.mga9.i586.rpm
kernel-desktop-devel-6.6.18-1.mga9.i586.rpm
kernel-desktop-devel-latest-6.6.18-1.mga9.i586.rpm
kernel-desktop-latest-6.6.18-1.mga9.i586.rpm
kernel-desktop586-6.6.18-1.mga9.i586.rpm
kernel-desktop586-devel-6.6.18-1.mga9.i586.rpm
kernel-desktop586-devel-latest-6.6.18-1.mga9.i586.rpm
kernel-desktop586-latest-6.6.18-1.mga9.i586.rpm
kernel-doc-6.6.18-1.mga9.noarch.rpm
kernel-server-6.6.18-1.mga9.i586.rpm
kernel-server-devel-6.6.18-1.mga9.i586.rpm
kernel-server-devel-latest-6.6.18-1.mga9.i586.rpm
kernel-server-latest-6.6.18-1.mga9.i586.rpm
kernel-source-6.6.18-1.mga9.noarch.rpm
kernel-userspace-headers-6.6.18-1.mga9.i586.rpm
libbpf-devel-6.6.18-1.mga9.i586.rpm
libbpf1-6.6.18-1.mga9.i586.rpm
perf-6.6.18-1.mga9.i586.rpm
xtables-addons-kernel-6.6.18-desktop-1.mga9-3.24-55.mga9.i586.rpm
xtables-addons-kernel-6.6.18-desktop586-1.mga9-3.24-55.mga9.i586.rpm
xtables-addons-kernel-6.6.18-server-1.mga9-3.24-55.mga9.i586.rpm
xtables-addons-kernel-desktop-latest-3.24-55.mga9.i586.rpm
xtables-addons-kernel-desktop586-latest-3.24-55.mga9.i586.rpm
xtables-addons-kernel-server-latest-3.24-55.mga9.i586.rpm



x86_64:
bpftool-6.6.18-1.mga9.x86_64.rpm
cpupower-6.6.18-1.mga9.x86_64.rpm
cpupower-devel-6.6.18-1.mga9.x86_64.rpm
kernel-desktop-6.6.18-1.mga9.x86_64.rpm
kernel-desktop-devel-6.6.18-1.mga9.x86_64.rpm
kernel-desktop-devel-latest-6.6.18-1.mga9.x86_64.rpm
kernel-desktop-latest-6.6.18-1.mga9.x86_64.rpm
kernel-doc-6.6.18-1.mga9.noarch.rpm
kernel-server-6.6.18-1.mga9.x86_64.rpm
kernel-server-devel-6.6.18-1.mga9.x86_64.rpm
kernel-server-devel-latest-6.6.18-1.mga9.x86_64.rpm
kernel-server-latest-6.6.18-1.mga9.x86_64.rpm
kernel-source-6.6.18-1.mga9.noarch.rpm
kernel-userspace-headers-6.6.18-1.mga9.x86_64.rpm
lib64bpf-devel-6.6.18-1.mga9.x86_64.rpm
lib64bpf1-6.6.18-1.mga9.x86_64.rpm
perf-6.6.18-1.mga9.x86_64.rpm
virtualbox-kernel-6.6.18-desktop-1.mga9-7.0.14-45.mga9.x86_64.rpm
virtualbox-kernel-6.6.18-server-1.mga9-7.0.14-45.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.14-45.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.14-45.mga9.x86_64.rpm
xtables-addons-kernel-6.6.18-desktop-1.mga9-3.24-55.mga9.x86_64.rpm
xtables-addons-kernel-6.6.18-server-1.mga9-3.24-55.mga9.x86_64.rpm
xtables-addons-kernel-desktop-latest-3.24-55.mga9.x86_64.rpm
xtables-addons-kernel-server-latest-3.24-55.mga9.x86_64.rpm


SRPM:
kernel-6.6.18-1.mga9.src.rpm
kmod-virtualbox-7.0.14-45.mga9.src.rpm
kmod-xtables-addons-3.24-55.mga9.src.rpm

MGA9-64, Xfce, Celeron N2840, Chromebook

The following 5 packages are going to be installed:

- cpupower-6.6.18-1.mga9.x86_64
- kernel-desktop-6.6.18-1.mga9.x86_64
- kernel-desktop-latest-6.6.18-1.mga9.x86_64
- kernel-userspace-headers-6.6.18-1.mga9.x86_64
- lib64bpf1-6.6.18-1.mga9.x86_64

99MB of additional disk space will be used.

-- rebooted

- browser works
- audio work
- video looks normal

CC: (none) => brtians1

Real Hardware Mageia 9 i586

I let all the set of kernels in previous test so I get all the kernels with the respective devel

uname -r
6.6.18-server-1.mga9

dkms-anbox installed from a previous test was uninstalled after the update, this is expected

Wifi OK
Video OK
Sound OK

Not issues or regressions

Real Hardware Mageia 9 i586

uname -r
6.6.18-desktop-1.mga9

Wifi OK
Video OK
Sound OK

Real Hardware Mageia 9 i586

uname -r
6.6.18-desktop586-1.mga9

Wifi OK
Video OK
Sound OK

Mageia9, x64
IntelNUC12, core i7 with Intel graphics.
Server and desktop kernels installed.  Booted the server version.
Desktop running smoothly.  NFS, bluetooth audio, graphics working.
32-bit Mageia client launched in virtualbox - mga10, needing a 1900+ package update.

CC: (none) => tarazed25

Mageia9, x86_64
Intel Core i9, NVIDIA GeForce GTX 1080
Smooth update, all packages.
`perf test` worked.

$ sudo cpupower -c 4-9 frequency-info
analyzing CPU 4:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 4
....
analyzing CPU 9:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 9
  CPUs which need to have their frequency coordinated by software: 9
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.20 GHz - 4.30 GHz
...

Bluetooth audio connection reestablished immediately by switching on the portable speaker.
NFS shares available.  Virtualbox is good; launched a Mageia client and updated 327 packages on it.
The big graphics packages; stellarium, celestia, blender, kstars, all work for a quick look.
docker works.

mga9-64, Plasma

Laptop: acer Aspire A717-71G
using only the Intel GPU (nvidia GPU not configured)

/home / and swap is on LVM, on a LUKS ext4 partition, separate /boot

Common desktop apps works, wifi works

suspend-resume: OK
hibernate-resume: OK

-desktop kernel used.

6.6.18-desktop-1.mga9, mga9-64, Plasma X11

Laptop: Lenovo ThinkPad T510
nouveau driver
/home, /, swap are on LVM, on a LUKS ext4 partition, separate /boot

Common desktop apps works, wifi works, web video in Firefox

suspend-resume: OK

hibernate-resume: Quirk:  (no regression)
  Hibernate: unexpectedly long time, then disk lamp activity (obviously saving), then after long wait power lamp instead of switching off start blinking quickly (panic?).  So it fail to shut down, and unfortunately it is not logging at this stage...  User have to press power key 4 seconds to shut off.  Apparently the saving works, because:
  Resuming: after grub, entering LUKS key, sddm login, I am back in the session where I was (And it was not a Plasma desktop driven restore) 

Actually this is an improvement because IIRC when i have tried earlier, i also had to shut off at blinking lamp, but also resume failed.

This was mainly to complete the #32467 of which we delayed the kernel.

TL;DR: with nvidia, vt switching hang hard after a suspend-resume cycle.


mga9-64, Plasma X11

my "svarten";

Main board: Intel i7-870, P55 chipset

GPU: GTX750Ti with nvidia 550.54.14 from testing repo

/home, /, swap are on LVM, on a LUKS ext4 partition, separate /boot

§ Software tested OK: Plasma X11, Thunderbird, Firefox, LibreOffice, nextcloud-client, syncthing, DropBox, KDEConnect, ...

§ teapot performing OK. (Note to self: as usual 60 Hz sync up to half screen window with TB and FF with many tabs)

§ VirtualBox 7.0.14 OK both using dkms built kmod, and Mageia binary package. MSW7 guest: internet videos, dynamic guest window resizing, USB2 flashstick, host folder sharing, bidirectional clipboard, and drag file from Dolphin to Explorer.

§ suspend-resume OK

§ FAIL: vt switching Works before a suspend-resume cycle, but never after: vt switching ctrl-alt-F6 and back ctrl-alt-F2 fails: hard hang black screen with non moveable mouse cursor, even REISUB did not work, user lost work.  I also note this problem do *not* exist with linus 6.6.18-1.
I remember we had this problem before but did we not get it sorted?

(In reply to Morgan Leijström from comment #28)
> TL;DR: with nvidia, vt switching hang hard after a suspend-resume cycle.
> 
> 
> mga9-64, Plasma X11
> 
> my "svarten";
> 
> Main board: Intel i7-870, P55 chipset

what is the motherboard exact model already?

> 
> GPU: GTX750Ti with nvidia 550.54.14 from testing repo

> § FAIL: vt switching Works before a suspend-resume cycle, but never after:
> vt switching ctrl-alt-F6 and back ctrl-alt-F2 fails: hard hang black screen
> with non moveable mouse cursor, even REISUB did not work, user lost work.  I
> also note this problem do *not* exist with linus 6.6.18-1.
> I remember we had this problem before but did we not get it sorted?

There was a patch/fix for that, that it's still included.
[BTW I've a 6.6.20 in my copr, well, ready tomorrow]

Did you get the same fail with 535.xx or newer 470.239.07 or it's specific of 550.54.14?

mga9-64, kernel-desktop-6.6.18-1.mga9, Plasma
LightDM due to Bug 32805

Laptop: Dell Precision M6300
NVIDIA G84GLM [Quadro FX 1600M] driver: nouveau

/home / and swap is on LVM, on ext4 partition (not encrypted)

Common desktop apps, wifi, web video in Firefox, Syncthing, KDEConnect

suspend-resume: OK
hibernate-resume: OK
vt switching: OK


---

Will answer Comment 29 tomorrow.

(In reply to Giuseppe Ghibò from comment #29)
> [BTW I've a 6.6.20 in my copr, well, ready tomorrow]

Then I think we must wait to that version and start again, perhaps in new bugs and close both 6.6.18 as wontfix

(In reply to Giuseppe Ghibò from comment #29)
> [BTW I've a 6.6.20 in my copr, well, ready tomorrow]

Do you mean 
A) Ready for pretesting, download from copr
 or
B) Ready for Mageia QA?


(In reply to katnatek from comment #31)
> Then I think we must wait to that version and start again, perhaps in new
> bugs and close both 6.6.18 as wontfix

IMO, 6.6.18-1 is tested enough to release.

The vt with nvidia bug have been for long time before we "temporarily" fixed it recently, i think it should not block releasing 6.6.18.

---

While talking, should QA now be testing the nvidia-470 and -current now in nonfree testing, and mesa in testing?

---

my "svarten" 
Mobo: ASRock model: P55 Pro serial: N/A
BIOS: American Megatrends v: P2.60 date: 08/20/2010

Will try other nvidia driver versions later

(In reply to Morgan Leijström from comment #32)

> (In reply to Giuseppe Ghibò from comment #29)
> > [BTW I've a 6.6.20 in my copr, well, ready tomorrow]
> 
> Do you mean 
> A) Ready for pretesting, download from copr
>  or
> B) Ready for Mageia QA?
> 

A). Just ready for pretesting, it's not an official build (a 6.6.20 wasn't planned). It's here in oldversioningscheme:

https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/07099547-kernel/

> 
> (In reply to katnatek from comment #31)
> > Then I think we must wait to that version and start again, perhaps in new
> > bugs and close both 6.6.18 as wontfix
> 
> IMO, 6.6.18-1 is tested enough to release.

Apparently it is.

> 
> The vt with nvidia bug have been for long time before we "temporarily" fixed
> it recently, i think it should not block releasing 6.6.18.

Actually it comes after the resume, which is even a subset of the previous problem and IIRC was happening always on VT and not just on resume (at least for you).

What is weird is that the same fix for the nvidia VT for kernel-desktop|-server (because you said the problem doesn't occur in kernel-linus) was also keepen in kernel-linus (it's just one of the few 3-4 patches it has).

> 
> ---
> 
> While talking, should QA now be testing the nvidia-470 and -current now in
> nonfree testing, and mesa in testing?

I was going to answer about that. Let's start with nvidia470 which hasn't a major release change and should go smooth, and mesa (so we would get rid of). For nvidia-current, ok, but very low priority for now, after the other twos and other pending stuff.

> 
> ---
> 
> my "svarten" 
> Mobo: ASRock model: P55 Pro serial: N/A
> BIOS: American Megatrends v: P2.60 date: 08/20/2010

BIOS is also latest. You might try lstopo utility from hwloc package to detect if there is some weird configuration of PCIe slots, so maybe some PCIe line is shared between too many devices. Mostly these hard locks comes after the resume.

If you swap the gfx card from one PCIe slot to another? cuda-z might also show a very different bandwidth when placed in one slot or one another.

Maybe Iĺl try elder drivers with this kernel, and elder kernels with the new drivers.  And lstopo and cuda-z and move card.  But right now no more time for this.


__Quick test other drivers on "svarten"__
- all with 6.6.18-desktop-1.mga9

nvidia 470.239.06-1: like 550: works nicely except for vt change after resume.


__Xorg modesetting__

I know from before that Xorg modesetting works good. Still do, with speed about as of nvidia, and no problem with suspend-resume nor vt switching.


__Nouveau__

I know from before that nouveau is slow and occasionally quirky on this system.
It still is so: teapot get half speed of nvidia or Xorg modesetting, use more CPU, plus desktop restarted when i opened large pdf in Firefox, with in journal lots of instances of the line, both when crashing and otherwise sometimes: 

mar 04 14:17:35 svarten.tribun kernel: nouveau 0000:07:00.0: fifo: fault 01 [WRITE] at 0000000000068000 engine 03 [IFB] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel 2 [003fbd2000 Xorg[5703]]

Only problem with this is that nouveau is our default free driver, but this GPU apparently need modesetting.  Maybe something to think about for the future.  (other GPUs works better with nouveau, how to tell?)

(In reply to Giuseppe Ghibò from comment #33)
> (In reply to Morgan Leijström from comment #32)
> 
> > IMO, 6.6.18-1 is tested enough to release.
> 
> Apparently it is.

I set OK for both arches - I see both desktop and server had tests of both x86_64, and i586, and no problem except this vt switching problem of desktop with nvidia (not tested with -server)

If other agree (TJ?) please validate.

We also need an advisory.

CC: (none) => marja11
Whiteboard: (none) => MGA9-64-OK, MGA9-32-OK

One more report first...

MGA9-64 Plasma on an HP Probook 6550b, i3 450M, Intel graphics, Broadcom wifi.

No installation issues. The broadcom-wl driver module built and installed without incident. After the reboot, no issues to report. Looks good here, too.

Validating.

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

I not find CVEs in the changelog, advisory uploaded

Keywords: (none) => advisory

Continuing the vt switching and resume hangs at: Bug 31695 Comment 71

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

https://advisories.mageia.org/MGAA-2024-0092.html

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