- 16 Dec, 2005 5 commits
-
-
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:
-
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:
-
- 15 Dec, 2005 35 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:
Linus Torvalds <torvalds@osdl.org>
-
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 <viro@zeniv.linux.org.uk> 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:
-
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:
-
Linus Torvalds authored
-
Jeff Mahoney authored
The following patch fixes a bug where if the journal is aborted, it can leave a transaction open. The result will be a BUG when another code path attempts to start a transaction and will get a "nesting into different fs" error, since current->journal_info will be left non-NULL. Original fix against SUSE kernel by Chris Mason <mason@suse.com> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
