Bug 1046262

Summary:

System hangs when running gnome-control-center while having modesetting on

Product:

[Fedora] Fedora

Reporter:

Lukas Bezdicka <social>

Component:

xorg-x11-drv-nouveau

Assignee:

Ben Skeggs <bskeggs>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

CC:

airlied, ajax, bobpoljakov, bskeggs, dove.young, emanuele.parmigiani, freysteinn, gansalmon, gc, itamar, jonathan, kernel-maint, madhu.chinakonda

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2014-04-25 14:06:49 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:

Attachments:

Description	Flags
netconsole output after hang	none

Description Lukas Bezdicka 2013-12-24 09:28:38 UTC

Description of problem:
After updating from kernel-3.11.10-301.fc20.x86_64 to kernel-3.12.5-302.fc20.x86_64 system started to hang on many occasions while best reproducer is to just run gnome-control-center. The hang is complete lockup as even sysrq does not work to get anything out of system.

Version-Release number of selected component (if applicable):
3.12.5-302.fc20.x86_64

How reproducible:
always

Steps to Reproduce:
1. Get lenovo T420s as it seems to be HW dependant and install F20 there.
2. Run gnome-control-center and it locks up.
3. Boot up with nomodeset and system works fine except ugly graphics.

Actual results:
System hang I'd appreciate any hints to how to get reasonable debug out of it.

Expected results:
No hangs.

Additional info:
Works fine with rawhide kernel (kernel-3.13.0-0.rc4.git5.1.fc21.x86_64)

Comment 1 bobpoljakov 2014-01-03 15:53:50 UTC

Same problem on Lenovo ThinkPad T520.
Same problem with kernel.x86_64 0:3.12.6-300.fc20.

Comment 2 Josh Boyer 2014-01-06 14:45:12 UTC

What graphics card is involved here?

Comment 3 Lukas Bezdicka 2014-01-06 14:56:38 UTC

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [NVS 4200M] (rev a1)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
05:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 07)
0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)



intel and nvidia cards are both on

Comment 4 Josh Boyer 2014-01-06 16:32:18 UTC

Thanks.  Based on some other reports that look similar, let's go with nouveau.  If you can get a backtrace somehow, that would probably be rather helpful.  Perhaps installing kernel-debug would result in that.

Comment 5 Lukas Bezdicka 2014-01-07 11:58:53 UTC

Well I played with it today, network card stays on and sshd does respond but fails to open session. I also can't see any complaining from kernel in dmesg/messages after checking journalct -r and the most funny part kernel-debug fixes the issue. I'm unable to reproduce issue while having kernel-debug installed.

Comment 6 Lukas Bezdicka 2014-01-07 12:23:55 UTC

xrandr --prop does reproduce the issue.

Comment 7 Lukas Bezdicka 2014-01-07 12:24:38 UTC

Created attachment 846634 [details]
netconsole output after hang

Comment 8 Josh Boyer 2014-01-07 12:52:05 UTC

*** Bug 1049294 has been marked as a duplicate of this bug. ***

Comment 9 Ben Skeggs 2014-01-07 22:05:09 UTC

I suppose this goes away with "nouveau.runpm=0" in your kernel boot options?

Comment 10 Minuz71 2014-01-08 11:09:40 UTC

I have just tried with nouveau.runpm=0 and system hangs .

Comment 11 Ben Skeggs 2014-01-09 06:31:14 UTC

(In reply to Minuz71 from comment #10)
> I have just tried with nouveau.runpm=0 and system hangs .

That's, er, strange, considering the previous backtraces....  Can you get me new logs?

Comment 12 Minuz71 2014-01-09 08:54:16 UTC

I don't have log or backtrace. Gnome freeze at all and also logging stop.
I have opened this ticket https://bugzilla.redhat.com/show_bug.cgi?id=1049294 marked as duplicate of current. Never sent backtraces before.

I have just modified in the grub.cfg following line:
linux	/vmlinuz-3.12.6-300.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.luks.uuid=luks-432afd15-3606-4b99-a28d-a31285d41172 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=fedora/root nouveau.runpm=0 rhgb quiet
Maybe it's the wrong way.

Now I'm working with kernel 3.13.0-0.rc7.git0.1.fc21.x86_64 and everything is going well.
With nomodeset in kernel 3.12.6-300.fc20.x86_64 is working but heavy cpu load.
Thanks
Emanuele

Comment 13 Minuz71 2014-01-10 12:09:55 UTC

I made a mistake. Written nuveau in grub.cfg instead of nouveau.....
Sorry for the mistake... checked and tested with nouveau.runpm=0 and everything work fine with kernel 3.12.6-300.fc20.x86_64.
Emanuele

Comment 14 dove.young 2014-01-30 09:13:19 UTC

Same problem through 3.12.6 to 3.12.8 on Thinkpad T420. I am now stick on 3.11.10

Comment 15 Ben Skeggs 2014-01-30 22:09:29 UTC

the 3.12.7 kernel should resolve this problem

Comment 16 Minuz71 2014-01-31 11:11:50 UTC

Just tried one hour ago on thinkpad 430 with kernel 3.12.8 without nouveau.runpm=0 on the grub2.cfg and system hangs like before.

Comment 17 Giuseppe Castagna 2014-02-09 10:19:16 UTC

I confirm this problem on a Thinkpad T420s. The problem is still present both in kernel-3.12.9-301.fc20.x86_64 and in kernel-3.12.10-300.fc20.x86_64 from updates-testing.
  In both cases adding nouveau.runpm=0 in grub2.cfg fixes it. Just, in my case the problem it is straightforward to reproduce the problem: it just suffices to launch gnome-control-center and the system immediately freezes

Comment 18 Giuseppe Castagna 2014-02-13 23:06:28 UTC

I have compiled kernel 3.13.2 from koji and installed it

http://kojipkgs.fedoraproject.org//packages/kernel/3.13.2/200.fc20/src/kernel-3.13.2-200.fc20.src.rpm

The problem seems to have been fixed there.

Comment 19 Lukas Bezdicka 2014-04-25 14:06:49 UTC

I consider this fixed, thanks.