Am Donnerstag, 7. Januar 2021, 22:15:16 CET schrieb Ivan Babrou:
> On Thu, Jan 7, 2021 at 12:59 PM Thomas Renninger wrote:
> > Am Donnerstag, 7. Januar 2021, 18:42:25 CET schrieb Ivan Babrou:
> > > On Thu, Jan 7, 2021 at 2:07 AM Thomas Renninger wrote:
> > > > Am D
Am Donnerstag, 7. Januar 2021, 18:42:25 CET schrieb Ivan Babrou:
> On Thu, Jan 7, 2021 at 2:07 AM Thomas Renninger wrote:
> > Am Dienstag, 5. Januar 2021, 00:57:18 CET schrieb Ivan Babrou:
> > > This allows building cpupower in parallel rather than serially.
> >
> &
Am Dienstag, 5. Januar 2021, 00:57:18 CET schrieb Ivan Babrou:
> This allows building cpupower in parallel rather than serially.
cpupower is built serially:
[ make clean ]
time make
real0m3,742s
user0m3,330s
sys 0m1,105s
[ make clean ]
time make -j10
real0m1,045s
user0m3,15
Am Mittwoch, 11. November 2020, 06:13:50 CET schrieb Viresh Kumar:
> On 10-11-20, 13:53, Thomas Renninger wrote:
> > Am Dienstag, 10. November 2020, 12:07:37 CET schrieb Viresh Kumar:
> > > The cpufreq and thermal core, both provide sysfs statistics to help
> > > userspa
Am Dienstag, 10. November 2020, 12:07:37 CET schrieb Viresh Kumar:
> The cpufreq and thermal core, both provide sysfs statistics to help
> userspace learn about the behavior of frequencies and cooling states.
>
> This is how they look:
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:
Am Mittwoch, 26. August 2020, 16:45:24 CEST schrieb Joe Perches:
> On Wed, 2020-08-26 at 11:30 +0200, Thomas Renninger wrote:
> > Hi,
> >
> Read the block immediately below that too:
>
> "This does not apply if only one branch of a conditional statement is a
>
Hi,
getting rid of lines with multiple instructions, separated by comma is
certainly a good idea.
One nit pick, though:
Am Dienstag, 25. August 2020, 06:56:26 CEST schrieb Joe Perches:
> Use semicolons and braces.
>
> Signed-off-by: Joe Perches
> ---
> tools/lib/subcmd/help.c
On Monday, October 7, 2019 11:11:30 PM CEST Natarajan, Janakarajan wrote:
> On 10/5/2019 7:40 AM, Thomas Renninger wrote:
>
...
> >>
> >> APERF/MPERF from CPL > 0) and avoid using the msr module (patch 2).
> >
> > And this one only exists on late
Hi,
On Wednesday, October 2, 2019 4:45:03 PM CEST Natarajan, Janakarajan wrote:
> On 9/27/19 4:48 PM, Thomas Renninger wrote:
>
> > On Friday, September 27, 2019 6:07:56 PM CEST Natarajan, Janakarajan
> > wrote:
>
> >> On 9/18/2019 11:34 AM, Natarajan, Janakaraj
On Friday, September 27, 2019 6:07:56 PM CEST Natarajan, Janakarajan wrote:
> On 9/18/2019 11:34 AM, Natarajan, Janakarajan wrote:
> > This is advantageous because an IPI is not generated when a read_msr() is
> > executed on the local logical CPU thereby reducing the chance of having
> > APERF a
On Monday, September 9, 2019 3:09:57 PM CEST Jean Delvare wrote:
> Hi Greg,
...
> > Sure, feel free to not register it at all if the mode is enabled.
> Now I feel sorry that I asked my question upstream when there's nothing
> to be done there. I'll go bother SUSE kernel folks instead, sorry for
On Thursday, September 12, 2019 11:43:40 AM CEST Abhishek wrote:
> Hi Shuah,
>
> Thanks for the review. Few comments below.
...
> Since these two options are not being used by any other architecture
> except x86, I suggest these options should not even be shown for
> other architecture. So we ca
the same and is more
flexible:
- Still allows additional cpupower info features for other CPUs later easily
- Should also cover AMD or other non-perf bias supporting CPUs to exclude
perf_bias
setting/info
If this one works for you, can you please re-submit with also handling the set
cmd
similar
related cores at hand.
If you tested this it would be nice to see this pushed:
Reviewed-by: Thomas Renninger
Thanks!
Thomas
omes
up with something similar...
Thomas
FWIW:
Reviewed-by: Thomas Renninger
> While at it, correct the "not supported" print statement to say CPU
> "model" which is what that test does.
>
> Suggested-by: Erwan Velu
> Signed-off-by: Borislav Petkov
>
Thanks Rafael for your quick look at and all the time you spend for this!
A /sys userspace knob will certainly not be enough for us.
You'll need a tool installed fixing this.
powertop on laptops or tuned on servers or a well hidden bootup quirk or
whatsoever.
The patch I sent with this part:
+
to repush this into our kernel(s) now.
On Monday, March 18, 2019 11:57:08 PM CET Rafael J. Wysocki wrote:
> On Mon, Mar 18, 2019 at 2:22 PM Thomas Renninger wrote:
> > On Monday, March 18, 2019 12:40:46 PM CET Rafael J. Wysocki wrote:
> > > On Mon, Mar 18, 2019 at 12:15 PM Thoma
On Monday, March 18, 2019 12:40:46 PM CET Rafael J. Wysocki wrote:
> On Mon, Mar 18, 2019 at 12:15 PM Thomas Renninger wrote:
...
> And who's BIOS, really? I guess you mean the OEM? Note, however,
> that the user and the OEM may not agree on that, but whatever.
I mean both!
Th
On Monday, March 18, 2019 11:26:10 AM CET Rafael J. Wysocki wrote:
> On Fri, Mar 15, 2019 at 4:36 PM Thomas Renninger wrote:
> > Hi Rafael,
> >
...
> > On my workstation the BIOS initializes perf bias to:
> > cpupower info
> > analyzing CPU 0:
> > per
Hi Rafael,
On Thursday, March 14, 2019 11:08:03 PM CET Rafael J. Wysocki wrote:
> On Thu, Mar 14, 2019 at 3:42 PM Thomas Renninger wrote:
> > This is a revert of mainline git commits:
> > commit b51ef52df71cb28e9d90cd1d48b79bf19f0bab06
> > commit 17edf2d79f1ea6dfdb4
# echo online > /sys/devices/system/cpu/cpu1/online
liszt:~/:[0]# x86_energy_perf_policy
cpu0: EPB 0
cpu1: EPB 6
cpu2: EPB 0
cpu3: EPB 0
Signed-off-by: Thomas Renninger
Tested-by: Simon Schricker
Index: do_not_modify_perf_bias/arch/x86/kernel/cpu/common.c
==
On Friday, March 1, 2019 3:53:25 PM CET Thomas Renninger wrote:
> From: Torsten Duwe
>
> Dump a previous oops or panic, which has made it to pstore,
> to the new syslog after reboot, optionally deleting it.
> This can happen automatically, without user land interaction.
>
From: Torsten Duwe
Dump a previous oops or panic, which has made it to pstore,
to the new syslog after reboot, optionally deleting it.
This can happen automatically, without user land interaction.
Signed-off-by: Torsten Duwe
CC: Thomas Renninger
---
fs/pstore/inode.c| 6 +++---
fs
On Wednesday, December 5, 2018 12:31:04 PM CET Abhishek Goel wrote:
> This script adds support for auto-completion for cpupower tool.
> Added support for auto-completion of all the eight commands for
> cpupower tool and their all subsequent sub-commands, wherever
> possible.
>From what I see all c
On Tuesday, October 16, 2018 5:06:05 PM CEST Jiri Olsa wrote:
> hi,
> while hardening some of the tools rpm, we noticed we
> can't pass build flags to some of them.
>
> Sending separate tools fixes for what we found. It's
> mostly override for CFLAGS and adding LDFLAGS to the
> build commands.
Lo
On Tuesday, October 16, 2018 10:56:26 AM CEST Konstantin Khlebnikov wrote:
> Rename duplicate sysfs_read_file into cpupower_read_sysfs and fix linking.
>
> Signed-off-by: Konstantin Khlebnikov
Acked-by: Thomas Renninger
Thanks!
> - $(OUTPUT)../lib/cpufreq.o $(OUTPUT)..
...
Good luck and have fun...,
Thomas
> Patches will flow through the pm sub-systems to the mainline.
>
> Suggested-by: Rafael J. Wysocki
> Signed-off-by: Shuah Khan
Acked-by: Thomas Renninger
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
&
On Thursday, June 08, 2017 08:24:01 PM Greg KH wrote:
> On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote:
> > ---
> > arch/x86/kernel/Makefile| 1 +
> > arch/x86/kernel/cpuinfo_sysfs.c | 166
> > drivers/base/cpuinfo.c |
> Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library")
> > Reported-by: Julian Seward
> > Signed-off-by: Laura Abbott
> > ---
> > v2: Drop another redundant cpupower_is_cpu_online
>
> Reviewed-by:Shilpasri G Bhat
Acked-by: Thomas Renninger
I
On Sunday, May 01, 2016 01:11:33 PM Sean Fu wrote:
> Hi guys:
> I encountered a build error when running "make V=1 tools/all".
> Shall we write a patch to fix it?
This is not a bug.
> The following is error log.
>
> start =
On Monday, March 07, 2016 07:50:57 PM Len Brown wrote:
> > But with Broadwell-EP processor (E5-2687W v4) the CPU will not enter turbo
> > modes if this value is not set to performance
>
> BDX-EP supports HWP.
> Are these failing machines running in HWP mode?
>
> (On BDX-EP, and only on BDX-EP, EP
On Monday, March 07, 2016 02:24:54 PM Thomas Renninger wrote:
> It came out that on certain CPUs perf bias MSR has to be set to performance,
> so that the CPU enters turbo states at all.
>
> Better do not try to wrongly adjust perf bias value,
> its value probably is intended by BI
b51ef52df71cb28e9d90cd1d48b79bf19f0bab06
commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6
commit abe48b108247e9b90b4c6739662a2e5c765ed114
Signed-off-by: Thomas Renninger
---
arch/x86/kernel/cpu/common.c | 18 --
arch/x86/kernel/cpu/cpu.h|1 -
arch/x86/kernel/cpu/intel.c | 32
On Wednesday, March 02, 2016 01:26:18 AM Rafael J. Wysocki wrote:
> On Tuesday, March 01, 2016 01:17:37 PM Thomas Renninger wrote:
> > > > if (!cpu_has(c, X86_FEATURE_EPB))z
> > > >
> > > > return;
> >
On Saturday, February 27, 2016 12:15:47 AM Rafael J. Wysocki wrote:
> On Friday, February 26, 2016 05:38:00 PM Thomas Renninger wrote:
> > The assumption that BIOSes never want to have this register being set to
> > full performance (zero) is wrong.
> >
> > While w
This in fact is a re-send, including x86 maintainers.
Even this is a PM (Power Management) issue, the code is in the
x86 architecture paths.
>From last submit:
> > Patch is against latest linux-pm kernel.
> > Rafael: Can you queue this one up, please.
> Well, I'm not an x86 arch maintainer.
> Can
correct value here and do not
blindly overrule.
How this has been found: SLE11 had this patch, SLE12 it slipped through.
It took quite some time to nail down that this patch missing is the reason
for not entering turbo modes with this specific processor.
Signed-off-by: Thomas Renninger
--- a
latency || latency == UINT_MAX) {
> ^
> Signed-off-by: Shreyas B. Prabhu
Signed-off-by: Thomas Renninger
Builds for me by luck, thanks!
Thomas
ested.
>
> Signed-off-by: Oleg Drokin
Signed-off-by: Thomas Renninger
Thanks!
> ---
> I assume allowing run-time changes via /sys/module is preferrable,
> opposed to forced module unload and reload to change this option,
> but I can submit another patch to only depend on the
On Friday, January 22, 2016 01:09:15 PM Thomas Renninger wrote:
> The assumption that BIOSes never want to have this register being set to
> full performance (zero) is wrong.
Patch is against latest linux-pm kernel.
Rafael: Can you queue this one up, please.
Thanks,
Thomas
the correct value here and do not
blindly overrule.
How this has been found: SLE11 had this patch, SLE12 it slipped through.
It took quite some time to nail down that this patch missing is the reason
for not entering turbo modes with this specific processor.
Signed-off-by: Thomas Renninger
uot;
in the changelog.
Feel free to add a Reviewed-by: Thomas Renninger
if you plan to re-submit.
Thanks!
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
es
> functions relying on get_cpu_topology() to fail. For example-
>
> $ cpupower monitor
> Cannot read number of available processors
>
> Fix this by skipping fetching topology info for offline cpus.
Looks fine.
Thanks!
Acked-by: Thomas Renninger
>
> Signed-off-by: Shr
continue;
>
> + if (sysfs_is_cpu_online(cpu) != 1)
> + continue;
> +
> printf(_("Setting cpu: %d\n"), cpu);
> ret = do_one_cpu(cpu, &new_pol, freq, policychange);
> if (ret) {
Thanks for catching this o
ug
> > output, which isn't a percentage...
>
> Thomas, any comments?
I tried to find fitting HW without much success.
The MAX_FREQ_SYSFS is used only on rare HW and it may never got a proper test.
Patch looks sane. Even I cannot add a Tested-by:
you may add:
Acked-by
...
I am not that familiar with the pci lib and its recent changes, but
below patch looks reasonable.
Acked-by: Thomas Renninger
> The libpci internal helpers got updated accordingly,
> but as the cpupower pci helpers initialized the struct themselves the
> behavior changed.
>
&g
On Tuesday, March 10, 2015 11:30:44 PM Rafael J. Wysocki wrote:
> On Tuesday, March 10, 2015 08:33:54 AM Josh Boyer wrote:
> > On Fri, Mar 6, 2015 at 8:47 AM, Josh Boyer
wrote:
> > > Hi All,
> > >
> > > Commit 5c1de006e8e66 (cpupower Makefile change to help run the tool
> > > without 'make insta
an error code makes a lot sense
here.
>
> Cc: Thomas Renninger
> Cc: Rafael J. Wysocki
> Signed-off-by: Prarit Bhargava
Acked-by: Thomas Renninger
Thanks!
Thomas
> ---
> tools/power/cpupower/utils/helpers/sysfs.c |2 +-
> 1 file changed, 1 insertion(+), 1 delet
Thomas is needed.
Patch is correct, Thanks!
Acked-by: Thomas Renninger
Thomas
>
> > ---
> >
> > tools/power/cpupower/utils/cpupower.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/power/cpupower/utils/cpupower.c
of idle states: -19
> [hang]
>
> The problem is that the cpupower code only checks for a zero return from
> sysfs_get_idlestate_count(). The function can return -ENODEV (-19) as
> above. This patch fixes callers to sysfs_get_idlestate_count() to check
> the right return valu
On Friday, October 24, 2014 12:40:56 PM Wilck, Martin wrote:
> Thomas,
>
>
> > > I vote for MODULE_SOFTDEP for upstream, and modalias for distros that
> > > don't support MODULE_SOFTDEP yet.
> >
> > I vote for ipmi_msghandler.c renaming into ipmi_handler.c
>
>
> sorry, I am not with you here.
On Monday, October 20, 2014 10:28:53 AM Wilck, Martin wrote:
> On Fri, 2014-10-17 at 18:14 +0200, Corey Minyard wrote:
>
>
> > How about this. I did a little research, and there's something called
> > soft module dependencies. Apparently you can add:
> >
> > MODULE_SOFTDEP("post: ipmi_devintf"
t; parameter. Others do not need this as well.
> This is the way msr.c (/dev/cpu/X/msr) is doing it as well.
>
> Side effect of this patch will be that the userspace interface cannot
> be disabled at kernel level anymore. But this can also be enforced by not
> letting userspac
Hi,
On Tuesday, October 14, 2014 08:22:20 PM Corey Minyard wrote:
> On 10/14/2014 09:40 AM, tr...@suse.de wrote:
> > This removes the ipmi_devintf to be a module, but it will automatically
> > compiled in if ipmi_msghandler is set.
> >
> > ipmi_msghandler module is renamed to ipmi_handler because
On Wednesday, March 05, 2014 06:26:54 AM Zheng, Lv wrote:
...
> > > After the table manager cleanups are tested and shipped in the ACPICA
> > > repo,
> > > the new facilities will automatically be rolled into Linux branches.
> >
> > I'd suggest to just wait for that.
> > Best already try to integ
On Tuesday, March 04, 2014 12:31:57 AM Zheng, Lv wrote:
> Hi, Thomas
>
> > From: Thomas Renninger [mailto:tr...@suse.de]
> > Sent: Monday, March 03, 2014 8:42 PM
> >
> > Hi Lv,
> >
> > On Monday, March 03, 2014 01:20:31 AM Zheng, Lv wrote:
> >
Hi Lv,
On Monday, March 03, 2014 01:20:31 AM Zheng, Lv wrote:
> Hi, Thomas
>
> I have a patch series that can cleanup the ACPICA table manager, and change
> the acpi_load_table into the following style:
Ok. I suggest that:
1) If Thomas (Gleixner) or whoever wants to try out or needs it urgently,
Latest changes are compile tested only!
If this gets serialized/merged and accepted in acpica in
some form with whatever other stuff currently added,
please drop me a mail.
I can then submit the Linux parts again to the kernel people
with the documentation adjusted as well:
Documentation/acpi/ini
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@kernel.org
CC: mi...@redhat.com
CC: r...@rjwysocki.net
CC: de...@acpica.org
---
drivers/acpi/osl.c |4 +++-
1 files changed, 3 insertions(+), 1
In Linux there even exists a driver already making use of this table:
drivers/acpi/bgrt.c:MODULE_DESCRIPTION("BGRT boot graphic support");
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@ker
IC-WKS 01072009
INTL 20130823)
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@kernel.org
CC: mi...@redhat.com
CC: r...@rjwysocki.net
CC: de...@acpica.org
---
drivers/acpi/osl.c
This one allows OS to add arbitrary ACPI tables.
ToDo: It should get checked whether a table with the same signature already
exists and if this is the case, adding should not happen.
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux
On Tuesday, February 18, 2014 12:51:07 PM H. Peter Anvin wrote:
> On 02/18/2014 10:44 AM, Thomas Renninger wrote:
> > On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> >> Why can't you add SSDTs? It would be particularly useful.
> >
> > There a
On Tuesday, February 18, 2014 07:59:17 PM Moore, Robert wrote:
> Maybe not exactly "running", but at the very least, ACPICA must be
> initialized.
>
> All of this of course depends on how early the table needs to be loaded.
I'd say as early as possible.
Not sure about Thomas' use case.
I expect m
iginal Message-
> > From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Thomas
> > Renninger
> > Sent: Tuesday, February 18, 2014 10:23 AM
> > Cc: x...@kernel.org; c...@conrad-kostecki.de; linux-kernel@vger.kernel.org;
> > mi...@redhat.com; h...@zytor.com; t...@linutro
On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> Why can't you add SSDTs? It would be particularly useful.
There are 2 ways how ACPI tables get added:
- Via pointer from a root table (XSDT or RSDT iirc)
- Via load statement inside of ACPI context when ACPI BIOS
code get
IC-WKS 01072009
INTL 20130823)
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@kernel.org
CC: mi...@redhat.com
CC: r...@rjwysocki.net
CC: de...@acpica.org
---
drivers/acpi/osl.c
This one allows OS to add arbitrary ACPI tables.
ToDo: It should get checked whether a table with the same signature already
exists and if this is the case, adding should not happen.
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux
In Linux there even exists a driver already making use of this table:
drivers/acpi/bgrt.c:MODULE_DESCRIPTION("BGRT boot graphic support");
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@ker
The ACPICA patches have to go into separate acpica repository first.
It should also be checked in acpica whether the table signature the OS likes
to add already exists (from BIOS). In this case the table must not be added.
Worked here by trying to override a DSDT and addind a BGRT table.
Tho
Signed-off-by: Thomas Renninger
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x...@kernel.org
CC: mi...@redhat.com
CC: r...@rjwysocki.net
CC: de...@acpica.org
---
drivers/acpi/osl.c |4 +++-
1 files changed, 3 insertions(+), 1
On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote:
> On 02/17/2014 10:23 AM, Thomas Renninger wrote:
> > Easiest I can think of instead of trying to modify RSDP or similar, is
> > to still pass the tables via unzipped, glued cpio which the kernel
> > can access e
bles in there get loaded and set up as if they
were passed from BIOS.
Thomas
> On February 17, 2014 8:28:05 AM PST, Thomas Renninger wrote:
> >On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
> >> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> &g
On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> > >>> I'm fine with ACPI tables if
On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
>
> According to the Microsoft requirements document
Rafael: Could you queue these two again in your tree if they are ok, please.
Sidenote:
If I find the time, I like to adjust the cpuidle ladder governor:
If a lighter sleep state is disabled (and in this governor deeper sleep
states are not entered any more as well), I like to set the disabled
flag
commit 62d6ae880e3e76098
documentation submitted by Carsten Emde.
Signed-off-by: Thomas Renninger
CC: Carsten Emde
CC: Yanmin Zhang
CC: Deepthi Dharwar
CC: ShuoX Liu
CC: c...@linux.com
---
tools/power/cpupower/man/cpupower-idle-info.1 |3 +-
tools/power/cpupower/man/cpupower-idle-set.1
will be -
cpupower idle-set -e 5
Idlestate 6 not available on CPU 0
---
cpupower idle-set -e 6
Idlestate 6 not available on CPU 0
Signed-off-by: Thomas Renninger
---
tools/power/cpupower/utils/helpers/sysfs.c |4 ++--
1 files changed, 2 insertions(+), 2
On Wednesday, November 13, 2013 12:10:08 AM Ingo Molnar wrote:
> * Borislav Petkov wrote:
...
> > > Shouldn't that be ?
> >
> > Yes, it should:
> >
> > Final-Recipient: rfc822; sta...@kernel.org
> > Action: failed
> > Status: 5.0.0
> > Diagnostic-Code: X-Postfix; host mail.kernel.org[198.145.19
Commit-ID: 11f918d3e2d3861b6931e97b3aa778e4984935aa
Gitweb: http://git.kernel.org/tip/11f918d3e2d3861b6931e97b3aa778e4984935aa
Author: Thomas Renninger
AuthorDate: Tue, 12 Nov 2013 17:39:43 +0100
Committer: Ingo Molnar
CommitDate: Tue, 12 Nov 2013 22:03:49 +0100
x86/microcode/amd
Hi,
I do not have a problem with this, just for info:
On Friday, September 06, 2013 07:08:00 PM Yinghai Lu wrote:
> Current acpi tables in initrd is limited to 10, that is too small.
> 64 should be good enough as we have 35 sigs and could have several
> SSDT.
The whole mechanism is for debugging
On Tuesday, July 09, 2013 06:48:55 PM Jiri Olsa wrote:
> hi,
> following up on the 'perf timechart' FIXME note and changing
> its tracepoint match not to use event types data.
Looks sane and pretty straight forward.
Still I am not that deep involved in perf to give a Reviewed-by: quickly...
#defi
On Wednesday, July 03, 2013 11:56:27 PM Rafael J. Wysocki wrote:
> On Wednesday, July 03, 2013 02:48:38 PM Thomas Renninger wrote:
> > It is quite some time that this one is deprecated.
> > Get rid of it.
> >
> > If there should really some important user be overseen it
Moraes Holschuh
Signed-off-by: Thomas Renninger
---
Documentation/laptops/thinkpad-acpi.txt | 73 +++
drivers/platform/x86/thinkpad_acpi.c| 29
2 files changed, 6 insertions(+), 96 deletions(-)
diff --git a/Documentation/laptops/thinkpad-acpi.txt
b
SLE11 nowadays makes use of the new interface without doing any modifications
to the kernel in this area. That means the old interface is not needed at
least since 3.0 or longer.
Time to get rid of it.
CC: Arjan van de Ven
CC: h...@zytor.com
Signed-off-by: Thomas Renninger
---
arch/x86
Please consider to apply for vanilla kernel submission.
Thanks,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ a
: Rafael J. Wysocki
CC: Matthew Garrett
CC: Henrique de Moraes Holschuh
Signed-off-by: Thomas Renninger
---
Documentation/laptops/asus-laptop.txt |8 +-
Documentation/laptops/sony-laptop.txt |8 +-
Documentation/power/video_extension.txt | 15 -
drivers/acpi/Kconfig
On Thursday, April 11, 2013 07:55:57 AM Yinghai Lu wrote:
> On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger wrote:
> > Currently ranges are passed via kernel boot parameters:
> > memmap=exactmap memmap=X#Y memmap=
> >
> > Pass them via e820 table directly i
On Thursday, April 11, 2013 08:28:37 AM Yu, Fenghua wrote:
> > From: Thomas Renninger [mailto:tr...@suse.de]
...
> > Does this apply to secure boot specification?
>
> Secure boot can add another level of security because the early loaded
> microcode is part of initrd and
On Wednesday, April 10, 2013 05:47:25 PM Yu, Fenghua wrote:
> > -Original Message-
> > From: Thomas Renninger [mailto:tr...@suse.de]
> > Sent: Wednesday, April 10, 2013 12:41 AM
> > Hello,
> >
> > On Wednesday, April 10, 2013 01:34:33 PM Tang Chen
Hello,
On Wednesday, April 10, 2013 01:34:33 PM Tang Chen wrote:
> On 04/05/2013 07:46 AM, Yinghai Lu wrote:
> > Use common get_ramdisk_image() to get ramdisk start phys address.
> >
> > We need this to get correct ramdisk adress for 64bit bzImage that
> > initrd can be loaded above 4G by kexec-t
e/acpi/tables/FACP:
my:
PM Profile : 04 [Enterprise Server]
changed (as expected) to:
PM Profile : 02 [Mobile]
>From acpi overriding parts:
Tested-by: Thomas Renninger
I also went through the override related patches and from
what I can judge (certainly not the early memory, flat 32 bit memo
On Thursday, April 04, 2013 08:09:46 PM Yinghai Lu wrote:
> On Thu, Apr 4, 2013 at 7:28 PM, Thomas Renninger wrote:
> > On Thursday, April 04, 2013 04:46:04 PM Yinghai Lu wrote:
> >> One commit that tried to parse SRAT early get reverted before v3.9-rc1.
&
On Thursday, April 04, 2013 04:46:04 PM Yinghai Lu wrote:
> One commit that tried to parse SRAT early get reverted before v3.9-rc1.
>
> | commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f
> | Author: Tang Chen
> | Date: Fri Feb 22 16:33:44 2013 -0800
> |
> |acpi, memory-hotplug: parse SRAT b
efulness now and it's going to get
used (automatically) and the stuff is even documented, I cannot suggest
anything anymore how to integrate that better.
Acked-by: Thomas Renninger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Tuesday, April 02, 2013 03:03:37 PM Jacob Shin wrote:
> On Tue, Apr 02, 2013 at 09:23:52PM +0200, Borislav Petkov wrote:
> > On Tue, Apr 02, 2013 at 01:11:44PM -0500, Jacob Shin wrote:
> > > Future AMD processors, starting with Family 16h, can provide software
> > > with feedback on how the work
On Thursday, March 28, 2013 01:24:17 PM Jacob Shin wrote:
> Future AMD processors, starting with Family 16h, can provide software
> with feedback on how the workload may respond to frequency change --
> memory-bound workloads will not benefit from higher frequency, where
> as compute-bound workload
On Monday, March 04, 2013 05:14:43 PM Thomas Renninger wrote:
> From: Hannes Reinecke
>
> xhci has its own interrupt enabling routine, which will try to
> use MSI-X/MSI if present. So the usb core shouldn't try to enable
> legacy interrupts; on some machines the xhci leg
trenn)
Cc: Bjorn Helgaas
Cc: Oliver Neukum
Cc: Thomas Renninger
Cc: Yinghai Lu
Cc: Frederik Himpe
Cc: David Haerdeman
Cc: Alan Stern
Reviewed-by: Thomas Renninger
Signed-off-by: Hannes Reinecke
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..2b487d4 1
On Monday, March 04, 2013 10:26:40 AM Alan Stern wrote:
> On Mon, 4 Mar 2013, Hannes Reinecke wrote:
> > xhci has its own interrupt enabling routine, which will try to
> > use MSI-X/MSI if present. So the usb core shouldn't try to enable
> > legacy interrupts; on some machines the xhci legacy IRQ s
1 - 100 of 286 matches
Mail list logo
