Description of problem: Trying to boot Fedora 16 with Discrete Graphics using Nivida 1000M hangs boot process and never starts. Version-Release number of selected component (if applicable): xorg-x11-drv-intel-2.16.0-2.fc16.x86_64 xorg-x11-drv-s3virge-1.10.4-9.fc16.x86_64 xorg-x11-drv-penmount-1.5.0-3.fc16.x86_64 xorg-x11-drv-tdfx-1.4.3-9.fc16.x86_64 xorg-x11-resutils-7.5-2.fc15.x86_64 xorg-x11-drv-wacom-0.11.99-4.20110527.fc16.x86_64 xorg-x11-drv-mga-1.4.13-8.fc16.x86_64 xorg-x11-server-Xephyr-1.11.1-1.fc16.x86_64 xorg-x11-font-utils-7.5-6.fc15.x86_64 xorg-x11-drv-rendition-4.2.4-7.fc16.x86_64 xorg-x11-drv-voodoo-1.2.4-7.fc16.x86_64 xorg-x11-xinit-1.3.1-1.fc16.x86_64 xorg-x11-drv-savage-2.3.2-5.fc16.x86_64 xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16.x86_64 xorg-x11-drv-void-1.4.0-2.fc16.x86_64 xorg-x11-drv-acecad-1.5.0-2.fc16.x86_64 xorg-x11-drv-v4l-0.2.0-14.fc16.x86_64 xorg-x11-drv-elographics-1.3.0-2.fc16.x86_64 xorg-x11-drv-dummy-0.3.4-7.fc16.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-4.fc15.noarch xorg-x11-drv-mouse-1.7.1-2.fc16.x86_64 xorg-x11-drv-vmmouse-12.7.0-2.fc16.x86_64 xorg-x11-drv-cirrus-1.3.2-10.fc16.x86_64 xorg-x11-drv-glint-1.2.5-2.fc16.x86_64 xorg-x11-drv-sis-0.10.3-7.fc16.x86_64 xorg-x11-apps-7.6-2.fc15.x86_64 xorg-x11-drv-nv-2.1.18-8.fc16.x86_64 xorg-x11-drv-i740-1.3.2-9.fc16.x86_64 xorg-x11-drv-mach64-6.9.0-2.fc16.x86_64 xorg-x11-drv-sisusb-0.9.4-7.fc16.x86_64 xorg-x11-drv-apm-1.2.3-8.fc16.x86_64 xorg-x11-drv-vmware-11.0.3-6.fc16.x86_64 xorg-x11-utils-7.5-3.fc16.x86_64 xorg-x11-server-common-1.11.1-1.fc16.x86_64 xorg-x11-drv-evdev-2.6.99-3.20110601giteaf202531.fc16.x86_64 xorg-x11-drv-ati-6.14.2-2.20110727git8c9266ed2.fc16.x86_64 xorg-x11-drv-mutouch-1.3.0-2.fc16.x86_64 xorg-x11-drv-ast-0.91.10-7.fc16.x86_64 xorg-x11-drv-qxl-0.0.21-8.fc16.x86_64 xorg-x11-drv-vesa-2.3.0-9.fc16.x86_64 xorg-x11-drv-synaptics-1.5.0-2.fc16.x86_64 xorg-x11-server-Xorg-1.11.1-1.fc16.x86_64 xorg-x11-drv-r128-6.8.1-11.fc16.x86_64 xorg-x11-drv-siliconmotion-1.7.5-2.fc16.x86_64 xorg-x11-drv-fbdev-0.4.2-2.fc16.x86_64 xorg-x11-xkb-utils-7.5-5.fc16.x86_64 xorg-x11-drv-keyboard-1.6.0-2.fc16.x86_64 xorg-x11-drv-trident-1.3.4-7.fc16.x86_64 xorg-x11-drv-fpit-1.4.0-2.fc16.x86_64 xorg-x11-xauth-1.0.6-1.fc16.x86_64 xorg-x11-drivers-7.4-2.fc15.x86_64 xorg-x11-drv-openchrome-0.2.904-16.fc16.x86_64 xorg-x11-drv-hyperpen-1.4.1-2.fc16.x86_64 xorg-x11-drv-aiptek-1.4.1-2.fc16.x86_64 xorg-x11-drv-i128-1.3.4-9.fc16.x86_64 xorg-x11-server-utils-7.5-7.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora (Has to be in Integrated Graphics Mode ...aka Intel onboard Graphics chipset) 2. Fedora boot process hangs during startup right after grub loading ramdisk. 3. Actual results: Fedora should boot properly. Expected results: Fedora does not boot properly. Additional info:
I am having similar issues. However, I found a tip at http://www.nvnews.net/vbulletin/showthread.php?t=163153 and it seems that if you disable hardware virtualization in the BIOS it works. I have confirmed this on my machine. While I am happy that it works, I would be even more happy if it could work and I could still have hardware virtualization. Also, as a side note, discrete mode with virtualization enabled works fine in Arch Linux.
I have the same problem, although my w520 has an nVidia Quadro 2000M. Disabling hardware virtualization also allows the system to boot, but then I lose one of the greatest features of Fedora. I run Arch Linux on another partition and it works fine with both nouveau and nvidia drivers.
Booting with "noapic" works around this problem with no functionality lost (so far).
Doesn't work. Can't enter password for LUKs when booting with noapic.
Hmmm... I'm using LUKS also, and it works too. Try adding: nouveau.modeset=0 rd.driver.blacklist=nouveau and remove quiet rhgb from the kernel command line. That's what I boot with.
I tried getting the Nvidia Card to function properly for hours today with no success. Which driver are you using? Akmod? That's what I tried but the screen brightness was extremely low and when I tried to adjust with the fn-home key it would lock the system up and force me to reboot.
Right. I upgraded my system, added the RPMFusion repos, and installed the akmod nvidia drivers. The brightness control will not work, by default, with the nvidia drivers. It's a problem that only nVidia can solve (if they were willing to). You can however use nvidiabl kernel module to adjust the brightness. The source code is here: https://github.com/guillaumezin/nvidiabl You'll need to add your w520 laptop model to the source code, like I did here: https://github.com/chenxiaolong/nvidiabl/commit/03724043dbaf3e5d538c6711255a9373f5137247 You'll also need to boot with the following options for nvidiabl to work: video.disable=1 thinkpad_acpi.brightness_enable=0 Then, there's another bug where you'll have to reload thinkpad_acpi for brightness control to work under GNOME: rmmod thinkpad_acpi modprobe thinkpad_acpi brightness_enable=0 And another bug where brightness control doesn't work at all under KDE. Gah...chain of bugs with nVidia...
It'd be really great if someone could post the kernel log from a failed attempt at booting with nouveau. Though "noapic" being required generally points at some worse problem being present too.
Hi Ben, Could you explain how I can do that? If I remove the 'rhgb' and 'quiet' from the kernel command line, it doesn't really show anything useful (at least to me). Is there any debug kernel parameter I can pass to see more info?
Chen, The file in /var/log/message, and the output of the command "dmesg" from the Terminal will do if you manage to get to a tty. Otherwise, read here http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems
@Luigi: I cannot get to a TTY without using noapic. Once it hangs, the fans runs at full speed and the system no longer responds (if I continuously press caps lock starting from GRUB, it will work until the hang). Unfortunately, I don't quite understand the link you posted :(. I don't know if this is going to be useful, but here's the entire contents of my /var/log when booting with 'noapic loglevel=7' and with the nouveau driver: http://ompldr.org/vY2E4Mw/var_log_noapic_loglevel7.tar.xz
Here a video of booting with nouveau and 'noapic loglevel=7' (the text should be readable when played at 1920x1080, but my camera too slow to capture all the text clearly): http://ompldr.org/vY2E5Yg/00429.ogv And without noapic (ie. default boot): http://ompldr.org/vY2E4bg/00428.ogv
i see this same problem on my w520. it is common to all linux installs i have tried on this machine- debian, ubuntu, fedora, mint, opensuse. simply adding 'noapic' to the kernel parameters solves the problem for every livecd and install i have tried on this machine. only fedora though seems to preserve the kernel parms used when installing from a livecd. on the other linuxes i have to go and edit the grub.cfg or whatever and re-add the 'noapic' after installing
This has been fixed at least in my case by upgrading to the kernel-3.3.0-4.fc16.x86_64 package, as described in bug #752723: https://bugzilla.redhat.com/show_bug.cgi?id=752723
(In reply to comment #14) > This has been fixed at least in my case by upgrading to the > kernel-3.3.0-4.fc16.x86_64 package, as described in bug #752723: > > https://bugzilla.redhat.com/show_bug.cgi?id=752723 Still broken for me. Running nouveau driver and same kernel. Must have 'noapic' kernel option for machine to boot.
I've got the same problem using the kernel-3.3.2-1.fc16.x86_64 (boot hangs without the noapic option). The brightness control works fine, if I pass the noapic option. This is really annoying bug because the VGA output does not work with the integrated graphics so I have to use the discrete graphics, if I need a secondary display.
The bug also affects the Fedora 17 x86_64.
I don't know whether it's useful but in my case it always stops booting after showing following lines: [2.735927] udev[148]: starting version 182 [2.792905] [drm] Initialized drm 1.1.0 20060810 After showing these lines the fan speed is changed to its maximum level.
This bug has been reintroduced somewhere between beginning June and mid/end August I believe, as it had been working for me in the beginning of June. I believe this is the same error as bug #835648 and bug #752723.
*** Bug 835648 has been marked as a duplicate of this bug. ***
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . We noted this is the same bug as 835648, discussed yesterday. However, the discussion resulted in a reappraisal of the NTH status of this bug. It's still rejected as a blocker for now (see post on 835648), but now accepted as NTH due to the severity of the issue. Right now this bug is known to affect F16, F17 and F18, I believe.
Transferring CommonBugs here from bug 835648.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Moving this bug to Rawhide version as this bug occurs in F16 to F18 releases and it's very likely to hit also F19. Ben, do you have any progress with solving this bug?
T420 with discrete graphics (nvs4200), hangs on boot if vt-d enabled (also prevents you from booting f18 dvd). Don't recall experiencing this at all with f17: kernel-devel-3.7.2-204.fc18.x86_64 kernel-headers-3.7.2-204.fc18.x86_64 kernel-3.7.2-204.fc18.x86_64 xorg-x11-drv-nvidia-304.64-3.fc18.x86_64 xorg-x11-drv-nvidia-libs-304.64-3.fc18.x86_64 nvidia-settings-1.0-26.fc18.x86_64 kmod-nvidia-3.7.2-204.fc18.x86_64-304.64-2.fc18.x86_64 nvidia-xconfig-1.0-25.fc18.x86_64 akmod-nvidia-304.64-2.fc18.x86_64 systemd-libs-197-1.fc18.1.x86_64 systemd-197-1.fc18.1.x86_64 systemd-sysv-197-1.fc18.1.x86_64 dracut-024-18.git20130102.fc18.x86_64 Last Starting Setup Virtual Console... Starting dracut pre-udev hook... [OK] Started Setup Virtual Console. [OK] Started dracut pre-udev hook. Starting udev Kernel Device Manager... [OK] Reached target System Initialization. [OK] Started udev Kernel Device Manager. Starting dracut pre-trigger hook... [OK] Started dracut pre-trigger hook. Starting udev Coldplug all Devices...
Additional info: T420 boots with discrete graphics and enabled Intel vt-d, as long as "pci=noacpi" is present on the kernel commandline.
(In reply to comment #24) > Moving this bug to Rawhide version as this bug occurs in F16 to F18 releases > and it's very likely to hit also F19. > > Ben, do you have any progress with solving this bug? It's not a nouveau bug, and happens regardless of whether nouveau loads or not. Upstream kernel bugzilla entry is: https://bugzilla.kernel.org/show_bug.cgi?id=43054 Reassigning...
Upstream proposed fix: disable x2apic on machines with problematic nVidia cards This leads to some performance regression in virtualization: http://fedoraproject.org/wiki/Features/Virtx2apic I think this should be documented to let user choose between: Intel only + working x2apic and VT-d, nVidia + disabled VT-d, but working x2apic or nVidia + disabled x2apic, but enabled VT-d
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Looks like ben really wanted this to be against rawhide, not 19.
*** Bug 827107 has been marked as a duplicate of this bug. ***
Is this bug still live? I don't see any activity here or upstream.
This bug is still actual. I have the same issue with F20 x86_64 on ThinkPad T420 with nvidia graphic. Workaround with noapic helps.
I can confirm it still exists on my W520 with F20 x86_64- you need noapic to boot or it hangs and the fan goes to max speed.
I can also confirm that this happens for my T520 with F20 x86_64. I keep VT-d disabled for now, but it's really annoying...
According to the upstream bug reports, this is an issue with the Lenovo BIOS on certain platforms. I'm not sure if/when this will be fixed, but it's up to Lenovo, AFAIK. Therefore, should the status of this bug report be changed to reflect that?
In case anyone is looking to workaround this in a Thinkpad T420, the following worked for me: https://bugzilla.redhat.com/show_bug.cgi?id=913326#c10
This comment was flagged a spam, view the edit history to see the original text if required.