From: Dimitri Sivanich <sivan...@sgi.com>
This patch fixes the problem of incorrect nodes and pnodes being returned when
referring to nodes that either have no cpus (AKA "headless") or no memory.
Signed-off-by: Dimitri Sivanich <sivan...@sgi.com>
Signed-off-by: Mike
An aspect of the UV4 system architecture changes involve changing the
way sockets, nodes, and pnodes are translated between one another.
Decode the information from the BIOS provided EFI system table to build
the needed conversion tables.
Signed-off-by: Mike Travis <tra...@sgi.com>
Re
definition.
This allows calling source code to be built for both pre-UV4 kernels as
well as post-UV4 kernels.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/uv_hub.h | 10 --
arch/x86/kernel/apic
From: Dimitri Sivanich
This patch fixes the problem of incorrect nodes and pnodes being returned when
referring to nodes that either have no cpus (AKA "headless") or no memory.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
Tested-by: John Estabrook
Tested-by: Gar
An aspect of the UV4 system architecture changes involve changing the
way sockets, nodes, and pnodes are translated between one another.
Decode the information from the BIOS provided EFI system table to build
the needed conversion tables.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
V
BIOS via the EFI UVsystab table. Support for older EFI UVsystab tables
is maintained.
Signed-off-by: Mike Travis <tra...@sgi.com>
Tested-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com>
---
arch
Since UV3 and UV4 MMIOH regions are setup the same, we can use a common
function to setup both.
Signed-off-by: Mike Travis <tra...@sgi.com>
Reviewed-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com&
Add UV4 specific defines to determine if current system type is a UV4 system.
Signed-off-by: Mike Travis <tra...@sgi.com>
Reviewed-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com>
---
arch/x86/k
V
BIOS via the EFI UVsystab table. Support for older EFI UVsystab tables
is maintained.
Signed-off-by: Mike Travis
Tested-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/bios.h | 59 ++--
arch/x86/p
Since UV3 and UV4 MMIOH regions are setup the same, we can use a common
function to setup both.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/kernel/apic/x2apic_uv_x.c |3 ++-
1 file changed, 2 insertions(+), 1
Add UV4 specific defines to determine if current system type is a UV4 system.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/kernel/apic/x2apic_uv_x.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions
Clean up any redundancies caused by new UV4 MMR definitions superseding
any previously definitions local to functions.
Signed-off-by: Mike Travis <tra...@sgi.com>
Reviewed-by: Dimitri Sivanich <sivan...@sgi.com>
Reviewed-by: Andrew Banman <aban...@sgi.com>
Tested-by: John
Clean up any redundancies caused by new UV4 MMR definitions superseding
any previously definitions local to functions.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Andrew Banman
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/uv_hub.h
to measure execution time.
Signed-off-by: Mike Travis <tra...@sgi.com>
Tested-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com>
---
arch/x86/include/asm/uv/uv_hub.h | 131 +++
With the UV4 system architecture addressing changes, BIOS now provides
this information via an EFI system table. This is the initial decoding
of that system table. It also collects the sizing information for
later allocation of dynamic conversion tables.
Signed-off-by: Mike Travis <
Change the references to the SCIR fields to the new per cpu info structs.
Signed-off-by: Mike Travis <tra...@sgi.com>
Reviewed-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com>
---
arch/x86
to measure execution time.
Signed-off-by: Mike Travis
Tested-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/uv_hub.h | 131 -
arch/x86/kernel/apic/x2apic_uv_x.c | 96 ++-
2 files
With the UV4 system architecture addressing changes, BIOS now provides
this information via an EFI system table. This is the initial decoding
of that system table. It also collects the sizing information for
later allocation of dynamic conversion tables.
Signed-off-by: Mike Travis
Reviewed
Change the references to the SCIR fields to the new per cpu info structs.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/uv_hub.h | 17 ++---
arch/x86/kernel/apic/x2apic_uv_x.c | 18
overlay addresses and NMI definitions to
allow for flexibility in newer UV architecture types.
Signed-off-by: Mike Travis <tra...@sgi.com>
Reviewed-by: Dimitri Sivanich <sivan...@sgi.com>
Tested-by: John Estabrook <estabr...@sgi.com>
Tested-by: Gary Kroening <g...@sgi.com>
-
overlay addresses and NMI definitions to
allow for flexibility in newer UV architecture types.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Tested-by: John Estabrook
Tested-by: Gary Kroening
---
arch/x86/include/asm/uv/uv_hub.h |5
arch/x86/kernel/apic/x2apic_uv_x.c | 208
On 6/23/2015 2:01 AM, Ingo Molnar wrote:
>
> * Mike Travis wrote:
>
>> <<<
>> We have a large university system in the UK that is experiencing
>> very long delays modprobing the driver for a specific I/O device.
>> The delay is from 8-10 m
On 6/23/2015 2:01 AM, Ingo Molnar wrote:
* Mike Travis tra...@sgi.com wrote:
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
On 6/22/2015 10:23 AM, Toshi Kani wrote:
> On Mon, 2015-06-22 at 09:21 -0700, Mike Travis wrote:
>>
>> On 6/19/2015 2:44 PM, Toshi Kani wrote:
>>> __ioremap_caller() calls region_is_ram() to look up the resource
>>> to check if a target range is RAM, which wa
On 6/19/2015 2:44 PM, Toshi Kani wrote:
> __ioremap_caller() calls region_is_ram() to look up the resource
> to check if a target range is RAM, which was added as an additinal
> check to improve the lookup performance over page_is_ram() (commit
> 906e36c5c717 "x86: use optimized ioresource
On 6/19/2015 2:44 PM, Toshi Kani wrote:
__ioremap_caller() calls region_is_ram() to look up the resource
to check if a target range is RAM, which was added as an additinal
check to improve the lookup performance over page_is_ram() (commit
906e36c5c717 x86: use optimized ioresource lookup in
On 6/22/2015 10:23 AM, Toshi Kani wrote:
On Mon, 2015-06-22 at 09:21 -0700, Mike Travis wrote:
On 6/19/2015 2:44 PM, Toshi Kani wrote:
__ioremap_caller() calls region_is_ram() to look up the resource
to check if a target range is RAM, which was added as an additinal
check to improve
On 5/1/2015 12:27 AM, Ingo Molnar wrote:
>
> * George Beshers wrote:
>
>> UV: NMI: simple dump failover if kdump fails
>>
>> The ability to trigger a kdump using the system NMI command
>> was added by
>>
>> commit 12ba6c990fab50fe568f3a
On 5/1/2015 12:27 AM, Ingo Molnar wrote:
* George Beshers gbesh...@sgi.com wrote:
UV: NMI: simple dump failover if kdump fails
The ability to trigger a kdump using the system NMI command
was added by
commit 12ba6c990fab50fe568f3ad8715e81e356552428
Author: Mike Travis tra
.
Signed-off-by: Mike Travis
Acked-by: Hedi Berriche
Acked-by: Dimitri Sivanich
---
arch/x86/kernel/apic/x2apic_uv_x.c | 74 -
1 file changed, 49 insertions(+), 25 deletions(-)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic
Optimize the first "SGI" OEM check to return faster if the system is
not an SGI or UV system.
Signed-off-by: Mike Travis
Acked-by: Hedi Berriche
Acked-by: Dimitri Sivanich
---
arch/x86/kernel/apic/x2apic_uv_x.c |3 +++
1 file changed, 3 insertions(+)
--- linux.orig/arch/x86/k
In preparation for new UV systems, update various APIC checks
to prevent incompatible hardware/BIOS/kernel conflicts.
--
--
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
Update check for UV2000/3000. Note when HUB is not recognized.
Signed-off-by: Mike Travis
Acked-by: Hedi Berriche
Acked-by: Dimitri Sivanich
---
arch/x86/kernel/apic/x2apic_uv_x.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- linux.orig/arch/x86/kernel/apic
Optimize the first SGI OEM check to return faster if the system is
not an SGI or UV system.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Hedi Berriche h...@sgi.com
Acked-by: Dimitri Sivanich sivan...@sgi.com
---
arch/x86/kernel/apic/x2apic_uv_x.c |3 +++
1 file changed, 3 insertions
Update check for UV2000/3000. Note when HUB is not recognized.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Hedi Berriche h...@sgi.com
Acked-by: Dimitri Sivanich sivan...@sgi.com
---
arch/x86/kernel/apic/x2apic_uv_x.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions
In preparation for new UV systems, update various APIC checks
to prevent incompatible hardware/BIOS/kernel conflicts.
--
--
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
.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Hedi Berriche h...@sgi.com
Acked-by: Dimitri Sivanich sivan...@sgi.com
---
arch/x86/kernel/apic/x2apic_uv_x.c | 74 -
1 file changed, 49 insertions(+), 25 deletions(-)
--- linux.orig/arch/x86/kernel/apic
On 3/23/2015 11:32 PM, Ingo Molnar wrote:
>
> * Mike Travis wrote:
>
>> Fix a bug in the oem check function that determines if the system
>> is a UV system and the BIOS is compatible with the kernel's UV apic
>> driver. This prevents some possibly obscure pani
On 3/23/2015 11:32 PM, Ingo Molnar wrote:
* Mike Travis tra...@sgi.com wrote:
Fix a bug in the oem check function that determines if the system
is a UV system and the BIOS is compatible with the kernel's UV apic
driver. This prevents some possibly obscure panics and guards the
system
. Also add update for new UV3000 system.
The first "OEM" check was also optimized to return faster if the
system is not an SGI or UV system.
Signed-off-by: Mike Travis
Acked-by: Hedi Berriche
Acked-by: Dimitri Sivanich
---
arch/x86/kernel/apic/x2apic_uv_
. Also add update for new UV3000 system.
The first OEM check was also optimized to return faster if the
system is not an SGI or UV system.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Hedi Berriche h...@sgi.com
Acked-by: Dimitri Sivanich sivan...@sgi.com
---
arch/x86/kernel/apic/x2apic_uv_x.c
On 8/29/2014 1:16 PM, Andrew Morton wrote:
> On Fri, 29 Aug 2014 14:53:28 -0500 Mike Travis wrote:
>
>>
>> We have a large university system in the UK that is experiencing
>> very long delays modprobing the driver for a specific I/O device.
>> The delay i
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
s aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
Cc:
---
v2: slight rearrangement of code
v3: added Cc: stable
---
arch/x86/mm/ioremap.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
--- li
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
Cc:
---
v2: remove 'weak
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
v2: remove 'weak' and EXPORT_SYMBOL_GPL
s aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
v2: slight rearrangement of code
---
arch/x86/mm/ioremap.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
--- linux.orig/arch/x86/mm/iore
operation continues.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
---
v2: slight rearrangement of code
---
arch/x86/mm/ioremap.c | 20
1 file changed, 16 insertions(+), 4 deletions
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
operation continues.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
Cc: sta...@vger.kernel.org
---
v2: slight rearrangement of code
v3: added Cc: stable
---
arch/x86/mm/ioremap.c | 20
1 file changed
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
On 8/29/2014 1:16 PM, Andrew Morton wrote:
On Fri, 29 Aug 2014 14:53:28 -0500 Mike Travis tra...@sgi.com wrote:
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device
On 8/27/2014 4:37 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis wrote:
>
>>>
>>>
>>>
>>> Doing strcmp("System RAM") is rather a hack. Is there nothing in
>>> resource.flags which can be used? Or adde
On 8/27/2014 4:20 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:15:28 -0700 Mike Travis wrote:
>
>>
>>>
>>>> There are two causes for requiring a restart/reload of the drivers.
>>>> First is periodic preventive maintenance (PM) and the se
On 8/27/2014 4:18 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis wrote:
>
>>
>>>>
>>>> ...
>>>>
>>>> --- linux.orig/kernel/resource.c
>>>> +++ linux/kernel/resource.c
>>>> @@ -494,6
On 8/27/2014 4:06 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 17:59:27 -0500 Mike Travis wrote:
>
>>
>> We have a large university system in the UK that is experiencing
>> very long delays modprobing the driver for a specific I/O device.
>> The delay i
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
On 8/27/2014 4:05 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis wrote:
>
>> Since the ioremap operation is verifying that the specified address range
>> is NOT RAM, it will search the entire ioresource list if the condition
>> is true
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
include/linux/mm.h |1 +
kernel
s aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis
Acked-by: Alex Thorlton
Reviewed-by: Cliff Wickman
---
arch/x86/mm/ioremap.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux/arch/x86/mm/iore
operation continues.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
---
arch/x86/mm/ioremap.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux
result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis tra...@sgi.com
Acked-by: Alex Thorlton athorl...@sgi.com
Reviewed-by: Cliff Wickman c...@sgi.com
On 8/27/2014 4:05 PM, Andrew Morton wrote:
On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis tra...@sgi.com wrote:
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition
is true. To make matters worse
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on
On 8/27/2014 4:06 PM, Andrew Morton wrote:
On Wed, 27 Aug 2014 17:59:27 -0500 Mike Travis tra...@sgi.com wrote:
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device
On 8/27/2014 4:18 PM, Andrew Morton wrote:
On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis tra...@sgi.com wrote:
...
--- linux.orig/kernel/resource.c
+++ linux/kernel/resource.c
@@ -494,6 +494,43 @@ int __weak page_is_ram(unsigned long pfn
}
EXPORT_SYMBOL_GPL(page_is_ram
On 8/27/2014 4:20 PM, Andrew Morton wrote:
On Wed, 27 Aug 2014 16:15:28 -0700 Mike Travis tra...@sgi.com wrote:
There are two causes for requiring a restart/reload of the drivers.
First is periodic preventive maintenance (PM) and the second is if
any of the devices experience a fatal
On 8/27/2014 4:37 PM, Andrew Morton wrote:
On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis tra...@sgi.com wrote:
looks at the code
Doing strcmp(System RAM) is rather a hack. Is there nothing in
resource.flags which can be used? Or added otherwise?
I agree except this mimics
On 3/5/2014 1:57 PM, Christoph Lameter wrote:
> The driver seems to use local64_t to define a single static instance of a
> counter and then seems to think that it is safe to increment the counter
> from multiple processors using local64_inc and friends. Common
> misunderstanding and a reason
On 3/5/2014 1:57 PM, Christoph Lameter wrote:
The driver seems to use local64_t to define a single static instance of a
counter and then seems to think that it is safe to increment the counter
from multiple processors using local64_inc and friends. Common
misunderstanding and a reason why I
Commit-ID: fc8b13740b2978b34872650cc8e928392e3758aa
Gitweb: http://git.kernel.org/tip/fc8b13740b2978b34872650cc8e928392e3758aa
Author: Mike Travis
AuthorDate: Tue, 14 Jan 2014 10:25:52 -0600
Committer: Ingo Molnar
CommitDate: Sat, 25 Jan 2014 08:55:09 +0100
kgdb/kdb: Fix no KDB config
Commit-ID: 74c93f9d39b556ff9ac2340d568ad5caf8446c65
Gitweb: http://git.kernel.org/tip/74c93f9d39b556ff9ac2340d568ad5caf8446c65
Author: Mike Travis
AuthorDate: Tue, 14 Jan 2014 10:25:53 -0600
Committer: Ingo Molnar
CommitDate: Sat, 25 Jan 2014 08:55:10 +0100
x86/uv/nmi: Fix Sparse
Commit-ID: 64389998151214c71ba59ac893180744fd880052
Gitweb: http://git.kernel.org/tip/64389998151214c71ba59ac893180744fd880052
Author: Mike Travis
AuthorDate: Tue, 14 Jan 2014 10:25:54 -0600
Committer: Ingo Molnar
CommitDate: Sat, 25 Jan 2014 08:55:11 +0100
x86/uv/nmi, kgdb/kdb: Fix
Commit-ID: 74c93f9d39b556ff9ac2340d568ad5caf8446c65
Gitweb: http://git.kernel.org/tip/74c93f9d39b556ff9ac2340d568ad5caf8446c65
Author: Mike Travis tra...@sgi.com
AuthorDate: Tue, 14 Jan 2014 10:25:53 -0600
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sat, 25 Jan 2014 08:55:10
Commit-ID: 64389998151214c71ba59ac893180744fd880052
Gitweb: http://git.kernel.org/tip/64389998151214c71ba59ac893180744fd880052
Author: Mike Travis tra...@sgi.com
AuthorDate: Tue, 14 Jan 2014 10:25:54 -0600
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sat, 25 Jan 2014 08:55:11
Commit-ID: fc8b13740b2978b34872650cc8e928392e3758aa
Gitweb: http://git.kernel.org/tip/fc8b13740b2978b34872650cc8e928392e3758aa
Author: Mike Travis tra...@sgi.com
AuthorDate: Tue, 14 Jan 2014 10:25:52 -0600
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sat, 25 Jan 2014 08:55:09
v2: Update patch 2/3 to include which problems fixed. Other minor
changes detailed in the patches.
* 1/3: Change the fix for 'KDB not defined' build problem by changing
the kgdb_nmicallin() interface to include the KDB specific reason code.
This removes the dependency on KDB in the debug
' then an error message is displayed if KDB is not configured.
Also note that if both KGDB and KDB are enabled, then the action of 'kgdb'
or 'kdb' has no affect on which is used. See the KGDB documentation for
further information.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
v2
Make uv_register_nmi_notifier() and uv_handle_nmi_ping() static to
address sparse warnings.
Fix problem where uv_nmi_kexec_failed is unused when CONFIG_KEXEC
is not defined.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
v2: update the description to include problems fixed
Some code added to the debug_core module had KDB dependencies that it
shouldn't have. Move the KDB dependent REASON back to the caller to
remove the dependency in the debug core code.
Update the call from the UV NMI handler to conform to the new interface.
Signed-off-by: Mike Travis
Reviewed
On 1/14/2014 3:00 AM, Peter Zijlstra wrote:
> On Mon, Jan 13, 2014 at 10:24:09PM -0600, Mike Travis wrote:
>> Fix some problems found by the kbuild test robot.
>>
>> Signed-off-by: Mike Travis
>> Reviewed-by: Hedi Berriche
>
> In general it is best to actu
On 1/14/2014 3:00 AM, Peter Zijlstra wrote:
On Mon, Jan 13, 2014 at 10:24:09PM -0600, Mike Travis wrote:
Fix some problems found by the kbuild test robot.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi Berriche h...@sgi.com
In general it is best to actually mention
Some code added to the debug_core module had KDB dependencies that it
shouldn't have. Move the KDB dependent REASON back to the caller to
remove the dependency in the debug core code.
Update the call from the UV NMI handler to conform to the new interface.
Signed-off-by: Mike Travis tra
' then an error message is displayed if KDB is not configured.
Also note that if both KGDB and KDB are enabled, then the action of 'kgdb'
or 'kdb' has no affect on which is used. See the KGDB documentation for
further information.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi
Make uv_register_nmi_notifier() and uv_handle_nmi_ping() static to
address sparse warnings.
Fix problem where uv_nmi_kexec_failed is unused when CONFIG_KEXEC
is not defined.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi Berriche h...@sgi.com
---
v2: update the description
v2: Update patch 2/3 to include which problems fixed. Other minor
changes detailed in the patches.
* 1/3: Change the fix for 'KDB not defined' build problem by changing
the kgdb_nmicallin() interface to include the KDB specific reason code.
This removes the dependency on KDB in the debug
* Change the fix for 'KDB not defined' build problem by changing
the kgdb_nmicallin() interface to include the KDB specific
reason code. This removes the dependency on KDB in the debug
core. It also requires a change to the kgdb call in from UV
NMI handler to avoid a compile error.
*
Fix some problems found by the kbuild test robot.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86/include/asm/uv/uv.h |2 --
arch/x86/kernel/apic/x2apic_uv_x.c |1 -
arch/x86/platform/uv/uv_nmi.c |9 -
3 files changed, 4 insertions(+), 8
' then an error message is displayed if KDB is not configured.
Note that if both KGDB and KDB are enabled, then the action of 'kgdb' or
'kdb' has no affect on which is used. See the KGDB documention for further
information.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86
Some code added to the debug_core module had KDB dependencies that it
shouldn't have. Move the KDB dependent REASON back to the caller to
remove the dependency in the debug core code.
Signed-off-by: Mike Travis
Reviewed-by: Hedi Berriche
---
arch/x86/platform/uv/uv_nmi.c |2 +-
include
On 10/19/2013 1:56 AM, Ingo Molnar wrote:
>
> * Mike Travis wrote:
>
>>
>> * Change the fix for KDB not defined build problem by changing
>> the kgdb_nmicallin() interface to include the KDB specific
>> reason code. This removes a dependency on KDB in th
On 10/19/2013 1:56 AM, Ingo Molnar wrote:
* Mike Travis tra...@sgi.com wrote:
* Change the fix for KDB not defined build problem by changing
the kgdb_nmicallin() interface to include the KDB specific
reason code. This removes a dependency on KDB in the debug
core. Also requires
' then an error message is displayed if KDB is not configured.
Note that if both KGDB and KDB are enabled, then the action of 'kgdb' or
'kdb' has no affect on which is used. See the KGDB documention for further
information.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi Berriche h
Some code added to the debug_core module had KDB dependencies that it
shouldn't have. Move the KDB dependent REASON back to the caller to
remove the dependency in the debug core code.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi Berriche h...@sgi.com
---
arch/x86/platform/uv
* Change the fix for 'KDB not defined' build problem by changing
the kgdb_nmicallin() interface to include the KDB specific
reason code. This removes the dependency on KDB in the debug
core. It also requires a change to the kgdb call in from UV
NMI handler to avoid a compile error.
*
Fix some problems found by the kbuild test robot.
Signed-off-by: Mike Travis tra...@sgi.com
Reviewed-by: Hedi Berriche h...@sgi.com
---
arch/x86/include/asm/uv/uv.h |2 --
arch/x86/kernel/apic/x2apic_uv_x.c |1 -
arch/x86/platform/uv/uv_nmi.c |9 -
3 files changed
On 11/11/2013 10:53 AM, Ingo Molnar wrote:
>
> * tip-bot for Mike Travis wrote:
>
>> Commit-ID: 8eba18428ac926f436064ac281e76d36d51bd631
>> Gitweb:
>> http://git.kernel.org/tip/8eba18428ac926f436064ac281e76d36d51bd631
>> Author: Mike Travis
>>
601 - 700 of 1167 matches
Mail list logo
