From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933797AbdBQKta (ORCPT ); Fri, 17 Feb 2017 05:49:30 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:56016 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932674AbdBQKsE (ORCPT ); Fri, 17 Feb 2017 05:48:04 -0500 Date: Fri, 17 Feb 2017 11:47:55 +0100 (CET) From: Thomas Gleixner To: Ben Hutchings cc: x86@kernel.org, Miloslav Hula , 855183@bugs.debian.org, LKML , Peter Zijlstra , Kan Liang Subject: Re: Bug#855183: linux-image-4.9.0-0.bpo.1-amd64: modprobe intel_rapl_perf stay in uninterruptible sleep In-Reply-To: <1487292582.22520.12.camel@decadent.org.uk> Message-ID: References: <20170215080829.27308.94177.reportbug@imap.fsv.cvut.cz> <1487292582.22520.12.camel@decadent.org.uk> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1403296552-1487328475=:3536" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1403296552-1487328475=:3536 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 17 Feb 2017, Ben Hutchings wrote: > On Wed, 2017-02-15 at 09:08 +0100, Miloslav Hula wrote: > [...] > > When I boot the system up, there is a constant load 1.0. I found one > > process systemd-udevd in uninterruptible sleep. > > Digging in proc/PID/fd I found, this proces usees fd 7 for > > intel_rapl_perf.ko > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > I rmmod intel_rapl_perf, the systemd-udevd process disappeared. I > > tried to load intel_rapl_perf manually. > > > > * What was the outcome of this action? > > Now, the modprobe is in uninterruptible sleep > [...] > > Here's a traceback for that: > > > [ 1090.784260]  ffffa079b6c9d000 0000000000000000 ffffa089b8ffa0c0 ffffa079b688c140 > > [ 1090.784265]  ffffa089bf2987c0 ffffc1d3ce12bb30 ffffffff929f536d ffffa089bf3d8828 > > [ 1090.784268]  ffffc1d3ce12bb60 00000000924b0afe ffffa089bf2987c0 ffffa079b688c140 > > [ 1090.784272] Call Trace: > > [ 1090.784284]  [] ? __schedule+0x23d/0x6d0 > > [ 1090.784308]  [] ? uncore_cpu_prepare+0x100/0x100 [intel_uncore] > > [ 1090.784310]  [] ? schedule+0x32/0x80 > > [ 1090.784316]  [] ? schedule_timeout+0x21c/0x3c0 > > [ 1090.784327]  [] ? enqueue_task_fair+0x74/0x950 > > [ 1090.784329]  [] ? __schedule+0x245/0x6d0 > > [ 1090.784336]  [] ? sched_clock+0x5/0x10 > > [ 1090.784344]  [] ? uncore_cpu_prepare+0x100/0x100 [intel_uncore] > > [ 1090.784347]  [] ? wait_for_completion+0xfa/0x130 > > [ 1090.784353]  [] ? wake_up_q+0x60/0x60 > > [ 1090.784358]  [] ? cpuhp_issue_call+0x96/0xc0 > > [ 1090.784361]  [] ? __cpuhp_setup_state+0xca/0x200 > > [ 1090.784369]  [] ? intel_uncore_init+0x1f7/0xeaa [intel_uncore] Unfortunately that tells us only that something waits forever, but we don't see the stuff which does not invoke complete(). AFAICT thats a cpuhp thread which should run the cpu starting or online callback. What's really confusing is this information from the bug report: " When I changed: Power technology: - from Energy Efficient - to Custom Energy Performance BIAS Setting: - from Balanced Performance - to Performance problem disappeared. systemd-udevd starts normally, module can be normally rmmod/insmod'ed now, load is 0.07." Miloslav: Is there any chance you can try a 4.10-rc8 kernel on that machine? Thanks, tglx --8323329-1403296552-1487328475=:3536--