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:
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 are 2
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
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 most
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 are 2 ways how ACPI tables get added:
- Via
l 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...@linutronix.d
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
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.
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
Signed-off-by: Thomas Renninger tr...@suse.de
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
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.
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 tr...@suse.de
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x
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 tr...@suse.de
CC: h...@zytor.com
CC: t...@linutronix.de
CC: c...@conrad
01072009
INTL 20130823)
Signed-off-by: Thomas Renninger tr...@suse.de
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 | 89
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
: 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...@linutronix.de; de...@acpica.org
Subject: [Devel] ACPI: Also allow
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 acces
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:
> >> > On 02/14/2014 1
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
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 we can
as if they
were passed from BIOS.
Thomas
On February 17, 2014 8:28:05 AM PST, Thomas Renninger tr...@suse.de wrote:
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
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 early. The same way it is done
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
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 documents, such
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
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
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 tr...@suse.de
---
tools/power/cpupower/utils/helpers/sysfs.c |4 ++--
1 files changed, 2
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
commit 62d6ae880e3e76098
documentation submitted by Carsten Emde.
Signed-off-by: Thomas Renninger tr...@suse.de
CC: Carsten Emde c.e...@osadl.org
CC: Yanmin Zhang yanmin_zh...@intel.com
CC: Deepthi Dharwar deep...@linux.vnet.ibm.com
CC: ShuoX Liu shuox@intel.com
CC: c...@linux.com
---
tools
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
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
Commit-ID: 11f918d3e2d3861b6931e97b3aa778e4984935aa
Gitweb: http://git.kernel.org/tip/11f918d3e2d3861b6931e97b3aa778e4984935aa
Author: Thomas Renninger tr...@suse.de
AuthorDate: Tue, 12 Nov 2013 17:39:43 +0100
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 12 Nov 2013 22:03:49
On Wednesday, November 13, 2013 12:10:08 AM Ingo Molnar wrote:
* Borislav Petkov b...@suse.de wrote:
...
Shouldn't that be sta...@vger.kernel.org ?
Yes, it should:
Final-Recipient: rfc822; sta...@kernel.org
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host
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
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...
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...
#define
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 oversee
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 could get
reverted and worked
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
: 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
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 at
: Rafael J. Wysocki r...@sisk.pl
CC: Matthew Garrett matthew.garr...@nebula.com
CC: Henrique de Moraes Holschuh h...@hmh.eng.br
Signed-off-by: Thomas Renninger tr...@suse.de
---
Documentation/laptops/asus-laptop.txt |8 +-
Documentation/laptops/sony-laptop.txt |8 +-
Documentation/power
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 ar...@linux.intel.com
CC: h...@zytor.com
Signed-off-by: Thomas Renninger
Moraes Holschuh h...@hmh.eng.br
Signed-off-by: Thomas Renninger tr...@suse.de
---
Documentation/laptops/thinkpad-acpi.txt | 73 +++
drivers/platform/x86/thinkpad_acpi.c| 29
2 files changed, 6 insertions(+), 96 deletions(-)
diff --git a/Documentation
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 07:55:57 AM Yinghai Lu wrote:
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger tr...@suse.de wrote:
Currently ranges are passed via kernel boot parameters:
memmap=exactmap memmap=X#Y memmap=
Pass them via e820 table directly instead.
how to address
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 a
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
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 wrote:
On 04/05/2013 07:46 AM, Yinghai Lu wrote
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 initrd is measured by secure
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
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
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 08:09:46 PM Yinghai Lu wrote:
On Thu, Apr 4, 2013 at 7:28 PM, Thomas Renninger tr...@suse.de 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.
| commit
Profile : 04 [Enterprise Server]
changed (as expected) to:
PM Profile : 02 [Mobile]
From acpi overriding parts:
Tested-by: Thomas Renninger tr...@suse.de
I also went through the override related patches and from
what I can judge (certainly not the early memory, flat 32 bit memory you call
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
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 to maj
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 tr...@suse.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
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 tangc...@cn.fujitsu.com
| Date: Fri Feb 22 16:33:44 2013 -0800
|
|acpi,
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
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
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 workloads
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 workload may
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
On Monday, March 04, 2013 05:14:43 PM Thomas Renninger wrote:
From: Hannes Reinecke h...@suse.de
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 setting
)
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 100644
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
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 setting
(by trenn)
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Oliver Neukum oneu...@suse.de
Cc: Thomas Renninger tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Cc: Alan Stern st...@rowland.harvard.edu
Reviewed-by: Thomas Renninger tr
On Tuesday, February 26, 2013 04:20:07 PM Viresh Kumar wrote:
> On 26 February 2013 16:14, Thomas Renninger wrote:
> > Redefining MIN_LATENCY_MULTIPLIER shouldn't hurt that much, but this looks
> > like a workaround.
> > It only modifies the minimal sampling rate that usersp
On Tuesday, February 26, 2013 03:13:32 PM Viresh Kumar wrote:
> Currently MIN_LATENCY_MULTIPLIER is set defined as 100 and so on a system
> with transition latency of 1 ms, the minimum sampling time comes to be
> around 100 ms. That is quite big if you want to get better performance for
> your
On Tuesday, February 26, 2013 03:13:32 PM Viresh Kumar wrote:
Currently MIN_LATENCY_MULTIPLIER is set defined as 100 and so on a system
with transition latency of 1 ms, the minimum sampling time comes to be
around 100 ms. That is quite big if you want to get better performance for
your system.
On Tuesday, February 26, 2013 04:20:07 PM Viresh Kumar wrote:
On 26 February 2013 16:14, Thomas Renninger tr...@suse.de wrote:
Redefining MIN_LATENCY_MULTIPLIER shouldn't hurt that much, but this looks
like a workaround.
It only modifies the minimal sampling rate that userspace can set
Commit-ID: 565d956a7e191e95d81f515196951715f2616e6b
Gitweb: http://git.kernel.org/tip/565d956a7e191e95d81f515196951715f2616e6b
Author: Thomas Renninger
AuthorDate: Fri, 22 Feb 2013 14:12:22 +0100
Committer: H. Peter Anvin
CommitDate: Mon, 25 Feb 2013 10:47:09 -0800
ACPI: Overriding
Commit-ID: 565d956a7e191e95d81f515196951715f2616e6b
Gitweb: http://git.kernel.org/tip/565d956a7e191e95d81f515196951715f2616e6b
Author: Thomas Renninger tr...@suse.de
AuthorDate: Fri, 22 Feb 2013 14:12:22 +0100
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Mon, 25 Feb 2013 10
On Tuesday, January 29, 2013 03:10:38 AM Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 5:11 PM, H. Peter Anvin wrote:
> >> So I guess the final patch should be:
> >>- Add a new e820 type:
> >> E820_KDUMP_RESERVED /* Originally usable memory where the crashed
> >>
On Tuesday, January 29, 2013 03:10:38 AM Yinghai Lu wrote:
On Mon, Jan 28, 2013 at 5:11 PM, H. Peter Anvin h...@zytor.com wrote:
So I guess the final patch should be:
- Add a new e820 type:
E820_KDUMP_RESERVED /* Originally usable memory where the crashed
On Thursday, January 24, 2013 09:23:14 AM Takao Indoh wrote:
> (2013/01/23 9:47), Thomas Renninger wrote:
> > On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
> >> (2013/01/08 4:09), Thomas Renninger wrote:
> > ...
> >
> >>> I tried the provid
On Wednesday, January 23, 2013 08:07:19 PM Yinghai Lu wrote:
> On Tue, Jan 22, 2013 at 12:06 PM, Yinghai Lu wrote:
> > On Tue, Jan 22, 2013 at 8:32 AM, H. Peter Anvin wrote:
> >>> Again: Please explain what is bad with this solution.
> >>> I cannot see a better and more robust way for kdump
On Wednesday, January 23, 2013 08:07:19 PM Yinghai Lu wrote:
On Tue, Jan 22, 2013 at 12:06 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Jan 22, 2013 at 8:32 AM, H. Peter Anvin h...@zytor.com wrote:
Again: Please explain what is bad with this solution.
I cannot see a better and more
On Thursday, January 24, 2013 09:23:14 AM Takao Indoh wrote:
(2013/01/23 9:47), Thomas Renninger wrote:
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
...
I tried the provided patches first on 2.6.32, then I verfied with
3.8-rc2
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
> (2013/01/08 4:09), Thomas Renninger wrote:
...
> > I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
> > and in both cases the disk is not detected anymore in
> > reset_devices (kexec'ed/kd
On Tuesday, January 22, 2013 04:54:08 PM H. Peter Anvin wrote:
> On 01/22/2013 09:20 AM, Thomas Renninger wrote:
> > From: Yinghai Lu
> >
> > kdump voided the whole original e820 map and half way made
> > it up via memmap= options passed
this is a clean resend of Yinghai's memmap= extensions.
They were discussed on lkml in a thread with subject:
[PATCH] x86 e820: only void usable memory areas in memmap=exactmap case
The patches are based on origin/x86/mm2 where another memmap=
enhancement from Yinghai is already queued.
Would
(extended PCI config access) and
possibly other kernel parts which rely on remapped memory to be
in reserved or ACPI (data/nvs) declared e820 memory areas.
Tested-by: Thomas Renninger
Reviewed-by: Thomas Renninger
Signed-off-by: Thomas Renninger
---
Documentation/kernel-parameters.txt |9
On Tuesday, January 15, 2013 05:45:43 AM Yinghai Lu wrote:
> On Mon, Jan 14, 2013 at 4:54 PM, Thomas Renninger wrote:
...
> > From what I can see the patch looks fine, but above part should
> > simply be left out.
>
> then, I would like to rename it to resetusablemap instea
memmap=i#k
only i#k would get recognized.
This is wrong, this fix will only throw away all original e820 areas once
when memmap=exactmap is found in the whole boot command line and before
any other memmap= option is parsed.
Reviewed-by: Thomas Renninger
Signed-off-by: Thomas Renninger
---
arch/x86
memmap=exactmap memmap=i#k
only i#k would get recognized.
This is wrong, this fix will only throw away all original e820 areas once
when memmap=exactmap is found in the whole boot command line and before
any other memmap= option is parsed.
Reviewed-by: Thomas Renninger tr...@suse.de
Signed-off
fixes mmconf (extended PCI config access) and
possibly other kernel parts which rely on remapped memory to be
in reserved or ACPI (data/nvs) declared e820 memory areas.
Tested-by: Thomas Renninger tr...@suse.de
Reviewed-by: Thomas Renninger tr...@suse.de
Signed-off-by: Thomas Renninger tr...@suse.de
On Tuesday, January 15, 2013 05:45:43 AM Yinghai Lu wrote:
On Mon, Jan 14, 2013 at 4:54 PM, Thomas Renninger tr...@suse.de wrote:
...
From what I can see the patch looks fine, but above part should
simply be left out.
then, I would like to rename it to resetusablemap instead.
like
this is a clean resend of Yinghai's memmap= extensions.
They were discussed on lkml in a thread with subject:
[PATCH] x86 e820: only void usable memory areas in memmap=exactmap case
The patches are based on origin/x86/mm2 where another memmap=
enhancement from Yinghai is already queued.
Would
On Tuesday, January 22, 2013 04:54:08 PM H. Peter Anvin wrote:
On 01/22/2013 09:20 AM, Thomas Renninger wrote:
From: Yinghai Lu ying...@kernel.org
kdump voided the whole original e820 map and half way made
it up via memmap= options passed via kdump boot params again
101 - 200 of 549 matches
Mail list logo
