pxms are mapped to low node ids to maintain generic kernel use of functions such as pxm_to_node() that are used to determine device affinity. Otherwise, there is no pxm-to-node and node-to-pxm matching rule for x86_64 users of NUMA emulation where a single pxm may be bound to multiple NUMA nodes. Signed-off-by: David Rientjes <rientjes@google.com> --- drivers/acpi/numa.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/numa.c ...

Greg / Alan, - moved to staging and completely self-contained - REMOVed the sysfs entry creation at root and replaced it with sending events via rfkill. - verified and working with new logic - patch re-ordered Note: --

From: Pavan Savoy <pavan_savoy@ti.com> Kernel Space Init-Manager works along with User-Mode Init Manager daemon running to maintain the UART state. Communication between user-space daemon and this module can be 1. Via the pid written onto sysfs entry 2. Via the rfkill subsystem It also is a platform driver with a relevant platform device in the board-*.c along with the list of BT/FM/GPS chip enable gpio configuration Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> --- ...

From: Pavan Savoy <pavan_savoy@ti.com> Texas Instruments BT, FM and GPS combo chips/drivers make use of a single TTY to communicate with the chip. This module constitutes the core logic, TTY ldisc driver and the exported symbols for registering/unregistering of the protocol drivers such as BT/FM/GPS. Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> --- drivers/staging/ti-st/st_core.c | 1057 +++++++++++++++++++++++++++++++++++++++ drivers/staging/ti-st/st_core.h | 92 ++++ 2 files ...

From: Pavan Savoy <pavan_savoy@ti.com> This is BlueZ driver making use of Shared Transport line discipline to communicate with the chip. Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> --- drivers/staging/ti-st/bt_drv.c | 502 ++++++++++++++++++++++++++++++++++++++++ drivers/staging/ti-st/bt_drv.h | 61 +++++ 2 files changed, 563 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/ti-st/bt_drv.c create mode 100644 drivers/staging/ti-st/bt_drv.h diff --git ...

From: Pavan Savoy <pavan_savoy@ti.com> Texas Instruments BT, FM and GPS combo chips/drivers make use of a single TTY to communicate with the chip. This module constitutes the proprietary power management protocol from TI for the BT/FM/GPS combo chips Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> --- drivers/staging/ti-st/st_ll.c | 169 +++++++++++++++++++++++++++++++++++++++++ drivers/staging/ti-st/st_ll.h | 67 ++++++++++++++++ 2 files changed, 236 insertions(+), 0 deletions(-) ...

This patch adds additional LPC Controller DeviceIDs for the Intel Cougar Point PCH. The DeviceIDs are defined and referenced as a range of values, the same way Ibex Peak was implemented. This patch was built against the linux-next.git tree. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- include/linux/pci_ids.h.orig 2010-03-25 15:42:47.000000000 -0700 +++ include/linux/pci_ids.h 2010-03-25 16:00:31.000000000 -0700 @@ -2419,8 +2419,8 @@ #define ...

From: Arnaldo Carvalho de Melo <acme@redhat.com> Just like in the kernel and also to remove the need to include perf.h in the symbol subsystem. Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> --- tools/perf/perf.h | 2 -- tools/perf/util/include/linux/compiler.h | 2 ++ 2 files changed, 2 ...

From: Arnaldo Carvalho de Melo <acme@redhat.com> To reduce the coupling of the symbol system with the rest of perf. Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> --- tools/perf/util/event.c | 3 ++- tools/perf/util/map.c | 11 ++++------- tools/perf/util/map.h | 5 ++--- 3 files changed, 8 insertions(+), ...

From: Zhang, Yanmin <yanmin_zhang@linux.intel.com> Reported-by: Li Zefan <lizf@cn.fujitsu.com> Tested-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> --- tools/perf/builtin-record.c | 2 +- tools/perf/builtin-top.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index bb5b23d..60ecdd3 100644 --- ...

Hi, The commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 which can be seen here: http://kerneltrap.org/mailarchive/git-commits-head/2008/4/28/1639134 Breaks all non-GPL modules that use __vmalloc() or any of the vmap(), vm_map_ram(), etc functions on MIPS architecture. All those functions are EXPORT_SYMBOL() so are meant to be allowed to be used by non-GPL kernel modules. These calls all take page protection as an argument which is normally a constant like PAGE_KERNEL. This commit ...

From: Pavan Savoy <pavan_savoy@ti.com> Kernel Space Init-Manager works along with User-Mode Init Manager daemon running to maintain the UART state. Communication between user-space daemon and this module can be 1. Via the pid written onto sysfs entry 2. Via the rfkill subsystem It also is a platform driver with a relevant platform device in the board-*.c along with the list of BT/FM/GPS chip enable gpio configuration Signed-off-by: Pavan Savoy <pavan_savoy@ti.com> --- ...

Last known good: 2.6.33 Failing kernels: 2.6.34-rc1 and 2.6.34-rc2 Driver: Video(DRI - Intel) When XWindow starts I got: Mar 25 19:58:10 gumis kernel: [ 133.624028] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 25 19:58:10 gumis kernel: [ 133.624221] render error detected, EIR: 0x00000000 Mar 25 19:58:10 gumis kernel: [ 133.624291] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 ( awaiting 691 at 682) Mar 25 19:58:11 gumis kdm[2592]: ...

Since anticipatory IO scheduler was removed, copy_io_context() function isn't used anymore, so this patch removes it. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- block/blk-ioc.c | 14 -------------- include/linux/iocontext.h | 1 - 2 files changed, 15 deletions(-) diff -upkr linux-2.6.33/block/blk-ioc.c linux-2.6.33/block/blk-ioc.c --- linux-2.6.33/block/blk-ioc.c 2010-02-24 21:52:17.000000000 +0300 +++ linux-2.6.33/block/blk-ioc.c 2010-03-25 22:49:30.000000000 ...

Hi, I wrote a gpiolib implementation for Technologic Systems TS-5500 boards (x86) custom GPIO lines. Some of their GPIO lines are directly hooked to CPU (ElanSC520) GPIRQ lines, so they can trigger IRQs. However, looking at arch/x86/include/asm/gpio.h: /* * Not implemented, yet. */ static inline int gpio_to_irq(unsigned int gpio) { return -ENOSYS; } gpio_to_irq()/irq_to_gpio() are not defined on x86 yet. Q: Is there a reason not to have it call gpiolib's __gpio_to_irq(), ...

On latest git, I'm seeing "start_kernel(): bug: interrupts were enabled early" messages on ARM (sample log below). This appears to be caused by: start_kernel -> radix_tree_init -> kmem_cache_create (slub) -> down_write -> __down_write (lib/rwsem-spinlock.c) -> spin_unlock_irq radix_tree_init was moved earlier by: commit 773e3eb7b81e5ba13b5155dfb3bb75b8ce37f8f9 Author: Yinghai Lu <yinghai@kernel.org> Date: Wed Feb 10 01:20:33 2010 -0800 init: Move radix_tree_init() ...

Please ignore the above message, if you haven't already. set_sw_state or set_hw_state should have called set_events. The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ --

Adds the support for the DMA engine withing the timberdale FPGA. The DMA channels are strict device to host, or host to device and can not be used for generic memcpy. Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com> --- diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index c27f80e..a2fcb2e 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -149,6 +149,13 @@ config AMCC_PPC440SPE_ADMA help Enable support for the AMCC PPC440SPe RAID engines. ...

How do I send an rfkill event upon device /dev/rfkill from kernel space ? An action upon my driver, should break the poll on /dev/rfkill from a user-space daemon, but sending an OP_CHANGE event. As I've seen only writing blocked/non-blocked on the sysfs entry of an rfkill device generates an rfkill event. Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/ --

find the gendisk that the queue manages. --- block/blk-cgroup.c | 10 ++++++---- block/blk-sysfs.c | 4 ++++ include/linux/blkdev.h | 6 ++++++ 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 917957d..809451f 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -179,16 +179,18 @@ static int blkiocg_##__VAR##_read(struct cgroup *cgroup, \ struct blkio_cgroup *blkcg; \ struct blkio_group ...

Use request_queue to find the blkio_group of a device, rather than a cfq_data pointer. Additionally, it allows the blk-cgroup code to depend on the queue pointer itself. This avoids doing lookups for dev_t and facilitates looking up the device's human-readable name in later patches. --- block/blk-cgroup.c | 17 ++++++++--------- block/blk-cgroup.h | 13 +++++++------ block/cfq-iosched.c | 22 ++++++++++------------ 3 files changed, 25 insertions(+), 27 deletions(-) diff --git ...

Hi Chad, Where is the code to make sure gendisk does not go away if blk-cgroup code is referencing blkg->queue->disk under rcu lock? Thanks Vivek --

arch/x86/mm/init_64.c: linux/bootmem.h is included more than once. Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> --- arch/x86/mm/init_64.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index e9b040e..a544bec 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -49,7 +49,6 @@ #include <asm/numa.h> #include <asm/cacheflush.h> #include <asm/init.h> -#include <linux/bootmem.h> static ...

tools/perf/util/probe-finder.c: string.h is included more than once. Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> --- tools/perf/util/probe-finder.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c index 1e6c65e..682eb37 100644 --- a/tools/perf/util/probe-finder.c +++ b/tools/perf/util/probe-finder.c @@ -32,7 +32,6 @@ #include <stdarg.h> #include <ctype.h> -#include "string.h" ...

I'm an asshole... Sorry, you're right. Ciao, Andrea --

tools/perf/builtin-trace.c: util/exec_cmd.h and util/trace-event.h are included more than once. Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> --- tools/perf/builtin-trace.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c index 407041d..3c699c5 100644 --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -59,9 +59,6 @@ static int cleanup_scripting(void) #include "perf.h" #include ...

Looks good. -Alex --

arch/arm/mach-mx3/mach-pcm037.c: linux/fsl_devices.h is included more than once. Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> --- arch/arm/mach-mx3/mach-pcm037.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c index 11f5315..a550ae9 100644 --- a/arch/arm/mach-mx3/mach-pcm037.c +++ b/arch/arm/mach-mx3/mach-pcm037.c @@ -35,7 +35,6 @@ #include <linux/can/platform/sja1000.h> #include ...

arch/arm/mach-at91/board-sam9m10g45ek.c: mach/hardware.h is included more than once Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> --- arch/arm/mach-at91/board-sam9m10g45ek.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c index 98f9f4b..ee80059 100644 --- a/arch/arm/mach-at91/board-sam9m10g45ek.c +++ b/arch/arm/mach-at91/board-sam9m10g45ek.c @@ -25,7 +25,6 @@ #include ...

These patches fix a "pci=use_crs" regression and print a little more debug information for resource allocation conflicts. --- Bjorn Helgaas (2): x86/PCI: for host bridge address space collisions, show conflicting resource x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1 arch/x86/pci/acpi.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) --

Yanko's GA-MA78GM-S2H (BIOS F11) reports the following resource in a PCI host bridge _CRS: [07] 32-Bit DWORD Address Space Resource Min Relocatability : MinFixed Max Relocatability : MaxFixed Address Minimum : CFF00000 (_MIN) Address Maximum : FEBFFFFF (_MAX) Address Length : 3EE10000 (_LEN) This is invalid per spec (ACPI 4.0, 6.4.3.5) because it's a fixed size, fixed location descriptor, but _LEN != _MAX - _MIN + 1. Based ...

We must tell GCC to use even register for variable passed to ldrd instruction. Without this patch GCC 4.2.1 puts this variable to r2/r3 on EABI and r3/r4 on OABI, so force it to r2/r3. This does not change anything when EABI and OABI compilation works OK. Without this patch and with OABI I get: CC drivers/mtd/nand/orion_nand.o /tmp/ccMkwOCs.s: Assembler messages: /tmp/ccMkwOCs.s:63: Error: first destination register must be even -- `ldrd r3,[ip]' make[5]: *** ...

It's probably worth including the people who weighed in on the The "register...asm" looks fine, but it occurs to me the constraints are too weak (and they were before), so GCC could optimise that to the wrong behaviour. The "volatile" prevents GCC deleting the asm if it's output isn't used, but it doesn't stop GCC from reordering the asms, for example if it decides to unroll the loop. It probably won't reorder in that case, but it could. The result would be out of order values ...

Convert the device_terminate_all() operation on the DMA engine to a generic device_control() operation which can now optionally support also pausing and resuming DMA on a certain channel. Implemented for the COH 901 318 DMAC as an example. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Cc: Maciej Sosnowski <maciej.sosnowski@intel.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Li Yang <leoli@freescale.com> Cc: Guennadi Liakhovetski ...

Convert the device_is_tx_complete() operation on the DMA engine to a generic device_tx_status()operation which can return three states, DMA_TX_RUNNING, DMA_TX_COMPLETE, DMA_TX_PAUSED. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Cc: Maciej Sosnowski <maciej.sosnowski@intel.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Li Yang <leoli@freescale.com> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Paul Mundt <lethal@linux-sh.org> Cc: ...

[snip] General: you converted all drivers to the new .device_tx_status() API, but since they don't implement "residue," you left it uninitialised everywhere. Wouldn't it be better to set it to 0 or total length, In the original proposal by Dan Williams the last member was "unsigned long pos." I don't think, even on 64-bit systems anyone would kick off a > 4GB transfer, but who knows... And - I don't particularly like the name "pos," but I do like the idea of returning bytes transfered ...

Why not assign one of the two - 0 if the transfer is complete (DMA_SUCCESS status returned) or whatever max count otherwise? Except I do think this might confuse some users - seeing a residue larger than the total transfer length... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --

This patch set will enable generic functions for controlling slave transfers, e.g. the ability to pause and resume transfers, as well as the ability to read a wider status including not only the current and last transfer cookie but also the residual bytes left on a channel. This was discussed by Dan and Guennadi some while back and now I implemented it. I did my best to read my own code over and over again so I didn't break anything, but please review again. I need help: does someone have ...

Hi, I have a system where bootloader supports core0 running linux (control plane). core1 running application without OS (a data plane app). (core0 and core1 share some physical memory) Because of this setup and application requirements I want to ocassionally disable preemption of linux kernel for very small periods from user space process. Is the following valid solution to achive this ? I will load a kernel module foo.ko which supports the following ioctl's from user ...

That is an oddity, I tried to show a general case. We could append more info about that special case if you wish. --

£1,000,000Pounds has been awarded to you in the U.KPROMO.send your details as follows: Names,,,,,,,,, Tel,,,,,,,,,,, Age,,,,,,,,,,, Address,,,,,,,,,,,, Occupation,,,,,,,,,,, Country,,,,,,,,,,,,,, Email:bnlclaims2010@live.co.uk --

Move all debugctlmsr thingies into msr-index.h Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- arch/x86/include/asm/msr-index.h | 13 ++++++++----- arch/x86/kernel/cpu/perf_event_intel_ds.c | 23 +++++++---------------- arch/x86/kernel/cpu/perf_event_intel_lbr.c | 7 ++----- 3 files changed, 17 insertions(+), 26 deletions(-) Index: linux-2.6/arch/x86/include/asm/msr-index.h =================================================================== --- ...

TIF_DEBUGCTLMSR is trampling all over that MSR without regard for other uses (perf) and doesn't provide the flexibility needed for perf. Its users are ptrace-block-step and ptrace-bts, since ptrace-bts was never used and ptrace-block-step can be implemented using a much simpler approach axe all of it. Cc: Markus Metzger <markus.t.metzger@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- arch/x86/Kconfig.cpu | 20 ...

When using VT6410/6415/6330 chips on some VIA's platforms, the HDD connects to VT6410/6415/6330 cannot be detected. It is because the driver detects wrong via_isa_bridge ID, and then cause the this issue happen. This patch will fix this problem. Signed-off-by: Joseph Chan<josephchan@via.com.tw> --- a/drivers/ata/pata_via.c 2010-03-16 06:00:01.000000000 -0400 +++ b/drivers/ata/pata_via.c 2010-03-25 08:47:15.000000000 -0400 @@ -576,6 +576,10 @@ u8 rev = isa->revision; ...

I stand corrected, missed that for prototypes. Sorry for the noise. -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |

Hi Henrik, thanks for the work. Please, just keep the placement of those attributes Right. (I think checkpatch checks for this, too) Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |

Compiling this driver gave a section mismatch, so I reviewed the init/exit paths of the driver and made the correct changes. WARNING: drivers/isdn/hisax/built-in.o(.text+0x56bfb): Section mismatch in reference from the function teles_cs_config() to the function .devinit.text:hisax_init_pcmcia() The function teles_cs_config() references the function __devinit hisax_init_pcmcia(). This is often because teles_cs_config lacks a __devinit annotation or the annotation of hisax_init_pcmcia is ...

Compiling this driver gave a section mismatch, so I reviewed the init/exit paths of the driver and made the correct changes. WARNING: drivers/isdn/hisax/built-in.o(.text+0x55e37): Section mismatch in reference from the function elsa_cs_config() to the function .devinit.text:hisax_init_pcmcia() The function elsa_cs_config() references the function __devinit hisax_init_pcmcia(). This is often because elsa_cs_config lacks a __devinit annotation or the annotation of hisax_init_pcmcia is ...

Acked-by: <keil@b1-systems.de> Thank you for fixing this. --

No, checkpatch doesn't claim about that. Greets, Henrik --

From: Dominik Brodowski <linux@dominikbrodowski.net> I'll apply them. --

From: Karsten Keil <isdn@linux-pingi.de> Thanks for reviewing Karsten. Please put your proper name in your ACK lines in the future, they should look just like Signed-off-by: lines. I fixed this up when committing, thanks again. --

Reorder structure to remove 8 bytes of padding on 64 bit builds. This shrinks the size to 128 bytes so allowing allocation from a smaller slab & needed one fewer cache lines. Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> ---- patch against 2.6.34-rc2 compiled & booted on x86_64 regards Richard diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 05a9f83..421db5e 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -422,6 +422,7 ...

No, but something similar I guess. I wrote my own tool that parses the debug data & filters out the interesting results ;) Richard --

It is a 100% bogus warning. There are tentative patches floating around to fix the above warning, but they haven't been merged yet. In the meantime, please ignore... Cheers Trond --

Hi, Now in the GFS2 -nmw git tree. Thanks, Steve. --

Strange? So if you did: cat debugfs/tracing/trace | wc -l Would be worth running perf against this test, to see where the issues are occurring. -- Steve --

Fix some coding styles and remove moduleparam.h Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com> --- net/ipv4/netfilter/nf_nat_h323.c | 1 - net/ipv4/netfilter/nf_nat_standalone.c | 3 +-- net/ipv4/netfilter/nf_nat_tftp.c | 1 - net/netfilter/nf_conntrack_proto.c | 2 -- 4 files changed, 1 insertions(+), 6 deletions(-) diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c index 7e8e6fc..d4c0618 100644 --- ...

The number of frees is different? From 81 mio to 141 mio? Are you sure it I hope this is the same load? What debugging options did you use? We are now using per cpu operations in the hot paths. Enabling debugging for per cpu ops could decrease your performance now. Have a look at a dissassembly of kfree() to verify that there is no instrumentation. --

Hi all, Changes since 20100324: Dropped tree: tmio-mmc (long unresolved conflicts and unable to fetch) My fixes tree contains: a patch for a pktcdvd build error from Arnd Bergmann a revert of the commit that broke virtual consoles on PowerPC The input tree lost its build failure. The kgdb tree has its build failure back for which I have applied a merge fixup patch. The wireless tree lost its build ...

From: Randy Dunlap <randy.dunlap@oracle.com> Fix build error when CONFIG_MAGIC_SYSRQ is not enabled: drivers/xen/manage.c:223: error: implicit declaration of function 'handle_sysrq' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Chris Wright <chrisw@sous-sol.org> --- drivers/xen/manage.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) --- linux-next-20100325.orig/drivers/xen/manage.c +++ ...

When we look into pagemap using page-types with option -p, the value of pfn for hugepages looks wrong (see below.) This is because pte was evaluated only once for one vma although it should be updated for each hugepage. This patch fixes it. $ page-types -p 3277 -Nl -b huge voffset offset len flags 7f21e8a00 11e400 1 ___U___________H_G________________ 7f21e8a01 11e401 1ff ________________TG________________ ^^^ 7f21e8c00 11e400 1 ...

Add a workaround for TPM's which fail to flush last written PCR values in a TPM_SaveState, in preparation for suspend. Signed-off-by: David Safford <safford@watson.ibm.com> Acked-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> diff -u -r a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt --- a/Documentation/kernel-parameters.txt 2010-02-24 13:52:17.000000000 -0500 +++ b/Documentation/kernel-parameters.txt 2010-03-10 15:23:29.701436428 -0500 @@ -98,6 +98,7 @@ ...

This logic seems to still be strange after applying this patch. However, anyway, your patch is much better off than current one. So, I'll apply this in the next merge window. Or should we apply this immediately? -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> --

Um..., where is a stack corruption? sprintf() overflow? But, it's actually snprintf(), not sprintf()... Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> --

Some nouveau updates + misc drm core fixes, radeon kms: mostly fixes, however a cleanup to the ugly asic tables to avoid drift between C prototypes moves some stuff around, and I've merged Jerome's GPU recovery code, as I'd much rather users had some of hope of recovering from their GPU locking up than a dead box. It seems to work for quite a lot of people that have tested it, and it won't make a GPU lockup problem worse. This also finally fixes HDMI audio on rv7xx cards. The following ...

I leave i915 up to Eric after -rc1, we found it hard to sync our schedules before, I'm sure he has some stuff in his tree. Dave. --

Why desc_pool_virt should be aligned more than 16bit? --

On Thu, Mar 25, 2010 at 12:17 PM, Joonyoung Shim [CC'ing Russell and Ben as stakeholders] Dear Maintainers I too have been writing a driver for PL330 after taking into account the suggestions of Russell, Ben and other participants of the thread http://lists.infradead.org/pipermail/linux-arm-kernel/2010-February/009856.html If you don't think this driver conflicts with the theme of the thread, may I ask you to please put this driver on hold until you checkout my implementation of ...

Looks good to me now so: Acked-by: Linus Walleij <linus.walleij@stericsson.com> Linus Walleij --

Right. The write[bwl] is api for address ioremapped of io device. I will PL330 DMA controller fetches variable length instructions that consist of --

On Thu, 25 Mar 2010 19:05:47 +0900, Joonyoung Shim There is reason for desc_pool_virt to be 16bit aligned. It's just that you have 50% chance that it will. In such case, you will write 'imm' to a non 16bit-aligned address. In my book, that's bad. Same for pl330_dmamov(), which tries to write a 32bit value without checking the proper alignment. In such case, please use the put_unaligned macro to handle the possible unaligned access. M. -- Who you jivin' with that Cosmik ...

This is the wrong attitude. If it were not for a simple oversight Joonyoung's driver would already be upstream for the past two kernel releases. So you need to work together to improve that driver to incorporate what you need. It sounds like you just need to add an extension for the arch specific dma api. At first glance this can mimic the approach taken by Nobuhiro-san with the shdma driver. -- Dan --

Nothing wrong in attitude here. Giving feedback on the code only comes after one is convinced with the overall approach taken. The last time I raised the PL330 driver issue, most people were not enthusiastic with this drivers/dma/ approach. I wasn't active mainline discussions when the driver was originally submitted a few months ago. And now my replies are not very 'polite' because theres a lot going on I actually plan more than that. Apart from inefficient design, JoonYoung's driver has made ...

Ok, I'll rely on acked-by's from the interested parties once your driver is out as I do not have a vested interest in this hardware, just the dmaengine framework issues. -- Dan --

Hi,folks. Recently I'm studying some things of x86_64 on Linux. And the virsion is 2.6.18.8. From the document of Documentation/x86_64/mm.txt,I found the mapping method for x86_64 virtual memory map. I want to know ,why use this method for virtual memory mapping? ----------------------------------------------------------------------------------------------- 1 2 <previous description obsolete, deleted> 3 4 Virtual memory map with 4 level page tables: 5 6 0000000000000000 - ...

These have helped us debug some issues we've noticed in earlier IO controller versions and should be useful now as well. The extra logging covers: - idling behavior. Since there are so many conditions based on which we decide to idle or not, this patch adds a log message for some conditions that we've found useful. - workload slices and current prio and workload type Changelog from v1: o moved log message from cfq_set_active_queue() to __cfq_set_active_queue() o changed queue_count to ...

El Wed, 24 Mar 2010 18:11:36 -0700 Maybe you just need to run irqbalance http://www.irqbalance.org/ --

Ingo, Please pull the latest tip/tracing/urgent tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/tracing/urgent Li Zefan (2): tracing: Reduce overhead of module tracepoints tracing: Fix lockdep warning in global_clock() ---- include/linux/module.h | 6 ++---- include/trace/events/module.h | 14 +++++++------- kernel/module.c | 3 +-- kernel/trace/trace_clock.c | 4 ++-- 4 ...

From: Li Zefan <lizf@cn.fujitsu.com> Remove the @refcnt argument, because it has side-effects, and arguments with side-effects are not skipped by the jump over disabled instrumentation, so it adds overhead even when the tracepoints are disabled. Tested-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> LKML-Reference: <4BA97FA7.6040406@cn.fujitsu.com> Signed-off-by: Steven Rostedt ...

Nict catch. It seems good to me at least. :) Acked-by: Geunsik Lim <geunsik.lim@samsung.com> ------- Original Message ------- Sender : Randy Dunlap<rdunlap@xenotime.net> Date : 2010-03-25 06:58 (GMT+09:00) Title : Re: [PATCH] cpuset: Fix documentation punctuation Acked-by: Randy Dunlap <rdunlap@xenotime.net> Jiri, would you merge this, please? thanks, -- ~Randy --------------------------------------------------------------------------- GeunSik Lim, ...

If you don't like this, I could just submit the README changes but I would at least recommend that we change the messages so they don't like like Makefile errors. For example: REMINDER: You can make the gui by typing make gui --

These extra logging messages have helped us debug some issues we've noticed in earlier IO controller versions and should be useful now as well. The extra logging covers: - idling behavior. Since there are so many conditions based on which we decide to idle or not, this patch adds a log message for some conditions that we've found useful. - workload slices and current prio and workload type Signed-off-by: Divyesh Shah<dpshah@google.com> --- block/cfq-iosched.c | 17 +++++++++++++++-- 1 ...

Ok, root group is created when request queue is being initialized and device information like major/minor number is not available. This is not the cleanest solution but can't think of something better right now. Acked-by: Vivek Goyal <vgoyal@redhat.com> Thanks --

Russell, do you prefer me pushing these patches upstream (possibly even for -rc3), or do you wish to take these patches? Best, Dominik --

However, egrep 'mask: .*flags: ' is quite plausible.

POSIX 2008 says, for exec*: [ENOENT] A component of path or file does not name an existing file or path or file is an empty string. [ENOEXEC] The new process image file has the appropriate access permission but has an unrecognized format. [EINVAL] The new process image file has appropriate privileges and has a recognized executable binary format, but the system does not support execution of a file with this format. None of these perfectly fit, but EINVAL seems the ...

Patch (for error) is here: http://marc.info/?l=linux-wireless&m=126946621910346&w=2 -- ~Randy --

Acked-by: Paul Menage <menage@google.com> Thanks, --

Sure, that is certainly the plan. Regarding the ptrace bits, this is one of a handful of places where the BKL was put in by someone a really long time ago but with the rest of the series applied, it becomes evident that there is nothing whatsoever that it serializes with, so removing the BKL here does not make the situation worse. It could still be a bug that needs to be fixed by adding a new Let me give you three separate diffstats. One is for the trivial pushdown of the BKL into all the ...

That's why I said /mostly/ obscure modules. There are soundcore, usb-core, drm, vfat and a few other very common ones, along with many obscure ones. Arnd --

There is a typo in this one: commit 12c8fcce56c0de4fdcacf048fe723c8778af940d Author: Arnd Bergmann <arnd@relay.de.ibm.com> Date: Wed Mar 24 20:08:55 2010 +0100 block: replace BKL with global mutex It doesn't seem to interact with much else, so give this a try. Signed-off-by: Arnd Bergmann <arnd@arndb.de> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c index d9d6206..9c1277a 100644 --- a/kernel/trace/blktrace.c +++ b/kernel/trace/blktrace.c [ ...

(Cc'ing linux-mm) --

----- Original Message ----- From: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com> To: "Américo Wang" <xiyou.wangcong@gmail.com> Cc: "Janos Haar" <janos.haar@netcenter.hu>; <linux-kernel@vger.kernel.org>; <linux-mm@kvack.org> Sent: Thursday, March 25, 2010 7:31 AM No, the bug, what i have sent was from 2.6.32.10. (you can check it from the messages file in the link) The story begins about marc 9-10 but unfortunately the system not all the time was able to write down the messages ...

Looks good to me. Acked-by: Vivek Goyal <vgoyal@redhat.com> --

IIRC top can give very funny results if you break it hard enough, it likes to give 9999% cputime if the thing goes backwards over the sample interval. But I'm not sure your race is large enough to ever show up like that, so it might all just work out, but in general it does tend to require monotonic times. --

Hmm, not sure. Have not measured IRQ handler run times for quite a Right, but that's not the problem here. We talk about a (hopefully) well written interrupt handler which runs for a very short time. What's the point of running it with interrupts enabled ? Nothing, we just run into stack overflow problems. So what's better: an unreliable and ugly hackaround or just avoiding the possible stack overflow in the first place ? Thanks, tglx --

"misleading" is an euphemism at best ... So there are several questions: 1) Why are those multiple vectors all hitting the same cpu at the same time ? How many of them are firing at the same time ? 2) What kind of scenario is that ? Massive traffic on the card or some corner case ? 3) Why does the NIC driver code not set IRQF_DISABLED in the first place? AFAICT the network drivers just kick off NAPI, so whats the Which leads to the general question why we have that ...

Anyone you've forgotten to offend ? We have IRQF_DISABLED and stuff using that model because for something like ten years the Linux kernel had no real sane notion of handing stuff off to worker threads or threaded irq support and also because there were so many errata around IRQ masking as well as all the evil business with interrupt delivery being asynchronous to the PCI or ISA transactions on some CPUs (eg you could write the irq mask register on the device, read it back to ensure it ...

Thanks. I'm tempted to just ignore it in this case, but in theory it might still have troubles if there are a lot of interrupts to the same CPU. I've only had a report on a very large system with a very high interrupt rate on a very fast NIC though, so presumably it's not too common. Anyways this patch will fix the problem for all drivers that do not explicitely enable interrupts, which is the overwhelming majority. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

I believe it's more like that you have a lot of them (even with interrupt mitigation and NAPI polling) and they have to scale up the work to handle high bandwidths, so it ends up with a lot of time in them anyways, ending with skew in the timers and similar issues. Anyways my goal here was simply to have a least intrusive fix, not Yes it could work out this. Or it could not. I'm not sure, so I chose Ok so you're just proposing to always set IRQF_DISABLED? If you can force everyone to ...

Well in this case it's simply because it has 4 ports and they are all active and have a lot of MSI-X vectors for each stream. Even if you had the perfect interrupt handler that ran in one cycle, if you had enough of them in parallel from different ports Well it's simply the current state of affairs today. I'm merely attempting to make the current state slightly safer without breaking I'm not sure I fully understand your suggestion. Is your suggestion to only set IRQF_DISABLED that ...

At least the people who reported it to me thought it was a massive Ok, but afaik it's not that small a number: MSI-X support is getting more and more wide spread. It's pretty universal in the 10+GbitE space for space and starts getting deployed for block too. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

So historically _all_ interrupts allow nesting, except for what used to be called "fast" irq handlers. Notably the serial line, which especially on chips without buffering needs really low latencies. So that's where the irq handler code comes from: a "fast" interrupt will not ever enable the CPU interrupts at all, and can run without ever doing the whole "mask and ACK" code. But no, we absolutely MUST NOT make regular interrupt handlers be that kind of fast handlers (ie IRQF_DISABLED ...

* Linus Torvalds <torvalds@linux-foundation.org> wrote: I think the patch as posted solves a real problem, but also perpetuates a bad situation. At minimum we should print a (one-time) warning that some badness occured. That would push us either in the direction of improving drivers, or towards improving the generic code. Thanks, Ingo --

For the MSI ones it definitely works as they can not be shared. I'm just not sure whether we can just enforce that for MSI. Thanks, tglx --

The thing is, that won't show the drivers that just simply _expect_ other interrupts to happen. The SCSI situation, iirc, used to be that certain error conditions simply caused a delay loop (reset? I forget) that depended on 'jiffies'. So there was no 'local_irq_enable()' involved, nor did it even happen under any normal load - only in error situations. Now, I think (and sincerely) that the SCSI situation is likely long since fixed, but we have thousands and thousands of drivers, ...

Also, Arjan mentioned he wanted to sweep the kernel for jiffies users and convert them to timer interfaces.. --

Yes, but that kind of crap should not go unnoticed if it triggers (which may be rare): in form of a hard lockup. We had that lockdep behavior of disabling irqs in all handlers forever, ever since it went upstream four years ago. So we had 3 separate mechanisms in the past 3-4 years: - lockdep [which disables irqs in all handlers, indiscriminately] - dynticks [which found in-irq jiffies loops] - -rt [which found hardirqs-off loops] That should have weeded out most of that kind of ...

Dynticks found most of the loop-for-jiffies-in-handlers cruft: an IRQ handler hitting the idle loop and then spinning for jiffies, with dynticks enabled, would spin forver because there's no timer irq. That is because in dynticks mode we dont reactivate the tick when we go into an irq handler (that has hit the idle task). So any looping on jiffies will loop forever. We only reactivate the tick when we go out of idle. We had a few bugs of that kind in the early days of dynticks - they ...

From: Linus Torvalds <torvalds@linux-foundation.org> FWIW, I'm currently using IRQF_DISABLED for virtual network device interrupts on sparc64 as a workaround for some stack overflow issues. This change will just force me to work harder to find out a better way to fix the problem, so don't let my issue hold this back, it's just an FYI... --

I think IRQF_DISABLED is the sanest method to run IRQs: it's the most atomic, thus most cache-efficient, it doesnt nest, and it's also a tiny bit faster to The patch i sent basically hardcodes IRQF_DISABLED - so it should fix your problem automatically. IRQF_DISABLED will become an unconditional thing, and we can then also remove it. Ingo --

So what's the point ? Is the irq handler of that card so long running, that it causes trouble ? If yes, then this needs to be fixed. If no, What's the cost? Nothing at all. There is no f*cking difference between: IRQ1 10us IRQ2 10us IRQ3 10us IRQ4 10us and IRQ1 2us IRQ2 2us IRQ3 2us IRQ4 10us IRQ3 8us IRQ2 8us IRQ1 8us The system is neither running a task nor a softirq for 40us in both cases. So what's the point of running a well written (short) ...

Can you put this into: arch/x86/kernel/cpu/common.c (or wherever it fits in general x86 cpu init code) and remove this (arch/x86/kernel/cpu/intel.c): if (c->cpuid_level > 6) { unsigned ecx = cpuid_ecx(6); if (ecx & 0x01) set_cpu_cap(c, X86_FEATURE_APERFMPERF); } an x86 maintainer might want to double check, but I expect this should work for all x86 machines? Thomas --

So is > or >= the correct comparator here?

From: Thomas Renninger <trenn@suse.de> Agreed. ">" won't work on machines which have base cpuidlevel == 6 (like The problem here is that the patches touch both cpufreq and x86 code. Hmmm... -- Regards/Gruss, Boris. -- Advanced Micro Devices, Inc. Operating Systems Research Center --

My pci=use_crs patches change the contents of the iomem_resource tree, and it's possible they broke some assumptions PCMCIA was making, so you might see if "pci=nocrs" makes any difference. If it does, please attach an acpidump and the entire dmesg logs with and without that option. --

Christoph, does this look OK to you? I think Eric has all your later --

Tested-by: Joel Becker <joel.becker@oracle.com> I ran into this when moving my paravirt_ops PVMs to 2.6.34-rc1. I turned on CONFIG_NO_BOOTMEM to try it because it was the default. I had to put earlyprintk=xen on the command line to debug the problem. My boots hung after: ... (early) Local APIC disabled by BIOS -- you can enable it with "lapic" (early) APIC: disable apic facility (early) APIC: switched to apic NOOP (early) Allocating PCI resources starting at 78000000 (gap: ...

Ok, I missed that one. I'll update my patch. Thanks. Cheers, Ben. --

I think there is misunderstanding on this part. I would add this instead: - Without this patch, hugetlb_entry() callback is called once per vma, OK. I fixed it. Thanks, Naoya Horiguchi --

According to the following post it did not solve the problem: "There are references to syncronization issues between clock domains in documentation and source code. These references describe required delays when setting or clearing bits in CSR until the bit actually changes and the required delays between writing CSR and reading the data register. Incorporating the delays suggested in datasheet to code did not change anything, so I dug ...

Hi again. On further reflection, how about "std" (suspend to disk)? I think that's less ugly than the 'hib' suggestion :) Regards, Nigel --

But it also decodes as "standard" if someone is not in the right context. :-) If the "bio" part of the name is not essential (ie. there's no conflicting name already), we could call it simply hibernate_read_page(). Rafael --

I'd just use "hibernate" without abbreviating if reasonably possible. We can also use "image_" in some cases I guess. Rafael --

Yes, it looks good. Rafael --

Ok, I guess that now I see what you are doing.... adding interface layer between /dev/snapshot and core hibernation code. To recap, 2.6.33 hibernation looks like: core hibernation /\ / \ swsusp /dev/snapshot swap \ writing -------- read/write/ioctl interface \ s2disk and after your patches, we'd get core hibernation /\ ---------- sws_module_ops ...

Hi again. I realised after sending this that the " - and you? - " was ambiguous. I wasn't meaning to suggest that you might pull in a different direction, but rather uncertainty as to whether you might help with the effort - it's been a while (AFAIR) since you've done any hibernaton patches. Humble apologies for the ambiguity! Nigel --

Hi. So what's your long term plan then? Regards, Nigel --

Hi. Well, that's pretty much what I was thinking too - improve then remove. I was just suggesting that we flag now that this is our plan, so it doesn't come as a surprise to anyone later and we can proceed more quickly than might otherwise be the case. I'm imagining it won't take long to get uswsusp features into the kernel code. Regards, Nigel --

I'd really prefer to keep s2disk interface. It allows advanced stuff like internet suspend resume (yep someone is doing it), crazy stuff like multiple resumes from same image for fast booting (yep, some embedded people are doing that) and might-be-useful stuff like s2both... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

The user space interface does things that the in-kernel one doesn't really care for, so I don't think that would be a good thing to do. I admit it's a bit like this right now (snapshot_[read|write]_next() do some things to satisfy the user space interface's needs), but I don't really think it should go any further than that. Moreover, the Jiri's approach allows us to handle other types of storage as well as swap using uniform interface. Rafael --

Again, good idea, but the same comments as for the previous patch apply here too. Rafael --

Looks good. --

No, please use them, at least in a prototype version. We can always optimize things out later, but doing optimizations upfront doesn't really work well from my experience. So, if you'd use a lock somewhere, please use it, or maybe use a completion if that fits the design better. In the majority of cases it's not as heavy wieght as it seems at first sight. Rafael --

Well, if Al likes the vfs changes... why not. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

The whole thing boils down to whether or not there may be more than one swap map in use at a time. Perhaps it's better to use a static pointer, though? And I don't really know at this point how exactly this change is going to make your life easier down the road. Care to elaborate? Rafael --

Stupid me. I knew that, I just hadn't internalized it enough to do it right :) Btw, unless I miss something else, this is the same in follow_page()? diff --git a/mm/memory.c b/mm/memory.c index 22ee158..6c26042 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1301,18 +1301,14 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address, } if (pmd_trans_huge(*pmd)) { spin_lock(&mm->page_table_lock); - if (likely(pmd_trans_huge(*pmd))) { - if ...

Wait, there _is_ an unlocked fast-path pmd_trans_huge() in mincore_pmd_range(), maybe you missed it? This function is never called if the pmd is not huge. So the above is the _second check_ under lock to get a stable read on the entry that could be splitting or already have been split while we checked locklessly. --

Using Alan's patch and the one following the dashed line I can implement (and have already done so) a separate watchdog driver for the Fintek F71808E. Should I just ask for this patch to be applied together with Alan's? Then submit the new driver? (I'm a bit new to the non-technical aspects of Linux kernel development). ======================================================================== hwmon: f71882fg: use a muxed resource lock for the Super I/O port Sleep while acquiring a ...

Hi Giel, What Alan said :) Although I'm not sure what the proper place is to post this entire set, I guess linux-kernel itself, with lm_sensors in the CC. Regards, Hans --

Add a new watchdog driver for the Fintek F71808E Super I/O chip. --- drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/f71808e_wdt.c | 726 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 738 insertions(+), 0 deletions(-) create mode 100644 drivers/watchdog/f71808e_wdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index bdcdbd5..653896f 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ ...

On Thu, 25 Mar 2010 14:17:41 +0100 needs a set_current_state(TASK_UNINTERRUPTIBLE); here (error from my original test patch that I noticed re-reviewing it) --

After the schedule() returns we will be in TASK_RUNNING which is where we And you'll want a -- -- "Alan, I'm getting a bit worried about you." -- Linus Torvalds --

Oh, the original patch which caused the problem never saw the light of the day before 2.6.34-rc1 so there's no stable kernel to push the patch into. Thanks. -- tejun --

I don't think so. There are two points where zone-related locks are held. zone->lock is held in isolate_freepages() while it gets the free pages necessary for migration to complete. The size of the list of pages being migrated is constrained by COMPACT_CLUSTER_MAX so it is bounded by that. Worst case scenario is the zone is almost fully scanned. zone->lru_lock is held in isolate_migratepages) while it gets pages for migration. It's released if COMPACT_CLUSTER_MAX pages are isolated. ...

On Wed, 24 Mar 2010 13:48:16 -0700 If your concern is a race with memory hotplug, I have no concern about that because memory hotplug makes a range of pages as "not for use" before starting. If your concern is "code sharing", shared codes between memory hotplug and compaction is "migrate_pages()". Other parts are independent from each other. IIUC. Memory Hotremove does 1. select a range for removal [start ....end) 2. mark free pages as "not for use" by migrate_type 3. move all used ...

On Thu, 25 Mar 2010 09:48:26 +0000 Ah, sorry for my short word again. I mean draining "local" pcp list because a thread which run direct-compaction freed pages. IPI is not necessary and overkill. Thanks, -Kame --

I dropped both inlines. Both have only one caller and should be Not at this time. I'd need to go through migration and make it atomic-safe first. It's doing things like taking the page table lock which is not interrupt-safe. It's possible that migration can distinguish between atomic I assume you mean memory hot-remove as I cannot see any problems with memory hot-add. Kamezawa mostly covers this but I did miss one possibility. suitable_migration_target() will return true if a block ...

Hi Jason, Dmitry, I got this again today (I stopped reverting the input tree commits that I was reverting for another build problem). The patch below still seems to -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Hi, Yeah, something like that - thanks for noticing it and providing the patch. After looking at the Python implementation, I modified your patch as below... Basically, Python wants to use a PyInt (which is internally a long) if it can i.e. if the value will fit into that type. If not, it stores it into a PyLong, which isn't actually a long, but an arbitrary-precision integer variable. The code below is similar to to what Python does internally, and it seems to work as expected on the ...

Yes, that's possible. I was thinking we could still use your thread info field but only store to it when we know it will be useful for c/r rather than for each syscall. Personally, I'd rather avoid passing the extra ^shouldn't this be: (again, not familiar with ARM so my understanding is: I guess swi is "syscall word immediate". The syscall nr is embedded in the instruction as an immediate value and you're getting a copy of that instruction using the value of the pc register just ...

In c/r, we only need it at restart when a task calls it on itself. However the interface itself of get_syscall_nr() can be called by any task on another task. (In fact, I think that for the most part, saving the syscall number at checkpoint time may be better than figuring out at restart time). Oren. --

So, as Oren is saying, the point was to make the syscall_get_nr(..) work according to the interface specified in include/asm-generic/syscall.h. Considering it's unknown how we will deal with checkpoint/restart across CONFIG_ARM_THUMB, CONFIG_OABI_COMPAT etc., I also think it's a better idea to checkpoint the syscall number at checkpoint and for the restore, place architecture specific hooks to get the syscall number instead of calling syscall_get_nr(...) directly. In this way we ...

Hi Florian, All 4 (I took v2 for the watchdog) patches applies, thanks. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Ulrich, Can you please comment if a slot in TLS can be used for storing and executing an instruction? Are there any additional issues that we need to take care of? Are there architectures that dont support TLS? -- Thanks and Regards Srikar --

Hi Rafael, Mark, you contributed the initial runtime PM support for the i2c subsystem, I thought you would have comments on Rafael's I am a little surprised to see changes to a generic header file here, how is the i2c subsystem so special that we have needs other subsystems I fail to see why the functions above are outside of the #ifdef CONFIG_PM_SLEEP scope. They are only called by functions which are inside the #ifdef CONFIG_PM_SLEEP scope, so you'll get a build-time warning if ...

Thanks! Rafael --

Actually, I'm waiting now for some USB core changes to settle down before sending again a patch series. What I've tested (successfully) so far are these patches from your master branch in the tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git swiotlb: EXPORT_SYMBOL_GPL functions + variables that are defined in the header file. swiotlb: Make swiotlb bookkeeping functions visible in the header file. swiotlb: Make all bookkeeping functions and variables have same ...

Hi, I've given this a go, it seems to run fine (no slowness issues reported yet..). Memory available has gone up. I'll let it run for a few days and see how it goes.. # free -m total used free shared buffers cached Mem: 42337 11397 30940 0 36 5520 -/+ buffers/cache: 5840 36497 # cat /proc/mtrr reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x100000000 ( 4096MB), ...

Thanks for reporting it. Arnaldo, could you pick up below patch? Zefan, Could you try it? mmap_array[][][] is not reset to 0 after malloc. Below patch against tip/master of March 24th fixes it with a zalloc. Reported-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com> --- diff -Nraup linux-2.6_tip0324/tools/perf/builtin-record.c linux-2.6_tip0324_perfkvm/tools/perf/builtin-record.c --- linux-2.6_tip0324/tools/perf/builtin-record.c 2010-03-25 ...

Sure thing, will stash them in today's push to Ingo, thanks! - Arnaldo --

Thanks! Then who's going to fix this... --

Yeah, that perf_output_{un,}lock() stuff is a pain.. handle->locked should indicate if we're the outer most context the problem this stuff is solving is that of publishing the data head pointer, suppose two concurrent writers: head = 0; A: reserve N bytes write content commit B: reserve M bytes write content commit Now, if B happens during A, and B completes before A is done, B's commit would expose a head pointer of N+M bytes, even though the first N ...

I think I do all those :-) I was still looking at removing the TASK_WAKING check from task_rq_lock() since now we do set_task_cpu() under rq->lock again so it should be good again. Hmm, except for sched_fork() that still does set_task_cpu() without holding rq->lock, but that is before the child gets exposed so there should not be any concurrency. --

IOW, something like the (unchecked, uncompiled) patch below. What do you think? Oleg. --- x/kernel/sched.c +++ x/kernel/sched.c @@ -912,7 +912,7 @@ static inline void finish_lock_switch(st */ static inline int task_is_waking(struct task_struct *p) { - return unlikely((p->state == TASK_WAKING) && !(p->flags & PF_STARTING)); + return unlikely(p->state == TASK_WAKING); } /* @@ -2568,11 +2568,10 @@ void sched_fork(struct task_struct *p, i __sched_fork(p); /* - * We ...

Yeah, such a smaller patch might work too, but I was trying to remove some more of the complexity we grown. Being able to fully remove that TASK_WAKING check from task_rq_lock() and only have it in set_cpus_allowed_ptr() would reduce some fast-path logic. You patch add a memory barrier and an unlock_wait(), which, while seemingly correct, are harder to parse than the modified locking. (Ideally we'd protect ->cpus_allowed using a per-task lock, but adding more atomics ops to ttwu() is to ...

The problem what you said don't exist, because the kernel already move T to the active cpu when preparing to turn off a CPU. Thanks! Miao --

But when the kernel want to offline a cpu, it does raw_notifier_call_chain(CPU_DOWN_PREPARE) at first. this calls cpuset_track_online_cpus() to update cpuset's cpus and task->cpus_allowed, and then moves the task running on the dying cpu to the other online cpu. At that time, rt-threads for each cpu have not been created. And when the kernel does migration_call(CPU_DEAD), the rt-threads already exit. the task that holds callback_mutex can run as normal. --

Hello, nv reset code has received several changes during that time frame one of which being avoiding hardreset unless it's a hotplug situation. This was necessary because some controllers fail to re-recognize the attached drive after a hardreset. This decision was made as losing drives which can be recovered by SRST is less dangerous than losing drives which require hardreset after a failure. NV reset protocols are very messed up and at this point I don't think it's possible to make it ...

Sorry, My example was wrong. new example is here. free_pages: 4 requested: 2 free_blocks_total: 4 theory: 1 - (TotalFree/SizeRequested)/BlocksFree = 1 - (4/2)/4 = 0.5 code : 1000 - ((1000 + 4*1000/2))/4 = 1000 - (1000 + 2000)/4 = 1000/4 = 250 I don't think this is three decimal picking up code. This seems might makes lots compaction invocation rather than theory. --

ok... I don't oppose it anymore. Let's dive into Kconfig select hell ;) --

Ok, I cannot apologise for this enough. Since that paper was published, further work showed that the equation could be much improved. As part of that, I updated the equation to the following; double index = 1 - ( (1 + ((double)info->free_pages / requested)) / info->free_blocks_total); or when approximated to three decimal places int index = 1000 - ( (1000 + ( info->free_pages * 1000 / requested)) / info->free_blocks_total); Your analysis of the paper is perfect. ...

I fully agree this. --

Hmmm... I haven't understand your mention because I guess I was wrong. probably my last question was unclear. I mean, 1) If we still need SLAB_DESTROY_BY_RCU, why do we need to add refcount? Which difference is exist between normal page migration and compaction? 2) If we added refcount, which race will solve? IOW, Is this patch fix old issue or compaction specific issue? --

Do you mean current memroy hotplug code is broken??? I think compaction need refcount, hotplug also need it. both they migrate another task's page. but , I haven't seen hotplug failure. Am I missing something? or the compaction have its specific race situation? --

But Christoph seems oppose to remove SLAB_DESTROY_BY_RCU. then refcount is meaningless now. I agree you if we will remove SLAB_DESTROY_BY_RCU in the future. --

I hadn't considered the memory hotplug case but you're right, it's possible it's at risk. While compaction can trigger this problem reliably, it's not exactly easy to trigger. I was triggering it under very heavy memory load with a large number of very short lived processes (specifically, an excessive compile-based load). It's possible that memory hotplug has not been tested under similar It's worth double-checking. -- Mel Gorman Part-time Phd Student Linux ...

On Thu, 25 Mar 2010 09:21:32 +0000 I wonder a code which the easiest to be read will be like following. == if (PageAnon(page)) { struct anon_vma anon = page_lock_anon_vma(page); /* to take this lock, this page must be mapped. */ if (!anon_vma) goto uncharge; increase refcnt page_unlock_anon_vma(anon); } .... == and == void anon_vma_free(struct anon_vma *anon) { /* * To increase refcnt of anon-vma, anon_vma->lock should be held by * ...

On Thu, 25 Mar 2010 18:59:25 +0900 (JST) BTW, by above change and the change in patch [2/11], "A page turnd to be SwapCache and free unmapped but not freed" page will be never migrated. Mel, could you change the check as this ?? if (PageAnon(page)) { rcu_read_lock(); if (!page_mapcount(page)) { rcu_read_unlock(); if (!PageSwapCache(page)) goto uncharge; /* unmapped swap cache can be migrated */ } else { ... } ..... } else Thx, -Kame --

The issue is only performance. If we can preserve the cache hotness in a different way (or do things in a completely different manner) then its fine. --

I agree kosaki's opinion. I guess Mel met the problem before this patch. Apparently, It had a problem like Mel's description. But we can close race window by this patch. so we don't need to new ref counter. At least, rcu_read_lock prevent anon_vma's free. so we can hold spinlock of anon_vma although it's not good habit. About reusing anon_vma by SLAB_XXX_RCU, page_check_address and I agree. (use one locking rule) I don't mean that we have to remove SLAB_XXX_RCU. I want to ...

On Wed, Mar 24, 2010 at 7:14 PM, Andrew Morton Yes. In addition, applying the patch I provided also fixes it in current code. Current code: --

AFAIK they are not exclusive options? I can't imagine anyone building a kernel with both, but the rest of the patch is designed to allow Thanks - who can pick this up to feed it upstream? Jason --

Sorry! Please ignore this patch, because I sent an old version. I'll send the new one later. Regards! Miao --

Maybe we can add pointers to functions for the DCD/DTR in the struct altera_uart_platform_uart. Then board config file can define them if they implement these pins, NULL/0 otherwise. struct altera_uart_platform_uart { ... int (*getppdcd)(...); /* get DCD status */ ... }; static unsigned int altera_uart_get_mctrl(struct uart_port *port) { ... if (port->getppdcd) sigs |= (port->getppdcd(...)) ? TIOCM_CD : 0); - Thomas --

There's the current reservation code which has some issues and is butt ugly, but does its job mostly. The only real problem I have with it is that it doesn't support fixed counters. That's not very hard to fix (patches posted), but of course requires some basic cooperation from impartial maintainers. I think extending NMI watchdog is not on by default luckily. Anyways I don't really understand what the problem with just allocating counters properly in perf_events like everyone ...

I see this now, with full backtrace: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.34-rc2-cachefs #115 ------------------------------------------------------- halt/2291 is trying to acquire lock: (s_active#31){++++.+}, at: [<ffffffff81104950>] sysfs_addrm_finish+0x31/0x5a but task is already holding lock: (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}, at: [<ffffffff812a3a92>] lock_policy_rwsem_write+0x4a/0x7b which lock ...

.... What about struct keycode_table_entry { unsigned keycode; int len; char scancode[]; } ? gcc extension, but commonly used around kernel. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --