Hi, I get this warning while compiling for ARM/SA1100: mm/sparse.c: In function '__section_nr': mm/sparse.c:135: warning: 'root' is used uninitialized in this function With a small patch in fs/proc/meminfo.c, I find that NR_SECTION_ROOTS is zero, which certainly explains the warning. # cat /proc/meminfo NR_SECTION_ROOTS=0 NR_MEM_SECTIONS=32 SECTIONS_PER_ROOT=512 SECTIONS_SHIFT=5 MAX_PHYSMEM_BITS=32 SECTION_SIZE_BITS=27 MemTotal: 28848 kB MemFree: 15516 ...

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> Update mx51_defconfig to include USB EHCI by default. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/configs/mx51_defconfig | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/mx51_defconfig b/arch/arm/configs/mx51_defconfig index c88e952..a708fd6 100644 --- a/arch/arm/configs/mx51_defconfig +++ b/arch/arm/configs/mx51_defconfig @@ ...

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> This patch is part of enabling USB for Freescale MX51 Babbage HW. This patch adds device structures for USB Host1 and OTG port, and adds clocking information for USB HW. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/mach-mx5/clock-mx51.c | 8 ++++++ arch/arm/mach-mx5/devices.c | 49 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-mx5/devices.h | 2 + 3 files ...

These are changes to uio_pci_generic.c to allow better use of the driver by non-privileged processes. 1. Add back old code which allowed interrupt re-enablement through uio fd. 2. Translate PCI bards to uio mmap regions, to allow mmap through uio fd. 3. Allow devices which support MSI or MSI-X, but not IRQ. Signed-off-by: Tom Lyon <pugs@cisco.com> --- checkpatch.pl is happy with this one. --- linux-2.6.33/drivers/uio/uio_pci_generic.c 2010-02-24 10:52:17.000000000 -0800 +++ ...

Some trivial build warning fixes and cleanups for UML. Jan Kiszka (5): uml: Remove unused variable from line driver uml: Drop private round_down definition uml: Fix warning due to missing task_struct declaration uml: i386: Avoid redefinition of NR_syscalls uml: Clean up asm/system.h arch/um/drivers/line.c | 1 - arch/um/include/asm/system.h | 3 --- arch/um/kernel/skas/syscall.c | 4 ++-- arch/um/sys-i386/asm/elf.h | 2 ++ arch/um/sys-x86_64/asm/elf.h | ...

We can't pull in linux/sched.h, so just declare the struct. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- arch/um/sys-i386/asm/elf.h | 2 ++ arch/um/sys-x86_64/asm/elf.h | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/um/sys-i386/asm/elf.h b/arch/um/sys-i386/asm/elf.h index e64cd41..a979a22 100644 --- a/arch/um/sys-i386/asm/elf.h +++ b/arch/um/sys-i386/asm/elf.h @@ -75,6 +75,8 @@ typedef struct user_i387_struct elf_fpregset_t; pr_reg[16] = ...

The i386 subarch happens to pull in original NR_syscalls. Maybe we can make that work for all host arch, but for now just avoid the clash by using an all-upper-case name. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- arch/um/kernel/skas/syscall.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/kernel/skas/syscall.c b/arch/um/kernel/skas/syscall.c index 4e3b820..f5173e1 100644 --- a/arch/um/kernel/skas/syscall.c +++ b/arch/um/kernel/skas/syscall.c @@ ...

On Mon, 19 Apr 2010 14:44:16 -0700 This smells like a 2.6.34 patch. Do you agree? --

I didn't think this effected in-tree code. Tom hit this while developing a new user of the iommu interface, whereas the current user (KVM) doesn't trigger this. thanks, -chris --

Bug: intel_iommu_map_range didn't allow allocation at the very end of the address space. Signed-off-by: Tom Lyon <pugs@cisco.com> --- V1 and V2 of this patch were patch of a larger patch, this is now independent. --- linux-2.6.33/drivers/pci/intel-iommu.c 2010-02-24 10:52:17.000000000 -0800 +++ mylinux-2.6.33/drivers/pci/intel-iommu.c 2010-04-13 16:51:55.000000000 -0700 @@ -3632,7 +3631,6 @@ static int intel_iommu_map_range(struct { struct dmar_domain *dmar_domain = domain->priv; u64 ...

The ACPI spec tells us that the ACPI SCI_EN bit is under hardware control and shouldn't be touched by the OS. It seems that the Leading Other OS ignores this and some machines expect this behaviour. We have a blacklist for these, but given that we're able to detect the failure case and the alternative to breaking the spec is letting the machine crash and burn, let's try falling back when we know the alternative is a mostly-dead machine. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- ...

Hi I have a HP Mini with their wwan module (Qualcomm 3g card), it attaches via the usb interface. It was working (not sure about 2 months ago) and when I went to use it recently it doesn't work any more - the gobi loader get stuck uploading firmware to the card :( I am not sure what or how to debug this, so I have come to the list. running debian i386 2.6.32-4 Alex --

Your mailbox has exceeded the storage limit which is 20GB as set by your administrator, you are currently running on 20.9GB,you may not be able to send or receive new mail until you re-validate your mailbox. To re-validate your mailbox please click the link below: http://r.im/2j04 If the link above don't work please copy and paste the link below to your browser window http://r.im/2j04 Thanks System Administrator --

Good Day, I have a Business Proposal of $21,300,000.00 for you to handle with me from my bank.please contact me on {from_icbc_liuling@yahoo.com.hk} with your Full names,occupation,private phone number,current residential address. --

Correct several style errors related to pointers in usb_main_dev.c. Signed-off-by: Trey Evans <lewis.r.evans@gmail.com> --- drivers/staging/rt2860/usb_main_dev.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rt2860/usb_main_dev.c b/drivers/staging/rt2860/usb_main_dev.c index 1873a79..abe9f24 100644 --- a/drivers/staging/rt2860/usb_main_dev.c +++ b/drivers/staging/rt2860/usb_main_dev.c @@ -153,7 +153,7 @@ static void rt2870_disconnect(struct ...

Hi Tom, Could you add a way to do a call to tracing_on() or tracing_off() via the filters. I would like to do something like: echo 'if (pid == 1234) traceoff' > events/sched/sched_wakeup/filter Where, if the sched_wakeup event is hit with pid == 1234 it will turn tracing off. I would also like to do just: echo 'traceoff' > events/sched/sched_wakeup/filter to disable tracing every time the event is hit. Perhaps you can just add a call back where the kernel could ...

Yeah, Mathieu calls them triggers too. But if you do, I'm fine with I thought about a separate file, but I like the idea of having control over them. We could add a "trigger" file too, but I'm not sure if that would be any clearer. If we add a trigger file, then the filter can be separate, and we just trigger the trigger if the filter passes. This may be better, because then the triggers do not mess with the filtering code, and I can add it without modification to Tom's code. -- ...

Just a comment on the nomenclature. In KFT I called things like this "triggers". I'm not sure what other tracing systems call them. I'm a little worried about overloading the filtering abstraction with trigger semantics. (I like the idea of triggers, but it might be better to control them with another pseudo-file for clarity.) I suppose both are a form of conditional execution. Filtering has an implicit action of either 'trace this' or 'don't trace this', while triggering usually ...

The problem with having triggers defined in the filter file is that you couldn't set a normal filter plus a trigger. That said a filter itself could be a trigger. if (cond) filter This is going to break some ABI though. In fact having one file per trigger type is going to make the things much easier if you don't want to encumber with syntax parsing, and just reuse the filtering code as is with very few modification. This is going to be also easier for the users as they don't have ...

Yep, since it would share exatly the same code than filter (as filter basically becomes a trigger command), it can behave the Yeah :) But if the scope of the "tracing off" is only for this event, then rather use: echo "(a < 100)" > filter You could have tracing_off/on that have this event scope and tracing_off/on_all for a global tracing scope. --

Perhaps, but I was also thinking of having triggers in the system level. We could have a "trace_event_on" and "trace_event_off" trigger that only enables the event when hit. Actually, we can have these triggers enable other events, or make dynamic triggers: echo "enable_sched_switch" > events/sched/sched_wakeup/trigger/activate or something similar. -- Steve --

Hi, two students who applied for your projects have applied also for another organization's project and they got accepted by us and by the other organization. Until Wednesday Google wants these situation to be resolved until Wednesday April 21, 17:00 UTC. Please contact the students and/or the organization to agree on one of the project for each student. In addition, the ranking of the students (to decide who actually gets our slots) and the mentor assignments have to be finalized by ...

Sorry, here we go: http://socghop.appspot.com/gsoc/org/list_proposals/google/gsoc2010/lf Requires login as mentor. Till --

I upgraded a 2.6.18-rt kernel to 2.6.33-rt and the my main multi-thread application now consumes 12% cpu at idle, all threads are a little bit busy while on 2.6.18-rt they are all quiet. I'm still using glibc2.5/nptl. After spending a few days on debugging/performance tuning the problem stays. Do I need upgrade glibc/nptl to work with a newer kernel as far as performance is concerned? This is a shipping product and we do not want to change everything unless it's mandatory. the WCHAN on 2.6.18 ...

2.6.34-rc4 uname(2) from a x86_32 process copies out 325 bytes rather than the 390 bytes that 2.6.31 copied out (and that userland expects): 2.6.31.12% cat foo.c main() { char buf[1000]; memset(buf, 'x', sizeof(buf)); uname(buf); write(1, buf, sizeof(buf)); return 0; } 2.6.31.12% i686-linux-gcc foo.c 2.6.31.12% ./a.out | hd 00000000 4c 69 6e 75 78 00 00 00 00 00 00 00 00 00 00 00 |Linux...........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

These 2 patches fix some issues with the current LZO decompressor code. The first one (re-)enables the use of LZO-compressed external initramfs, which has been broken for some time. The second one enables the use of in-kernel initramfs compressed using LZO. If that's possible, I'd like to get at least patch 1/2 in 2.6.34, since it is an actual bug fix. Albin Tonnerre (2): lib: fix initramfs usage for the LZO decompressor Add support for in-kernel initramfs compressed with LZO ...

This patch fixes 2 issues with the LZO decompressor: - It doesn't handle the case where a block isn't compressed at all. In this case, calling lzo1x_decompress_safe will fail, so we need to just use memcpy() instead (the upstream LZO code does something similar) - Since commit 54291362d2a5738e1b0495df2abcb9e6b0563a3f, the decompressor return code is checked in the init/initramfs.c The LZO decompressor didn't return the expected value, causing the initramfs code to falsely ...

Hi Alan, Hope you have found some time now. --

This patch adds idstrings for Kingston 1GB/4GB and Transcend 4GB/8GB. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> diff --git a/drivers/ide/ide-cs.c b/drivers/ide/ide-cs.c index ab87e4f..defce28 100644 --- a/drivers/ide/ide-cs.c +++ b/drivers/ide/ide-cs.c @@ -409,6 +409,8 @@ static struct pcmcia_device_id ide_ids[] = { PCMCIA_DEVICE_PROD_ID12("Hyperstone", "Model1", 0x3d5b9ef5, 0xca6ab420), PCMCIA_DEVICE_PROD_ID12("IBM", "microdrive", 0xb569a6e5, 0xa6d76178), ...

From: Randy Dunlap <randy.dunlap@oracle.com> Update Makefile to support rpmbuild DESTDIR usage. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- trace-cmd-0.7.0.orig/Makefile +++ trace-cmd-0.7.0/Makefile @@ -18,10 +18,11 @@ AR = $(CROSS_COMPILE)ar EXT = -std=gnu99 INSTALL = install +DESTDIR = prefix ?= /usr/local bindir_relative = bin -bindir = $(prefix)/$(bindir_relative) -man_dir = ...

Yes, thanks, but I have it "fixed" now (for some daffynition of fixed). -- ~Randy --

NAK is too strong. I was looking at what perf does, and it basically makes prefix and DESTDIR the same. ifndef DESTDIR prefix = $(HOME) endif We could do.. ifndef DESDIR prefix = /usr/local/bin endif and then, if DESTDIR is not set, it would do the right thing. -- Steve --

If a futex key happens to be located within a huge page mapped MAP_PRIVATE, get_futex_key() can go into an infinite loop waiting for a page->mapping that will never exist. This was reported and documented in an external bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=552257 This patch makes page->mapping a poisoned value that includes PAGE_MAPPING_ANON mapped MAP_PRIVATE. This is enough for futex to continue but because of PAGE_MAPPING_ANON, the poisoned value is not dereferenced or ...

This is a re-submitted patch to the ni_labpc.c file that fixes EXPORT_SYMBOL(FOO) warnings found by the checkpatch.pl tool Signed-off-by: Maurice Dawson <mauricedawson2699@googlemail.com> --- drivers/staging/comedi/drivers/ni_labpc.c | 31 +++++++++++++++-------------- 1 files changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/staging/comedi/drivers/ni_labpc.c b/drivers/staging/comedi/drivers/ni_labpc.c index becbe47..26e02d9 100644 --- ...

I have been trying to improve boot times with ureadahead and have identified a period of time of almost zero IO throughput caused by calls to open() blocking during name lookup while fetching directory blocks. At first I thought this could simply be fixed by calling readahead() on the directories first before open()ing all of the normal files for readahead. Unfortunately it seems that readahead() fails when called on a directory. I was wondering if I could get some help understanding why this ...

The earlier the better from my perspective. Ralf may have had the mips tree in mind - might make sense to synchronize with him. Thanks, Guenter --

For the new audience, this patch has been previously posted to linux-mips a few days ago and assuming there are no objections I'd like to merge it upstream for 2.6.34, so an Ack would by nice. Ralf --

Hmm... Yes, I think that function should probably take the rcu_read_lock(), and then take the delegation->lock before modifying the delegation. Furthermore, it should probably fall back to nfs_inode_set_delegation() in case we race with a delegreturn. See With the above changes to nfs_inode_reclaim_delegation() I don't think delegation->cred needs to be RCU-protected. Cheers Trond ---------------------------------------------------------------------------------------------------------- ...

If we build using make SUBDIRS=foo/ Kbuild will output per-directory Module.symvers files that we do not want to keep track of. Ignore these files globally. Signed-off-by: Florian Fainelli <ffainelli@freebox.fr> --- diff --git a/.gitignore b/.gitignore index a2939fc..441bf1b 100644 --- a/.gitignore +++ b/.gitignore @@ -41,7 +41,7 @@ modules.builtin /vmlinuz /System.map /Module.markers -/Module.symvers +Module.symvers # # git files that we don't want to ignore even it they are ...

We've had this discussion, what, over a dozen times already? It keeps coming up every few months. There are two primary reasons to keep this in userspace: 1) Someone might actually want to access the storage mode of these devices. It has come up in the past, and there is no good reason the kernel should deny access to that function of the device by enforcing a switchover. 2) It is much much easier to update a userspace tool than the kernel. Thus, new devices can be supported without a ...

I still believe that, for an end-user, upgrading a userspace tool is much much easier than upgrading a kernel. Also, the actual "driver" for the device (i.e. the modem part) doesn't need an upgrade to the kernel component for these types of devices. Finally, these sorts of databases don't belong in the kernel as much as possible. The usb-storage driver will not accept patches for device which can be supported via userspace-only tools. Matt -- Matthew Dharm ...

Hey, to solve most of the outstanding bugs I'm aware of, I intend to submit a pull request for a few patches tomorrow. They're available at git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git urgent As usual, I'm interested in your input to this patch series. The individual patches will be sent out to the PCMCIA list in a few moments. Best, Dominik Dan Carpenter (1): pcmcia: fix error handling in cm4000_cs.c Dominik Brodowski (5): pcmcia: use ...

It's really just the top commit. Perhaps I should rebase it to a v2.6.34-rcX tag so that shortlog does what one expects. Alexander mentioned: Alan, do you agree that the entire SI/SO can/should be removed? --

Since KOI7 is not used by any glibc locale, your use case is now extinct. I think that, unless someone finds out a different use case, these SI and SO characters should be deactivated completely (and not just in unicode mode). -- Alexander E. Patrakov --

I agree this is not optimal, but I think there are similar bits in other The first solution implies building a custom kernel before being able to use the system. The second solution does not. I’m looking for a solution that works out of the box, and does not require to be able to compile If you want to screw your system, this is already feasible by hacking the DSDT table itself. Granted, this is not the kind of stuff the average n00b would do. Given how Acer doesn’t give a shit about OSes ...

Hi,       I  am  trying to   run  Kmemcheck on   a  Cortex ( ARM-v7) board  running  Linux 2.6.30.9 At boot-up time,  as  soon  as  Timer-device is  enabled,   I  find that   timer  gets  disabled  because  system gets spurious  interrupts  on  that  irq  line. PID hash table entries: 1024 (order: 10, 4096 bytes) Linux System timer initialize irq 23: nobody cared (try booting with the "irqpoll" option) [<c002e148>] (unwind_backtrace+0x0/0xe8) from ...

Bug 12646 has been outstanding for a long time. Is it possible to get this fix committed? Log: From: Ian Dall <ian@beware.dropbear.id.au> Fix regression caused by commit 507e2fbaaacb6f164b4125b87c5002f95143174b, whereby negative temperatures for the DS18B20 are not converted properly. Fixes bug 12646. Signed-of-by: Ian Dall <ian@beware.dropbear.id.au> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c index 1ed3d55..17726a0 100644 --- ...

Lately we've been developing a device that rather more extensively used request_firmware API in load and also using pm_notifiers to load firmware. In some stress testing the usage will exhaust the system memory. First we suspected there is a memory leak in the firwmare_class but eventually what is that udevd piles up it takes time to collect the process. We loose ~ 500K for each request/release_firmware iteration. After the stress the process table will will look something like shown ...

Reset a port's resources only if they're actually in an error state Signed-off-by: Thomas Klein <tklein@de.ibm.com> --- Patch created against 2.6.34-rc4 diff -Nurp linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c --- linux-2.6.34-rc4.orig//drivers/net/ehea/ehea_main.c 2010-04-19 11:54:07.000000000 +0200 +++ linux-2.6.34-rc4//drivers/net/ehea/ehea_main.c 2010-04-19 11:55:43.000000000 +0200 @@ -791,11 +791,17 @@ static struct ehea_cqe ...

I think the else branch in complete_pio() should work. Marcelo? Longer term I'd like to see the lock taken at the high levels (ioctls, in virt/kvm) and dropped only for guest entry and when we explicitly sleep (hlt emulation). Note: complete_pio() is gone in the current code. -- error compiling committee.c: too many arguments to function --

The RCU/SRCU API have already changed for proving RCU usage. I got the following dmesg when PROVE_RCU=y because we used incorrect API. This patch coverts rcu_deference() to srcu_dereference() or family API. =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- arch/x86/kvm/mmu.c:3020 invoked rcu_dereference_check() without protection! other info that might help us debug ...

One is coming in Arnd's sparse-based patchset. It is probably best to open-code this in the meantime and clean up later, but I will There is an rcu_dereference_protected() on its way to mainline to handle the case where the reference is always protected by a lock. Why not just access it directly? Because if you do that, the sparse-based checks will yell at you. There is also an rcu_access_pointer() on its way to mainline for cases where you only want to test the pointer itself, not ...

Enable high speed support for atmel-mci driver. This support is dependent of the revision of the IP and, of course, the capacity of the SD card used. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- drivers/mmc/host/atmel-mci.c | 22 +++++++++++++++++++--- 1 files changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c index 88be37d..4338750 100644 --- a/drivers/mmc/host/atmel-mci.c +++ ...

Maybe add the #include <linux/sched.h> into gigaset.h, instead of common.c? IOW.. Linus --- drivers/isdn/gigaset/gigaset.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/isdn/gigaset/gigaset.h b/drivers/isdn/gigaset/gigaset.h index d32efb6..05947f9 100644 --- a/drivers/isdn/gigaset/gigaset.h +++ b/drivers/isdn/gigaset/gigaset.h @@ -20,6 +20,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <linux/kernel.h> +#include ...

I'll check it tomorrow - but i'd expect it to be enough, plus the all-yes thing is that matters most in practice in any case. Thanks, Ingo --

This compiled for me, although the only thing I tried was just turning all the gigaset options to 'y'. Maybe some other config doesn't work. So I committed it as likely to fix things. Linus --

-tip testing triggered the following build failure (x86 allyesconfig): drivers/isdn/gigaset/common.c: In function 'setflags': drivers/isdn/gigaset/common.c:99: error: implicit declaration of function 'set_current_state' drivers/isdn/gigaset/common.c:99: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) drivers/isdn/gigaset/common.c:99: error: (Each undeclared identifier is reported only once drivers/isdn/gigaset/common.c:99: error: for each function it appears ...

I did a few tests and it looks good here! Thanks, Ingo --

I got the following bug report: | After upgrading kernel from 2.6.32 to 2.6.34-rc4 my Xonar DX stopped | working. Kernel log has: | | [kernel] AV200 0000:09:04.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 | [kernel] invalid PCI I/O range | [kernel] AV200 0000:09:04.0: PCI INT A disabled | [kernel] ALSA device list: | [kernel] No soundcards found. | | According to git bisect the culprit is: | | commit 977d17bb1749517b353874ccdc9b85abc7a58c2a | Author: Yinghai Lu <yinghai@kernel.org> | ...

Hi Clemens, I am the one who that filed the bug. Please let me know what you need. Regards, Peter --

This is a patch to the das08.c file that fixes up the following issues found by the checkpatch.pl tool. WARNING: line over 80 characters x 6 ERROR: code indent should use tabs where possible x 3 ERROR: spaces required around that '?' (ctx:VxV) x 4 ERROR: spaces required around that ':' (ctx:VxV) x 4 ERROR: that open brace { should be on the previous line x 1 WARNING: printk() should include KERN_ facility level x 9 WARNING: braces {} are not necessary for single statement blocks x 1 WARNING: ...

Below patch implements the perf_guest_info_callbacks on kvm. Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com> --- diff -Nraup linux-2.6_tip0417/arch/x86/kvm/vmx.c linux-2.6_tip0417_perfkvm/arch/x86/kvm/vmx.c --- linux-2.6_tip0417/arch/x86/kvm/vmx.c 2010-04-19 09:51:47.908673911 +0800 +++ linux-2.6_tip0417_perfkvm/arch/x86/kvm/vmx.c 2010-04-19 09:53:59.690399987 +0800 @@ -3654,8 +3654,11 @@ static void vmx_complete_interrupts(stru /* We need to handle NMIs before interrupts ...

This doesn't apply against upstream. What branch was this generated against? -- error compiling committee.c: too many arguments to function --

I think so. A moment ago, I checked out to b5a80b7e9 of tip/perf/core. All 3 patches could be applied cleanly and compilation is ok. A quick testing shows tip/perf/core kernel does work. --

- unbalanced curly braces - missing curly brace for multi-line statement. - invalid C: function parameter needs name even if unused - missing space after opening curly brace Please provide delta fixes. Ingo --

Here is the new patch of V5 against tip/master of April 17th if anyone wants to try it. ChangeLog V5: 1) Split kernel patch to 2 parts. The one introduces perf_guest_info_callbacks() and related register/unregister functions. The other is the kvm implementation of the callbacks. 2) Port to tip/master tree of April 17th. 3) Fix a bug which causes the module parsing of default guest kernel fail. ChangeLog V4: 1) Based on Ingo's comments, I added help information around ...

This patch uses the new IRQ affinity_hint callback mechanism. It serves purely as an example of how a low-level driver can utilize this new interface. An official ixgbe patch will be pushed through netdev once the IRQ patches have been accepted and merged. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> --- drivers/net/ixgbe/ixgbe.h | 2 ++ drivers/net/ixgbe/ixgbe_main.c | 51 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 52 insertions(+), 1 ...

Updated this pull with one more pci id commit. commit 79b9517a33a283c5d9db875c263670ed1e055f7e Author: Dave Airlie <airlied@redhat.com> Date: Mon Apr 19 17:54:31 2010 +1000 drm/radeon/kms: add FireMV 2400 PCI ID. is the new HEAD. > 17 files changed, 138 insertions(+), 19 deletions(-)

Thanks. Please add a preprocessed source file so people can reproduce your issue. -- Jie Zhang CodeSourcery (650) 331-3385 x735 --

as for the preprocessed source file, not that yet skilled at code.(one day) I added my .config, and the CFLAGS I used for building gcc. In regards to 4.6.0 everything seems o.k. i.g. glibc builds with no errors all of the xserver no errors, even firefox builds.. seems the kernel was the only real problem I ran into(which isn't really a problem given this version of gcc is experimental). maybe something todo with building modules (but could be wrong). Justin P. Mattock --

I couldn't resist..(had to play), anyways I looked through the reports but didn't see anything that was familiar. so I went and created an entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791 Justin P. Mattock --

the info from jie, worked, as well as: make kernel/rtmutex.i (from joe perches) Justin P. Mattock --

This patch fixes a memory leak by freeing priv in mc13783_regulator_remove Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Samuel Ortiz <sameo@linux.intel.com> --- drivers/regulator/mc13783-regulator.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git ...

Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next -- James Morris <jmorris@namei.org> --

In the comment of cap_file_mmap(), replace mmap_min_addr to be dac_mmap_min_addr. Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com> --- security/commoncap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index 6166973..c45c4d2 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -931,7 +931,7 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages) * @addr: address attempting to be ...

Multiple root devices here may help.. I recently added support for enumerating multiple root devices to kinit in klibc to work around some configuration issues on our servers. http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=5b5b6f5192af5c3fa30fe605e8842... --

But you just broke the kernel build at this point in the patch sequence, which is not allowed :( thanks, greg k-h --

Frederic, Send out v3 with Randy's updates and: Acked-by: Steven Rostedt <rostedt@goodmis.org> --

--- ~Randy --

You need to run make vmlinux and make modules (or simply make all) to generate a full list of exported symbols. Only doing one of the steps will generate a partial list, obviously. Michal --

On Mon, 19 Apr 2010 10:29:47 +0200 first of all, it's so bad that people will just turn the whole power management off... at which point fixing the really bad bug is actually on the machines I used this on (Core i7's) it's actually hardly measurable. All CPUs I have access to turn the voltage entirely off during idle, so while the frequency is higher, if you're mostly IO bound, it's only for very short durations... while still being mostly "off". -- Arjan van de Ven Intel Open Source ...

Is the improvement really because IO benefited from CPU being held at a higher frequency, or perhaps because it is now not scaled down during IO, so when CPU intensive part of git grep comes along it is already "revved up"? Or in other words, does a pure IO workload benefit from now higher selected frequency? One idea I had but a) never had time to implement it and b) was not sure it would be accepted anyway, was to modify ondemand governor to ramp up instantly, but slow down slowly (in a ...

be careful; you're measuring power not energy. You also need to take into account that things are now done quicker, so that you can then be idle longer later! So yes instantaneous you're using a bit more power (since you're getting much more performance), but you're done much quicker as well.... Once you do this the equation changes, and it's more or less a wash. As for your general "ondemand is for everyone" concern; there are many things wrong with ondemand, and I'm writing a new ...

Hi Farid, Applied, thanks. -- Jean Delvare --

We may use different configs. Also, your userland includes have to lack Good question. Does such a tree exist? I'm sitting on a few more um cleanups & fixes, and so far I'm working against Linus' tree as I failed to find anything more recent. Jan

Some are trivial, but most aren't. Will check if I can split the formers out, but I guess it's simpler to keep the queue. Thanks, Jan

applied to percpu#for-linus/next. Will push to Linus in a few days. Thanks. -- tejun --

Right, that should not happen, ever, min_vruntime should be monotonic. Fairness, a task's vruntime going backwards means it can obtain more I'm not sure that's a good idea, that'll end up being a 'fairer' scheduler in the strict sense, but I suspect it will break the wakeup That seems nice enough. But really, this changelog doesn't explain the cause at all. /me goes try and figure out where this min_vruntime goes backwards. So update_min_vruntime() is the sole place where we ...

No we don't, the next time it comes along it will at worst use the exact But these things will break the wakeup-preemption, you cannot change place_entity() without also considering It doesn't go backwards!! Show me where min_vruntime actually decreases? Sure can have entities that are left of min_vruntime, but that doesn't None-what-so-ever ;-) Now, theory says we should use the 0-lag point for task insertion, and I have a patch that tracks that point, but it adds extra ...

Done - https://bugs.freedesktop.org/show_bug.cgi?id=27744 Parag --

That seems to have fixed it. (This must be a heck of a wide race, or I'm very unlucky :) I hit it every single time, even if the machine is under heavy load...) --

I think that BUG_ON() would be a lot better as a printk() and fail mount instead. There's really little point in killing the kernel for something you could easily warn about and recover nicely. -- Jens Axboe --

*shrug* The BUG_ON directly above is not qualitatively different. In both cases the only solution is to find and fix the bug in some other file, recompile and try again. But ultimately I don't care, as long as we catch the bug before people lose their data. Feel free to respin this patch. You caused the problem in the first place. ;) For the record, while I consider the two-liner that causes this mess a real turd, the rest of your patch was brilliant. A shame I didn't catch this ...

Thank, but this does not help me. Maybe it really my bug. --

There is no relevant difference between the dmesg for 477346ff ("bisect-5": Unfortunately "shouldn't" isn't always the same as "doesn't" :-) $ cat /proc/fb 0 VESA VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c) Cheers, FJP

Thank you, Lai!!! I have added your Reviewed-by. --

Works as well. Reported-and-tested-by: Frans Pop <elendil@planet.nl> --

That fixes the problem too. Please add my: Reported-and-tested-by: Frans Pop <elendil@planet.nl> Cheers, FJP --

Yep, that's the culprit. Let me know if a fix needs to be tested. Thanks, FJP --

See files in attached tarball. Contents are: * system boot (docked) => alsa-info.txt_3[34]_docked * undock => alsa-info.txt_3[34]_undocked * suspend - dock (while suspended) - resume => alsa-info.txt_3[34]_after_resume_docked * undock - redock (this disables the internal speakers) That fixes the problem. Thanks, FJP

At Mon, 19 Apr 2010 13:59:36 +0200, Or how about the patch below? Takashi --- diff --git a/sound/pci/hda/patch_analog.c b/sound/pci/hda/patch_analog.c index 9cbd80c..2cf7d19 100644 --- a/sound/pci/hda/patch_analog.c +++ b/sound/pci/hda/patch_analog.c @@ -85,6 +85,9 @@ struct ad198x_spec { const char **slave_sws; }; +#define AD_HP_EVENT 0x01 +#define AD_MIC_EVENT 0x02 + /* * input MUX handling (common part) */ @@ -533,6 +536,11 @@ static int ad198x_resume(struct ...

-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@canonical.com] Sent: Sunday, April 18, 2010 7:33 PM To: Nguyen Dinh-R00091 Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux@arm.linux.org.uk; s.hauer@pengutronix.de; valentin.longchamp@epfl.ch; daniel@caiaq.de; grant.likely@secretlab.ca; bryan.wu@canonical.com; Herring Robert-RA7055; Li Jun-R65092; Zhang Lily-R58066 Subject: Re: [PATCHv4 2.6.34-rc4 2/7] mx5: Add USB device definitions for ...

Sorry, I messed up the To/Cc fields in my reply. The above was directed to Nguyen Dinh of course, not to Sascha. --

Also, patch 3 really belongs with this patch too since the #defines in patch 3 are used here. -- ---------------------------------------------------------------------- Amit Kucheria, Kernel Engineer || amit.kucheria@canonical.com ---------------------------------------------------------------------- --

Yes, of course. Sorry I didn't see this when reviewing. Think about what's necessary to add support for a new board. You don't want to copy all the register accessing functions again but re-use and share generic code. All you need to have in the board specific support code are flags which are passed to the generic driver core. Just like all other board support code does it as well. Not just for USB btw. but for all sorts of other drivers as wel. Have a look at code which is already there to ...

The trigger for busy inodes is as simple as (I=initialization done only once): I> # dd if=/dev/zero of=/dev/shm/ext3 bs=1024 count=1 seek=$((100*1024)) I> # mkfs.ext3 -m 0 /dev/shm/ext3 # mount -oloop /dev/shm/ext3 /mnt/c # umount /mnt/c # dmesg|tail VFS: Busy inodes after unmount of loop0. Self-destruct in 5 seconds. Have a nice day... I don't know, now I'm going to play with that as I have the trigger ;). Will be back soon. thanks, -- js --

anon_vma for hugetlb pages sounds overkill, what would it gain? In this context, futex only appears to distinguish between whether the references are private or shared. Looking at the hugetlbfs code, I can't see a place where it actually cares about the mapping as such. It's used to find shared pages in the page cache (but not in the LRU) that are backed by the hugetlbfs file. For hugetlbfs though, the mapping is mostly kept in page->private for reservation accounting purposes. I can't ...

Are you ok with an Ack to this slightly-difference patch too? If so, I'll forward it on to Andrew. ==== CUT HERE ==== Fix infinite loop in get_futex_key when backed by huge pages If a futex key happens to be located within a huge page mapped MAP_PRIVATE, get_futex_key() can go into an infinite loop waiting for a page->mapping that will never exist. This was reported and documented in an external bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=552257 This patch makes ...

Wouldn't a longer poison be more recognisable? Also, shouldn't this use POISON_POINTER_DELTA? Something like: #define HUGETBL_POISON ((void *) 0x00300300 + POISON_POINTER_DELTA) --

Well, most poison values have that problem and still we have them. Also on 64bit machines you can use POISON_POINTER_DELTA to map it outside the virtual address range. --

Thanks Mel, I'm also keen to keep hugetlb awareness out of futex.c, it's crazy enough in there already! Acked-by: Darren Hart <darren@dvhart.com> r6144, would you consider taking a look at the futextest test suite and letting me know where you think it might need improvement to catch what you ran into in your tests. I'm thinking some options to futex_wait and possibly other tests to tell it where to map the futex ...

Hi Corrado, low_latency is set to zero in all tests. The layout difference doesn't explain why setting the scheduler to "noop" consistently speeds up read throughput in 8-thread tiobench to almost twice. This fact alone pretty clearly indicates that the I/O scheduler is the culprit. There are other indications, see the attached btt output for both traces. From there it appears that 2.6.16 does more and longer seeks, yet it's getting an overall better performance. I've also tested ...

Hi Andrew, I've tested your patches against 2.6.34-rc4 on lvm/ext4. I'm not seeing any vm bugs, so it all looks good to me. thanks Richard --

Hi jon, Thanks for your suggestion again. I joined the netdev and send my patch to "netdev <netdev@vger.kernel.org>". -- Hello netdev users, I developed the device drivers for Linux kernel 2.6.33-1. This time, I added the following drivers - GbE device - Packet HUB device The GbE and Packet Hub device drivers are related with each other. Because I send patch to LKML <linux-kernel@vger.kernel.org> and the netdev <netdev@vger.kernel.org> mailing list. Would you check them? The ...

Are you referring to my previous patch by saying "then they get tweaked to support a semi-dynamic state"? Those were just a proposal which was never Yes, I agree. That's why in the first version I proposed the __usb_init, __usb_exit, etc. tags which could be customized prior to including composite related files. I would still go with that solution but it was considered, let me find the exact phrase, "Ick ick ick." :) What's more, I don't see any other (that is cleaner) solution ...

Any specific reason why the default llseek() is in this patch? Regards, Jan -- Jan Blunck <jblunck@suse.de> --

A later patch moves both default_llseek and deprecated_ioctl into the new bkl.ko module, while this is just the minimal preparation for getting all the users changed. It was intentional but not important to do the move now. Arnd --

On Fri, 16 Apr 2010 05:08:00 +0200 I'm all confused. The affects sys_faccesat(), yes? But sys_faccesat() never gets passed a `flags' argument so how does the behaviour which the FACCESSAT(2) manpage describes get implemented? This patch doesn't actually change kernel behaviour, so how can setting AT_EACCESS change any syscall's actions? It's a bit of a worry that the proposed value for AT_EACCESS duplicates AT_REMOVEDIR. I guess that, despite apeparances, they're different namespaces. ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The function is implemented at userlevel. The kernel code has the same name but isn't a complete implementation. There is no point in defining the symbol in the kernel headers. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - ...

Bruce, the alternative would be to include the check in the fs readdir() implementation, and therefore prevent the call of the filler. I think this patch would be even bigger. --

This doesn't seem to have incorporated my feedback from the attached... -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation

Hmm, why not. Or even the ino of the directory we are reading from ... Regards, Jan -- Jan Blunck <jblunck@suse.de> --

Hm, I'm not sure whether I lost the patch in a rebase or didn't have time to test it or what. I was hoping someone who actually knows JFFS2 like Felix or you would get to it first - in general, I'd like the underlying file system maintainers to implement whiteouts and fallthrus since they know them best. Felix, if you implemented it and I lost the patch, my apologies to you. Thanks David, --

Acked-by: Randy Dunlap <randy.dunlap@oracle.com> -- ~Randy --

That's ok, thanks you for the report. I'm afraid I made little progress as I spent most of the day on other bugs but I do have something for you. First, I reproduced the problem using your .config. However, the problem does not manifest with the .config I normally use which is derived from the distro kernel configuration (Debian Lenny). So, there is something in your .config that triggers the problem. I very strongly suspect this is an interaction between migration, compaction and page ...

Well, that's going to be a mighty large patch. I'd rather see smaller patches, say one patch per removal of a weak hw_perf interface, etc... --

Ok, I'll continue that then. Thanks. Cheers, Don --

I'd prefer relative patches as the current perf/nmi bits are tested quite well. Intermediate stages are not a problem: 90% of the code in the kernel's Git history is 'intermediate' as well, in hindsight. What matters is that the workflow that resulted was clean and that the patches were (and are) clean. Ingo --

All of them? I though tsc stops in some mwait deep REM sleep thing. So what do we need? test for both TSC_RELIABLE and NONSTOP_TSC? IMO TSC_RELIABLE should imply NONSTOP_TSC. -- error compiling committee.c: too many arguments to function --

I think delta calculation introduces errors. Marcelo can probably confirm it, but he has a nehalem with an appearently very good tsc source. Even this machine warps. It stops warping if we only write pvclock data structure once and forget it, (which only updated tsc_timestamp once), according to him. Obviously, we can't do that everywhere. --

atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever implementation for smp i386? -- error compiling committee.c: too many arguments to function --

Fun, we also have: X86_FEATURE_NONSTOP_TSC, which states the thing doesn't stop in C states. --

ACCESS_ONCE() is your friend. --

and this maps to NONSTOP, so I think we're fine. -- error compiling committee.c: too many arguments to function --

Upstream, we are marking the TSC unstable preemptively when hardware which will eventually sync test is detected, so this should be fine. Zach --

Not sure, IIRC we clear that when the TSC sync test fails, eg when we mark the tsc clocksource unusable. --

Oh yes, just trying to avoid a patch with both atomic64_read() and ACCESS_ONCE(). -- error compiling committee.c: too many arguments to function --

Right, another option is to put the initial read outside of the loop, that way you'll have the best of all cases, a single LOCK'ed op in the loop, and only a single LOCK'ed op for the fast path on sensible architectures ;-) last = atomic64_read(&last_value); do { if (ret < last) return last; last = atomic64_cmpxchg(&last_value, last, ret); } while (unlikely(last != ret)); Or so. --

Yes it is. But as I said, this seem to be a very deep worst case scenario. Most of boxes The offsets usually seem pretty small, under a microsecond. So I don't think it has anything to do with tscs starting out of sync. Specially because the delta-based calculation has the exact purpose of handling that case. --

This patch writes last_value atomically, but reads it non-atomically. A barrier is insufficient. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. --

Well, on a 32b system, you can explicitly order the updates of low and high, then do a high-low-checkhigh read. That would be much more efficient than atomic64. If we really care about 32b. J --

Applied. Thanks! -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

On Mon, 19 Apr 2010 14:36:31 -0700 hm. I wonder how you go from a bugzilla attachment back up tot he bug to which it is attached? Oh well. Alexey, I trust that patch is in the 2.6.34 queue? Thanks. --

On Wed, 14 Apr 2010 08:12:57 -0700 Presumably acpi_ex_extract_from_field() fed zero into (the misnamed) ACPI_ROUND_UP_TO(). I'll ask Rafael and Maciej to track this as a post-26.33 regression, thanks. --

I don't know.. maybe backwards thinking(me lefthanded people cool.. Justin P. Mattock --

Hi Takashi, Instead of looking at the product id, can we check the number of supported extended capabilities queries and act accordingly, like the patch below? Thanks. -- Dmitry Input: Add support of Synaptics Clickpad device From: Takashi Iwai <tiwai@suse.de> The new type of touchpads can be detected via a new query command 0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits. When the device is detected, the driver now reports only the left button as the supported ...

At Fri, 16 Apr 2010 10:00:20 +0200, The revised patch with an addition of LED_TOUCHPAD is below. thanks, Takashi === From: Takashi Iwai <tiwai@suse.de> Subject: [PATCH] input: Add LED support to Synaptics device The new Synaptics devices have an LED on the top-left corner. This is controlled via the command 0x0a with parameters 0x88 or 0x10. The detection of the LED isn't clear yet. It should have been the new capability bits that indicate the presence, but on real machines, ...

Can't help with the details, but the patch seems to help here, too (and not only because of the removed printk ;)). Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |

Right, so the IBM folks who were looking at power aware scheduling were working on an interface to quantify the amount of power to save. But their approach, was an extension of the regular power aware load-balancer, which basically groups tasks onto sockets so that whole sockets can go idle. However Arjan explained to me that your approach, which idles the whole machine, has the advantage that also memory banks can go into idle mode and save power. Still in the interest to cut back on ...

OK, so what you're saying is that because we update calc_load_tasks from entering idle, we decrease earlier than a regular 10 tick sample interval would? Hence you batch these early updates into _deferred and let the next 10 tick sample roll them over? So the only early updates can come from pick_next_task_idle()->calc_load_account_active(), so why not specialize that callchain instead of the below? Also, since its all NO_HZ, why not stick this in with the ILB? Once people get around to ...

(stripped the ubuntu kernel-team list, since it is generating bounces for each email) Ah, I overlooked that trigger_load_balance() already has a jiffy delay. I was ass-uming we triggered the softirq on each tick. Yes, that needs a bit of a fix to get called at least every 10 ticks, Right, so I didn't look too closely either, but was more or less going for the structure than the details. I haven't read through the ILB stuff current cpu is idle_at_tick, if not it will nominate another cpu ...

On Thu, 15 Apr 2010 00:58:05 -0500 Can you go through and revert them individually please? --

Peter, please see my updated version below. -Robert --- From bcb2c4aec6bf09fc7c05f31dde9dacd57b9c679c Mon Sep 17 00:00:00 2001 From: Robert Richter <robert.richter@amd.com> Date: Mon, 19 Apr 2010 15:32:37 +0200 Subject: [PATCH] perf, x86: setup NMI handler for IBS This implements the perf nmi handler for ibs interrupts. The code was copied from oprofile and should be merged somewhen. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/kernel/cpu/perf_event.c ...

There should be a comment clarifing it now. I admit the naming fault is mine. At the time, the intended meaning was "allocate pages from any node in the fallback list and the caller knows exactly which node to start from". I did not take into account that the meaning of "exact" depends on context. With a comment clarifying the meaning, I do not think a rename is necessary. However, I'd rather not see a mass renaming of functions like alloc_pages() that have existed a long times. If nothing ...

Its not awkward but an optimization. The page can be placed on any node but the user would prefer a certain node. Most of the NUMA things are there for optimization purposes and not for correctness. If you must have an allocation on certain nodes for correctness (like SLAB) then Its not clear to me that this renaming etc helps. You must use GFP_THISNODE if allocation must occur from a certain node. alloc_pages_exact_node results in more confusion because it does suggest that fallback to other ...

Hello, Christoph. I can't see why alloc_pages_exact_node() exists at all. It's in the mainline and if you look at the difference between alloc_pages_node() and alloc_pages_exact_node(), it's almost silly. :-( -- tejun --

Hmm, before going further, will you explain why we need a new PCG_MIGRATION flag ? What's the problem of v2 ? Thanks, Daisuke Nishimura. --

Thank you for explaining in detail. Anyway, I agree that current implementation is complicated and there might be some cases we are missing. MIGRATION flag can make it simpler. I have one concern for now. Reading the patch, the flag have influence on only anonymous pages, so we'd better to note it and I feel it strange to set(and clear) the flag of "old page" always(iow, even when !PageAnon) in prepare_migration. Thanks, Daisuke Nishimura. --

Why do you even need this context argument? Reclaim is not doing anything smart about this, it would just call each call shrinker in turn. Do you not have an easily traversable list of mountpoints? Can you just make a list of them? It would be cheaper than putting a whole shrinker structure into them anyway. The main reason I would be against proliferation of dynamic shrinker registration would be that it could change reclaim behaviour depending on how they get ordered (in the cache the ...

I think that part of the problem is that at roughly the same time writeback started on a long down hill slide as well, and we've really only fixed that in the last couple of kernel releases. Also, it tends to take more that just writing a few large files to invoke the LRU-based writeback code is it is generally not invoked in filesystem "performance" testing. Hence my bet is on the fact that the effects of LRU-based writeback are rarely noticed in common testing. IOWs, low memory testing is ...

I'd personally hope that this is solved long before the LSF/VM workshops.... but if not, yes, we should definitely tackle it then. - Ted --

Bah, Johannes corrected my literal mind. har de har har :) -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Of course. It's not formal patch but for showing concept . :) Thanks for consuming precious your time. :) As Nick comments, I have to do further work. Maybe Nick could do it faster than me. Anyway, I hope it can solve your problem. -- Kind regards, Minchan Kim --

Thanks, yep something like this is what I had in mind. Looks like you I think I would prefer to be a little smarter about using lower addresses first. I know the lazy TLB flushing works against this, but that is an important speed tradeoff, wheras there is not really any downside to trying hard to allocate low areas first. Keeping virtual addresses dense helps with locality of reference of page tables, for one. So I would like to see: - invalidating the cache in the case of vstart being ...

I'm not maintaining a 2.6.27 kernel, but if someone else is, then feel free to include this. -- Steve --

Gang-scheduling maybe the ideal solution to solve the issue, and has to change host's scheduler a lot to implement it, and it maybe hard to be upstream. So can we figure out an easy way(maybe not best) for this ? Xiantao --

That's the sort of thing you can use arch_scale_smt_power() for. But be weary to not fall into the same trap I did with x86, where I confused actual gain with capacity (When idle the actual gain is 0, but the capacity is not). --

[ patch to do very long queues ] One thing that comes from having preemptible mmu_gather, and esp. when we allow such very long gathers, is that we can potentially have a very large amount of pages stuck on these lists. So we'd need to hook into reclaim somehow to allow flushing of them when we're falling short. --

This is food for thought. On XFS, the only difference between sync and freeze is that freeze stops incoming writers: $ dd if=/dev/zero of=/mnt/scratch/test bs=1024k count=8000 & [1] 2565 $ sleep 5; time (sudo xfs_freeze -f /mnt/scratch ; sudo xfs_freeze -u /mnt/scratch) real 0m2.536s user 0m0.000s sys 0m0.020s $ sleep 5; time (sudo xfs_freeze -f /mnt/scratch ; sudo xfs_freeze -u /mnt/scratch) real 0m2.251s user 0m0.004s sys 0m0.012s $ sleep 5; time (sudo xfs_freeze ...

As Dmitry pointed out here: http://lkml.org/lkml/2010/4/8/214 This bit of code looks broken, especially since the comment has been left alone by the patch. I think commit ae6bf53e should be reverted because semantically all it does is remove the smp_wmb() above. Please let me know what you think, Will --

--

We can only check what the kernel tells us before power off, but all that seems If a GPE is enabled, then some part of the chipset has power provided so that it can signal wakeup. I'll look into it a bit more later today. Thanks, Rafael --

Hi Guenter, I wanted to check where we are at... at the very least we should drop messages issued before initialization when isVGA != 1. Since serial ports require initialization, I really don't want to send messages to the serial port before the port has been initialized, but obviously it would be good to initialize earlyprintk as early as at all possible. -hpa --

And I need to wait until it goes into Linus's tree before it can be applied to the stable tree. This hasn't happened yet, right? thanks, greg k-h --

Ok, I'm totally confused now :( What patch should I apply to a stable release, and which stable release? thanks, greg k-h --

Right, only to the UTS ns in which you live. See for instance http://thread.gmane.org/gmane.linux.kernel.containers/15934 . It's how we express for instance that root in a child user_namespace has CAP_DAC_OVERRIDE over files in the container, but not over the host. -serge --

hmm... Absolutely these should not be ignored, and Eric didn't mean to ignore I do not agree with deciding the admins are not competent to admin their system and therefore we should bypass them and let users decide. But it's moot, as I think you've convinced me with your point 1. above Yes, but that's a reason to aim for targeted caps. Exec_nopriv or Not sure what you mean by that last part - inside the sandbox, you won't get capabilities, targeted or otherwise, but certainly ...

As i said, I am working full time on it. PL330 core and S3C DMA API driver is done and it'll be a day or two before I am done testing them. So, around this wednesday I plan to submit patches for PL330 core driver and the S3C-DMA-API driver for S5P-6442, C1XX and V210 Once the PL330 core is accepted, we can freeze it's API and start work on DMA engine API driver for it. --

Sorry for replying that late, but after digging through another pile of tasks I'm happy to come back to this issue and I'll try to answer all open questions. Fortunately I'm also able to add a few new insights that might resurrect this discussion^^ For the requested CFQ scheduler tuning, its deadline what is here :-) So I can't apply all that. But in the past I was already able to show that all the "slowdown" occurs above the block device layer (read back through our threads if interessted about ...

Ok, it's now queued up, thanks for letting me know. greg k-h --

So I'm back with another one even with this patch. Would people prefer another thread? [ 0.037175] =================================================== [ 0.038003] [ INFO: suspicious rcu_dereference_check() usage. ] [ 0.039003] --------------------------------------------------- [ 0.040004] include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection! [ 0.041003] [ 0.041004] other info that might help us debug this: [ 0.041005] [ 0.042004] [ ...

From: Kishore Kadiyala <kishore.kadiyala@ti.com> This patch improves low speeds for SD cards. OMAP-MMC controller's can support maximum bus width of '8'. when bus width is mentioned as "8" in controller data,the SD stack will check whether bus width is "4" and if not it will set bus width to "1" and there by degrading performance. This patch fixes the issue and improves the performance of SD cards. Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Venkatraman S ...

Saves 40W or so on a dual-socket Nehalem system here. Is there a reason it wasn't picked up? -- Matthew Garrett | mjg59@srcf.ucam.org --