linux-kernel - Re: Bug#855183: linux-image-4.9.0-0.bpo.1-amd64: modprobe intel_rapl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1702171141220.3536@nanos>
Date:   Fri, 17 Feb 2017 11:47:55 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ben Hutchings <ben@...adent.org.uk>
cc:     x86@...nel.org, Miloslav Hula <miloslav.hula@...il.com>,
        855183@...s.debian.org, LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kan Liang <kan.liang@...el.com>
Subject: Re: Bug#855183: linux-image-4.9.0-0.bpo.1-amd64: modprobe intel_rapl_perf
 stay in uninterruptible sleep

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]  [<ffffffff929f536d>] ? __schedule+0x23d/0x6d0
> > [ 1090.784308]  [<ffffffffc083e6b0>] ? uncore_cpu_prepare+0x100/0x100 [intel_uncore]
> > [ 1090.784310]  [<ffffffff929f5832>] ? schedule+0x32/0x80
> > [ 1090.784316]  [<ffffffff929f8d3c>] ? schedule_timeout+0x21c/0x3c0
> > [ 1090.784327]  [<ffffffff924b1374>] ? enqueue_task_fair+0x74/0x950
> > [ 1090.784329]  [<ffffffff929f5375>] ? __schedule+0x245/0x6d0
> > [ 1090.784336]  [<ffffffff9242ed05>] ? sched_clock+0x5/0x10
> > [ 1090.784344]  [<ffffffffc083e6b0>] ? uncore_cpu_prepare+0x100/0x100 [intel_uncore]
> > [ 1090.784347]  [<ffffffff929f624a>] ? wait_for_completion+0xfa/0x130
> > [ 1090.784353]  [<ffffffff924a2b60>] ? wake_up_q+0x60/0x60
> > [ 1090.784358]  [<ffffffff924791b6>] ? cpuhp_issue_call+0x96/0xc0
> > [ 1090.784361]  [<ffffffff9247946a>] ? __cpuhp_setup_state+0xca/0x200
> > [ 1090.784369]  [<ffffffffc069d34d>] ? 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