public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "timo.lindfors at iki dot fi" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/15789] ERROR: couldn't initialize gettimeofday
Date: Tue, 30 Jul 2013 07:16:00 -0000	[thread overview]
Message-ID: <bug-15789-6586-4d2jLJLRCy@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-15789-6586@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=15789

--- Comment #2 from Timo Juhani Lindfors <timo.lindfors at iki dot fi> ---
Seems also non-systemtap xen users have hit this problem:


commit c705c78c0d0835a4aa5d0d9a3422e3218462030c
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Tue Mar 5 13:42:54 2013 -0500

    acpi: Export the acpi_processor_get_performance_info

    The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
    (cpufreq: handle cpufreq being disabled for all exported function)
    tightens the cpufreq API by returning errors when disable_cpufreq()
    had been called.

    The problem we are hitting is that the module xen-acpi-processor which
    uses the ACPI's functions: acpi_processor_register_performance,
    acpi_processor_preregister_performance, and acpi_processor_notify_smm
    fails at acpi_processor_register_performance with -22.

    Note that earlier during bootup in arch/x86/xen/setup.c there is also
    an call to cpufreq's API: disable_cpufreq().

    This is b/c we want the Linux kernel to parse the ACPI data, but leave
    the cpufreq decisions to the hypervisor.

    In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
    added are now hit and the calls to cpufreq_register_notifier will now
    fail. This means that acpi_processor_ppc_init ends up printing:

    "Warning: Processor Platform Limit not supported"

    and the acpi_processor_ppc_status is not set.

    The repercussions of that is that the call to
    acpi_processor_register_performance fails right away at:

        if (!(acpi_processor_ppc_status & PPC_REGISTERED))

    and we don't progress any further on parsing and extracting the _P*
    objects.
    The only reason the Xen code called that function was b/c it was
    exported and the only way to gather the P-states. But we can also
    just make acpi_processor_get_performance_info be exported and not
    use acpi_processor_register_performance. This patch does so.

    Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

-- 
You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2013-07-30  7:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  9:20 [Bug runtime/15789] New: " timo.lindfors at iki dot fi
2013-07-26  9:33 ` [Bug runtime/15789] " timo.lindfors at iki dot fi
2013-07-30  7:16 ` timo.lindfors at iki dot fi [this message]
2013-08-02 18:07 ` dsmith at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15789-6586-4d2jLJLRCy@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).