- 19 Dec, 2005 1 commit
-
-
Nicolas Pitre authored
Patch from Nicolas Pitre Strictly speaking, the NPTL kernel helpers are required for pre ARMv6 only. They are available on ARMv6+ as well for obvious compatibility reasons. However there are cases where extra memory barriers are needed when using an SMP ARMv6 machine but not on pre-ARMv6. This patch adds a memory barrier kernel helper that glibc can use as needed for pre-ARMv6 binaries to be forward compatible with an SMP kernel on ARMv6, as well as the necessary dmb instructions to the cmpxchg helper. Signed-off-by:
Nicolas Pitre <nico@cam.org> Acked-by:
Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
- 17 Dec, 2005 1 commit
-
-
Russell King authored
Rather than providing more wrappers for 6-arg syscalls, arrange for them to be supported as standard. This just means that we always store the 6th argument on the stack, rather than in the wrappers. This means we eliminate the wrappers for: * sys_futex * sys_arm_fadvise64_64 * sys_mbind * sys_ipc Signed-off-by:
-
- 16 Dec, 2005 14 commits
-
-
-
Al Viro authored
DMA_MODE_{READ,WRITE} are declared in asm-powerpc/dma.h and their declarations there match the definitions. Old declarations in ppc4xx_dma.h are not right anymore (wrong type, to start with). Killed them, added include of asm/dma.h where needed. Signed-off-by:Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Al Viro authored
booke_wdt.c had been missed in cpu_specs[] removal sweep Signed-off-by:
-
Alan Stern authored
This patch (as617) adds a couple of memory barriers that Ben H. forgot in his recent suspend/resume fix. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Andi Kleen authored
Use correct address when referencing mmconfig aperture while checking for broken MCFG. This was a typo when porting the code from 64bit to 32bit. It caused oopses at boot on some ThinkPads. Should definitely go into 2.6.15. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Milton Miller authored
PCI express hotplug uses the pcieportbus driver so pcie must be initialized before hotplug/. This patch changes the link order. Signed-Off-By:
Milton Miller <miltonm@bga.com> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Mark A. Greer authored
The busses/i2c-mv64xxx.c driver doesn't currently compile because of an incorrect argument to dev_err(). This patch fixes that. Signed-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Christoph Lameter authored
sparc64, i386 and x86_64 have support for a special data section dedicated to rarely updated data that is frequently read. The section was created to avoid false sharing of those rarely read data with frequently written kernel data. This patch creates such a data section for ia64 and will group rarely written data into this section. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
Tony Luck <tony.luck@intel.com>
-
hawkes@sgi.com authored
Change the NR_CPUS default for ia64/sn up to 1024. Signed-off-by:
John Hawkes <hawkes@sgi.com> Signed-off-by:
John Hesterberg <jh@sgi.com> Signed-off-by:
-
Jack Steiner authored
I see why the problem exists only on SN. SN uses a different hardware mechanism to purge TLB entries across nodes. It looks like there is a bug in the SN TLB flushing code. During context switch, kernel threads inherit the mm of the task that was previously running on the cpu. This confuses the code in sn2_global_tlb_purge(). The result is a missed TLB purge for the task that owns the "borrowed" mm. (I hit the problem running heavy stress where kswapd was purging code pages of a user task that woke kswapd. The user task took a SIGILL fault trying to execute code in the page that had been ripped out from underneath it). Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
-
Jes Sorensen authored
Use raw_smp_processor_id() instead of get_cpu() as we don't need the extra features of get_cpu(). Signed-off-by:
Jes Sorensen <jes@trained-monkey.org> Signed-off-by:
-
Linus Torvalds authored
The logic that decides that a fork() might be able to avoid copying a VM area when it can be re-created by page faults didn't know about the new vm_insert_page() case. Also make some things a bit more anal wrt VM_PFNMAP. Pointed out by Hugh Dickins <hugh@veritas.com> Signed-off-by: -
John Hawkes authored
The udelay() inline for ia64 uses the ITC. If CONFIG_PREEMPT is enabled and the platform has unsynchronized ITCs and the calling task migrates to another CPU while doing the udelay loop, then the effective delay may be too short or very, very long. This patch disables preemption around 100 usec chunks of the overall desired udelay time. This minimizes preemption-holdoffs. udelay() is now too big to be inline, move it out of line and export it. Signed-off-by:
-
Benjamin Herrenschmidt authored
This finally fixes the radeon memory mapping bug that was incorrectly fixed by the previous patch. This time, we use the actual vram size as the size to calculate how far to move the AGP aperture from the framebuffer in card's memory space. If there are still issues with this patch, they are due to bugs in the X driver that I'm working on fixing too. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Mark M. Hoffman <mhoffman@lightlink.com> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
- 15 Dec, 2005 24 commits
-
-
Sergei Shtylylov authored
We have found some issues with Au1550 AC'97 OSS driver in 2.6 (sound/oss/au1550_ac97.c), though it also should concern 2.4 driver (drivers/sound/au1550_psc.c). start_dac() grabs a spinlock already held by its caller, au1550_write(). This doesn't show up with the standard UP spinlock impelmentation but when the different one (mutex based) is in use, a lockup happens. And the interrupt handlers also didn't grab the spinlock -- that's OK in the usual kernel but not when the IRQ handlers are threaded. So, they're grabbing the spinlock now (as every correct interrupt handler should do). Signed-off-by:
Konstantin Baidarov <kbaidarov@ru.mvista.com> Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Adrian Bunk authored
We can't export a static struct to modules. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Paolo Galtieri authored
While doing some testing I discovered that if the BIOS on a board does not properly setup the DMI information it leads to a panic in the IPMI code. The panic is due to dereferencing a pointer which is not initialized. The pointer is initialized in port_setup() and/or mem_setup() and used in init_one_smi() and cleanup_one_si(), however if either port_setup() or mem_setup() return ENODEV the pointer does not get initialized. Signed-off-by:
Paolo Galtieri <pgaltieri@mvista.com> Acked-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
