Testing shows a problem in that UV5 hubless systems were not being
recognized. Add them to the list of OEM IDs checked.
Fixes: 6c7794423a998 ("Add UV5 direct references")
Signed-off-by: Mike Travis
---
arch/x86/kernel/apic/x2apic_uv_x.c | 13 ++---
1 file changed, 10 insert
Thanks Jiri for catching that.
Acked-By: Mike Travis
On 11/9/2020 1:36 AM, Jiri Slaby wrote:
Commit 39297dde7390 ("x86/platform/uv: Remove UV BAU TLB Shootdown
Handler") removed uv_flush_tlb_others. Its declaration was removed also
from asm/uv/uv.h. But only for the CONFIG_X86
On 9/2/2019 11:49 PM, Christoph Hellwig wrote:
static inline bool is_early_uv_system(void)
{
return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
No need for the inner braces here.
But woudn't this be nicer as:
return efi.uv_systab !=
On 9/3/2019 12:47 AM, Ingo Molnar wrote:
* Mike Travis wrote:
These patches support upcoming UV systems that do not have a UV HUB.
* Save OEM_ID from ACPI MADT probe
* Return UV Hubless System Type
* Add return code to UV BIOS Init function
* Setup UV
On 9/3/2019 8:41 AM, Christoph Hellwig wrote:
On Tue, Sep 03, 2019 at 07:12:28AM -0700, Mike Travis wrote:
+#define is_uv_hubless _is_uv_hubless
Why the weird macro indirection?
-static inline int is_uv_hubless(void) { return 0; }
+static inline int _is_uv_hubless(int uv) { return 0
On 9/3/2019 9:19 AM, Christoph Hellwig wrote:
On Mon, Sep 02, 2019 at 07:18:23PM -0500, Mike Travis wrote:
+#ifdef UV1_HUB_IS_SUPPORTED
All these ifdefs are dead code, please just remove them.
Those ifdefs are not dead code and are being actively used. Plus UV1
support is dead and I
On 9/3/2019 11:58 AM, Mike Travis wrote:
On 9/3/2019 9:19 AM, Christoph Hellwig wrote:
On Mon, Sep 02, 2019 at 07:18:23PM -0500, Mike Travis wrote:
+#ifdef UV1_HUB_IS_SUPPORTED
All these ifdefs are dead code, please just remove them.
Those ifdefs are not dead code and are being
se to tend to them
in the next release cycle. But please let us get through this cycle
without this much chaos?
Thanks,
Mike
On 9/3/2019 11:52 PM, Christoph Hellwig wrote:
On Tue, Sep 03, 2019 at 11:58:49AM -0700, Mike Travis wrote:
Those ifdefs are not dead code and are being actively used.
On 7/9/2019 1:09 PM, Russ Anderson wrote:
On Tue, Jul 09, 2019 at 09:50:27PM +0200, Thomas Gleixner wrote:
On Tue, 2 Jul 2019, Nadav Amit wrote:
SGI UV support is outdated and not maintained, and it is not clear how
it performs relatively to non-UV. Remove the code to simplify the code.
On 7/9/2019 2:09 PM, Nadav Amit wrote:
On Jul 9, 2019, at 1:29 PM, Mike Travis wrote:
On 7/9/2019 1:09 PM, Russ Anderson wrote:
On Tue, Jul 09, 2019 at 09:50:27PM +0200, Thomas Gleixner wrote:
On Tue, 2 Jul 2019, Nadav Amit wrote:
SGI UV support is outdated and not maintained
The UV NMI MMR addresses and fields moved between UV4 and UV5
necessitating a rewrite of the UV NMI handler. Adjust references
to accommodate those changes.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 13
Make modifications to the GAM MMR mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions
The changes in the UV5 arch shrunk the NODE PRESENT table to just 2x64
entries (128 total) so are in to 64 bit MMRs instead of a depth of 64
bits in an array. Adjust references when counting up the nodes present.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
Update check of BIOS TSC sync status to include both possible "invalid"
states provided by newer UV5 BIOS.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h |2 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 24 ++--
2 fil
-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
arch/x86/include/asm/idtentry.h |4
arch/x86/include/asm/uv/uv.h |4
arch/x86/include/asm/uv/uv_bau.h | 755 --
arch/x86/kernel/idt.c|3
arch/x86/mm/tlb.c| 24
arch/x86/platform/uv
There is a symbol clash from the auto-generated uv_mmrs.h file that
clashes with code in the UV kernel modules (is_uv() is the symbol).
Change those prior to the symbol clash so as to not cause a compile error.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
Make modifications to the MMIOH mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 213 +
1 file changed, 144 insertions(+), 69 deletions(-)
--- linux.orig/arch/x86/kernel
UV class systems no longer use System Controller for monitoring of CPU
activity provided by this driver. Other methods have been developed
for BIOS and the management controller (BMC). This patch removes that
supporting code.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
arch
A patch to add and process the UV Arch Type field in the UVsystab passed
from UV BIOS to the kernel. This allows the system to be recognized
without relying on the OEM_ID which OEMs want to change.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86
Add new references to UV5 (and UVY class) system MMR addresses and
fields primarily caused by the expansion from 46 to 52 bits of
physical memory address.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 49
Subject: [PATCH 00/12] x86/platform/uv: Updates for UV5
Add changes needed for new UV5 UV architecture. Chief among the changes
are 52 bits of physical memory address and 57 bits of virtual address space.
0001 Remove UV BAU TLB Shootdown Handler
- removes BAU TLB code being replaced by
Make modifications to the GRU mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 --
1 file changed, 24 insertions(+), 6 deletions
On 9/8/2020 8:44 AM, Greg KH wrote:
On Tue, Sep 08, 2020 at 08:35:37AM -0700, Mike Travis wrote:
On 9/8/2020 8:23 AM, Greg KH wrote:
On Mon, Sep 07, 2020 at 01:54:34PM -0500, Mike Travis wrote:
--- linux.orig/drivers/misc/sgi-gru/grufile.c
+++ linux/drivers/misc/sgi-gru/grufile.c
@@ -7,7
On 9/8/2020 8:47 AM, pet...@infradead.org wrote:
On Tue, Sep 08, 2020 at 08:28:16AM -0700, Mike Travis wrote:
I didn't. If I could figure out how to convert quilt patches into git
commits I might be able to do that? (And I didn't know that diffstats were
needed on the into?)
$ git
On 10/12/2020 2:10 PM, Linus Torvalds wrote:
On Mon, Oct 12, 2020 at 3:10 AM Borislav Petkov wrote:
please pull the x86/platform queue.
Hmm. I didn't immediately notice this new warning, because it only
happens with the clang build that I don't do in between every pull.
But this pull
On 10/12/2020 2:27 PM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:15:55PM -0700, Mike Travis wrote:
Of course, it also looks like that 'uvh_nmi_mmrx_mask' thing is a
write-only variable so it doesn't matter, but can we _please_ get this
code fixed ASAP?
Yes, I'll look at it right
On 10/12/2020 2:42 PM, Mike Travis wrote:
On 10/12/2020 2:27 PM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:15:55PM -0700, Mike Travis wrote:
Of course, it also looks like that 'uvh_nmi_mmrx_mask' thing is a
write-only variable so it doesn't matter, but can we _please_ get
al is better.
Yeah, below is a proper patch which builds fine with gcc and clang-10.
You guys have fun - I'm going to bed. :-)
---
From: Mike Travis
Date: Mon, 12 Oct 2020 23:46:34 +0200
Subject: [PATCH] x86/platform/uv: Correct uvh_nmi_mmrx_mask's type
Clang rightfully warns:
arch/x86/plat
On 10/13/2020 4:11 AM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:58:07PM -0700, Mike Travis wrote:
I was in the process of tracing it through and perhaps it does need a bit
more analysis to be correct. What does it mean to send a patch to fix the
compile error, just remove it?
Yes
On 10/13/2020 6:29 AM, Borislav Petkov wrote:
On Tue, Oct 13, 2020 at 05:33:37AM -0700, Mike Travis wrote:
I'm working on the correct code now, and I have UV4 & UV4A machine time
starting at 7am (PDT) to test it. The UV5 simulator does not yet emulate
console initiated NMI from the
On 10/13/2020 6:37 AM, Mike Travis wrote:
On 10/13/2020 6:29 AM, Borislav Petkov wrote:
On Tue, Oct 13, 2020 at 05:33:37AM -0700, Mike Travis wrote:
I'm working on the correct code now, and I have UV4 & UV4A machine time
starting at 7am (PDT) to test it. The UV5 simulator does not
Remove an unused variable.
Signed-off-by: Mike Travis
---
arch/x86/platform/uv/uv_nmi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index 0f5cbcf0da63..eafc530c8767 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86
AIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86/kernel/head64.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -151,18 +151,16 @@ void __init x86_64_start_kernel(char * r
ady clears allocated memory
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Built and tested: (x86_64) defconfig, nonum, nosmp (*).
Built: (x86_64) all{yes,mod}config,
(i386) defconfig, all{yes,mod}config, nonum, nosmp.
* -
Hi Nick,
Have you done anything more with allowing > 256 CPUS in this spinlock
patch? We've been testing with 1k cpus and to verify with -mm kernel,
we need to "unpatch" these spinlock changes.
Thanks,
Mike
Nick Piggin wrote:
> On Thursday 20 December 2007 18:04, Christoph Lameter wrote:
>>>
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> This patchset simplifies the code that arches need to maintain to
>> support per cpu functionality. Most of the code is moved into arch
>> independent code. Only a minimal set of definitions is kept for each
>> arch.
>>
>
> As your submission did not include an RFC I assume this is expected to be
> the final version.
I have another version coming that includes the changes requested by you
and others.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Ingo Molnar wrote:
> * Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
>> On Tue, 8 Jan 2008, Ingo Molnar wrote:
>>
>>> i had the patch below for v2, it's still needed (because i didnt
>>> apply the s390/etc. bits), right?
>> Well the patch really should go through mm because it is a change that
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> Change the following static arrays sized by NR_CPUS to
>> per_cpu data variables:
>>
>> char cpu_to_node_map[NR_CPUS];
>
> x86.git randconfig testing found the !NUMA build bugs below.
>
> Ingo
Thanks! I'll add
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>>> 32cpus1kcpus-before 1kcpus-after
>>>7172678 Total +23314404 Total -147590 Total
>> 1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
>> reduction of
Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>>> i.e. we've got ~22K bloat per CPU - which is not bad, but because
>>> it's a static component, it hurts smaller boxes. For distributors to
>>> enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
>>> below 1-2K
I'm trying to minimize as much traffic between
node 0 and the other nodes. Apic id AFAICT is used mostly for
sending IPI's, either to cpus within the node or to remote cpus.
Using the remote cpu's node memory to query it's apicid seems
reasonable? And, of course, having all the data about one's
Jan Engelhardt wrote:
> On Jan 13 2008 10:34, [EMAIL PROTECTED] wrote:
>> --- a/arch/x86/kernel/mpparse_64.c
>> +++ b/arch/x86/kernel/mpparse_64.c
>> @@ -132,7 +132,7 @@ static void __cpuinit MP_processor_info(
>> * area is created.
>> */
>> if (x86_cpu_to_apicid_ptr) {
>> -
Jan Engelhardt wrote:
...
>> --- a/arch/x86/mm/srat_64.c
>> +++ b/arch/x86/mm/srat_64.c
>> @@ -384,6 +388,12 @@ int __init acpi_scan_nodes(unsigned long
>> }
>>
>> #ifdef CONFIG_NUMA_EMU
>> +static int fake_node_to_pxm_map[MAX_NUMNODES] __initdata = {
>> +[0 ... MAX_NUMNODES-1] = PXM_INVAL
Jan Engelhardt wrote:
> On Jan 13 2008 10:34, [EMAIL PROTECTED] wrote:
>> +++ b/include/asm-x86/cpu.h
>> @@ -7,7 +7,7 @@
>> #include
>> #include
>>
>> -struct i386_cpu {
>> +struct x86_cpu {
>> struct cpu cpu;
>> };
>> extern int arch_register_cpu(int num);
>
> Is not struct x86_cpu kinda
Mel Gorman wrote:
> On (13/01/08 10:34), [EMAIL PROTECTED] didst pronounce:
...
>> int update_end_of_memory(unsigned long end) {return -1;}
>> @@ -343,7 +346,8 @@ int __init acpi_scan_nodes(unsigned long
>> /* First clean up the node list */
>> for (i = 0; i < MAX_NUMNODES; i++) {
>>
Eric Dumazet wrote:
>
>> --- a/include/asm-x86/mmzone_64.h
>> +++ b/include/asm-x86/mmzone_64.h
>> @@ -15,8 +15,8 @@
>> struct memnode {
>> int shift;
>> unsigned int mapsize;
>> -u8 *map;
>> -u8 embedded_map[64-16];
>> +u16 *map;
>> +u16 embedded_map[64-16];
>
> Must
Andi Kleen wrote:
> [EMAIL PROTECTED] writes:
>> +
>> /* Returns the number of the node containing CPU 'cpu' */
>> static inline int cpu_to_node(int cpu)
>> {
>> -return cpu_to_node_map[cpu];
>> +u16 *cpu_to_node_map = x86_cpu_to_node_map_early_ptr;
>> +
>> +if (cpu_to_node_map)
>>
Eric Dumazet wrote:
> On Wed, 16 Jan 2008 09:09:04 -0800
> [EMAIL PROTECTED] wrote:
>
>> Change the size of node ids from 8 bits to 16 bits to
>> accomodate more than 256 nodes.
>>
>> Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
>> Reviewed-by: Chris
Frans Pop wrote:
> [EMAIL PROTECTED] wrote:
>>8472457 Total 30486950 +259% 30342823 +258%
>
> Hmmm. The table for previous versions looked a lot more impressive.
>
> now:8472457 Total +22014493 +259% +21870366 +258%
> V2 :7172678 Total+23314404 +325%
>
> Another point: you want this change, sorry if my previous mail was not
> detailed enough :
>
> --- a/arch/x86/mm/numa_64.c
> +++ b/arch/x86/mm/numa_64.c
> @@ -78,7 +78,7 @@ static int __init allocate_cachealigned_memnodemap(void)
> unsigned long pad, pad_addr;
>
> memnodemap =
Andrew Morton wrote:
> On Wed, 16 Jan 2008 10:34:39 -0800 [EMAIL PROTECTED] wrote:
>
>> This patch removes the EXPORT_SYMBOL for:
>>
>> x86_cpu_to_node_map_init
>> x86_cpu_to_node_map_early_ptr
>>
>> ... thus fixing the section mismatch problem.
>
> Which section mismatch problem?
gt;
> Based on 2.6.24-rc8-mm1
>
> Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
> Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]>
> ---
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
endent
> code. Only a minimal set of definitions is kept for each arch.
>
> The patch also unifies the x86 arch so that there is only a single
> asm-x86/percpu.h
>
> Based on: 2.6.24-rc8-mm1
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> Signe
Sam Ravnborg wrote:
> Hi Mike.
>
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -20,6 +20,7 @@ config X86
>> def_bool y
>> select HAVE_OPROFILE
>> select HAVE_KPROBES
>> +select HAVE_SETUP_PER_CPU_AREA if ARCH = "x86_64"
>
> It is simpler to just say:
>> +select
Sam Ravnborg wrote:
> Hi Mike.
>
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -20,6 +20,7 @@ config X86
>> def_bool y
>> select HAVE_OPROFILE
>> select HAVE_KPROBES
>> +select HAVE_SETUP_PER_CPU_AREA if ARCH = "x86_64"
>
> It is simpler to just say:
>> +select
o know what they are
>> doing there :).
>
> yes, Mike Travis has i think some patches in the works for this build
> problem. Disabling NUMA on 32-bit is the solution meanwhile.
>
> Ingo
I have the fix for this problem coming...
Thanks,
Mike
--
To unsubscribe from
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>>>> +config THREAD_ORDER
>>>> + int "Kernel stack size (in page order)"
>>>> + range 1 3
>>>> + depends on X86_64_SMP
>>>> + default "3
Andi Kleen wrote:
> First I think you have to get rid of the THREAD_ORDER stuff -- your
> goal of the whole patchkit after all is to allow distributions to
> support NR_CPUS==4096 in the standard kernels and I doubt any
> distribution will over chose a THREAD_ORDER > 1 in their
> standard kernels
Ingo Oeser wrote:
> Hi Mike,
>
> On Friday 18 January 2008, [EMAIL PROTECTED] wrote:
>> +config THREAD_ORDER
>> +int "Kernel stack size (in page order)"
>> +range 1 3
>> +depends on X86_64_SMP
>> +default "3" if X86_SMP_MAX
>> +default "1"
>> +help
>> + Increases
Jan Engelhardt wrote:
> On Jan 18 2008 10:30, [EMAIL PROTECTED] wrote:
>> --- a/include/linux/numa.h
>> +++ b/include/linux/numa.h
>> @@ -10,4 +10,10 @@
>>
>> #define MAX_NUMNODES(1 << NODES_SHIFT)
>>
>> +#if MAX_NUMNODES > 256
>> +typedef u16 numanode_t;
>> +#else
>> +typedef u8 numanode_t;
Andi Kleen wrote:
> On Friday 18 January 2008 19:30:16 [EMAIL PROTECTED] wrote:
>> Provide a means to trap usages of per_cpu map variables before
>> they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate.
>
> Are you sure that debug option is generally useful enough
> to merge? It seems
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>> Hi Andrew,
>>
>> My automatic scripts accidentally sent this mail prematurely. Please
>> hold off applying yet.
>
> I've picked it up for x86.git and i'll keep testing it (the patche
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> This patchset simplifies the code that arches need to maintain to
>> support per cpu functionality. Most of the code is moved into arch
>> independent code. Only a minimal set of definitions is kept for each
>> arch.
>>
David Rientjes wrote:
> On Fri, 18 Jan 2008, Yinghai Lu wrote:
>
>>> +#if MAX_NUMNODES > 256
>>> +typedef u16 numanode_t;
>>> +#else
>>> +typedef u8 numanode_t;
>>> +#endif
>>> +
>>> #endif /* _LINUX_NUMA_H */
>> that is wrong, you can not change pxm_to_node_map from int to u8 or u16.
>>
Thanks
HREAD_ORDER: max limit now 3
>> X86_SMP_MAX: say Y to enable possible cpus == NR_CPUS
>>
>> Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
>
> i've bisected a boot failure down to this patch (sans the THREAD_ORDER
> bits): it causes an instant reboot of the
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0
Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> One of my test systems didn't boot with latest git-x86. I bisected it
>> down to f1321f875910172bcc3e1f302fe145a9e4d3bdf7
>>
>> With later patches the fault seemed to happen even earlier before
>> other initialization messages.
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0
David Rientjes wrote:
> On Sat, 19 Jan 2008, Mike Travis wrote:
>
>>> Yeah, NID_INVAL is negative so no unsigned type will work here,
>>> unfortunately. And that reduces the intended savings of your change since
>>> the smaller type can only be used
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> and then it crashes with:
>>
>> [0.00] Bootmem setup node 0 -3fff
>> [0.00] KERN_NOTICE cpu_to_node(0): usage too early!
>> PANIC: early exception 06 rip 10:81f77f30 error 0
arch files.
>>
>> Cc: Rusty Russell <[EMAIL PROTECTED]>
>> Cc: Andi Kleen <[EMAIL PROTECTED]>
>> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>> Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
>
> This doesn't build on sparc64.
>
86
>>
>> Note there are two versions of this patchset:
>> - 2.6.24-rc8-mm1
>> - 2.6.24-rc8-mm1 + latest (08/1/21) git-x86
>
> thanks, applied.
>
>> Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
>> ---
>> Fixup-V2:
>> - pulled the
Yinghai Lu wrote:
> [PATCH] x86_64: remove duplicated line about x86_bios_cpu_apicid_early_ptr
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
> index 2643a8f..b587166 100644
> --- a/arch/x86/kernel/setup_64.c
> +++
Yinghai Lu wrote:
> [PATCH] x86_64: should use array directly for early_ptr
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> --- a/arch/x86/kernel/setup_64.c 2008-01-23 01:21:06.0 -0800
> +++ b/arch/x86/kernel/setup_64.c 2008-01-23 01:21:24.0 -0800
> @@ -344,10
Mike Travis wrote:
> Yinghai Lu wrote:
>> [PATCH] x86_64: remove duplicated line about x86_bios_cpu_apicid_early_ptr
>>
>> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>>
>> diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
>> in
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> +config THREAD_ORDER
>> +int "Kernel stack size (in page order)"
>> +range 1 3
>> +depends on X86_64
>> +default "3" if X86_SMP
>> +default "1"
>> +help
>> + Increases kernel stack size.
>
> you
"fixup" patch for changes in -mm but not in x86.git (attached).
I'll try out your config next.
Thanks,
Mike
Subject: x86: fixes conflict between -mm and x86.git
Ingo - you can apply this to x86.git after the other zero-based
changes to fix a build problem.
Thanks,
Mike
Signe
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>>> tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
>>> with the attached .config.
>> The build error was fixed with the note I sent to you yesterday with a
>> "
Ingo Molnar wrote:
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>> Ingo.
>>
>> commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another
>> patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86:
>> fixup cpu_info array conversion) already removed clearing of
>>
Ingo Molnar wrote:
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>> Ingo.
>>
>> commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9 is not needed. another
>> patch (by you !! commit 699d934d5f958d7944d195c03c334f28cc0b3669 x86:
>> fixup cpu_info array conversion) already removed clearing of
>>
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>>>> by revert commit fbdcf18df73758b2e187ab94678b30cd5f6ff9f9, we could
>>>> use c->cpu_index in identify_cpu.
>>> but that's 2.6.25 stuff, right? Travis?
>>>
>> Looki
Andi Kleen wrote:
> On Friday 28 December 2007 01:10:51 [EMAIL PROTECTED] wrote:
>> x86_64 provides an optimized way to determine the local per cpu area
>> offset through the pda and determines the base by accessing a remote
>> pda.
>
> And? The rationale for this patch seems to be incomplete.
>
>
Andi Kleen wrote:
> On Friday 28 December 2007 23:05:05 Mike Travis wrote:
>> Andi Kleen wrote:
>>> On Friday 28 December 2007 01:10:51 [EMAIL PROTECTED] wrote:
>>>> x86_64 provides an optimized way to determine the local per cpu area
>>>> offs
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>>> Also for such changes .text size comparisons before/after are a good
>>> idea.
>> x86_64-defconfig:
>>
>> pre-percpu post-percpu
>>
Mike Travis wrote:
> Ingo Molnar wrote:
>> * Mike Travis <[EMAIL PROTECTED]> wrote:
>>
>>>> Also for such changes .text size comparisons before/after are a good
>>>> idea.
>>> x86_64-defconfig:
>>>
>>> pre
Ingo Molnar wrote:
...
>
> tried it on x86.git and 1/3 did not build and 2/3 causes a boot hang
> with the attached .config.
>
> Ingo
>
I've tracked down the failure to an early printk that when CONFIG_PRINTK_TIME
is enabled, any early printks cause cpu_clock to be called, which
4dbf2038f4d
>> Parent: 3212bff370c2f22e4987c6679ba485654cefb178
>> Author: Mike Travis <[EMAIL PROTECTED]>
>> AuthorDate: Wed Jan 30 13:33:32 2008 +0100
>> Committer: Ingo Molnar <[EMAIL PROTECTED]>
>> CommitDate: Wed Jan 30 13:33:32 2008 +0100
he length of the per cpu area
>
> * Removes the &__per_cpu_x in lockdep. The __per_cpu_x are already
> pointers. There is no need to take the address.
>
> * Changes generic setup_per_cpu_areas to allocate per_cpu space in
> node local memory. This requires a gener
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> Powerpc has a way to determine the address of the per cpu area of the
>> currently executing processor via the paca and the array of per cpu
>> offsets is avoided by looking up the per cpu area from the remote
>> paca's
Luck, Tony wrote:
>> Could you check the patch below? With this applied to latest -git, ia64
>> buils fine for me in a cross-compiling environment. (but i dont know
>> whether it boots ...)
>
> Uni-processor build still fails with this patch (config is
> arch/ia64/configs/tiger_defconfig
>
Luck, Tony wrote:
>> Could you check the patch below? With this applied to latest -git, ia64
>> buils fine for me in a cross-compiling environment. (but i dont know
>> whether it boots ...)
>
> Uni-processor build still fails with this patch (config is
> arch/ia64/configs/tiger_defconfig
>
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> Change:
>> config ARCH_SETS_UP_PER_CPU_AREA
>> to:
>> config HAVE_SETUP_PER_CPU_AREA
>
> undocumented change:
>
>> config ARCH_NO_VIRT_TO_BUS
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -380,6 +380,8 @@
CTED]>
Cc: [EMAIL PROTECTED]
Cc: Philippe Elie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
(1 - if modules enabled, does not complete boot even
without this patch)
x86_64 configs built and booted:
ingo-stress-test(1)
defco
Change cpufreq tables from arrays to per_cpu variables in
drivers/acpi/processor_thermal.c
Based on linux-2.6.git + x86.git
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/acpi/processor_thermal.c | 21 +++-
Removal of trivial comments in processor.h
Based on linux-2.6.git + x86.git
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h |4
1 file changed, 4 deletions(-)
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -302,10 +302,6 @@
Change cpu frequency tables from arrays to per_cpu variables.
Based on linux-2.6.git + x86.git
Cc: Dave Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/cpufreq/cpufreq_userspace.c | 71 +++-
Change cpu_buffer from array to per_cpu variable in
oprofile functions.
Based on linux-2.6.git + x86.git
Cc: Philippe Elie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
drivers/oprofile/buffer_sync.c|2 +-
drivers/oprofile/
Dave Jones wrote:
> On Fri, Feb 08, 2008 at 03:37:39PM -0800, Mike Travis wrote:
> > Change cpu frequency tables from arrays to per_cpu variables.
> >
> > Based on linux-2.6.git + x86.git
>
> Looks ok to me. Would you like me to push this though cpufreq.git,
Thanks Hugh for catching this. I've added it to my test code base
and it works fine for x86_64...
Reviewed-by: Mike Travis <[EMAIL PROTECTED]>
Hugh Dickins wrote:
> Recent percpu changes have broken CONFIG_DEBUG_PREEMPT's per_cpu checking
> on several architectures. On s390, spa
901 - 1000 of 1167 matches
Mail list logo
