[MacBookPro10,1] Plugging in displayport monitor causes kworker to take 100% CPU

[Brendan]

I'm seeing the same symptoms as described by: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1020221

I thought it would be worth reporting, because I just upgraded to the new Ubuntu 13.10, so it hasn't been resolved yet.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: xserver-xorg-video-nouveau 1:1.0.9-2ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
NonfreeKernelModules: wl
.tmp.unity.support.test.0:

ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
Date: Tue Nov 5 10:58:19 2013
DistUpgraded: 2013-11-03 13:42:12,641 DEBUG enabling apt cron job
DistroCodename: saucy
DistroVariant: ubuntu
DkmsStatus:
 bcmwl, 6.30.223.141+bdcom, 3.11.0-12-generic, x86_64: installed
 bcmwl, 6.30.223.141+bdcom, 3.8.0-32-generic, x86_64: installed
 virtualbox, 4.2.16, 3.11.0-12-generic, x86_64: installed
 virtualbox, 4.2.16, 3.8.0-32-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00f7]
 NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition] [10de:0fd5] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00f2]
InstallationDate: Installed on 2013-07-03 (125 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Apple Inc. MacBookPro10,1
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: \boot\vmlinuz-3.11.0-12-generic ro root=UUID=759bfd6b-68b3-4455-ba2a-c79286c0bcc1 initrd=boot\initrd.img-3.11.0-12-generic
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: Upgraded to saucy on 2013-11-03 (1 days ago)
dmi.bios.date: 12/21/2012
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP101.88Z.00EE.B03.1212211437
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-C3EC7CD22292981F
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro10,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-C3EC7CD22292981F
dmi.modalias: dmi:bvnAppleInc.:bvrMBP101.88Z.00EE.B03.1212211437:bd12/21/2012:svnAppleInc.:pnMacBookPro10,1:pvr1.0:rvnAppleInc.:rnMac-C3EC7CD22292981F:rvrMacBookPro10,1:cvnAppleInc.:ct10:cvrMac-C3EC7CD22292981F:
dmi.product.name: MacBookPro10,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.46-1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.14.3-3ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.904-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.9-2ubuntu1
xserver.bootTime: Tue Nov 5 10:24:31 2013
xserver.configfile: default
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.14.3-3ubuntu2
xserver.video_driver: nouveau
---
.tmp.unity.support.test.0:

ApportVersion: 2.13.2-0ubuntu2
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
DistUpgraded: Fresh install
DistroCodename: trusty
DistroRelease: Ubuntu 14.04
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00f7]
 NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition] [10de:0fd5] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Apple Inc. Device [106b:00f2]
InstallationDate: Installed on 2014-01-31 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64+mac (20140130)
MachineType: Apple Inc. MacBookPro10,1
Package: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu1
PackageArchitecture: amd64
ProcKernelCmdLine: \boot\vmlinuz-3.13.0-5-generic ro root=UUID=ac629b0b-84b0-46a1-9aae-ecb1ecfdc46c initrd=boot\initrd.img-3.13.0-5-generic
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Tags: trusty ubuntu reproducible compiz-0.9
Uname: Linux 3.13.0-5-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/21/2012
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP101.88Z.00EE.B03.1212211437
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-C3EC7CD22292981F
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro10,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-C3EC7CD22292981F
dmi.modalias: dmi:bvnAppleInc.:bvrMBP101.88Z.00EE.B03.1212211437:bd12/21/2012:svnAppleInc.:pnMacBookPro10,1:pvr1.0:rvnAppleInc.:rnMac-C3EC7CD22292981F:rvrMacBookPro10,1:cvnAppleInc.:ct10:cvrMac-C3EC7CD22292981F:
dmi.product.name: MacBookPro10,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.0.1-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.0.1-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.14.5-1ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.907-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu1
xserver.bootTime: Thu Jan 30 19:51:12 2014
xserver.configfile: default
xserver.errors:
 Failed to load module "nvidia" (module does not exist, 0)
 Failed to load module "nvidia" (module does not exist, 0)
 NOUVEAU(G0): [XvMC] Failed to initialize extension.
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.14.5-1ubuntu2

[penalvch (penalvch)]

Brendan, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-nouveau REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Bo Milvang-Jensen (milvang)]

I am experiencing a problem that sounds a lot like this: on a machine with Ubuntu 13.10 and an NVIDIA GT 640 graphics card, I had one monitor connected to the DVI-I port, and when I connected another monitor, to the DP port, kworker started running at 100%, and it still does after I unplugged the DP monitor. While I had the two monitors connected, the system would freeze for up to several minutes when I used the System Settings --> Display and Monitor, and I never managed to get anything shown on the DP monitor.

Should I file a bug report for this? I'm completely new to the Launchpad bug reporting system!

Thanks,
Cheers, Bo

[penalvch (penalvch)]

Bo Milvang-Jensen, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

The bug does still occur on Trusty. I did a fresh install from the nightly builds (the AMD64-Mac ISO), and plugged in the monitor while running `top`. kworker takes up 100% of CPU and makes the system extremely unresponsive.

I rebooted, and ran apport-collect in order to generate the updated debug information.

Thanks for your time, please let me know if there's anything else you need from me. Somebody in the Ubuntu forums thought they might have a workaround, here: http://ubuntuforums.org/showthread.php?t=2191275

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[Brendan (schismoid)]

apport information

[page p (waunchpad-net)]

I'm experiencing the same issue on a MacBookPro11,3 I just bought. Plug in the second monitor via thunderbolt to displayport and a kworker thread pins a cpu. +1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[penalvch (penalvch)]

page p, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[page p (waunchpad-net)]

hi Chris, secretly i run fedora 20 and appreciate the info... i really miss smolt where i could just point to that information and see what the current optin population was... can not believe this is really the only information about it on the internetz... should we email the nouveau driver team directly as i have been working for days trying to find a solution.

not being able to use a second display is painful...

[penalvch (penalvch)]

page p, you are welcome to perform https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1248256/comments/60 while booted into a Ubuntu live environment, so as not to disturb your Fedora 20 install.

[Dale Hamel (daleha-gmail)]

This does not appear to be exclusive to the nouveau or xorg. I've been able to reproduce it at the console by plugging in display port without X11 running.

I open htop, everything looks fine. Then I plug in the display port cable and the CPU immediately shoots up to 100%.

I've also loaded the intel driver (rebooting into macOS, selecting integrated driver and confirming it is running with vga_switcheroo once i reboot back into linux), and i get the exact same behavior.

Note, booting with the displayport cable attached will cause the system to hang during initialization, I guess because the kworker takes 100% of the CPU.

I've also had this happen with the proprietary nvidia driver loaded. This doesn't seem to have anything to do with the graphics driver, but rather the kernel itself is having a hard time with the thunderbolt port managing the display port connection.

Oddly enough, this issue doesn't happen 100% of the time for me. I've had days where it didn't happen at all, and days where it is non stop.

I'm running out of ideas on debugging this one, other than that the problem is almost certainly in the kernel itself, and is probably related to sketchy thunderbolt support since this never happens with just normal HDMI output.

[Brendan (schismoid)]

Dale,

Thank you for the excellent work reproducing and tracking down this bug. What do you think the next step should be? Is there an appropriate place to file this as a bug against the kernel?

I'm honestly surprised it doesn't seem to be affecting more people. Are there really so few people using external monitors over display port?

[Dale Hamel (daleha-gmail)]

Well I'd much prefer to use just a normal HDMI monitor, but i work at a Mac shop and i'm stuck with a cinema display...

I guess the price of the cinema display might be inhibitive? How many people really buy macs to run linux on them? My guess is that this is why this bug is rated so low here.

I'm setting up a debug kernel to take a look at what is spawning the kworkers later tonight based on "http://engineernabendu.blogspot.ca/2013/10/tracking-linux-kworker-threads.html" but I'm getting close to tossing my hands up and buying an HDMI monitor myself...

[page p (waunchpad-net)]

the same issue exist with my hdmi out as well... we want to use display port as hdmi has the limit of the 1080p resolution... the monitor i connect with is 2560 x 1440 http://tinyurl.com/l5bavcq ... the MacBookPro11,3 is 2880x1800 (not that i use it at that, 1600x1200 seems good enough)... perhaps it has to do with the higher resolutions as we ready for these 4k displays...

i also have noted that an irq thread is null in htop and using higher then normal cpu... something like : irq48/null just below the kworker thread...

and definitely thank you Dale... i can build a fedora kernel in an env and i can apply patches to test... i have no idea though about where to look in the kernel code or how to help debug... that is beyond me but can look around... where is the thunderbolt code in a vanilla kernel?

cheers.

[Brendan (schismoid)]

FWIW, I've got a Dell Monitor and bug #1020221
is reporting this issue on a ThinkPad, so I don't think it's exclusively an Apple-hardware problem. You might be correct that it's a somewhat unusual setup.

I'm happy to help out, but I am a total novice when it comes to kernel debugging. Let me know if there's anything I can contribute.

[Dale Hamel (daleha-gmail)]

Progress:

     kworker/0:1-15854 [000] d.h4 1821.296727: workqueue_queue_work: work struct=ffffffff819b1920 function=console_callback workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h2 1821.302144: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.326482: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.s2 1821.326908: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.399680: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.408694: workqueue_queue_work: work struct=ffffffff819b1920 function=console_callback workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h2 1821.451348: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.s2 1821.466868: workqueue_queue_work: work struct=ffff88046f20f010 function=vmstat_update workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.472866: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.s2 1821.476856: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.545851: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.604354: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.618864: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.s2 1821.626806: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.691890: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h2 1821.757689: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.h3 1821.765032: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:1-15854 [000] d.s2 1821.766767: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker...

[Dale Hamel (daleha-gmail)]

Note: kworker/0:1 was found to have extremely CPU usage through ps -auxf:

root 15854 50.0 0.0 0 0 ? R 17:35 2:09 \_ [kworker/0:1]

There are a number of other threads with similar output:

     kworker/0:3-1128 [000] d.s2 1973.688813: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker/0:3-1128 [000] d.h2 1973.704711: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:3-1128 [000] d.h3 1973.757128: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:3-1128 [000] d.h3 1973.830281: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:3-1128 [000] d.s3 1973.838757: workqueue_queue_work: work struct=ffff88046f2135d8 function=od_dbs_timer [cpufreq_ondemand] workqueue=ffff88046d17ba00 req_cpu=0 cpu=0
     kworker/0:3-1128 [000] d.h2 1973.859889: workqueue_queue_work: work struct=ffffffff819b85e0 function=push_to_pool workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
     kworker/0:3-1128 [000] d.h3 1973.903514: workqueue_queue_work: work struct=ffff88045db116e0 function=nouveau_connector_hotplug_work workqueue=ffff88046d17ba00 req_cpu=32 cpu=0
^C

The output is from: /sys/kernel/debug/tracing/trace_pipe

It appears that the hotplug function is failing and being readded to the queue over and over again.

Note that this output was obtained while the nouveau GPU was active via vga_switcheroo.

[Dale Hamel (daleha-gmail)]

The code in question appears to be:

http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nouveau_connector.c#L915

[Dale Hamel (daleha-gmail)]

Though it's just a wrapper for:

http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_crtc_helper.c#L884

Theory:

For some reason, it is constantly toggling between DRM_MODE_DPMS_ON for some reason.

Maybe we should report this bug against nouveau and probably the intel drivers as they will likely have better connections to kernel developers.

[Dale Hamel (daleha-gmail)]

My (assumed) kernel trace:

http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nv50_display.c#L2201 - attempts to create the display here:

http://lxr.free-electrons.com/ident?i=nouveau_connector_create

Later on in the function there is some display port related code... wonder if it has anything to do with this.

http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nv50_display.c#L1944

anyways, nouveau_connector_create is what is scheduling the job that keeps looping. I bet we could at least come up with a junk fix that will stop the loop (probably with hilarious unintentional consequences)

[Dale Hamel (daleha-gmail)]

I've created this issue against nouveau kernel driver:

https://bugs.freedesktop.org/show_bug.cgi?id=77073

[Dale Hamel (daleha-gmail)]

Oohh!! Found something very interesting in this log:

https://bugs.freedesktop.org/attachment.cgi?id=96925

drm:drm_helper_hpd_irq_event is being fired a lot, which is likely the cause of the kernel workers?

[Dale Hamel (daleha-gmail)]

They pointed to this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=76732

[Dale Hamel (daleha-gmail)]

The main thing I've been able to gleam is that the bug first appeared in 3.9, so I'm going to try rolling back to 3.8.13 (and earlier) to see if that resolves the issue. It would be awesome to be able to bisect the exact point when this issue was introduced.

[Dale Hamel (daleha-gmail)]

Another possible (but hilarious fix) is to comment out a line as suggested here:

https://bugs.freedesktop.org/show_bug.cgi?id=76732#c22

Haven't tried that one yet, but 3.8-rc6 should be clean as it is before 0a0afd282fd715dd63d64b243299a64da14f8e8d, which is the first bad commit.

[Dale Hamel (daleha-gmail)]

I can confirm 3.8-rc6 resolves this problem.

So, if rolling back your kernel is an option I would suggest trying that. Otherwise, keep an eye on the upstream ticket.

Hope all this helps guys!

[Dale Hamel (daleha-gmail)]

I should probably mention I'm not using ubuntu at all, I'm using gentoo, so it's a lot easier for me to switch around my kernel...

[page p (waunchpad-net)]

i just tried these two on F20

http://koji.fedoraproject.org/koji/buildinfo?buildID=382551
http://koji.fedoraproject.org/koji/buildinfo?buildID=415645

neither would boot, just hangs identifying the ssd on either kernel... i might try to install F18 later on a spare partition...

[Brendan (schismoid)]

For Ubuntu users, the relevant kernel packages are available here: http://kernel.ubuntu.com/~kernel-ppa/mainline/

I haven't tested any of them yet, but I will try rolling back to a 3.8.X kernel next week.

[Dale Hamel (daleha-gmail)]

@page p make sure that you're modules match your kernel version. Don't mean to be condescending, but that's a common error.

[Dee (bliteknight)]

Not sure the status of this bug, but I just installed Ubuntu 5.4.0-6ubuntu1~16.04.2 with Linux version 4.4.0-38-generic on a dual core machine with an onboard GeForce 9400.

I ran into the issue of one of the cores running at 100% when ever I turned on my monitor and connected to the terminal via DVI/HDMI. If I reboot and only ssh to the machine I get <1% usage across both cores at idle, but as soon as I switch on the monitor one of the cores jumps to 100%

I ran "sudo perf record -g -a sleep 20" then "sudo perf report --sort comm,dso" and this is what I found in the report:

- 100.00% 99.85% kworker/1:7 [kernel.kallsyms]
   - 100.00% ret_from_fork
        kthread
        worker_thread
      - process_one_work
         - 99.97% nvif_notify_work
            + nouveau_connector_hotplug
         + 0.03% nvkm_notify_work
         + 0.00% vmstat_update
     0.00% native_write_msr_safe
- 100.00% 0.09% kworker/1:7 [nouveau]
   - 99.88% nvif_notify_work
      - nouveau_connector_hotplug
         - 99.87% drm_helper_hpd_irq_event
            - 99.86% nouveau_connector_detect
               + 96.48% drm_get_edid
               + 3.39% i2c_transfer
               + 0.00% drm_mode_object_find
            + 0.00% mutex_unlock
         + 0.01% mutex_lock
   + 0.09% ret_from_fork
   + 0.03% nvkm_notify_work
+ 99.96% 0.00% kworker/1:7 [drm_kms_helper]
+ 99.93% 0.05% kworker/1:7 [i2c_algo_bit]
+ 96.56% 0.01% kworker/1:7 [drm]
+ 0.01% 0.00% kworker/1:7 [forcedeth]

So it looks like I got struck but this same hotplug issue. If I connect to my monitor via VGA i don't get the CPU spike...works for me since I am running my machine headless but if anyone else needs to connect via HDMI/DVI this could be an issue. I'm not sure if installing the nvidia drivers fixes the hotplug cpu spike up.

[penalvch (penalvch)]

Dee (bliteknight), it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.