Bug 752613 - Nvidia 100M on Lenovo W520 Wont boot if using Discrete Graphics
Summary: Nvidia 100M on Lenovo W520 Wont boot if using Discrete Graphics
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH RejectedBlocker https://f...
: 827107 835648 (view as bug list)
Depends On:
Blocks: F18Beta-accepted, F18BetaFreezeExcept
TreeView+ depends on / blocked
Reported: 2011-11-09 23:58 UTC by Vincent passaro
Modified: 2024-02-20 23:25 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Linux Kernel 43054 0 None None None Never

Description Vincent passaro 2011-11-09 23:58:57 UTC
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):


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.
Actual results:

Fedora should boot properly.

Expected results: 

Fedora does not boot properly. 

Additional info:

Comment 1 Josh Adams 2011-11-19 17:30:21 UTC
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.

Comment 2 Andrew Gunnerson 2011-11-23 03:58:28 UTC
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.

Comment 3 Andrew Gunnerson 2011-12-06 23:33:30 UTC
Booting with "noapic" works around this problem with no functionality lost (so far).

Comment 4 Vincent passaro 2011-12-08 20:01:03 UTC
Doesn't work. 

Can't enter password for LUKs when booting with noapic.

Comment 5 Andrew Gunnerson 2011-12-09 00:42:29 UTC
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.

Comment 6 Vincent passaro 2011-12-09 01:45:57 UTC
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.

Comment 7 Andrew Gunnerson 2011-12-09 05:34:08 UTC
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:


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...

Comment 8 Ben Skeggs 2011-12-10 00:58:08 UTC
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.

Comment 9 Andrew Gunnerson 2011-12-10 03:00:49 UTC
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?

Comment 10 Luigi Pardey 2011-12-31 15:33:22 UTC

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

Comment 11 Andrew Gunnerson 2012-01-15 21:41:08 UTC
@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:


Comment 12 Andrew Gunnerson 2012-01-15 22:42:32 UTC
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):


And without noapic (ie. default boot):


Comment 13 patrick korsnick 2012-02-23 20:37:05 UTC
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

Comment 14 GordonL 2012-03-29 06:53:57 UTC
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:


Comment 15 patrick korsnick 2012-04-01 21:35:11 UTC
(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.

Comment 16 perutka.ondrej 2012-04-20 22:01:25 UTC
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.

Comment 17 perutka.ondrej 2012-07-09 11:48:47 UTC
The bug also affects the Fedora 17 x86_64.

Comment 18 perutka.ondrej 2012-09-22 23:17:26 UTC
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.

Comment 19 Patrick Uiterwijk 2012-09-26 14:13:37 UTC
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.

Comment 20 Adam Williamson 2012-10-04 17:08:01 UTC
*** Bug 835648 has been marked as a duplicate of this bug. ***

Comment 21 Adam Williamson 2012-10-04 17:09:54 UTC
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.

Comment 22 Kamil Páral 2012-11-26 14:17:31 UTC
Transferring CommonBugs here from bug 835648.

Comment 23 Fedora End Of Life 2013-01-16 12:27:49 UTC
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: 

Comment 24 Martin 2013-01-16 16:00:40 UTC
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?

Comment 25 jro 2013-01-23 19:45:44 UTC
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:



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...

Comment 26 Matthias Hensler 2013-01-23 20:01:33 UTC
Additional info: T420 boots with discrete graphics and enabled Intel vt-d, as long as "pci=noacpi" is present on the kernel commandline.

Comment 27 Ben Skeggs 2013-01-24 03:36:40 UTC
(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


Comment 28 Martin 2013-01-24 13:36:23 UTC
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

Comment 29 Fedora End Of Life 2013-04-03 15:37:34 UTC
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:

Comment 30 Adam Williamson 2013-04-20 00:16:28 UTC
Looks like ben really wanted this to be against rawhide, not 19.

Comment 31 Adam Williamson 2013-05-15 14:37:23 UTC
*** Bug 827107 has been marked as a duplicate of this bug. ***

Comment 32 Adam Williamson 2013-12-20 03:26:32 UTC
Is this bug still live? I don't see any activity here or upstream.

Comment 33 Illya 2014-01-29 12:39:33 UTC
This bug is still actual. I have the same issue with F20 x86_64 on ThinkPad T420 with  nvidia graphic.

Workaround with noapic helps.

Comment 34 patrick korsnick 2014-02-25 03:55:25 UTC
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.

Comment 35 Markus Duft 2014-06-18 05:18:33 UTC
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...

Comment 36 ILMostro 2014-10-20 17:11:45 UTC
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?

Comment 37 Tiago Mello 2020-01-25 11:29:14 UTC
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

Comment 38 HaresGour 2024-02-20 06:18:27 UTC Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.