Created attachment 955384 [details] Xorg log on DRM 1.1.2 Description of problem: With any kernel 3.16.2 (Nouveau DRM interface 1.1.2), Xorg won't start. Same issue exist on F21. I have attach my Xorg log, even though there is not much there. Im posting first against Xorg driver because of the kernel commit comment, that seems to expect something from userspace: commit 7820e5eef0faa4a5e10834296680827f7ce78a89 Author: Mario Kleiner <mario.kleiner.de> Date: Wed Aug 6 06:09:44 2014 +0200 drm/nouveau: Bump version from 1.1.1 to 1.1.2 Linux 3.16 fixed multiple bugs in kms pageflip completion events and timestamping, which were originally introduced in Linux 3.13. These fixes have been backported to all stable kernels since 3.13. However, the userspace nouveau-ddx needs to be aware if it is running on a kernel on which these bugs are fixed, or not. Bump the patchlevel of the drm driver version to signal this, so backporting this patch to stable 3.13+ kernels will give the ddx the required info. Signed-off-by: Mario Kleiner <mario.kleiner.de> Cc: <stable.org> #v3.13+ Signed-off-by: Ben Skeggs <bskeggs> Feel free to move back to kernel if this isn't meaningless here. Version-Release number of selected component (if applicable): To rule out possible already fixed issues I've bumped to nouveau driver 1.0.11, drm 0.9.0 and latest modesetting driver. Result is the same with packaged version. How reproducible: Always Steps to Reproduce: 1. Boot latest kernel (3.16.7) on affected HW Actual results: X11 does not start Expected results: Get GDM prompts Additional info: The effected hardware in this case is: DMI: Apple Inc. MacBookPro4,1/Mac-F42C86C8, BIOS MBP41.88Z.00C1.B03.0802271651 02/27/08 Running a G84 (NV84) with VBIOS version reported as 60.84.49.03.00 Failes when kernel report: [drm] Initialized nouveau 1.1.2
Ok, after getting some help on #nouveau from bonbons and xexaxo, we notice that: /sys/class/drm/card0/device/boot_vga Value is 1 on working kernel, and 0 on non-working kernel. The following hack let me test that if this value is back to 1 on newer kernel, X starts: echo 1 > one sudo mount -o bind one /sys/class/drm/card0/device/boot_vga sudo systemctl restart gdm That probably also means something is broken for this laptop in the kernel.
Would it be possible to elaborate why nouveau instead of kernel ? The problem is clearly on the kernel side, and was stated so by the developers.
https://fedoraproject.org/wiki/KernelBugTriage#Video_Subsystem_bugs
Created attachment 960500 [details] dump of journalctl -b with 3.17.3-200.fc20.x86_64 kernel The bug still exists with 3.17.3-200.fc20.x86_64 kernel version. For the sake of completeness, I attach journal, Xorg, lspci and lsmod dumps with unsuccessful graphical boot.
Created attachment 960501 [details] Xorg log with 3.17.3-200.fc20.x86_64 kernel after running startx
Created attachment 960502 [details] lsmod
Created attachment 960503 [details] lspci
The problem still exists with kernel-3.17.4-200.fc20. The highest working kernel is 3.16.4-200.fc20.x86_64.
Same story with 3.17.6-200.fc20 kernel.
I've just tested the new Fedora 21, tried to boot from live USB, no success there - seems to be the same story. I'll open the bug for F21.
I opened the bug report for Fedora 21 live media. System boots successfully into basic graphical mode, and it's possible to boot into normal mode using above-mentioned hack: https://bugzilla.redhat.com/show_bug.cgi?id=1176253
I've just tested the 3.17.8-200.fc20 kernel, same story. Note: I marked F21 bug linked above as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1172807 which has been reported earlier and gives details on a specific git commit causing the trouble.
No success with 3.18.5-101.fc20.x86_64. The trick #/bin/bash echo 1 > one sudo mount -o bind one /sys/class/drm/card0/device/boot_vga sudo systemctl restart kdm.service works fine and X boots.
Nicolas, in your IRC discussion on #nouveau a git commit 7babfd7f066dae02c63d9ccac886419ccfb80cfd was mentioned as a possible culprit and exactly same commit is listed in https://bugzilla.redhat.com/show_bug.cgi?id=1172807, see https://bugzilla.redhat.com/show_bug.cgi?id=1172807#c6. It seems the patch https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=7babfd7f066dae02c63d9ccac886419ccfb80cfd is the culprit. Perhaps it should be reported on the very kernel bugzilla. Did you have any other success with #nouveau people?
Perhaps, last time I spoke with them they didn't trust Fedora's kernel and wanted me to test it with stable vala kernel. I ran out of time, and could not spend the time verifying we get the same result.
This bug seems to affect Debian Wheezy and Manjaro Linux distros as well (which is to be expected if we assume the kernel commit is to blame): https://forum.manjaro.org/index.php?topic=21424.0
Still present on F22. Gnome Wayland works though (in the sense it run, even though some features are missing ;-P).
Thanks for checking. Unfortunately it will take some time till Wayland replaces X. For X, I was going to git bisect the kernel to verify if 7babfd7f066dae02c63d9ccac886419ccfb80cfd is indeed to blame - too afraid to do that now, my MacBook is my only machine at the moment.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.