Commits · 113b500bbbe98c030047a667169135a915c274f3 · Kirill Smelkov / linux

08 Mar, 2005 40 commits

[PATCH] x86: clean up FIXME in do_timer_interrupt · 113b500b

Lee Revell authored Mar 07, 2005

Clean up the logic in do_timer_interrupt()
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

113b500b

[PATCH] cpuid takes unsigned arguments · 18ecb768

Rik van Riel authored Mar 07, 2005

Because Xen is compiled with -Wall -Werror, has inherited processor.h from
Linux and Fedora is now built with gcc4, I discovered this bug.

The few callers I verified all call cpuid with unsigned ints, but the
function is defined with signed ints.  This trivial patch fixes that.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

18ecb768

[PATCH] i386: C99 initializers for hw_interrupt_type structures · 17ee4446

Thomas Gleixner authored Mar 07, 2005

Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

17ee4446

[PATCH] make highmem_start access only valid addresses (i386) · 0cc880d1

Dave Hansen authored Mar 07, 2005

When CONFIG_HIGHMEM=y, but ZONE_NORMAL isn't quite full, there is, of
course, no actual memory at *high_memory.  This isn't a problem with normal
virt<->phys translations because it's never dereferenced, but
CONFIG_NONLINEAR is a bit more finicky.  So, don't do __va() in
non-existent addresses.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

0cc880d1

[PATCH] Support for GEODE CPUs · 8a59ebd4

kianusch@sk-tech.net authored Mar 07, 2005

Those CPU's are found mostly in embedded systems ...  one of the most
prominent Hardware using GEODE CPU is probably soekris net4801
(http://www.soekris.com).

This patch has been on my homepage
(http://www.sk-tech.net/support/soekris.html) for quite a time - but I've
been asked several time to have it included in the main kernel.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

8a59ebd4

[PATCH] x86: iounmap() isa special case · bf9c6f42

Andrew Morton authored Mar 07, 2005

ioremap() has special-case handling for the IS region, but inunmap() does not.
 So iounmap() generates a warning when a caller correctly performs an
ioremap()/iounmap() sequence.

Fix that by teaching iounmap() about the IS address range.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

bf9c6f42

[PATCH] Determine SCx200 CB address at run-time · dccafd6e

Henrik Brix Andersen authored Mar 07, 2005

The current SCx200 drivers use a fixed base address of 0x9000 for the
Configuration Block, but some systems (at least the Soekris net4801) uses a
base address of 0x6000. This patch first tries the fixed address then - if
no configuration block could be found - tries the address written to the
Configuration Block Address Scratchpad register by the BIOS.
Signed-off-by: Henrik Brix Andersen <brix@gentoo.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

dccafd6e

[PATCH] fix iounmap and a pageattr memleak (x86 and x86-64) · 54fe2b5b

Andrea Arcangeli authored Mar 07, 2005

Reject zero page vm-area request, align size properly and hide the guard page
from the callers like ioremap - this avoids a kernel crash due one more page
being passed to change_page_attr
Signed-off-by: Andrea Arcangeli <andrea@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

54fe2b5b

[PATCH] x86: remove-free_all_bootmem() #define · b525cd44

Dave Hansen authored Mar 07, 2005

in arch/i386/mm/init.c, there's a #define for __free_all_bootmem():

#ifndef CONFIG_DISCONTIGMEM
#define __free_all_bootmem() free_all_bootmem()
#else
#define __free_all_bootmem() free_all_bootmem_node(NODE_DATA(0))
#endif /* !CONFIG_DISCONTIGMEM */

However, both of those functions end up eventually calling the same
thing:

	free_all_bootmem_core(NODE_DATA(0))

This might have once been a placeholder for a more complex bootmem
init call, but that never happened.  So, kill off the DISCONTIG
version, and just call free_all_bootmem() directly in both cases.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

b525cd44

[PATCH] x86: consolidate set_max_mapnr_init() implementations · 70b833b5

Dave Hansen authored Mar 07, 2005

discontig.c has its own version of set_max_mapnr_init().  However, all that it
really does differently from the mm/init.c version is skip setting max_mapnr
(which doesn't exist because there's no mem_map[]).
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

70b833b5

[PATCH] x86: refactor memory setup · af916f7d

Dave Hansen authored Mar 07, 2005

Refactor the i386 default and CONFIG_DISCONTIG_MEM setup_memory() functions to
share the common bootmem initialisation code.  This code is intended to be
identical, but there are currently some fixes applied to one and not the
other.  This patch extracts this common initialisation code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

af916f7d

[PATCH] Allow hot-add enabled i386 NUMA box to boot · e7f21c70

Keith Mannthey authored Mar 07, 2005

Dave Hanson mentioned I should send this patch to you.  I posted it to
linux-mm a while ago without complaint.  This patch solves a simple
problem related to the interpretation on the SRAT table and the info
found in the e820.

When a possible hot-add area is exposed on my box (IBM x445 with hot
add enabled in the bios) my SRAT table correctly exposed a new node from
the end of my physical memory to 64gb.  In the present kernels the numa
KVA areas (based on the SRAT) are calculated before find_max_pfn.  The
remap area is created for this large non-populated zone and the system
dies a while later during bootup.

I believe the correct things to do (as did the hot-plug community) the
correct thing to do is the keep the node_start_end_pfn data structures
focuses on memory that is in the system.  That is all this patch does.
It ignores any node data (correctly reported by the SRAT) that is above
the e820 end of memory.    

Signed-off-by: <kmannth@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

e7f21c70