- 03 Jan, 2005 40 commits
-
-
Dave Hansen authored
This function is unused on i386. 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>
-
H. Peter Anvin authored
Signed-off-by:
-
Zwane Mwaikambo authored
Booting with NX, CONFIG_X86_PAE and CONFIG_DEBUG_PAGEALLOC or mem=nopentium triple faults really early during boot as it appears to be tripping over pages from PAGE_OFFSET -> PAGE_OFFSET + 0x100000 not being marked as executable. Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by:
-
Zwane Mwaikambo authored
This patch is for the following bug, thanks to Ondrej Zary for reporting, testing and submitting a patch. http://bugzilla.kernel.org/show_bug.cgi?id=3767 It appears that the Cyrix MII won't touch %ecx at all resulting in stale data being returned as extended attributes, so clear ecx before issuing the cpuid. I have also made the capability print code display all the capability words for easier debugging in future. Signed-off-by:
Zwane Mwaikambo <zwane@linuxpower.ca> Signed-off-by:
-
Venkatesh Pallipadi authored
The setup.S data and code is not cleanly separated. The current space reserved for setup header is not enough to fit the complete header. As a result, part of the header (EDDBUF) will overwrite the initial code. I haven't seen any negative impact of this bug. As, by the time the setup code is overwritten, we would have finished executing it anyway. But, I think it is better to separate the header and code and prevent this data_overwriting_the_code condition. The atatched patch adds some space in the header to fit all the data listed in Documentation/i386/zero-page.txt for both i386 and x86_64 (and updates zero-page.txt). Signed-off-by:
: "Venkatesh Pallipadi" <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Martin J. Bligh authored
Badari hit a problem when configuring PAE off (ie CONFIG_4G) where the pkmap area could end up overlapping the fixmap area. For some reason, PKMAP_BASE was defined statically, which seems rather pointless, and asking for trouble. Patch below definines it dynamically, under the fixmap area. The ordering of the VMALLOC_RESERVE space is: FIXADDR_TOP fixed_addresses FIXADDR_START temp fixed addresses FIXADDR_BOOT_START Persistent kmap area PKMAP_BASE VMALLOC_END Vmalloc area VMALLOC_START high_memory Signed-off-by:
-
David Howells authored
The attached patch fixes the IDE driver to initialise correctly in the case that IDE_ARCH_OBSOLETE_INIT is not defined. Not defining this macro would seem to be the correct thing to do since it includes the word "obsolete" in its name. Signed-Off-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
David Howells authored
The attached patch creates a generic set of termio userspace access functions with proper error handling. None of the current archs check for errors in this case. Signed-Off-By:
-
Ananth N. Mavinakayanahalli authored
Here is a patch that adds a wrapper for defining jprobe.entry to make t easy to handle the three dword function descriptors defined by the PowerPC ELF ABI. x86, ppc64 and x86_64 are also updated. Signed-off-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by:
-
David Gibson authored
Currently the ppc64 sysfs code registers an entry for each possible cpu in sysfs, rather than just online cpus. That makes sense, since the sysfs entries are needed to control onlining of the cpus. However, this is done even if CONFIG_HOTPLUG_CPU is not set, or if it is not a hotplug capable (DLPAR) machine, which is a bit misleading. Secondly it also registers all the other sysfs entries (mostly performance monitoring controls) on all possible cpus, although they are quite meaningless on non-online cpus. This patch alters the code to only register sysfs directories at boot for cpus which are either online or could be onlined (cpu is possible, and CONFIG_HOTPLUG_CPU and an lpar machine). Furthermore, the entries apart from 'online' itself and 'physical_id' are only registered for online CPUs (and deregistered again if a cpu goes offline). Currently the ppc64 sysfs code registers an entry for each possible cpu in sysfs, rather than just online cpus. That makes sense, since the sysfs entries are needed to control onlining of the cpus. However, this is done even if CONFIG_HOTPLUG_CPU is not set, or if it is not a hotplug capable (DLPAR) machine, which is a bit misleading. Secondly it also registers all the other sysfs entries (mostly performance monitoring controls) on all possible cpus, although they are quite meaningless on non-online cpus. This patch alters the code to only register sysfs directories at boot for cpus which are either online or could be onlined (cpu is possible, and CONFIG_HOTPLUG_CPU and an lpar machine). Furthermore, the entries apart from 'online' itself and 'physical_id' are only registered for online CPUs (and deregistered again if a cpu goes offline). Signed-off-by:
-
Ananth N. Mavinakayanahalli authored
Kprobes (Kernel dynamic probes) is a lightweight mechanism for kernel modules to insert probes into a running kernel, without the need to modify the underlying source. The probe handlers can then be coded to log relevent data at the probe point. More information on kprobes can be found at: http://www-124.ibm.com/developerworks/oss/linux/projects/kprobes/ Jprobes (or jumper probes) is a small infrastructure to access function arguments. It can be used by defining a small stub with the same template as the routine in kernel, within which the required parameters can be logged. Signed-off-by:
-
Arthur Othieno authored
Documentation/powerpc/cpu_features.txt mysteriously disappeared sometime when 2.5 forked off. Searching through BK logs on linux.bkbits.net didn't reveal anything, unfortunately. The only reference I could pick up from searching the available lkml archives is the 2.4.20-pre11 ChangeLog where this was first merged. Thus far, nothing indicates it was intentionally removed, and AFAICS, is still up to date with the current code. Signed-off-by:
Arthur Othieno <a.othieno@bluewin.ch> Signed-off-by:
-
Matt Porter authored
Fixes io_remap_page_range() to use the 32-bit address translator similar to ioremap(). Someday u64 start/end resources should make this unnecessary. Fixes set_pte() to handle a long long pte_t properly. Signed-off-by:
Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Matt Porter authored
We'd like to get a uImage when just using 'make' on many targets. After some discussion, it made sense to simply add uImage to the default targets since it adds minimal build overhead and will work on all platforms. Also, fix a dependency in the boot stuff. Signed-off-by:
-
Corey Minyard authored
Add a debugging interface for PowerPC that allows signal handlers (or any jump to a context, really) to perform debug functions. It allows the a user program to turn on single-stepping, for instance, and the thread will get a trap after executing the next instruction. It can also (on supported PPC processors) turn on branch tracing and get a trap after the next branch instruction is executed. This is useful for in-application debugging. Note that you can enable single-stepping on x86 processors directly from signal handlers. Newer x86 processors have the equivalent of a branch-trace bit in the IA32_DEBUGCTL MSR and could have similar function to this syscall. Most other processors could benefit from a similar interface, except for ARM which is extraordinarily broken for debugging. Future uses of this could be adding the ability to set the hardware breakpoint registers from a signal handler. Signed-off-by:
Corey Minyard <minyard@mvista.com> Signed-off-by:
-
Matt Porter authored
This trivial patch removes long-standing typo in ibm44x.h. In fact, we already have correct DCRN_CPC0_GPIO define later in the same file. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
Matt Porter authored
This patch removes annoying warnings in ebony.c. Fix is similar to one I made in ocotea.c before. Signed-off-by:
-
Kumar Gala authored
Remove prototypes and externs out of the .c files Signed-off-by:
Andy Fleming <afleming@freescale.com> Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
Kumar Gala authored
Adds oprofile support for the e500 PowerPC core. Signed-off-by:
-
Matt Porter authored
Patch from Eugene to do some cleanup of the PPC4xx PIC code. Separates the interrupts that can have polarity/triggering modified for platform modification if necessary. Between the two of us, it's tested on most of the affected platforms. Signed-off-by:
-
Randy Vinson authored
I've added support for the IBM 750FX and 750GX Eval Boards (Chestnut/Buckeye). Signed-off-by:
Randy Vinson <rvinson@mvista.com> Signed-off-by:
-
Mark A. Greer authored
This patch adds support for the Artesyn Katana 750i, 752i, and 3750. Signed-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
-
Mark A. Greer authored
This patch adds support for the Force CPCI-690 cPCI board. Signed-off-by:
-
Mark A. Greer authored
This patch adds support for a line of evaluation platforms from Marvell that use the Marvell GT64260[ab] host bridges. This patch depends on the Marvell host bridge support patch (mv64x60). Signed-off-by:
-
Mark A. Greer authored
Here is an incremental patch [hopefully] with your concerns addressed. Note that the arch/ppc/boot code is not kernel code and only exists for a short period of time before execution jumps to the kernel. Signed-off-by:
-
Mark A. Greer authored
This patch adds core support for a line of host bridges from Marvell (formerly Galileo). This code has been tested with a GT64260a, GT64260b, MV64360, and MV64460. Patches for platforms that use these bridges will be sent separately. The patch is rather large so a link is provided. Signed-off-by:
-
Tom Rini authored
The following patch switches ppc32 from using arch/ppc/defconfig to arch/ppc/configs/common_defconfig as a defconfig. These files are supposed to be identical, but always end up out of sync. This also updates the common_defconfig with current options. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
-
Kumar Gala authored
Moves common handling of InstructionStorage, Alignment, Program, and Decrementer exceptions handlers for Book-E processors (44x & e500) into common code. Signed-off-by:
-
Kumar Gala authored
Updates the Freescale Book-E MMU usage to match the architecture spec. This is mainly growing the widths of fields in various registers to match the architecture spec instead of the implementation. Signed-off-by:
Becky Gill <becky.gill@freescale.com> Signed-off-by:
-
Martin Josefsson authored
Here's a patch that fixes a pretty serious bug introduced by a recent "bugfix". The problem is that RST packets are ignored if they follow an ACK packet, this means that the timeout of the connection isn't decreased, so we get lots of old connections lingering around until the timeout expires, the default timeout for state ESTABLISHED is 5 days. This needs to go into -bk as soon as possible. The bug is present in 2.6.10 as well. Signed-off-by:
-
Rusty Russell authored
When ipt_registrater_match() fails, ipt_recent doesn't remove its proc entry. Found by nfsim. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Rusty Russell authored
After changing firewall rules, we try to return the counters to userspace. We didn't fail at that point if the copy failed, but it doesn't really matter. Someone added a warn_unused_result attribute to copy_to_user, so we get bogus warnings. Signed-off-by:
-
Rusty Russell authored
We've been threatening to do this for ages: remove the backwards compatibility code. We can now combine ip_conntrack_core.c and ip_conntrack_standalone.c, likewise for the NAT code, but that will come later. Signed-off-by:
-
Rusty Russell authored
I removed this code in a previous patch, and Patrick McHardy explained what was wrong. Add a comment. Signed-off-by:
-
Rusty Russell authored
Several places use ip_ct_selective_cleanup() as a general iterator, which it was not intended for (it takes a const ip_conntrack *). So rename it, and make it take a non-const argument. Also, it missed unconfirmed connections, which aren't in the hash table. This introduces a potential problem for users which expect to iterate all connections (such as the helper deletion code). So keep a linked list of unconfirmed connections as well. Signed-off-by:
-
Rusty Russell authored
On failure from register_sysctl_table, we return with exit 0. Oops. init and fini should also be static. nfsim found these. Signed-off-by:
-
Rusty Russell authored
Peejix's nfsim test for ipt_recent, written two days ago, revealed this bugs with ipt_recent: checkentry() returns true or false, not an error. (Maybe it should, but that's a much larger change). Also, make hash_func() static. Signed-off-by:
-
Brent Casavant authored
Modifies the TCP ehash and TCP bhash to enable the use of vmalloc to alleviate boottime memory allocation imbalances on NUMA systems, utilizing flags to the alloc_large_system_hash routine in order to centralize the enabling of this behavior. Signed-off-by:
Brent Casavant <bcasavan@sgi.com> Signed-off-by:
-
Brent Casavant authored
The following patch modifies the dentry cache and inode cache to enable the use of vmalloc to alleviate boottime memory allocation imbalances on NUMA systems, utilizing flags to the alloc_large_system_hash routine in order to centralize the enabling of this behavior. In general, for each hash, we check at the early allocation point whether hash distribution is enabled, and if so we defer allocation. At the late allocation point we perform the allocation if it was not earlier deferred. These late allocation points are the same points utilized prior to the addition of alloc_large_system_hash to the kernel. Signed-off-by:
-
Brent Casavant authored
NUMA systems running current Linux kernels suffer from substantial inequities in the amount of memory allocated from each NUMA node during boot. In particular, several large hashes are allocated using alloc_bootmem, and as such are allocated contiguously from a single node each. This becomes a problem for certain workloads that are relatively common on big-iron HPC NUMA systems. In particular, a number of MPI and OpenMP applications which require nearly all available processors in the system and nearly all the memory on each node run into difficulties. Due to the uneven memory distribution onto a few nodes, any thread on those nodes will require a portion of its memory be allocated from remote nodes. Any access to those memory locations will be slower than local accesses, and thereby slows down the effective computation rate for the affected CPUs/threads. This problem is further amplified if the application is tightly synchronized between threads (as is often the case), as they entire job can run only at the speed of the slowest thread. Additionally since these hashes are usually accessed by all CPUS in the system, the NUMA network link on the node which hosts the hash experiences disproportionate traffic levels, thereby reducing the memory bandwidth available to that node's CPUs, and further penalizing performance of the threads executed thereupon. As such, it is desired to find a way to distribute these large hash allocations more evenly across NUMA nodes. Fortunately current kernels do perform allocation interleaving for vmalloc() during boot, which provides a stepping stone to a solution. This series of patches enables (but does not require) the kernel to allocate several boot time hashes using vmalloc rather than alloc_bootmem, thereby causing the hashes to be interleaved amongst NUMA nodes. In particular the dentry cache, inode cache, TCP ehash, and TCP bhash have been changed to be allocated in this manner. Due to the limited vmalloc space on architectures such as i386, this behavior is turned on by default only for IA64 NUMA systems (though there is no reason other interested architectures could not enable it if desired). Non-IA64 and non-NUMA systems continue to use the existing alloc_bootmem() allocation mechanism. A boot line parameter "hashdist" can be set to override the default behavior. The following two sets of example output show the uneven distribution just after boot, using init=/bin/sh to eliminate as much non-kernel allocation as possible. Without the boot hash distribution patches: Nid MemTotal MemFree MemUsed (in kB) 0 3870656 3697696 172960 1 3882992 3866656 16336 2 3883008 3866784 16224 3 3882992 3866464 16528 4 3883008 3866592 16416 5 3883008 3866720 16288 6 3882992 3342176 540816 7 3883008 3865440 17568 8 3882992 3866560 16432 9 3883008 3866400 16608 10 3882992 3866592 16400 11 3883008 3866400 16608 12 3882992 3866400 16592 13 3883008 3866432 16576 14 3883008 3866528 16480 15 3864768 3848256 16512 ToT 62097440 61152096 945344 Notice that nodes 0 and 6 have a substantially larger memory utilization than all other nodes. With the boot hash distribution patch: Nid MemTotal MemFree MemUsed (in kB) 0 3870656 3789792 80864 1 3882992 3843776 39216 2 3883008 3843808 39200 3 3882992 3843904 39088 4 3883008 3827488 55520 5 3883008 3843712 39296 6 3882992 3843936 39056 7 3883008 3844096 38912 8 3882992 3843712 39280 9 3883008 3844000 39008 10 3882992 3843872 39120 11 3883008 3843872 39136 12 3882992 3843808 39184 13 3883008 3843936 39072 14 3883008 3843712 39296 15 3864768 3825760 39008 ToT 62097440 61413184 684256 While not perfectly even, we can see that there is a substantial improvement in the spread of memory allocated by the kernel during boot. The remaining uneveness may be due in part to further boot time allocations that could be addressed in a similar manner, but some difference is due to the somewhat special nature of node 0 during boot. However the uneveness has fallen to a much more acceptable level (at least to a level that SGI isn't concerned about). The astute reader will also notice that in this example, with this patch approximately 256 MB less memory was allocated during boot. This is due to the size limits of a single vmalloc. More specifically, this is because the automatically computed size of the TCP ehash exceeds the maximum size which a single vmalloc can accomodate. However this is of little practical concern as the vmalloc size limit simply reduces one ridiculously large allocation (512MB) to a slightly less ridiculously large allocation (256MB). In practice machines with large memory configurations are using the thash_entries setting to limit the size of the TCP ehash _much_ lower than either of the automatically computed values. Illustrative of the exceedingly large nature of the automatically computed size, SGI currently recommends that customers boot with thash_entries=2097152, which works out to a 32MB allocation. In any case, setting hashdist=0 will allow for allocations in excess of vmalloc limits, if so desired. Other than the vmalloc limit, great care was taken to ensure that the size of TCP hash allocations was not altered by this patch. Due to slightly different computation techniques between the existing TCP code and alloc_large_system_hash (which is now utilized), some of the magic constants in the TCP hash allocation code were changed. On all sizes of system (128MB through 64GB) that I had access to, the patched code preserves the previous hash size, as long as the vmalloc limit (256MB on IA64) is not encountered. There was concern that changing the TCP-related hashes to use vmalloc space may adversely impact network performance. To this end the netperf set of benchmarks was run. Some individual tests seemed to benefit slightly, some seemed to be harmed slightly, but in all cases the average difference with and without these patches was well within the variabilty I would see from run to run. The following is the overall netperf averages (30 10 second runs each) against an older kernel with these same patches. These tests were run over loopback as GigE results were so inconsistent run to run both with and without these patches that they provided no meaningful comparison that I could discern. I used the same kernel (IA64 generic) for each run, simply varying the new "hashdist" boot parameter to turn on or off the new allocation behavior. In all cases the thash_entries value was manually specified as discussed previously to eliminate any variability that might result from that size difference. HP ZX1, hashdist=0 ================== TCP_RR = 19389 TCP_MAERTS = 6561 TCP_STREAM = 6590 TCP_CC = 9483 TCP_CRR = 8633 HP ZX1, hashdist=1 ================== TCP_RR = 19411 TCP_MAERTS = 6559 TCP_STREAM = 6584 TCP_CC = 9454 TCP_CRR = 8626 SGI Altix, hashdist=0 ===================== TCP_RR = 16871 TCP_MAERTS = 3925 TCP_STREAM = 4055 TCP_CC = 8438 TCP_CRR = 7750 SGI Altix, hashdist=1 ===================== TCP_RR = 17040 TCP_MAERTS = 3913 TCP_STREAM = 4044 TCP_CC = 8367 TCP_CRR = 7538 I believe the TCP_CC and TCP_CRR are the tests most sensitive to this particular change. But again, I want to emphasize that even the differences you see above are _well_ within the variability I saw from run to run of any given test. In addition, Jose Santos at IBM has run specSFS, which has been particularly sensitive to TLB issues, against these patches and saw no performance degredation (differences down in the noise). This patch: Modifies alloc_large_system_hash to enable the use of vmalloc to alleviate boottime allocation imbalances on NUMA systems. Due to limited vmalloc space on some architectures (i.e. x86), the use of vmalloc is enabled by default only on NUMA IA64 kernels. There should be no problem enabling this change for any other interested NUMA architecture. Signed-off-by:
-
