Hi, Ops! From this webpage: http://lkml.org/lkml/2008/4/2/60 This is already done: http://lkml.org/lkml/2008/4/2/60 Looks like a patch for 2.6.24.4, I will do some tests. Looks like from April, so maybe there is more news in the list. I will check it. -- Carles Pina i Estany GPG id: 0x17756391 http://pinux.info --

add calling setup_msi_irq back to arch_setup_msi_irq Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/io_apic_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_32.c +++ linux-2.6/arch/x86/kernel/io_apic_32.c @@ -2686,7 +2695,6 @@ static unsigned int build_irq_for_pci_de int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc) { - struct msi_msg msg; int irq, ret; ...

do we have 64bit system with sis chipset? Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_64.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_64.c +++ linux-2.6/arch/x86/kernel/io_apic_64.c @@ -65,7 +65,11 @@ int ioapic_force; -int sis_apic_bug; /* not ac...

all the same except INTR_REMAPPING related and ioapic io resource Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic_32.c | 213 ++++++++++++- arch/x86/kernel/io_apic_64.c | 666 ++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 832 insertions(+), 47 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic_32.c +++ linux-2.6/arch/x86/k...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/io_apic.c | 8 -------- 1 file changed, 8 deletions(-) Index: linux-2.6/arch/x86/kernel/io_apic.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/io_apic.c +++ linux-2.6/arch/x86/kernel/io_apic.c @@ -3785,7 +3785,6 @@ void __init setup_ioapic_dest(void) } #endif -#ifdef CONFIG_X86_64 #define IOAPIC_RESOURCE_NAME_SIZE 11 static struct resource *ioap...

applied for testing, thanks Arjan. Ingo --

This removes the last usage of the Big Kernel Lock from the ieee1394 stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl. The ioctl()s don't need to take the BKL, but they need to be serialized per struct file *. In particular, accesses to ->iso_state need to be serial. We simply use a blocking mutex for this purpose because libraw1394 does not use O_NONBLOCK. In practice, there is no lock contention anyway because most if not all libraw1394 clients use a libraw1394 handle only in a ...

Application programs should use a libraw1394 handle only in a single thread. The raw1394 driver was apparently relying on this, because it did nothing to protect its fi->state variable from corruption due to concurrent accesses. We now serialize the fi->state accesses. This affects the write() path. We re-use the state_mutex which was introduced to protect fi->iso_state accesses in the ioctl() path. These paths and accesses are independent of each other, hence separate mutexes could be ...

While running the libhugetlbfs test suite on a NUMA machine with 2.6.27-rc3, I discovered some strange behavior with __GFP_THISNODE. The hugetlb function alloc_fresh_huge_page_node() calls alloc_pages_node() with __GFP_THISNODE but occasionally a page that is not on the requested node is returned. Since the hugetlb code assumes that the page will be on the requested node, badness follows when the page is added to the wrong node's free_list. There is clearly something wrong with the buddy allocator...

mminit_loglevel is now used from mminit_verify_zonelist <- build_all_zonelists <- 1. online_pages <- memory_block_action <- memory_block_change_state <- store_mem_state (sys handler) 2. numa_zonelist_order_handler (proc handler) so it cannot be annotated __meminit - drop it fixes following section mismatch warning: WARNING: vmlinux.o(.text+0x71628): Section mismatch in reference from the function mminit_verify_zonelist() to the variable .meminit.data:mminit_loglevel The function m...

I am using the iwl500 branch from the above git repository and I am also receiving the timeout error. This is on a Wifi Link 5100 on an Asus M50VM laptop. $ dmesg|grep iw [ 8.574423] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kds [ 8.574655] iwlagn: Copyright(c) 2003-2008 Intel Corporation [ 8.575055] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 8.575369] iwlagn 0000:03:00.0: setting latency timer to 64 [ 8.575425] iwlagn: Detec...

Hi, While playing around with libcgroup, one of the isses hit was that attaching a task failed. Looking deeper into it, cpusets had been mounted along with other subsystems. And since we did not care about cpusets, we did not set cpus and mems there. Now an application programmer does not really care where and how subsystems are mounted (or at least that is what libcgroup aims to achieve :-) ). And such a scenario when the cpuset has not been handled is going to lead to failures which a user is ...

- remove redundant read of APIC_LVR register in 64bit mode - APIC is always integrated for 64bit mode so gcc will eliminate lapic_is_integrated call Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/apic_32.c =================================================================== --- linux-2.6.git.orig/arch/x86/kernel/apic_32.c 2008-08-15 22:14:45.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/apic_32.c 2008-08-15 22:41:52.000000000 +0400 @@ -92...

looks good to me - applied to tip/x86/apic - thanks Cyrill. Maciej, any objections? Ingo --

Whoops, my fault, now fixed; thanks! (Out of curiosity--how did you find this?) --

ACPI exposed a off by one bug in the PAT/ioremap changes. Please pull the fix from the ACPI tree. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11346 git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6 ioremap Andi Kleen (1): x86: Fix ioremap off by one BUG arch/x86/mm/ioremap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --

ah, in tip/master - that's a conflict resolution artifact i suspect. Thx. Ingo --

thanks, i've pulled it and rebased it to -git - as that's the best base this early in the cycle. I've pushed out the result into tip/x86/time - havent integrated it into tip/master yet. Ingo --

From: Alex Nixon <alex.nixon@citrix.com> Date: Fri, 15 Aug 2008 11:21:56 +0100 Subject: [PATCH] change init_gdt to update the gdt via write_gdt, rather than a direct write. By writing directly, a memory access violation can occur whilst hotplugging a CPU if the entry was previously marked read-only. Signed-off-by: Alex Nixon <alex.nixon@citrix.com> --- arch/x86/kernel/smpcommon.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/smpcomm...

Linus, please pull ALSA updates for 2.6.27-rc3 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus which contains more two changes to ASoC in addition to the last pending request. Thanks! Takashi === Clemens Ladisch (1): ALSA: virtuoso: add Xonar D1 support Mark Brown (2): ALSA: wm8990: Fix routing of left DAC to speaker mixer ALSA: wm8990: Implement speaker volume PGA Documentation/sound/alsa/ALSA-Configuration.txt | 10...

The attached patch fixes the following compiler error in the rt-kernel if CONFIG_DEBUG_PREEMPT is enabled. lib/locking-selftest.c: In function 'dotest': lib/locking-selftest.c:951: error: incompatible types in initialization lib/locking-selftest.c:1003: error: incompatible types in assignment

applied to tip/core/urgent, thanks Stephen. I'm wondering, could you send me the config that produces the build error? I do fairly comprehensive build testing but this one does not seem to trigger. Ingo --

Ingo, I'm trying to keep all the arch changes in recordmcount.pl in one place. I moved your code into that area, by adding the flags to the commands that were passed in. Does this change still work for you when compiling i386 on a x86_64 box? Signed-off-by: Steven Rostedt <srostedt@redhat.com> Index: linux-tip.git/scripts/recordmcount.pl =================================================================== --- linux-tip.git.orig/scripts/recordmcount.pl 2008-08-15 10:54:00.000000000 -04...

OK, I'll set up one of my x86_64 boxes to compile the kernel for i386s, and see if I can come up with something. The reason I did this patch, is to get the PPC patches ready to go on top. I still need to port to ppc32 (I have 64 working). -- Steve --

When user calls sys_setpriority(PRIO_PGRP ...) on a NPTL style multi-LWP process, only the task leader of the process is affected, all other sibling LWP threads didn't receive the setting. The problem was that the iterator used in sys_setpriority() only iteartes over one task for each process, ignoring all other sibling thread. Introduce a new macro do_each_pid_thread / while_each_pid_thread to walk each thread of a process. Convert 4 call sites in {set/get}priority and ioprio_{set/get}. Signed...