Created attachment 594546 [details]
dmesg got using serial console
Description of problem:
kernel freeze while booting on T520 with nVidia Quadro NVS 4200M
BIOS is configured to use nVidia only
last kernel message:
[drm] Initialized drm 1.1.0 20060810
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set GPU to discrete in BIOS Setup
2. Boot Fedora 17
kernel freeze without error or oops
last message on screen (also on serial console): [drm] Initialized drm 1.1.0 20060810
system boots to GDM
Also reproducible on RHEL 6.3 with kernel-2.6.32-269.el6
*** Bug 830748 has been marked as a duplicate of this bug. ***
I have the same problem. Lenovo Thinkpad T520. When I configure BIOS with discreet card only the system doesn't boot. Can only reach grub, uncompressing initrd and then it dies. Even Ctrl + Alt + Delete doesn't work.
$ rpm -q kernel | sort -nr
$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: nVidia Corporation Device 1057 (rev a1)
$ rpm -q xorg-x11-drv-nouveau
Hmm, I wonder if this is the same issue I see on W530 if I boot in discrete graphics mode..
Can you boot with "rdblacklist=i915" and see if you get further?
(In reply to comment #3)
> Hmm, I wonder if this is the same issue I see on W530 if I boot in discrete
> graphics mode..
> Can you boot with "rdblacklist=i915" and see if you get further?
Tried with kernel-3.5.0-2.fc17.x86_64, same result: [drm] Initialized drm 1.1.0 20060810
I relate. Thinkpad W530. Booting in Discreet mode (Nvidia K2000m only), crash. Reboot and then in BIOS Optimus has been enabled and then booting but back to Intel Graphics.
(In reply to comment #5)
> I relate. Thinkpad W530. Booting in Discreet mode (Nvidia K2000m only),
> crash. Reboot and then in BIOS Optimus has been enabled and then booting but
> back to Intel Graphics.
See comment #3.
*** Bug 848790 has been marked as a duplicate of this bug. ***
Booting in Discreet mode with rdblacklist=i915 doesn't work. Hangs after uncompressing initrd.
# uname -a
Linux dex 3.5.2-1.fc17.x86_64 #1 SMP Wed Aug 15 16:09:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
I have ran into this bug on my ThinkPad W520.
With kernel versions 3.4.6, 3.5.1 and 3.5.2, the same results: freeze after "Initialized DRM".
rdblacklist=i915 does not make any difference.
Until a while back this did work, but I can't tell when it broke since I normally only use my Intel built-in GPU, and now tried to change since I wanted to play a game.
However, I do know for sure it worked fine around early June this year.
I reproduced this bug on T520 with Fedora 18 Alpha GOLD Live KDE. BIOS setup was in discrete (nVidia) graphics mode. (Not Intel or Optimus modes)
On first boot Plymouth had graphical distortions, but after hitting ESC, VT showed without any flaws (repeated multiple times with same results for Plymouth and VT). X successfully started without any flaws, but after KDE loaded, whole T520 just freezed without graphical gliches.
On second boot, kernel freezed before Plymouth was showed.
Re-testing T520 with nVidia Quadro NVS 4200M on Nouveau test day.
It boots with llvmpipe OpenGL renderer in default.
Next time, I booted with "nouveau.noaccel=0 drm.debug=14".
Boot to X is successful (no Plymouth glitches), I can login to Gnome Shell. But after while when using Gnome Shell I get glitch and X crashes with:
[drm] nouveau 0000:01:00.0: Failed to idle channel 1.
[drm] nouveau 0000:01:00.0: PFIFO: unknown status 0x40000000
[drm] nouveau 0000:01:00.0: GPU lockup - switching to software fbcon
[drm] nouveau 0000:01:00.0: Failed to idle channel 1.
Sometimes laptop just slowly freezes to death (tested via caps lock).
I believe this is the same bug as #752723, as for me it (again) was fixed by disabling the Intel VT-d feature from the EFI setup.
In that case, this would be a regression, as it had been fixed with that bug, and it did work in the beginning of June for me.
I think 'rdblacklist=i915' would only stop dracut loading the module, it wouldn't stop module-init-tools. i think you'd also have to have a /etc/modprobe.conf.d/blah.conf file to blacklist i915 to really stop it loading, wouldn't you?
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . We agreed to delay the decision on this bug for more data. In particular we're interested in whether the workaround described in comment #12 - disabling VT-d - works for all reporters. If it does, we'd likely consider that sufficient for Beta. Could all reporters try disabling VT-d and see if it works around the issue for them?
I can confirm that disabling VT-d workarounds the issue. But this is regression from June. Ben, do you know which commit introduced this regression?
Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . Rejected as blocker and NTH. Bugs that only affect certain hardware are considered on the basis of the severity of the issue, the amount of hardware affected, and the ease of working around the issue: this bug is obviously severe, but only a moderate range of hardware is affected, and there is a straightforward and effective workaround (disable VT-d). So we don't consider it a critical issue for Beta. This means that if you do want to have it fixed for Beta, Ben, the fix needs to be in stable by Beta freeze, currently scheduled for 2012-10-09. Thanks!
After 752613 showed up in the blocker meeting today, it was clear this is a dupe of that.
*** This bug has been marked as a duplicate of bug 752613 ***
Moving CommonBugs to bug 752613.