|Summary:||kernel freeze after [drm] Initialized drm 1.1.0 20060810 on T520 with Quadro NVS 4200M|
|Product:||[Fedora] Fedora||Reporter:||Martin <mholec>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||airlied, ajax, awilliam, bskeggs, butenko.v.w, kparal, ndmiron, puiterwijk, robatino, rok.papez, tpelka, walicki|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-10-04 17:08:01 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Martin 2012-06-26 17:33:56 UTC
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): 3.4.3-1.fc17.x86_64 xorg-x11-drv-nouveau-0.0.16-35.20120306gitf5d1cd2.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. set GPU to discrete in BIOS Setup 2. Boot Fedora 17 Actual results: kernel freeze without error or oops last message on screen (also on serial console): [drm] Initialized drm 1.1.0 20060810 no artefacts Expected results: system boots to GDM Additional info: Also reproducible on RHEL 6.3 with kernel-2.6.32-269.el6
Comment 1 Martin 2012-06-26 17:49:59 UTC
*** Bug 830748 has been marked as a duplicate of this bug. ***
Comment 2 Rok Papez 2012-07-27 11:28:34 UTC
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 kernel-3.4.6-2.fc17.x86_64 kernel-3.4.5-2.fc17.x86_64 kernel-3.4.4-5.fc17.x86_64 $ 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 xorg-x11-drv-nouveau-0.0.16-37.20120306gitf5d1cd2.fc17.x86_64
Comment 3 Ben Skeggs 2012-08-03 02:12:00 UTC
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?
Comment 4 Martin 2012-08-08 09:24:03 UTC
(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 then freeze
Comment 5 Kikmoo 2012-08-18 20:31:58 UTC
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.
Comment 6 Ben Skeggs 2012-08-21 05:44:46 UTC
(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.
Comment 7 Ben Skeggs 2012-08-21 05:52:14 UTC
*** Bug 848790 has been marked as a duplicate of this bug. ***
Comment 8 Rok Papez 2012-08-21 08:09:29 UTC
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
Comment 9 Patrick Uiterwijk 2012-08-26 20:08:44 UTC
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.
Comment 10 Martin 2012-09-18 12:41:30 UTC
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.
Comment 11 Martin 2012-09-25 16:37:25 UTC
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).
Comment 12 Patrick Uiterwijk 2012-09-26 14:14:53 UTC
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.
Comment 13 Adam Williamson 2012-09-26 18:16:54 UTC
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?
Comment 14 Adam Williamson 2012-09-26 18:24:36 UTC
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?
Comment 15 Martin 2012-09-26 18:35:16 UTC
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?
Comment 16 Adam Williamson 2012-10-03 16:58:23 UTC
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!
Comment 17 Adam Williamson 2012-10-04 17:08:01 UTC
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 ***