Description of problem: Machine: Dino PC Gigabyte Sniper.Z97 motherboard, nvidia GeForce GTX 770, driver 346.59, Intel core i7-4790K 4.00 GHz Classic DVD installed from USB for UEFI boot. All systems seemed to be working but AltCtlF2 blanked the screen and the machine appeared to go into a wait state and the monitor connection timed out. Desktop comes back after AltCtlF1 x 2. The first press wakes up the monitor and the second recovers the desktop. My suspicion is that this is a problem between nvidia and the motherboard because there is always a long hiatus after a logout resulting in the monitor connection timing out. The kdm screen eventually appears and login is quick but reboot results in another hiatus before the machine actually responds. If the onboard Intel graphics are used, these delays do not happen so I think this is probably not a bug which Mageia can address. Advances in the nvidia driver might cure the problem in time. There is no category for this under Severity so I have left it as is. Version-Release number of selected component (if applicable): Cannot identify. How reproducible: Always AFAIK Steps to Reproduce: 1. boot this hardware combination in UEFI mode 2. from user desktop AltCtlF2 3. wait Reproducible: Steps to Reproduce:
QA has asked me to attach the journal. Not sure which, so I am submitting the user journal (encoded). Oops - the size limit is 1 MB and this comes in at 8.4 MB. Sorry. I could not get anything useful out of journalctl -f for the user.
I tried the KDE Live iso on a Lenovo Y500 Ideapad after switching to UEFI mode. This has nvidia graphics. Screen corruption occurred during the boot but it cleared for the install dialogue. CtrlAltF2 changed the display to something which might have been console mode but the screen was badly corrupted. CtrlAltF1 recovered the user desktop. Going back to a legacy mode boot restored the normal virtual console functionality.
(In reply to Len Lawrence from comment #1) > QA has asked me to attach the journal. Not sure which, so I am submitting > the user journal (encoded). Oops - the size limit is 1 MB and this comes in > at 8.4 MB. Sorry. I could not get anything useful out of journalctl -f for > the user. try for instance (as root): journalctl -a > journalctl.txt and then compress it xz journalctl.txt that'll give a much smaller journalctl.txt.xz
CC: (none) => marja11
Whiteboard: (none) => 5RC
Thanks Marja. We have just collided so I shall submit again.
Additional information following on from comment 1: 3.19.4-desktop-2.mga5 As root, journalctl -a > journal.txt Last few lines are all that are relevant: Apr 18 20:01:01 vega crond[9788]: pam_tcb(crond:session): Session opened for root by (uid=0) Apr 18 20:01:01 vega CROND[9789]: (root) CMD (nice -n 19 run-parts --report /etc/cron.hourly) Apr 18 20:01:01 vega CROND[9788]: pam_tcb(crond:session): Session closed for root Apr 18 20:26:30 vega su[4540]: pam_tcb(su-l:auth): Authentication passed for root from lcl(uid=1000) Apr 18 20:26:30 vega su[4540]: (to root) lcl on pts/0 Apr 18 20:26:30 vega su[4540]: pam_tcb(su-l:session): Session opened for root by lcl(uid=1000) Apr 18 20:26:40 vega acpid[3676]: client 3740[0:0] has disconnected Apr 18 20:27:13 vega systemd[1]: Starting Getty on tty2... Apr 18 20:27:13 vega systemd[1]: Started Getty on tty2. Apr 18 20:27:19 vega acpid[3676]: client 3740[0:0] has disconnected Apr 18 20:27:20 vega acpid[3676]: client connected from 3740[0:0] Apr 18 20:27:20 vega acpid[3676]: 1 client rule loaded Apr 18 20:27:20 vega acpid[3676]: client connected from 3740[0:0] Apr 18 20:27:20 vega acpid[3676]: 1 client rule loaded The same procedure on my Lenovo Ideapad booted in CSM mode gives this: 3.19.4-desktop-1.mga5 Apr 18 20:44:51 juza acpid[2217]: client 2321[0:0] has disconnected Apr 18 20:44:51 juza acpid[2217]: client 2321[0:0] has disconnected Apr 18 20:45:00 juza login[15638]: pam_tcb(login:auth): Authentication passed for lcl from LOGIN(uid=0) Apr 18 20:45:00 juza systemd-logind[2212]: New session c5 of user lcl. Apr 18 20:45:00 juza login[15638]: pam_tcb(login:session): Session opened for lcl by LOGIN(uid=0) Apr 18 20:45:00 juza login[15638]: LOGIN ON tty3 BY lcl Apr 18 20:45:03 juza login[15638]: pam_tcb(login:session): Session closed for lcl Apr 18 20:45:03 juza systemd-logind[2212]: Removed session c5. Apr 18 20:45:06 juza acpid[2217]: client connected from 2321[0:0] Apr 18 20:45:06 juza acpid[2217]: 1 client rule loaded Apr 18 20:45:06 juza acpid[2217]: client connected from 2321[0:0] Apr 18 20:45:06 juza acpid[2217]: 1 client rule loaded and there the system behaved itself. Back to vega and try again: Apr 18 21:04:24 vega acpid[3676]: client 3740[0:0] has disconnected Apr 18 21:05:59 vega acpid[3676]: client 3740[0:0] has disconnected Apr 18 21:06:49 vega acpid[3676]: client connected from 3740[0:0] Apr 18 21:06:49 vega acpid[3676]: 1 client rule loaded Apr 18 21:06:49 vega acpid[3676]: client connected from 3740[0:0] Apr 18 21:06:49 vega acpid[3676]: 1 client rule loaded Note that here there is no systemd getty... I waited a while after the blue light turned to orange and also tried the command again - waited just in case there were hardware timing issues as already mooted above.
CC: (none) => mageia, tmb
Created attachment 6312 [details] Compressed journal file Extracted the whole journal since the last reboot.
CC: (none) => eeeemail
Problems in other areas as well seem to indicate that this bug is probably specific to my test hardware so I would conclude that this bug is invalid, probably.
(In reply to Len Lawrence from comment #7) > Problems in other areas as well seem to indicate that this bug is probably > specific to my test hardware so I would conclude that this bug is invalid, > probably. You mean it's a hardware failure, or a software issue that occurs only with your hardware?
Keywords: (none) => NEEDINFO
I mean I have absolutely no idea except that the various faults/problems seem specific to that machine. I ordered it as a high performance machine but unfortunately their high spec hardware seems tailored for gamers, which is ironic because I never play games. If I knew how to investigate it I would. I have given up on that machine. With some of the issues it may well be hardware, timing, whatever. The other company I was thinking of using was Scan but it seems evident that they cater mainly for gamesters. So I shall fall back on the old reliable, Dell.
Closed old?
CC: (none) => nic
(In reply to Len Lawrence from comment #7) > Problems in other areas as well seem to indicate that this bug is probably > specific to my test hardware so I would conclude that this bug is invalid, > probably. Invalid would only be good if your hardware is broken, but it is just different. You were probably right to think that a nvidia driver update might cure the problem, and that there's nothing we can do. When we're sure about that we set the UPSTREAM keyword. I didn't find any other reports (outside Mageia) about this issue, though, but there's a good chance that only means that I didn't search well enough :-þ (In reply to Nic Baxter from comment #10) > Closed old? I prefer to set it to unconfirmed for now... it'll be easier to find if someone with the same hw (or just the same nvidia card) hits it. @ Len Or did this already get fixed?
Status: NEW => UNCONFIRMEDEver confirmed: 1 => 0
No Marja. Nothing has changed over the course of several kernel updates and graphics driver updates so I rather suspect that it can never be fixed. The machine is in all other respects functional so I leave it to you whether it should be UPSTREAM or UNCONFIRMED, or UNRESOLVED/UNRESOLVABLE?
@ Len Did this get solved, somewhere in the past year? If not, did you hit it again in a fresh UEFI install on that system?
@ Marja Been keeping an eye open for it but it seems to have disappeared with the latest isos and never affected Plasma. I just wondered if it was something to do with Wayland coming into play in some fashion. That would try to use onboard graphics I think via DVI, which is not connected to the monitor. Maybe you could advise whether it is invalid or solved or even unconfirmed? Thanks.
(In reply to Len Lawrence from comment #14) > @ Marja > > Been keeping an eye open for it but it seems to have disappeared with the > latest isos and never affected Plasma. Great :) > I just wondered if it was something > to do with Wayland coming into play in some fashion. That would try to use > onboard graphics I think via DVI, which is not connected to the monitor. > Maybe you could advise whether it is invalid or solved or even unconfirmed? > Solved, since you no longer see it :) If the issue reoccurs with a future iso, then please reopen this report. It should then be assigned to the kernel and drivers maintainers. (If the problem was with your hardware, then the latest isos wouldn't have solved it)
Status: UNCONFIRMED => RESOLVEDResolution: (none) => FIXED