Created attachment 8824 [details]
Log of Cauldron update

After this update, booting keeps locking up as described.

N.B. Further Cauldron updates applied (using Ctl-Alt-F2), but no change in booting lockup.

Just to add, I'm not experiencing this lockup on either of two machines with several installs on the one machine with 304.134 driver (Athlon X2 3Gh) and 2 installs on another machine (AMD FX 4100 quad 3.6) using 340.101 driver.  I spent hours yesterday doing M6 updates and bug hunting.  Main problem I'm seeing will be a separate bug about Plasma.

CC: (none) => petel123123

As you suggested, I have removed "quiet", and now see 40 extra lines logged after the earlier 'Looking for hardware' final msg before lockup.

The final output line now (at the end of the 40) is:

[   44.024891] audit: type=1130 audit(1483293367.808:67): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=cups comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


(Is there way of getting those lines written somewhere on disk, so can be copied/pasted later?)

Please run, as root

     urpmi --auto-update 2>&1 | tee updates.txt

and reboot. 

If the issue isn't solved, then please attach updates.txt to this bug report, and do also attach journal.txt that is the result of running, as root:

      journalctl -ab > journal.txt

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

Created attachment 8825 [details]
Cauldron update 1/1/17

Created attachment 8826 [details]
journal.txt from locked Boot of Mageia-6

As requested:  Cauldron update log + journal.txt from locked Boot.

(In reply to Maurice Batey from comment #4)

> The final output line now (at the end of the 40) is:
> 
> [   44.024891] audit: type=1130 audit(1483293367.808:67): pid=1 uid=0
> auid=4294967295 ses=4294967295 msg='unit=cups comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Personally, I would remove audit messages by adding audit=0 to kernel boot arguments. Might not hurt to disable ipv6 either. Snippet of my boot line:
   noiswmd ipv6.disable=1 audit=0 vga=795
Running radeon video hardware so nokmsboot is not needed.

You can reduce journal post size with --no-hostname option to journalctl.

I would boot runlevel 3, log in as root and run 'drakx11' and set video driver xorg/vesa. Reboot and if works, mcc and configure non-vendor video driver, reboot and if works, try mcc again and see if vendor driver works.

Seeing the same symptoms on real hardware, after updating today to kernel 4.9.0. Booting into kernel 4.8.15 works as it did before the update.

Hardware: Home-built desktop with ASRock A790GXH/128M motherboard, Athlon X2 7750 processor, 8GB RAM, Geforce 9800 GT video. Original M6 install produced with the sta2 pretest Classical iso that wasn't released to QA for further testing. 

The Mageia Classical installer always installs the server kernel on this machine, because the BIOS erroneously reports that it contains ECC RAM. In the past, this has made no user-discernible difference in operation.

Booting with the "splash quiet" kernel options, it appears to "hang up" after giving the following messages, though careful observation shows a periodic flash of the hard drive LED:

Starting Hold until boot process finishes up...
[  34.935040] xt_addrtype: ipv6 does not support BROADCAST matching

Booting without "splash quiet" shows the "hang up" to be indicated by a series of messages in the following form:

[various numbers, increasing with each line] audit: type=1100(or 1101) audit(various numbers):pid=(more numbers) uid=0 auid=4294967295 ses=4294967295 msg='op=PAM: authentication grantors=pam_permit acct="sddm" exe="usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success'

lines similar to that continue until I get tired and stop it.

(In reply to Maurice Batey from comment #7)
> Created attachment 8826 [details]
> journal.txt from locked Boot of Mageia-6
> 
> As requested:  Cauldron update log + journal.txt from locked Boot.

This looks odd:

Jan 01 19:38:50 localhost sddm-greeter[16530]: QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
Jan 01 19:38:50 localhost sddm-greeter[16530]: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile  0) 

Is bug 17221 hitting us again?

Anyway, assigning to SDDM and to the KDE maintainers.

Keywords: NEEDINFO => (none)
Source RPM: (none) => sddm
Assignee: bugsquad => kde

Created attachment 8828 [details]
Journal from TJ's failed boot

CC: (none) => andrewsfarm

Created attachment 8829 [details]
Journal from TJ's successful boot into older kernel

I'm not seeing precisely the same symptoms as Maurice. For one thing, the three question marks do not show when I attempt to boot into server kernel 4.9.0, but they do when I successfully boot into kernel 4.8.15.

I don't know much about what I'm seeing in these logs, but it looks to me like my failed boot shows it locked into a loop having something to do with the nvidia module.

Comment on attachment 8828 [details]
Journal from TJ's failed boot

(In reply to Thomas Andrews from comment #13)
> I'm not seeing precisely the same symptoms as Maurice. For one thing, the
> three question marks do not show when I attempt to boot into server kernel
> 4.9.0, but they do when I successfully boot into kernel 4.8.15.
> 
> I don't know much about what I'm seeing in these logs, but it looks to me
> like my failed boot shows it locked into a loop having something to do with
> the nvidia module.

It looks like you hit bug 20058 instead of this one ;-)

You've got 66 kernel call traces. Maurice has none.

Attachment 8828 is obsolete: 0 => 1

> log in as root and run 'drakx11' and set video driver xorg/vesa.

  Set it to 'nouveau'.

> Reboot and if works,

  Yes, it did

> mcc and configure non-vendor video driver, reboot and if works, try mcc 
> again and see if vendor driver works.

In MCC, accepted proprietary driver, after which reboot locked up as before.

Seems quite simple: 
  If Nouveau selected, boot proceeds normally;
  If p.driver selected, boot locks up...

Reassigning to the kernel and driver maintainers, because neoclust seems sure it's not an SDDM bug.

However, I doubt other DMs give this problem.

@ Maurice

Does the proprietary driver give the same problem with other DMs, like e.g. GDM?

Assignee: bugsquad => kernel
Source RPM: sddm => (none)

if it works with nouveau and not nv i doubt this is a sddm bug

does it help to add sddm to video group ?

adduser sddm video

and trying to use proprietary driver again ?

CC: (none) => tmb

> does it help to add sddm to video group ?
> adduser sddm video

$ adduser sddm video
$ grep video /etc/group
video:x:82:mab

Unless "82" is SDDM, it seems not to have worked.
  (Even after reboot)

> $ adduser sddm video
> $ grep video /etc/group
> video:x:82:mab

> Unless "82" is SDDM, it seems not to have worked.
> (Even after reboot)

There seem to be many other ways to do it, e.g.

   # gpasswd -a sddm video
   # usermod -a -G video sddm
   # groupmod -aG video sddm

(the latter mentioned in https://bugs.mageia.org/show_bug.cgi?id=17221 )

But is it needed? According to e.g.   https://github.com/sddm/sddm :

"Distributions without pam and systemd will need to put the "sddm" user 
into the "video" group, otherwise errors regarding GL and drm devices 
might be experienced."

- so perhaps the presence in Mageia-6 of both pam & systemd obviates the need?

> # usermod -a -G video sddm

P.s. That did the trick!

Also, having finessed the nVidia proprietary driver in MCC/Hardware, rebooting succeeds to Plasma5 login, and the nvidia driver is confirmed there as:
  "3.3.0 NVIDIA 340.101".

So it seem YES - sddm does need adding to the video group...

Resetting back to KDE maintainers as they do not follow sddm instructions (see comment #20)

Assignee: kernel => kde
Source RPM: (none) => sddm
CC: (none) => thierry.vignaud

since we have both pam and systemd...

Maybe we miss some BR or config flag (or both) to make sddm detect/use logind

I take a look to this tomorow morning.

I take a look to this tomorow morning.

"If pam and systemd are available, the greeter will go through logind,
which will give it access to drm devices.

Distributions without pam and systemd will need to put the **sddm** user
into the **video** group, otherwise errors regarding GL and drm devices
might be experienced."


so this is runtime deps but i hardly see a mga6 w/o pam and systemd :)

and pam-devel and systemd-devel are installed at build time too

is this still valid ? i still can't reproduce this issue

No recurrence since adding sddm to the video group...

yes but this is not the wanted solution :)

Just tested with a Mageia Sta2 iso and it works fine for me.

Please reopen if you still experience this issue with Sta2 ( when released )

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

(In reply to Thomas Andrews from comment #9)
> Seeing the same symptoms on real hardware, after updating today to kernel
> 4.9.0. Booting into kernel 4.8.15 works as it did before the update.
> 
> Hardware: Home-built desktop with ASRock A790GXH/128M motherboard, Athlon X2
> 7750 processor, 8GB RAM, Geforce 9800 GT video. Original M6 install produced
> with the sta2 pretest Classical iso that wasn't released to QA for further
> testing. 
> 
> The Mageia Classical installer always installs the server kernel on this
> machine, because the BIOS erroneously reports that it contains ECC RAM. In
> the past, this has made no user-discernible difference in operation.
> 
> Booting with the "splash quiet" kernel options, it appears to "hang up"
> after giving the following messages, though careful observation shows a
> periodic flash of the hard drive LED:
> 
> Starting Hold until boot process finishes up...
> [  34.935040] xt_addrtype: ipv6 does not support BROADCAST matching
> 
> Booting without "splash quiet" shows the "hang up" to be indicated by a
> series of messages in the following form:
> 
> [various numbers, increasing with each line] audit: type=1100(or 1101)
> audit(various numbers):pid=(more numbers) uid=0 auid=4294967295
> ses=4294967295 msg='op=PAM: authentication grantors=pam_permit acct="sddm"
> exe="usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success'
> 
> lines similar to that continue until I get tired and stop it.

I ran the Mageia 6 upgrade directly from the internet last night, and everything downloaded and installed ok, as far as I can tell.  The startup screen showed up ok and things looked good until I too got endless iterations of the sddm-helper message you show here.  Not knowing what was going on, I let it run overnight, and of course it simply continued with these messages.  I have since learned that sddm is the new display (or login) manager, and also seen mentions of the "sddm" user needing to be in the "video" group in distros without pam.  Don't know what pam is yet, still have to Google that.

I think I know what's wrong here, but I'm not sure, so here goes.  I run my Mageia 5 Linux in a virtual machine managed by Parallels Desktop for Mac running on a Mid 2012 13" MacBook Air.  OS X and Parallels are right up to date.  Parallels has a feature called Parallels Tools which is pretty well essential to install to get workable mouse and video performance.  It runs shell scripts to install itself which can be pretty picky about Linux distro versions.  Parallels is updated promptly in anticipation of Windows updates and upgrades, but they're usually several months behind when a Linux distro is updated or upgraded.  When I upgraded from Mageia 4 to 5 and Tools wouldn't install, Parallels said "not supported" yet, so I just had to wait.

At the moment it looks to me that, since Mageia 6 was only released yesterday, and since some of the changes are so major (e.g. Plasma 5 and SDDM), Parallels just can't handle it until they update it and officially support Mageia 6, probably in another 3 or 4 months.  Does this make sense?  Or is there something else going on that I don't know about?

I've got lots of snapshots of my virtual machine in various states, so there's no problem in reverting back to Mageia 5 until such time as Parallels catches up.

CC: (none) => acecoder

After upgrading from mga5 to mga6 I'm encoutering this issue with tons of sddm related messages print onto the main screen. BTW the only solution to work is to connect via ssh to the machine to try to repair.

I added the sddm user to the group but that wasn't sufficient.

Took me time to find something, but finally it seemed that the nvidia driver wasn't loaded (as per Xorg.0.log) and I had to manually create that link:
ln -sf /usr/lib64/nvidia-current/xorg/nvidia_drv.so /usr/lib64/xorg/modules/drivers/
which helped, showing it was indeed loaded but:
[    78.324] (WW) NVIDIA(0): The NVIDIA GeForce 8400 GS GPU installed in this system is
[    78.324] (WW) NVIDIA(0):     supported through the NVIDIA 340.xx Legacy drivers. Please
[    78.324] (WW) NVIDIA(0):     visit http://www.nvidia.com/object/unix.html for more
[    78.324] (WW) NVIDIA(0):     information.  The 384.59 NVIDIA driver will ignore this
[    78.324] (WW) NVIDIA(0):     GPU.  Continuing probe... 
[    78.324] (EE) No devices detected.

Because I had both the 384 driver and the 340. So I remove the 384:

urpme nvidia-current-doc-html-384.59-1.mga6.nonfree x11-driver-video-nvidia-current-384.59-1.mga6.nonfree dkms-nvidia-current-384.59-1.mga6.nonfree

So the correct link for my conf was rather:
ln -sf /usr/lib64/nvidia340/xorg/nvidia_drv.so /usr/lib64/xorg/modules/drivers/


After that I had an X server running, still not a correct as I have just the mouse on a black screen. Digging more !

Don't know why the links are not made for me :-(

Status: RESOLVED => REOPENED
Resolution: WORKSFORME => (none)
CC: (none) => bruno

CC'ing kernel & drivers maintainers because of:

(In reply to Bruno Cornec from comment #33)
> After upgrading from mga5 to mga6 I'm encoutering this issue with tons of
> sddm related messages print onto the main screen. BTW the only solution to
> work is to connect via ssh to the machine to try to repair.
> 
> I added the sddm user to the group but that wasn't sufficient.
> 
> Took me time to find something, but finally it seemed that the nvidia driver
> wasn't loaded (as per Xorg.0.log) and I had to manually create that link:
> ln -sf /usr/lib64/nvidia-current/xorg/nvidia_drv.so
> /usr/lib64/xorg/modules/drivers/
> which helped, showing it was indeed loaded but:
> [    78.324] (WW) NVIDIA(0): The NVIDIA GeForce 8400 GS GPU installed in
> this system is
> [    78.324] (WW) NVIDIA(0):     supported through the NVIDIA 340.xx Legacy
> drivers. Please
> [    78.324] (WW) NVIDIA(0):     visit
> http://www.nvidia.com/object/unix.html for more
> [    78.324] (WW) NVIDIA(0):     information.  The 384.59 NVIDIA driver will
> ignore this
> [    78.324] (WW) NVIDIA(0):     GPU.  Continuing probe... 
> [    78.324] (EE) No devices detected.
> 
> Because I had both the 384 driver and the 340. So I remove the 384:
> 
> urpme nvidia-current-doc-html-384.59-1.mga6.nonfree
> x11-driver-video-nvidia-current-384.59-1.mga6.nonfree
> dkms-nvidia-current-384.59-1.mga6.nonfree
> 
> So the correct link for my conf was rather:
> ln -sf /usr/lib64/nvidia340/xorg/nvidia_drv.so
> /usr/lib64/xorg/modules/drivers/
> 
> 
> After that I had an X server running, still not a correct as I have just the
> mouse on a black screen. Digging more !
> 
> Don't know why the links are not made for me :-(

CC: (none) => kernel

(In reply to Bruno Cornec from comment #33)

> which helped, showing it was indeed loaded but:
> [    78.324] (WW) NVIDIA(0): The NVIDIA GeForce 8400 GS GPU installed in
> this system is
> [    78.324] (WW) NVIDIA(0):     supported through the NVIDIA 340.xx Legacy
> drivers. Please
> [    78.324] (WW) NVIDIA(0):     visit
> http://www.nvidia.com/object/unix.html for more
> [    78.324] (WW) NVIDIA(0):     information.  The 384.59 NVIDIA driver will
> ignore this
> [    78.324] (WW) NVIDIA(0):     GPU.  Continuing probe... 
> [    78.324] (EE) No devices detected.
> 

Ok, so we need to switch this card from -current to -nvidia340

Can you provide output of lspcidrake -v

# lspcidrake -v
unknown         : Intel Corporation|7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers [SYSTEM_PIC] (vendor:8086 device:3422) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 0 Rank [BRIDGE_HOST] (vendor:8086 device:2da2 subv:1849 subd:2c70) (rev: 01)
shpchp          : Intel Corporation|5520/5500/X58 I/O Hub PCI Express Root Port 7 [BRIDGE_PCI] (vendor:8086 device:340e) (rev: 12)
snd_hda_intel   : Intel Corporation|82801JI (ICH10 Family) HD Audio Controller [MULTIMEDIA_AUDIO_DEV] (vendor:8086 device:3a3e subv:1849 subd:0890)
r8169           : Realtek Semiconductor Co., Ltd.|RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8168 subv:1849 subd:8168) (rev: 03)
unknown         : Intel Corporation|Xeon 5600 Series QPI Physical 1 [BRIDGE_HOST] (vendor:8086 device:2d95 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 2 Address [BRIDGE_HOST] (vendor:8086 device:2db1 subv:1849 subd:2c70) (rev: 01)
shpchp          : Intel Corporation|82801JI (ICH10 Family) PCI Express Root Port 6 [BRIDGE_PCI] (vendor:8086 device:3a4a)
i5500_temp      : Intel Corporation|7500/5520/5500/X58 I/O Hub Throttle Registers [SYSTEM_PIC] (vendor:8086 device:3438) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Target Address Decoder [BRIDGE_HOST] (vendor:8086 device:2d99 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 2 Thermal Control [BRIDGE_HOST] (vendor:8086 device:2db3 subv:1849 subd:2c70) (rev: 01)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #2 [SERIAL_USB] (vendor:8086 device:3a35 subv:1849 subd:3a35)
firewire_ohci   : VIA Technologies, Inc.|VT6315 Series Firewire Controller [SERIAL_FIREWIRE] (vendor:1106 device:3403 subv:1849 subd:3403)
shpchp          : Intel Corporation|5520/5500/X58 I/O Hub PCI Express Root Port 1 [BRIDGE_PCI] (vendor:8086 device:3408) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 1 Control [BRIDGE_HOST] (vendor:8086 device:2da8 subv:1849 subd:2c70) (rev: 01)
lpc_ich         : Intel Corporation|82801JIR (ICH10R) LPC Interface Controller [BRIDGE_ISA] (vendor:8086 device:3a16 subv:1849 subd:3a16)
unknown         : Intel Corporation|Xeon 5600 Series QuickPath Architecture System Address Decoder [BRIDGE_HOST] (vendor:8086 device:2d81 subv:1849 subd:2c70) (rev: 01)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #5 [SERIAL_USB] (vendor:8086 device:3a38 subv:1849 subd:3a38)
unknown         : Intel Corporation|Xeon 5600 Series QPI Link 0 [BRIDGE_HOST] (vendor:8086 device:2d90 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 1 Rank [BRIDGE_HOST] (vendor:8086 device:2daa subv:1849 subd:2c70) (rev: 01)
shpchp          : Intel Corporation|82801JI (ICH10 Family) PCI Express Root Port 1 [BRIDGE_PCI] (vendor:8086 device:3a40)
unknown         : JMicron Technology Corp.|JMB360 AHCI Controller [STORAGE_SATA] (vendor:197b device:2360 subv:1849 subd:2360) (rev: 02)
ata_piix        : Intel Corporation|82801JI (ICH10 Family) 4 port SATA IDE Controller #1 [STORAGE_IDE] (vendor:8086 device:3a20 subv:1849 subd:3a20)
unknown         : Intel Corporation|Xeon 5600 Series Mirror Port Link 0 [BRIDGE_HOST] (vendor:8086 device:2d92 subv:1849 subd:2c70) (rev: 01)
i7core_edac     : Intel Corporation|7500/5520/5500/X58 I/O Hub System Management Registers [SYSTEM_PIC] (vendor:8086 device:342e) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 0 Address [BRIDGE_HOST] (vendor:8086 device:2da1 subv:1849 subd:2c70) (rev: 01)
ehci_pci        : Intel Corporation|82801JI (ICH10 Family) USB2 EHCI Controller #1 [SERIAL_USB] (vendor:8086 device:3a3a subv:1849 subd:3a3a)
unknown         : Intel Corporation|Xeon 5600 Series QPI Link 1 [BRIDGE_HOST] (vendor:8086 device:2d94 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 2 Control [BRIDGE_HOST] (vendor:8086 device:2db0 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|7500/5520/5500/X58 I/O Hub Control Status and RAS Registers [SYSTEM_PIC] (vendor:8086 device:3423) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 0 Thermal Control [BRIDGE_HOST] (vendor:8086 device:2da3 subv:1849 subd:2c70) (rev: 01)
ehci_pci        : Intel Corporation|82801JI (ICH10 Family) USB2 EHCI Controller #2 [SERIAL_USB] (vendor:8086 device:3a3c subv:1849 subd:3a3c)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Registers [BRIDGE_HOST] (vendor:8086 device:2d98 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 2 Rank [BRIDGE_HOST] (vendor:8086 device:2db2 subv:1849 subd:2c70) (rev: 01)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #1 [SERIAL_USB] (vendor:8086 device:3a34 subv:1849 subd:3a34)
Card:NVIDIA GeForce 8100 to GeForce 415: NVIDIA Corporation|G98 [GeForce 8400 GS Rev. 2] [DISPLAY_VGA] (vendor:10de device:06e4) (rev: a1)
unknown         : Intel Corporation|Xeon 5600 Series QuickPath Architecture Generic Non-core Registers [BRIDGE_HOST] (vendor:8086 device:2c70 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller RAS Registers [BRIDGE_HOST] (vendor:8086 device:2d9a subv:1849 subd:2c70) (rev: 01)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #4 [SERIAL_USB] (vendor:8086 device:3a37 subv:1849 subd:3a37)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #3 [SERIAL_USB] (vendor:8086 device:3a36 subv:1849 subd:3a36)
pata_via        : VIA Technologies, Inc.|VT6415 PATA IDE Host Controller [STORAGE_IDE] (vendor:1106 device:0415 subv:1849 subd:0415) (rev: a0)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 1 Address [BRIDGE_HOST] (vendor:8086 device:2da9 subv:1849 subd:2c70) (rev: 01)
shpchp          : Intel Corporation|5520/5500/X58 I/O Hub PCI Express Root Port 3 [BRIDGE_PCI] (vendor:8086 device:340a) (rev: 12)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Test Registers [BRIDGE_HOST] (vendor:8086 device:2d9c subv:1849 subd:2c70) (rev: 01)
uhci_hcd        : Intel Corporation|82801JI (ICH10 Family) USB UHCI Controller #6 [SERIAL_USB] (vendor:8086 device:3a39 subv:1849 subd:3a39)
unknown         : Intel Corporation|Xeon 5600 Series QPI Physical 0 [BRIDGE_HOST] (vendor:8086 device:2d91 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 1 Thermal Control [BRIDGE_HOST] (vendor:8086 device:2dab subv:1849 subd:2c70) (rev: 01)
shpchp          : Intel Corporation|82801JI (ICH10 Family) PCI Express Port 2 [BRIDGE_PCI] (vendor:8086 device:3a42)
unknown         : Intel Corporation|5520/5500/X58 I/O Hub to ESI Port [BRIDGE_HOST] (vendor:8086 device:3405 subv:1849 subd:3405) (rev: 12)
i2c_i801        : Intel Corporation|82801JI (ICH10 Family) SMBus Controller [SERIAL_SMBUS] (vendor:8086 device:3a30 subv:1849 subd:3a30)
unknown         : Intel Corporation|Xeon 5600 Series Integrated Memory Controller Channel 0 Control [BRIDGE_HOST] (vendor:8086 device:2da0 subv:1849 subd:2c70) (rev: 01)
unknown         : Intel Corporation|82801 PCI Bridge [BRIDGE_PCI] (vendor:8086 device:244e) (rev: 90)
unknown         : Intel Corporation|Xeon 5600 Series Mirror Port Link 1 [BRIDGE_HOST] (vendor:8086 device:2d93 subv:1849 subd:2c70) (rev: 01)
ata_piix        : Intel Corporation|82801JI (ICH10 Family) 2 port SATA IDE Controller #2 [STORAGE_IDE] (vendor:8086 device:3a26 subv:1849 subd:3a26)
hub             : Linux 4.9.43-server-1.mga6 ehci_hcd|EHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0002)
usb_storage     : TOSHIBA|External USB 3.0 [Mass Storage|SCSI|Bulk-Only] (vendor:0480 device:a202)
hub             : Linux 4.9.43-server-1.mga6 ehci_hcd|EHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0002)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)
hub             : Linux 4.9.43-server-1.mga6 uhci_hcd|UHCI Host Controller [Hub|Unused|Full speed (or root) hub] (vendor:1d6b device:0001)


I still have plenty of issues with the graphical conf/sddm/black screens, tryong to launch KDE, ... not to say it's mga6 fault, as I made a mistake in my mga5 (tride a new version of my MondoRescue project natively, which moved /lib, /bin files in wrong places, so my real only possibility was to update to mga6 to put everything back to normal. Now it's not easy as I have a /var on mdadm, which isn't really well supported, ending up in this difficult situation. But as soon as I'll solve more problems, I'll try to bring back info on the bugs currently opened.

Thanks !
Bruno.

FTR: starting with init 3 and then as a user launching startx startkde gives me a black screen (nothing launched) and a mouse cursor. I have a menu with right button which allows me to launch konsole. I've been able to use nvidia-settings to increase my resolution (works up to 1920x1080).

Now trying to understand why nothing is launched with plasma5 vs KDE4, why the screenlock is giving a black screen again without possibility to do anything except kill X from another window, and why my sddm is still not OK.

No traffic in here  for 6 months, and as far as I am concerned the problem has gone away, but as it was closed then reopened 6 months ago perhaps the reopener can take over its fate?

sddm on nvidia nonfree is OK under Mageia 7 and Cauldron.

Status of this old bug is unclear.
Closing this OLD.
Feel free to really REOPEN if affected for Mageia 7.

Please also note that NVIDIA 340 series drivers are no longer supported upstream for newer kernel and this series could be supported only under Mageia7.

Version: Cauldron => 7
Priority: release_blocker => Normal
Status: REOPENED => RESOLVED
Resolution: (none) => OLD
Severity: normal => major

(In reply to Aurelien Oudelet from comment #39)
> sddm on nvidia nonfree is OK under Mageia 7 and Cauldron.
> 
> Please also note that NVIDIA 340 series drivers are no longer supported
> upstream for newer kernel and this series could be supported only under
> Mageia7.

OK here, as long as still OK for nVidia 430 series on Mga7 & Cauldron!