mga9-64 OK here

HW: Intel i7-870, P55 chipset

GPU: GTX750Ti with nvidia drivers tested OK: both nvidia470 470.223.02-1, and newfeature 545.29.02.

SW: Plasma X11, Normal desktop apps

§ All normal desktop apps OK - will keep using this.

§ VirtualBox 7.0.10, tested both using dkms built module and virtualbox-kernel-6.5.11-desktop-5.mga9-7.0.10-37.mga9.x86_64.rpm

MSW7 guest OK: internet videos, dynamic guest window resizing, USB2 flashstick, host folder sharing, bidirectional clipboard, and drag file from Dolphin to Explorer (worked on second attempt, quirky as usual)


---
suspend-resume: will report after some days usage.

CC: (none) => fri

Giuseppe
Courageous of you to launch this.
I guess it is in updates/testing, and really for QA; so assigning to them.

Assignee: bugsquad => qa-bugs

(In reply to Morgan Leijström from comment #1)
> suspend-resume: will report after some days usage.

Already hit fail (needing sometimes to power cycle monitor after suspend, like 6.4 series desktop kernels), changing to use linus 5.6.11-2 on this system, which I have already used a few days before, no problem.

(In reply to Morgan Leijström from comment #3)
> (In reply to Morgan Leijström from comment #1)
> > suspend-resume: will report after some days usage.
> 
> Already hit fail (needing sometimes to power cycle monitor after suspend,
> like 6.4 series desktop kernels), changing to use linus 5.6.11-2 on this
> system, which I have already used a few days before, no problem.

So:

- kernel-linus-6.5.11-2.mga9 works all the time with any driver series.
- kernel-desktop-6.5.11-5.mga9 apparently works, but on the long term usage (e.g. after 24 hours?) it tends to fail.

What was the specific bug # for this?

(In reply to Giuseppe Ghibò from comment #4)
> (In reply to Morgan Leijström from comment #3)

> So:
> 
> - kernel-linus-6.5.11-2.mga9 works all the time with any driver series.

An so did 6.4 linus kernels, and did the mga8 desktop kernels on same GPU with nvidia drivers.

> - kernel-desktop-6.5.11-5.mga9 apparently works, but on the long term usage
> (e.g. after 24 hours?) it tends to fail.

Strangely it seem to depend on how long it have been sleeping, say more than an hour.  Maybe the monitor goes into deeper sleep, needing more time or special signal to wake up and respond to the graphics card... somehow.. wild guessing is the bet I can do... 

It seems I can suspend-resume several times for a short sleep, no problem - but after lunch or night I need to power cycle the monitor after iI wake up the computer. 

> What was the specific bug # for this?

None. We have been chatting about this occasionally in various kernel bugs and mail list for half a year, since I switched the system from mga8 to 9 beta.

If you have time to work on it i can open a bug.
Self i can not give it much time.
Seem very special to my system - I have not seen anyone else mentioning this specific resume problem, so basically i think we should use the time for other stuff.

Do we have a list of changes we routinely add to desktop and server kernels over linus? Maybe include it in https://wiki.mageia.org/en/Kernel_flavours

advisory based on the one for bug 32482 and comment 0 added to SVN

Keywords: (none) => advisory
CC: (none) => marja11

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

> 
> If you have time to work on it i can open a bug.
> Self i can not give it much time.

Not much time, but we can do a couple of attempts. Maybe you can open it.

> Seem very special to my system - I have not seen anyone else mentioning this
> specific resume problem, so basically i think we should use the time for
> other stuff.

We can do a few attempts, I've some ideas, but have to use COPR to provide "isolated" builds, otherwise it will be too noisy on updates_testing because one release would supersedes the others.

> 
> Do we have a list of changes we routinely add to desktop and server kernels
> over linus? Maybe include it in https://wiki.mageia.org/en/Kernel_flavours

AFAIK there aren't.

(In reply to Marja Van Waes from comment #6)

> advisory based on the one for bug 32482 and comment 0 added to SVN

Thanks. Do we need to add the link here?

(In reply to Marja Van Waes from comment #9)

> (In reply to Giuseppe Ghibò from comment #8)
> > (In reply to Marja Van Waes from comment #6)
> > 
> > > advisory based on the one for bug 32482 and comment 0 added to SVN
> > 
> > Thanks. Do we need to add the link here?
> 
> Yes, to double check nothing is wrong with it. I replaced the links to the
> kernel patches with links to all 6.5 - 6.5.11 kernel changelogs, but didn't
> check whether there are more fixed CVEs than before.
> 
> https://svnweb.mageia.org/advisories/32537.adv?revision=15276&view=markup

apparently 6.5.11 covers more, e.g. CVE-2023-6176 should be fixed already.

Tested kernel-desktop on real hardware Mageia 9 i586 with lxq, 2 reboot and use some time the system in each one, I don't find nothing weird

I will test kernel-desktop586

(In reply to Giuseppe Ghibò from comment #7)
> (In reply to Morgan Leijström from comment #5)

> Not much time, but we can do a couple of attempts. Maybe you can open it.

Bug 32541 - Resume-from-suspend problems using Nvidia drivers on mga9 desktop kernels with GM107

Tested kernel-desktop586 on real hardware Mageia 9 i586 with lxq, 2 use some time the system , I don't find nothing weird, this comment is done using kernel.desktop586

Whiteboard: (none) => MGA9-32-OK

In the list in comment 0, the following packages don't belong there. QA balks at downloading them(old versions):

xtables-addons-kernel-desktop586-latest-3.24-46.mga9.i586.rpm
xtables-addons-kernel-desktop-latest-3.24-46.mga9.i586.rpm
xtables-addons-kernel-server-latest-3.24-46.mga9.i586.rpm

CC: (none) => andrewsfarm

MGA9-64, Xfce, Celeron N2840, Chromebook

The following 5 packages are going to be installed:

- cpupower-6.5.11-5.mga9.x86_64
- kernel-desktop-6.5.11-5.mga9.x86_64
- kernel-desktop-latest-6.5.11-5.mga9.x86_64
- kernel-userspace-headers-6.5.11-5.mga9.x86_64
- lib64bpf1-6.5.11-5.mga9.x86_64

99MB of additional disk space will be used.

-- rebooted

$ uname -a
Linux localhost 6.5.11-desktop-5.mga9 #1 SMP PREEMPT_DYNAMIC Sun Nov 19 01:09:14 UTC 2023 x86_64 GNU/Linux


- browser works
- audio work
- video looks normal

CC: (none) => brtians1

MGA9-32 Xfce on an HP Probook 6550b. 

As a result of many previous tests, this problem child had become cluttered with several kernels, some of which will not boot at all reliably. After removing the kernels that don't boot well, I updated all three 32-bit kernels in one fell swoop - with no installation issues.

I booted into each kernel in turn, each time with great success. No issues to report at all.

Installed in Mageia 9 x86-64 Plasma.

All works ok for the mmoment.

Apps ok.
Settings. ok.
Sleep ok.
Sound and vídeo ok.
No installation issues.
Virtualbox ok.

Greetings!

CC: (none) => joselp

(In reply to Thomas Andrews from comment #14)
> In the list in comment 0, the following packages don't belong there. QA
> balks at downloading them(old versions):
> 
> xtables-addons-kernel-desktop586-latest-3.24-46.mga9.i586.rpm
> xtables-addons-kernel-desktop-latest-3.24-46.mga9.i586.rpm
> xtables-addons-kernel-server-latest-3.24-46.mga9.i586.rpm

Thanks for spotting.

Newer fixed file list for kernel 6.5.x series.

SRPMS:
======
kernel-6.5.11-5.mga9.src.rpm
kmod-virtualbox-7.0.10-37.mga9.src.rpm
kmod-xtables-addons-3.24-50.mga9.src.rpm

x86_64:
=======
bpftool-6.5.11-5.mga9.x86_64.rpm
cpupower-6.5.11-5.mga9.x86_64.rpm
cpupower-devel-6.5.11-5.mga9.x86_64.rpm

kernel-desktop-6.5.11-5.mga9.x86_64.rpm
kernel-desktop-devel-6.5.11-5.mga9.x86_64.rpm
kernel-desktop-devel-latest-6.5.11-5.mga9.x86_64.rpm
kernel-desktop-latest-6.5.11-5.mga9.x86_64.rpm

kernel-doc-6.5.11-5.mga9.noarch.rpm

kernel-server-6.5.11-5.mga9.x86_64.rpm
kernel-server-devel-6.5.11-5.mga9.x86_64.rpm
kernel-server-devel-latest-6.5.11-5.mga9.x86_64.rpm
kernel-server-latest-6.5.11-5.mga9.x86_64.rpm

kernel-source-6.5.11-5.mga9.noarch.rpm

kernel-userspace-headers-6.5.11-5.mga9.x86_64.rpm

lib64bpf-devel-6.5.11-5.mga9.x86_64.rpm
lib64bpf1-6.5.11-5.mga9.x86_64.rpm

perf-6.5.11-5.mga9.x86_64.rpm

virtualbox-kernel-6.5.11-desktop-5.mga9-7.0.10-37.mga9.x86_64.rpm
virtualbox-kernel-6.5.11-server-5.mga9-7.0.10-37.mga9.x86_64.rpm
virtualbox-kernel-desktop-latest-7.0.10-37.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.10-37.mga9.x86_64.rpm

xtables-addons-kernel-6.5.11-desktop-5.mga9-3.24-50.mga9.x86_64.rpm
xtables-addons-kernel-6.5.11-server-5.mga9-3.24-50.mga9.x86_64.rpm
xtables-addons-kernel-desktop-latest-3.24-50.mga9.x86_64.rpm
xtables-addons-kernel-server-latest-3.24-50.mga9.x86_64.rpm

i586:
=====
bpftool-6.5.11-5.mga9.i586.rpm
cpupower-6.5.11-5.mga9.i586.rpm
cpupower-devel-6.5.11-5.mga9.i586.rpm

kernel-desktop586-6.5.11-5.mga9.i586.rpm
kernel-desktop586-devel-6.5.11-5.mga9.i586.rpm
kernel-desktop586-devel-latest-6.5.11-5.mga9.i586.rpm
kernel-desktop586-latest-6.5.11-5.mga9.i586.rpm

kernel-desktop-6.5.11-5.mga9.i586.rpm
kernel-desktop-devel-6.5.11-5.mga9.i586.rpm
kernel-desktop-devel-latest-6.5.11-5.mga9.i586.rpm
kernel-desktop-latest-6.5.11-5.mga9.i586.rpm

kernel-doc-6.5.11-5.mga9.noarch.rpm

kernel-server-6.5.11-5.mga9.i586.rpm
kernel-server-devel-6.5.11-5.mga9.i586.rpm
kernel-server-devel-latest-6.5.11-5.mga9.i586.rpm
kernel-server-latest-6.5.11-5.mga9.i586.rpm

kernel-source-6.5.11-5.mga9.noarch.rpm

kernel-userspace-headers-6.5.11-5.mga9.i586.rpm

libbpf1-6.5.11-5.mga9.i586.rpm
libbpf-devel-6.5.11-5.mga9.i586.rpm

perf-6.5.11-5.mga9.i586.rpm

xtables-addons-kernel-6.5.11-desktop-5.mga9-3.24-50.mga9.i586.rpm 
xtables-addons-kernel-6.5.11-desktop586-5.mga9-3.24-50.mga9.i586.rpm
xtables-addons-kernel-6.5.11-server-5.mga9-3.24-50.mga9.i586.rpm

xtables-addons-kernel-desktop-latest-3.24-50.mga9.i586.rpm
xtables-addons-kernel-desktop586-latest-3.24-50.mga9.i586.rpm
xtables-addons-kernel-server-latest-3.24-50.mga9.i586.rpm

Created attachment 14178 [details]
script to donwload kernel RPMs and produce a files list

Ok, this script version produces the same file list footprint.

MGA9-64 Plasma on an HP Probook 6550b, same hardware as comment 16. 

No installation issues. The dkms-broadcom-wl driver built successfully. After the reboot, used it this morning for this and that, including now, and no issues to report.

Just as a reminder for the future... When we move on to the 6.6 series kernels, be sure to check that dkms packages build with it. Over the years dkms-rtl8192eu has proved particularly sensitive to kernel updates, but others have had problems, too.

MGA9-64, GNOME, AMD Ryzen 5600, Nvidia 1050


The following 7 packages are going to be installed:

- cpupower-6.5.11-5.mga9.x86_64
- kernel-desktop-6.5.11-5.mga9.x86_64
- kernel-desktop-devel-6.5.11-5.mga9.x86_64
- kernel-desktop-devel-latest-6.5.11-5.mga9.x86_64
- kernel-desktop-latest-6.5.11-5.mga9.x86_64
- kernel-userspace-headers-6.5.11-5.mga9.x86_64
- lib64bpf1-6.5.11-5.mga9.x86_64

149MB of additional disk space will be used.

-----

- Nvidia working

# lsmod | grep nvidia
nvidia_uvm           1703936  0
nvidia_drm             90112  6
drm_kms_helper        249856  1 nvidia_drm
nvidia_modeset       1318912  8 nvidia_drm
video                  69632  1 nvidia_modeset
nvidia              56643584  259 nvidia_uvm,nvidia_modeset
drm                   802816  10 drm_kms_helper,nvidia,nvidia_drm

- Bluetooth functioning
- system behaving as expected.

MGA9-32bit, Xfce, Ryzen 2600, Nouveau

The following 5 packages are going to be installed:

- cpupower-6.5.11-5.mga9.i586
- kernel-desktop-6.5.11-5.mga9.i586
- kernel-desktop-latest-6.5.11-5.mga9.i586
- kernel-userspace-headers-6.5.11-5.mga9.i586
- libbpf1-6.5.11-5.mga9.i586


---rebooted
$ uname -a
Linux localhost 6.5.11-desktop-5.mga9 #1 SMP PREEMPT_DYNAMIC Sun Nov 19 00:56:21 UTC 2023 i686 GNU/Linux


- sound is working
- video is working
- browser is working
- libreoffice is working

(In reply to Giuseppe Ghibò from comment #10)
> (In reply to Marja Van Waes from comment #9)
>
> > 
> > https://svnweb.mageia.org/advisories/32537.adv?revision=15276&view=markup
> 
> apparently 6.5.11 covers more, e.g. CVE-2023-6176 should be fixed already.

Updated advisory with CVE-2023-6176 included can be found here:
https://svnweb.mageia.org/advisories/32537.adv?revision=15280&view=markup

MGA9-64, Kernel Server, Intel, Xfce, Nextcloud

Installed Kernel-server, cpupower, etc.


Rebooted

Confirmed system is up and functioning as expected.

Today I get a strange desktop crash that let me only with window manager (openbox), I don't remove MGA9-32-OK but I'll be watching this with kernel-desktop

(In reply to katnatek from comment #29)

> Today I get a strange desktop crash that let me only with window manager
> (openbox), I don't remove MGA9-32-OK but I'll be watching this with
> kernel-desktop

you might look to the journal to see which application crashed, maybe was just an oom killer due to lack of RAM. Alternatively you might enable the core dump, to let core dump generated for the offeding application, and then you can use gdb on them.

(In reply to Marja Van Waes from comment #27)
> (In reply to Giuseppe Ghibò from comment #10)
> > (In reply to Marja Van Waes from comment #9)
> >
> > > 
> > > https://svnweb.mageia.org/advisories/32537.adv?revision=15276&view=markup
> > 
> > apparently 6.5.11 covers more, e.g. CVE-2023-6176 should be fixed already.
> 
> Updated advisory with CVE-2023-6176 included can be found here:
> https://svnweb.mageia.org/advisories/32537.adv?revision=15280&view=markup

I didn't manage to find a reference to that CVE (CVE-2023-6176) in the kernel changelogs.

However, I did find references in 6.5 to:
  CVE-2023-3772
  CVE-2023-3773
  CVE-2023-4155
  CVE-2023-34319
in 6.5.3 to:
  CVE-2023-25775
and in 6.5.9 to:
"relieve" CVE-2020-26555

and some more references, but they seemed to only be about situations that looked like specific CVEs.
I don't know what "relieve" means, make a vulnerability less vulnerable, without really fixing it??

MGA9-64 Plasma on an HP Pavilion 15, AMD A8-4555M APU, AMD HD 7600G graphics.

No installation issues. After the reboot I tried Firefox, Thunderbird, VirtualBox, VLC. No issues to report.

Suspend/resume by closing/opening the lid works, as always, but I often wonder if all that does is shut off the display - not a suspend in the traditional sense. Unlike my other laptop, resuming from closing the lid does not involve working the power button. All I have to do is open the lid again.

Resume from hibernation has never worked on this computer. I don't know if that has something to do with the kernel, or with the way the rEFInd bootloader works on this machine. 

Suspend/hibernate/resume always seems so hardware-dependent that I never pursue a solution - I just live with the way it works or doesn't on each machine. It's not like it's something that's vital for the way I operate.

mga9-64 OK on my laptop Dell Precision M6300;
CPU: Intel(R) Core(TM)2 Duo CPU  T7500
GPU: G84GLM [Quadro FX 1600M], using kernel modesetting
Wifi: PRO/Wireless 3945ABG [Golan]

Plasma, desktop apps, firefox internet video, suspend-resume

---

mga9-64 OK on laptop Acer Aspire7 A717-71G; Intel EFI, LVM on LUKS on NVMe, i5-7300HQ, using the intel GPU, wifi=QCA6174

(In reply to Thomas Andrews from comment #32)

> MGA9-64 Plasma on an HP Pavilion 15, AMD A8-4555M APU, AMD HD 7600G graphics.
> 
> No installation issues. After the reboot I tried Firefox, Thunderbird,
> VirtualBox, VLC. No issues to report.
> 
> Suspend/resume by closing/opening the lid works, as always, but I often
> wonder if all that does is shut off the display - not a suspend in the
> traditional sense. Unlike my other laptop, resuming from closing the lid
> does not involve working the power button. All I have to do is open the lid
> again.
> 
> Resume from hibernation has never worked on this computer. I don't know if
> that has something to do with the kernel, or with the way the rEFInd
> bootloader works on this machine. 
> 
> Suspend/hibernate/resume always seems so hardware-dependent that I never
> pursue a solution - I just live with the way it works or doesn't on each
> machine. It's not like it's something that's vital for the way I operate.

Yes.

BTW, for the others there is:

systemctl suspend
systemctl hibernate

(as root) which might do the same job by cli. To check it's really suspended you might hear if the CPU fan spins, and if it's ethernet connected, whether it answers to network ping(s). Sometimes suspending seems working, but it's not completing all the stuff (e.g. you still get the fan spins, and this might exausts the battery soon if you are on a laptop): I noticed this behaviour on some Ryzen 5xxx laptop CPUs. Suggestions found on the net for the same behaviour suggests to dump the ACPI table, modify it, and reload on startup.

Regarding resuming you are right, they may change from PC to PC. E.g. on some laptop resuming happens by just opening the LID, someone other just by mouse activity or keyboard activity, and in others you need to press the power button once.

There is also one critical case on resuming, and it's when you try resuming from a system that was booting from an external USB disk.

The hibernate requirement is usually that the SWAP space is big enough to save the whole memory image into SWAP space. If it's not big enough hibernate would fail. Another requirement is that the resume SWAP partition is specified on the kernel boot cmdline (through resume=...), otherwise it would hibernate, but at next boot it won't resume because don't know there is an hibernating partition to start from. It might also fail if the SWAP partition is big enough, but it's "busy", because the system is already swapping a lot, and there is not enough space to fit memory image + partial swapping. To give some number I noticed that with a 32GB RAM, I need at least 48GB swap to get hibernate not failing. A side effect is that the more swap space you add the more is used (unless you change vm.spappiness to 0), and this might also impact on SSDs writing cycles. This logic IMHO is fallacious because doesn't consider the real cases: you can't specify a partition that it's used for hibernation only and not also for virtual memory. Only chance is to add the extra space as swap partition, on the fly, just before issuing the hibernating commands.

Actually it works with swap partition smaller than RAM.

I know some years ago I routinely used a laptop hibernating with swap the size same as RAM (4GB) and no problem (SSDs was expensive).

  I now found a couple interesting links:

https://www.reddit.com/r/kernel/comments/k7mem8/what_kind_of_optimizations_are_used_to_reduce/

https://www.kernel.org/doc/html/latest/power/swsusp.html

https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate

(In reply to Morgan Leijström from comment #35)
> Actually it works with swap partition smaller than RAM.
> 
> I know some years ago I routinely used a laptop hibernating with swap the
> size same as RAM (4GB) and no problem (SSDs was expensive).
> 
>   I now found a couple interesting links:
> 
> https://www.reddit.com/r/kernel/comments/k7mem8/
> what_kind_of_optimizations_are_used_to_reduce/
> 
> https://www.kernel.org/doc/html/latest/power/swsusp.html
> 
> https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate

This can be used to fill the memory:

https://github.com/julman99/eatmemory

There was also an off-tree patchset/project called tux-on-ice for the hibernation

https://gitlab.com/nigelcunningham/tuxonice-kernel

but is no longer supported since 5.14.x.

(In reply to Marja Van Waes from comment #31)
> 
> (In reply to Marja Van Waes from comment #27)
> > (In reply to Giuseppe Ghibò from comment #10)
> > > (In reply to Marja Van Waes from comment #9)
> > >
> > > > 
> > > > https://svnweb.mageia.org/advisories/32537.adv?revision=15276&view=markup
> > > 
> > > apparently 6.5.11 covers more, e.g. CVE-2023-6176 should be fixed already.
> > 
> > Updated advisory with CVE-2023-6176 included can be found here:
> > https://svnweb.mageia.org/advisories/32537.adv?revision=15280&view=markup
> 
> I didn't manage to find a reference to that CVE (CVE-2023-6176) in the
> kernel changelogs.

I haven't seen listed explicitely too in the logs, AFAIK https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6176 lists fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066 which is included into 6.5.4 (admitting that's the only fix).

(In reply to Giuseppe Ghibò from comment #30)
> (In reply to katnatek from comment #29)
> 
> > Today I get a strange desktop crash that let me only with window manager
> > (openbox), I don't remove MGA9-32-OK but I'll be watching this with
> > kernel-desktop
> 
> you might look to the journal to see which application crashed, maybe was
> just an oom killer due to lack of RAM. Alternatively you might enable the
> core dump, to let core dump generated for the offeding application, and then
> you can use gdb on them.

I think was a bad configuration in the monitor tool, testing bug#32554 i get the same but was not a crash was the tool reset the display to integrated LCD what is a problem in this broken display laptop, sorry for the noise

(In reply to Marja Van Waes from comment #31)

> "relieve" CVE-2020-26555
> 
> and some more references, but they seemed to only be about situations that
> looked like specific CVEs.
> I don't know what "relieve" means, make a vulnerability less vulnerable,
> without really fixing it??

The term "relieve" was initially used here:

https://lkml.org/lkml/2023/10/1/48

With reference to comment 4:
After installing the linus kernel in this series I found no problems except my mouse seemed to malfunction every now and again (not battery trouble) to the point where I had to reboot to recover control.  It did not occur to me that this might have been a system freeze as I had to mess about with the mouse initially after booting to get it to work.  So maybe kernel linus does not always work?

Anyway, have updated to the dektop/server kernels and so far the desktop version is running OK but there was still a problem with the mouse.  Shall see how it goes.

Kernel: 6.5.11-desktop-5.mga9 arch: x86_64
10-core Intel Core i9-7900X
NVIDIA GP102 [GeForce GTX 1080 Ti] driver: nouveau
Intel Ethernet I219-V driver: e1000e
32GB RAM

CC: (none) => tarazed25

@Len, have you tried the mouse on another computer? Things do break. Cleaned it, changed surface it runs on?

@Morgan, yes I have tried swapping mice and cleaning things.  So far so good.  
Thanks.

(In reply to Giuseppe Ghibò from comment #37)
> (In reply to Marja Van Waes from comment #31)
> > 
> > (In reply to Marja Van Waes from comment #27)
> > 
> > I didn't manage to find a reference to that CVE (CVE-2023-6176) in the
> > kernel changelogs.
> 
> I haven't seen listed explicitely too in the logs, AFAIK
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6176 lists fix
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066 which is included into 6.5.4

You're rightm that is that CVE.

(In reply to Giuseppe Ghibò from comment #39)
> (In reply to Marja Van Waes from comment #31)
> 
> > "relieve" CVE-2020-26555
> > 

> > I don't know what "relieve" means, make a vulnerability less vulnerable,
> > without really fixing it??
> 
> The term "relieve" was initially used here:
> 
> https://lkml.org/lkml/2023/10/1/48

Thanks, to my n00b eyes, that looks like a real fix.

(In reply to Marja Van Waes from comment #31)

> However, I did find references in 6.5 to:
>   CVE-2023-3772
>   CVE-2023-3773
>   CVE-2023-4155
>   CVE-2023-34319
> in 6.5.3 to:
>   CVE-2023-25775
> and in 6.5.9 to:
> "relieve" CVE-2020-26555
> 

I plan to include these 6 CVEs in the advisory. And to sort the CVEs in the "CVE:"-section, but not in the description.

It is do good that the description says: ".... and fixes or adds mitigations for _at_least_ the following security issues:". So no problem if we miss some :o)

s/do/so/

@Len: "not battery trouble" indicates probably cordless mouse. Which brand name?

I use Logitech mice/keyboards with the unifying receiver, and so far they have been OK. 

I do have one that has given me trouble on the Probook 6550b, where sometimes I have to unplug the receiver and plug it back in for it to work. But it's only the one, so I believe that problem is wear of the usb port I've been using for years, even though the receiver stays in it all the time.

Updated advisory:
https://svnweb.mageia.org/advisories/32537.adv?revision=15284&view=markup

@Thomas: Yes, I use the Logitech combo mouse and keyboard on three of my machines and on the production machine the glitches seem to have gone away after a bit of swapping and re-plugging.  A neighbouring machine has a wired Alienware keyboard and wireless Logitech mouse and that did give trouble as well but seems to have settled back to normal operation.  The most recent kernels seem to be behaving.  Thanks.

(In reply to Brian Rockwell from comment #24)
> MGA9-64, GNOME, AMD Ryzen 5600, Nvidia 1050

X11 or Wayland?

GPU driver: Proprietary, nouveau or Xorg modesetting?


Here when i use kernel-desktop-6.5.11-5, nvidia 535.129.03 (from testing), and mesa 23.1.9-01 (Bug 32562), Gnome fail to launch on Wayland, but works on X11.  It works with Wayland on Xorg modesetting. GPU = Nvidia GTX750.

I have not tested more than that, 
but i think i used Wayland successfully this summer on proprietary driver.
So a regression, but in which package and version?
(I usually do not use Gnome, just occasionally test)

On Foolishness, my Dell Inspiron 5100, mga9-32 Xfce, P4, Radeon R200 graphics.

No installation issues, and no obvious issues to report after the reboot.

Forgot to mention, this is using kernel-desktop.

Adding to comment 1:

Now also on that system have tested OK with nvidia-current-535.129.03-1 and The new newfeature 545.29.06 (dkms built modules), and nouveau, and Xorg modesetting drivers.

(In reply to Thomas Andrews from comment #50)

> Forgot to mention, this is using kernel-desktop.

So, it seems everything ok.

Tested successfully on a Surface Pro 9 (except webcam but it was expected not to work).

Tested successfully on a desktop computer, Ryzen 9 5900X and GPU RX 6600.

CC: (none) => chb0

(In reply to Giuseppe Ghibò from comment #52)
> (In reply to Thomas Andrews from comment #50)
> 
> > Forgot to mention, this is using kernel-desktop.
> 
> So, it seems everything ok.

Looks like it to me.

When TMB was doing the kernels, he was the one who decided when there had been enough tests, and would OK and validate. So, I guess it's up to you now...

Since it works I think we can release.

(In reply to Marja Van Waes from comment #46)
> Updated advisory:
> https://svnweb.mageia.org/advisories/32537.adv?revision=15284&view=markup

Seems ok, I'd only correct the latest line:

And fixes at least one normal bug about sleep lockups:

  Drop Patch1030 and 1050 to fix sleep lockups (bug #32082)

to

"...And fixes at least one normal bug about sleep lockups (bug #32082)"

since it's of no interest the number of patch that has been dropped in the SPEC file in the advisory.

Then I think it's OK and we can release.

Everybody agrees.
I push the validation button for you :)

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

(In reply to Giuseppe Ghibò from comment #55)
> Since it works I think we can release.
> 
> (In reply to Marja Van Waes from comment #46)
> > Updated advisory:
> > https://svnweb.mageia.org/advisories/32537.adv?revision=15284&view=markup
> 
> Seems ok, I'd only correct the latest line:
> 
> And fixes at least one normal bug about sleep lockups:
> 
>   Drop Patch1030 and 1050 to fix sleep lockups (bug #32082)
> 
> to
> 
> "...And fixes at least one normal bug about sleep lockups (bug #32082)"
> 
> since it's of no interest the number of patch that has been dropped in the
> SPEC file in the advisory.

You're right. Done and committed to SVN:

Index: 32537.adv
===================================================================
--- 32537.adv   (revision 15304)
+++ 32537.adv   (working copy)
@@ -134,10 +134,7 @@
   together. Such an unusual packet would therefore trigger a buffer
   overrun in the driver. (CVE-2023-34319) 
  
-  And fixes at least one normal bug about sleep lockups:
-
-  Drop Patch1030 and 1050 to fix sleep lockups (bug #32082)
-
+  And fixes at least one normal bug about sleep lockups: (bug #32082)
 references:
  - https://bugs.mageia.org/show_bug.cgi?id=32537
  - https://bugs.mageia.org/show_bug.cgi?id=32082

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

https://advisories.mageia.org/MGASA-2023-0328.html

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

Lesson to learn

nvidia470 need be updated for kernel 5.6 series.

We did not know or forgot to block this before nvidia470 update :(

(In reply to Morgan Leijström from comment #60)
> Lesson to learn
> 
> nvidia470 need be updated for kernel 5.6 series.
> 
> We did not know or forgot to block this before nvidia470 update :(

You mean kernel 6.5 series.

Something else to check when we move on to the 6.6 series...

There's a lot of things that need to be updated when we update to a new kernel series.  Check past updates...