Bug 1354256
| Summary: | Unable to install Fedora 24 on MSI GS60 6QE, likely due to hybrid graphics | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mario J Borgnia <mborgnia> |
| Component: | 0install | Assignee: | Michel Lind <michel> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | a.nolting, hdegoede, mborgnia, michel, peter |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-08 15:30:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mario J Borgnia
2016-07-11 05:08:51 UTC
Hi, What happens if you start the livecd in runlevel 3? (just add 3 at the end of the kernel commandline) If that works can you collect a "dmesg" output in runlevel 3 please? Thanks & Regards, Hans Hi Hans, I figured the following. The use of nomodeset in basic graphic mode in this hybrid system does not work well with Fedora. Instead need to use the less restrictive: nouveau.modeset=0 There is also a problem with intel cstates that may require: intel_idle.scstate_max=7 As you may guess, I am trying to get the NVIDIA GPU to work with this system. I am most familiar with OpenSUSE, as I have used it for all my work for the past 10 years or so. While trying to troubleshoot this installation on my MSI GS60 6QE I read your post at http://hansdegoede.livejournal.com/. I decided to give Fedora a try. With OpenSUSE I was able to boot and get a system that seems to be working, I cannot install get the NVIDIA driver to work. I decided to give Fedora a try, and bumped into this bug. I guess that it is resolved for now. Please let me know if you need any additional information. Thanks! Mario (In reply to Hans de Goede from comment #1) > Hi, > > What happens if you start the livecd in runlevel 3? (just add 3 at the end > of the kernel commandline) > > If that works can you collect a "dmesg" output in runlevel 3 please? > > Thanks & Regards, > > Hans Hi, I would not call needing to add "nouveau.modeset=0 intel_idle.scstate_max=7" resolved, it may be a workaround, but we really want things to just work, without the user needing to add such things. Can you perhaps make some room on your disk to do a proper fedora install, update to kernel (to the 3.6.x one from updates-testing) and then see if things are better ? If not can you try blacklisting the nouveau driver and then after boot ssh-ing into the machine and then insmod the driver and see if you can get dmesg output after the insmod? Regards, Hans Hi, I agree with you, and I am willing to try and find the causes for this problem. I can wipe the current OpenSUSE installation and install Fedora. Once I have it running update to kernel 4.6.X (I guess you meant that). I will inform once I am there. Best Mario There is a typo in my post, it should be # nouveau.modeset=0 # intel_idle.cstate_max=7 Hi Hans, I am running kernel 4.6.3-300.fc24.x86_64. How are things supposed to be better? How do I go about installing support for switchable graphics? This is what I have done so far: sudo vi /etc/default/grub # add nouveau.modeset=0 intel_idle.cstate_max=7 to the end of GRUB_CMDLINE_LINUX grub-mkconfig -o /boot/efi/EFI/fedora/grub.cfg reboot # added updates-testing repo yum --enablerepo=updates-testing check-update yum update Thanks! Mario Removing nouveau.modeset=0 leads to a system lockup. Adding rd.driver.blacklist=nouveau instead of the variable above does not help. Added both and nouveau was loaded after booting... Also did: echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf nouveau is still loaded rmmod nouveau did not prevent X from starting How do I really blacklist nouveau in Fedora 24? Installed bumblebee as per instructions in: https://fedoraproject.org/wiki/Bumblebee dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora24/noarch/bumblebee-release-1.2-1.noarch.rpm dnf -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/fedora24/noarch/bumblebee-nonfree-release-1.2-1.noarch.rpm dnf install bumblebee-nvidia bbswitch-dkms VirtualGL.x86_64 VirtualGL.i686 primus.x86_64 primus.i686 kernel-devel reboot optirun -b none nvidia-settings -c :8 [ 193.017473] [ERROR]The Bumblebee daemon has not been started yet or the socket path /var/run/bumblebee.socket was incorrect. [ 193.017511] [ERROR]Could not connect to bumblebee daemon - is it running? [ 639.041904] bbswitch: module verification failed: signature and/or required key missing - tainting kernel [ 639.042555] bbswitch: version 0.8 [ 639.042564] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0 [ 639.042571] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP [ 639.042589] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95) [ 639.042736] bbswitch: detected an Optimus _DSM function [ 639.042752] pci 0000:01:00.0: enabling device (0006 -> 0007) [ 639.042851] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on Hi Mario, I was hoping that with 4.6.x you would no longer need the nouveau.modeset=0, as for the blacklisting, try regenerating your initrd using "dracut -f", after creating the blacklist.conf . As for bumblebee, we do not support bumblebee, but I would like to see this laptop just work on the igpu without needing the nouveau.modeset=0 Regards, Hans Hi Hans, Thanks for your help! I guess I will have to remove bumblebee in order to try just blacklisting nouveau. Now that nvidia is installed, and nouveau is not loaded, the flag nouveau.modeset=0 can be removed. The bumblebee daemon was not working because I had enabled multi-user. When I enable graphical, the system will lock up if I log in. Still working on that. Is the idea that the laptop will work with the nvidia drivers as well or just the iGPU? Best regards Mario Hi Hans, I'm having exactly the same issues but with a Lenovo Y700. I followed the wiki instructions for bumblebee and it didn't work as described. I figured out that in the repo http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree-unmanaged/fedora24/noarch/ does not contain the file bumblebee-nonfree-unmanaged-release-1.2-1.noarch.rpm. There are only bumblebee-nvidia-2.0-(n).fc24.noarch.rpm packages found. Due to this issue I decided to use the managed variant. After installing bumble-nvidia (managed), primus etc. and calling bumblebee-nvidia the driver compilation ends with a "OK". But when the laptop reboots, the kernel module is not loaded. Alex You are likely affected by https://bugzilla.kernel.org/show_bug.cgi?id=156341 Your model (MSI GS60) and others will lock up as soon as the NVIDIA GPU is powered on again (via nouveau or bbswitch). A workaround is listed here: https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-234494238 Mario, can you give the acpi_osi workaround a try and report back the results? It should work with nouveau. @Alexander Is your model the same as https://bugs.launchpad.net/ideapad-laptop/+bug/1528299?LENOVO CDCN25WW, BIOS 1.25 (09/04/2015). More friendly name: Lenovo Ideapad Y700-15ISK. Based on the acpidump ("If(OSYS == 0x07D9)" in the PGON method of ssdt1.dsl), can you try adding this workaround to your kernel command line and report results: acpi_osi=! acpi_osi="!Windows 2009" Test: 1. boot with workaround 2. execute lspci. 3. wait for at least 5 seconds, execute lspci again 4. Verify that you see something like (from step 3): "nouveau 0000:01:00.0: DRM: resuming kernel object tree..." ... "nouveau 0000:01:00.0: DRM: resuming console..." Five seconds later it should show: "nouveau 0000:01:00.0: DRM: suspending console..." Then step 4 should the same "resuming" message. This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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. |