Fix this sparse warning: drivers/ide/alim15x3.c:594:2: warning: returning void-valued expression Signed-off-by: Hannes Eder <hannes@hanneseder.net> --- drivers/ide/alim15x3.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c index e56c7b7..45d2356 100644 --- a/drivers/ide/alim15x3.c +++ b/drivers/ide/alim15x3.c @@ -591,7 +591,7 @@ static int __init ali15x3_ide_init(void) static void __exit ...

Impact: make global function static Fix the following sparse warning: net/sched/sch_api.c:192:14: warning: symbol 'qdisc_match_from_root' was not declared. Should it be static? Signed-off-by: Hannes Eder <hannes@hanneseder.net> --- net/sched/sch_api.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index f859dd5..6bc29e8 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -189,7 +189,7 @@ ...

- Kernel 2.6.27.7 doesn't use the right value for TSC calibration I've updated my system (Slackware 12.1) to kernel 2.6.27.7 vanilla and looking in dmesg I read this: TSC: PIT calibration deviates from PMTIMER: 2968361 3400012. TSC: Using PIT calibration value But my cpu is : cpu family      : 15 model           : 3 model name      : Intel(R) Pentium(R) 4 CPU 3.40GHz stepping        : 4 So the clock frequency detected is 3Ghz instead of 3,4 Ghz. Also bogomips are different: for ...

Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> --- drivers/staging/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index c95b286..4089f14 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -22,6 +22,8 @@ menuconfig STAGING If in doubt, say N here. +if STAGING + config STAGING_EXCLUDE_BUILD bool "Exclude Staging drivers from being built" if STAGING default y @@ ...

I am running Ubuntu 8.10. The Ubuntu kernel produces sound fine. However, my custom 2.6.28-rc6-git1 test kernel remains silent. Please let me know if you need any additional information. snd_hda_intel 531744 5 snd_pcm_oss 43216 0 snd_mixer_oss 15496 1 snd_pcm_oss snd_pcm 84336 3 snd_hda_intel,snd_pcm_oss snd_page_alloc 9936 2 snd_hda_intel,snd_pcm snd_hwdep 8720 1 snd_hda_intel snd_seq_dummy 3268 ...

Please do not export/use sigkill_pending(). It is "private" for ptrace_stop() (and actually should die imho). We have fatal_signal_pending() for that. Oleg. --

This patch fixes this error: arch/um/kernel/mem.c: In function ‘init_highmem’: arch/um/kernel/mem.c:177: error: ‘pkmap_page_table’ undeclared (first use in this function) arch/um/kernel/mem.c:177: error: (Each undeclared identifier is reported only once arch/um/kernel/mem.c:177: error: for each function it appears in.) Compile and run tested. Signed-off-by: WANG Cong <wangcong@zeuux.org> Cc: Jeff Dike <jdike@addtoit.com> Cc: Al Viro ...

Impact: cleanup Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- arch/x86/include/asm/gart.h | 33 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/iommu.h | 33 --------------------------------- arch/x86/kernel/amd_iommu.c | 1 + arch/x86/kernel/amd_iommu_init.c | 1 + arch/x86/kernel/early-quirks.c | 1 + arch/x86/kernel/pci-dma.c | 1 + arch/x86/kernel/setup.c | 1 + 7 files changed, 38 insertions(+), 33 deletions(-) diff ...

pppol2tp_sock_to_session() do sock_hold() if the session to release is not NULL. Signed-off-by: Frédéric Moulins <frederic.moulins@alsatis.com> --- Patch is applicable to kernels 2.6.26 and following. Tested with a 2.6.26 stable kernel: without this patch, a session in a persistent tunnel cannot be established again (connect failed: -17), and the pppol2tp kernel module cannot be removed because still considered in use after stopping all userspace daemons. diff --git ...

dcdbas: Export functionality for use in other drivers The dcdbas code allows calls to be made into the firmware on Dell systems. Exporting this to other drivers allows them to implement Dell-specific functionality in a safe way. Signed-off-by: Matthew Garrett <mjg@redhat.com> diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c index 50a071f..45f109d 100644 --- a/drivers/firmware/dcdbas.c +++ b/drivers/firmware/dcdbas.c @@ -238,11 +238,11 @@ static ssize_t ...

Add one more compatible string to the table for of_platform binding, so that the platforms, which have the SysACE chip on board (e.g. Katmai), could describe it in their device trees correctly. Signed-off-by: Yuri Tikhonov <yur@emcraft.com> --- drivers/block/xsysace.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c index 29e1dfa..381d686 100644 --- a/drivers/block/xsysace.c +++ b/drivers/block/xsysace.c @@ -1206,6 ...

This patch introduces the API to abstract the exported VT-d functions for KVM into a generic API. This way the AMD IOMMU implementation can plug into this API later. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- include/linux/iommu.h | 100 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 include/linux/iommu.h diff --git a/include/linux/iommu.h b/include/linux/iommu.h new file mode 100644 index ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- drivers/pci/intel-iommu.c | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c index a90c832..8fa0269 100644 --- a/drivers/pci/intel-iommu.c +++ b/drivers/pci/intel-iommu.c @@ -2492,3 +2492,25 @@ static void intel_iommu_detach_device(struct iommu_domain *domain, intel_iommu_detach_dev(dmar_domain, pdev->bus->number, pdev->devfn); ...

Use the git -M switch, which show renames as renames instead of removes+adds. -- error compiling committee.c: too many arguments to function --

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- drivers/pci/intel-iommu.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c index b958b6f..a90c832 100644 --- a/drivers/pci/intel-iommu.c +++ b/drivers/pci/intel-iommu.c @@ -2460,3 +2460,35 @@ static void intel_iommu_domain_destroy(struct iommu_domain *domain) intel_iommu_domain_exit(dmar_domain); domain->priv = NULL; ...

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> --- drivers/pci/intel-iommu.c | 24 ++++++++++++++++++++++++ 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c index 5c8baa4..b958b6f 100644 --- a/drivers/pci/intel-iommu.c +++ b/drivers/pci/intel-iommu.c @@ -35,6 +35,7 @@ #include <linux/mempool.h> #include <linux/timer.h> #include <linux/iova.h> +#include <linux/iommu.h> #include <linux/intel-iommu.h> #include ...

For testing, the patches can be pulled against avi/master from -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy --

Hi Steven and Ingo, I encountered an issue when using ftrace. We know that we can use wild cards to set set_ftrace_filter, but there's problem when using such as "echo h* > /debug/tracing/set_ftrace_filter". If there are files named with "h" prefix in current directory, echo "h*" will echo these files' name to set_ftrace_filter, not "h*". For example: #cat /debug/tracing/available_filter_functions |grep ^hr |wc -l 23 #ls #touch hraa hrdd #ls hraa hrdd #echo hr* > ...

looks good otherwise. Ingo --

Using TB? It's best to inline the patch, that way I can comment on it better. Anyway, you should fix the example. I also recommend a single quote over double, to prevent any other translation that bash might do. The example in ftrace.txt should be: # echo 'hrtimer_*' > /debug/tracing/set_ftrace_filter Thanks, -- Steve /me goes back to eating turkeys. --

Fix the error handling in sys_mmap2(). Currently, if the pgoff check fails, fput() might have to be called (which it isn't), so do the pgoff check first, before fget() is called. Signed-off-by: David Howells <dhowells@redhat.com> --- arch/frv/kernel/sys_frv.c | 17 ++++++++--------- 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/arch/frv/kernel/sys_frv.c b/arch/frv/kernel/sys_frv.c index 49b2cf2..baadc97 100644 --- a/arch/frv/kernel/sys_frv.c +++ ...

From: Julia Lawall <julia@diku.dk> fget increments a reference count, so fput is needed to decrement it. I have added a goto to the end of the function where there was already such a call. The semantic patch that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; position p1,p2; identifier f; expression E; expression *ptr != NULL; @@ x@p1 = fget(...); ... when != x if (x == NULL) S <... when != ...

From: Julia Lawall <julia@diku.dk> The function snd_mixart_create creates a link between mgr and card that allows snd_mixart_free to free card as well. But if snd_mixart_create fails, then the link has not been created and card has to be freed explicitly. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S,S1; position p1,p2,p3; expression E,E1; type T,T1; expression *ptr != ...

At Thu, 27 Nov 2008 15:01:51 +0100 (CET), Looks good. Could you repost with a readable comment? thanks, --

At Thu, 27 Nov 2008 14:33:30 +0100 (CET), How about the patch below? Takashi --- diff --git a/sound/pci/mixart/mixart.c b/sound/pci/mixart/mixart.c index ae7601f..3cccfed 100644 --- a/sound/pci/mixart/mixart.c +++ b/sound/pci/mixart/mixart.c @@ -989,6 +989,7 @@ static int snd_mixart_pcm_digital(struct snd_mixart *chip) static int snd_mixart_chip_free(struct snd_mixart *chip) { + chip->mgr->chip[chip->chip_idx] = NULL; kfree(chip); return 0; } --

At Thu, 27 Nov 2008 15:40:40 +0100 (CET), Thanks, applied now. Takashi --

From: Julia Lawall <julia@diku.dk> In the function cx88_audio_initdev, the value card has been created using snd_card_new. The other error handling code in this function frees the value using snd_card_free. I have thus changed the first error case to do the same. On the other hand, it may be that card is not sufficiently initialized at this point to use snd_card_free, in which case something else should be done to free the memory in the error case. In the function snd_cx88_create the call ...

Use resource_size_t for physical address of SystemACE chip. This fixes the driver brokeness for 32 bit systems with 64 bit resources (e.g. PPC440SPe). Also this patch adds one more compatible string for more clean description of the hardware, and fixes a sector_t- related compilation warning. Signed-off-by: Yuri Tikhonov <yur@emcraft.com> Signed-off-by: Ilya Yanok <yanok@emcraft.com> --- drivers/block/xsysace.c | 24 +++++++++++++----------- 1 files changed, 13 insertions(+), 11 ...

Hello Grant, Sure. I've generated the patch against the origin/merge branch of Paul's tree, and posting it as separate "[PATCH] xsysace: add compatible string ". Regards, Yuri --

remove 8 bytes of padding from struct bio which also removes 16 bytes from struct bio_pair to make it 248 bytes. bio_pair then fits into one fewer cache lines & into a smaller slab. Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk> --- Hi Neil, This compiles but hasn't had any testing, as I don't have a raid to test it on. patch against 2.6.28-rc6. regards Richard diff --git a/include/linux/bio.h b/include/linux/bio.h index 6a64209..e6789b2 100644 --- ...

Hi Stephen, I have taken over trivial patches maintainership from Jesper. I will process all the patches in Jesper's queue when he sends them over to me. Could you please re-introduce trivial tree into linux-next lineup? It is 'for-next' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git for-next Thanks. -- Jiri Kosina --

From: Felix Beck <felix.beck@de.ibm.com> When the machine supports AP adapter interrupts polling will be switched off at module initialization and the driver will work in interrupt mode. Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/include/asm/isc.h | 1 drivers/s390/crypto/ap_bus.c | 174 ++++++++++++++++++++++++++++++++++++++++++- drivers/s390/crypto/ap_bus.h | 6 + 3 files changed, 177 ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> A kernel compile on 31 bit gives the following warnings in ptrace.c: arch/s390/kernel/ptrace.c: In function 'peek_user': arch/s390/kernel/ptrace.c:207: warning: unused variable 'dummy' arch/s390/kernel/ptrace.c: In function 'poke_user': arch/s390/kernel/ptrace.c:315: warning: unused variable 'dummy' Getting rid of the dummy variables removes the warnings. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> Move cio_tpi() to the rest of the CONFIG_CCW_CONSOLE functions to get rid of this one: drivers/s390/cio/cio.c:115: warning: 'cio_tpi' defined but not used Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/cio/cio.c | 75 ++++++++++++++++++++++++------------------------- 1 file changed, 37 insertions(+), 38 deletions(-) Index: ...

From: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/block/dasd_devmap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: quilt-2.6/drivers/s390/block/dasd_devmap.c =================================================================== --- quilt-2.6.orig/drivers/s390/block/dasd_devmap.c +++ quilt-2.6/drivers/s390/block/dasd_devmap.c @@ -562,7 ...

From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Values for the sac field have changed - update code accordingly. Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/include/asm/fcx.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: quilt-2.6/arch/s390/include/asm/fcx.h =================================================================== --- ...

From: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/debug.c | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) Index: quilt-2.6/arch/s390/kernel/debug.c =================================================================== --- quilt-2.6.orig/arch/s390/kernel/debug.c +++ quilt-2.6/arch/s390/kernel/debug.c @@ -10,6 +10,9 @@ ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/sclp_cmd.c | 29 ++++++++++++++++------------- drivers/s390/char/sclp_config.c | 10 ++++++---- drivers/s390/char/sclp_cpi_sys.c | 12 ++++++++---- drivers/s390/char/sclp_sdias.c | 18 +++++++++++------- 4 files changed, 41 insertions(+), 28 deletions(-) Index: ...

From: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/net/qeth_core.h | 7 - drivers/s390/net/qeth_core_main.c | 149 ++++++++++++++------------ drivers/s390/net/qeth_l2_main.c | 37 +++--- drivers/s390/net/qeth_l3_main.c | 211 +++++++++++++++++++------------------- 4 files changed, 212 insertions(+), 192 deletions(-) Index: ...

From: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/zcore.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) Index: quilt-2.6/drivers/s390/char/zcore.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/zcore.c +++ quilt-2.6/drivers/s390/char/zcore.c @@ -9,6 +9,9 @@ * Author(s): Michael ...

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- Documentation/kernel-parameters.txt | 3 ++ Documentation/kmsg/s390/hvc_iucv | 50 ++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) Index: quilt-2.6/Documentation/kernel-parameters.txt =================================================================== --- ...

From: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/scsi/zfcp_aux.c | 9 ++++++--- drivers/s390/scsi/zfcp_ccw.c | 3 +++ drivers/s390/scsi/zfcp_cfdc.c | 3 +++ drivers/s390/scsi/zfcp_dbf.c | 3 +++ drivers/s390/scsi/zfcp_erp.c | 3 +++ drivers/s390/scsi/zfcp_fc.c | 3 +++ drivers/s390/scsi/zfcp_fsf.c | 3 +++ ...

From: Hongjie Yang <hongjie@us.ibm.com> Signed-off-by: Hongjie Yang <hongjie@us.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/mm/extmem.c | 106 +++++++++++++++++-------------------------- drivers/s390/block/dcssblk.c | 72 +++++++++++++---------------- 2 files changed, 76 insertions(+), 102 deletions(-) Index: quilt-2.6/arch/s390/mm/extmem.c =================================================================== --- ...

From: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/monreader.c | 41 +++++++++++++++++------------------------ 1 file changed, 17 insertions(+), 24 deletions(-) Index: quilt-2.6/drivers/s390/char/monreader.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/monreader.c +++ ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/setup.c | 72 ++++++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 26 deletions(-) Index: quilt-2.6/arch/s390/kernel/setup.c =================================================================== --- quilt-2.6.orig/arch/s390/kernel/setup.c +++ quilt-2.6/arch/s390/kernel/setup.c @@ -14,6 +14,9 @@ * This file handles the ...

From: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/crypto/aes_s390.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) Index: quilt-2.6/arch/s390/crypto/aes_s390.c =================================================================== --- quilt-2.6.orig/arch/s390/crypto/aes_s390.c +++ quilt-2.6/arch/s390/crypto/aes_s390.c @@ -17,6 +17,9 @@ * */ ...

From: Sebastian Ott <sebott@linux.vnet.ibm.com> Due to former patches a comment and device id initialization were split from the addressed function call in io_subchannel_probe. Move it back to where it belongs. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/cio/device.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) Index: ...

From: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/char/vmcp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) Index: quilt-2.6/drivers/s390/char/vmcp.c =================================================================== --- quilt-2.6.orig/drivers/s390/char/vmcp.c +++ quilt-2.6/drivers/s390/char/vmcp.c @@ -11,6 +11,9 @@ * The ...

From: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/cpcmd.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: quilt-2.6/arch/s390/kernel/cpcmd.c =================================================================== --- quilt-2.6.orig/arch/s390/kernel/cpcmd.c +++ quilt-2.6/arch/s390/kernel/cpcmd.c @@ -7,6 +7,9 @@ * ...

From: Michael Ernst <mernst@de.ibm.com> Signed-off-by: Michael Ernst <mernst@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/cio/blacklist.c | 14 +++++++++----- drivers/s390/cio/chsc.c | 8 ++++++-- drivers/s390/cio/cio.c | 5 ++++- drivers/s390/cio/cmf.c | 8 +++++--- drivers/s390/cio/css.c | 8 ++++++-- 5 files changed, 30 insertions(+), 13 deletions(-) Index: ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> disabled_wait() won't return, so add an __attribute__((noreturn)). This will remove a false positive finding which our internal code checker reports. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/include/asm/processor.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Index: ...

From: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Provide a locking free version of iucv_message_receive and iucv_message_send that do not call local_bh_enable in a spin_lock_(bh|irqsave)() context. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> --- include/net/iucv/iucv.h | 45 ++++++++++++++ net/iucv/iucv.c | 152 ++++++++++++++++++++++++++++++++++++------------ 2 files changed, 161 insertions(+), 36 deletions(-) Index: ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> For CONFIG_SPARSEMEM_VMEMMAP=y on s390 I get warnings like init/main.c: In function 'start_kernel': init/main.c:641: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has type 'int' The warning can be suppressed with a cast to unsigned long in the CONFIG_SPARSEMEM_VMEMMAP=y version of __page_to_pfn. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- include/asm-generic/memory_model.h | 2 +- 1 ...

From: Jan Glauber <jang@linux.vnet.ibm.com> - make qdio_trace a per device view - remove s390dbf exceptions - remove CONFIG_QDIO_DEBUG, not needed anymore if we check for the level before calling sprintf - use snprintf for dbf entries - add start markers to see if the dbf view wrapped - add a global error view for all queues Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/Kconfig | 10 - ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> Since etr/stp don't need the old smp_call_function semantics anymore we can convert s390 to the generic IPI infrastructure. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/Kconfig | 1 arch/s390/include/asm/sigp.h | 1 arch/s390/include/asm/smp.h | 5 - arch/s390/kernel/smp.c | 175 ++++--------------------------------------- 4 ...

From: Stefan Haberland <stefan.haberland@de.ibm.com> For a large number of I/O requests the values were shifted binary. The shift was not transparent for the user because the shift value was not displayed. To make this interface more human readable the values are shifted decimal and the scale factor is displayed. Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/block/dasd_proc.c | 28 ...

From: Jan Glauber <jang@linux.vnet.ibm.com> - Use automatic acknowledgement of incoming buffers in QEBSM mode - Move ACK for non-QEBSM mode always to the newest buffer to prevent a race with qdio_stop_polling - Remove the polling spinlock, the upper layer drivers return new buffers in the same code path and could not run in parallel - Don't flood the error log in case of no-target-buffer-empty - In handle_inbound we check if we would overwrite an ACK'ed buffer, if so advance the pointer ...

From: Christof Schmitt <christof.schmitt@de.ibm.com> Register zfcp with the new /proc/service_level interface to report the FCP microcode level. When the adapter goes offline or a channel path disappears, zfcp unregisters, since the microcode version might change and zfcp does not know about it. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- drivers/s390/scsi/zfcp_aux.c | 13 +++++++++++++ ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> This converts the etr and stp code to the new stop_machine interface which allows to synchronize all cpus without allocating any memory. This way we get rid of the only reason why we haven't converted s390 to the generic IPI interface yet. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- arch/s390/kernel/time.c | 212 +++++++++++++++++++++++++++++------------------- 1 ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> The work function dispatched with schedule_work() can be run twice on different cpus because run_workqueue clears the WORK_STRUCT_PENDING bit and then executes the function. Another cpu can call schedule_work() again and run the work function a second time before the first call is completed. This patch serialized the etr and stp work function with a mutex. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> --- ...

From: Martin Schwidefsky <schwidefsky@de.ibm.com> arch_setup_additional_pages currently gets two arguments, the binary format descripton and an indication if the process uses an executable stack or not. The second argument is not used by anybody, it could be removed without replacement. What actually does make sense is to pass an indication if the process uses the elf interpreter or not. The glibc code will not use anything from the vdso if the process does not use the dynamic linker, so ...

Greetings, the features branch of git390 has grown to 60 patches for the next merge window: Carsten Otte (1): [S390] tape message cleanup Christian Borntraeger (3): [S390] vmcp: remove BKL [S390] convert vmcp printks to pr_xxx macros. [S390] convert cpcmd printks to pr_xxx macros. Christian Maaser (1): [S390] ap: Minor code beautification. Christof Schmitt (2): [S390] zfcp: Report microcode level through service level interface [S390] ...

Since CONFIG_R8169_NAPI has been removed,no need to include it in defconfig now Signed-off-by: Feng King <kinwin2008@gmail.com> --- arch/arm/configs/iop32x_defconfig | 1 - arch/mips/configs/mtx1_defconfig | 1 - arch/mips/configs/tb0219_defconfig | 1 - arch/mips/configs/tb0287_defconfig | 1 - 4 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/iop32x_defconfig b/arch/arm/configs/iop32x_defconfig index 8612f58..05be5e2 100644 --- ...

Yeah, I wondered about doing it that way, although not using the LED driver as GPIO is bi-directional. There is an existing GPIO subsystem which makes gpios available within the kernel, but does not expose them Perhaps exposing the existing gpio kernel infrastructure into /dev in some fashion would make sense? We'd have to create some kind of 'protocol' for the write operation that would mark which bits to change, and perhaps some way of explicitly setting pins to tri-state. That would ...

Yes, there are a number of other ones already in use that have them. What we have done in the past for them is just use a simple userspace program/library that uses usbfs/libusb to access the device directly. Can you do the same thing here as well? Or do you also need to send/recieve serial data through the device at the same time? thanks, greg k-h --

On Thu, 27 Nov 2008 00:29:36 -0800 Only concern I have is that a custom ioctl means every time a new serial chip grows GPIO pins we end up with more ioctls. We have an LED class driver which might perhaps do the job but isn't really oriented that way but would keep the tty and gpio pins separate and available to different applications at the same time. Failing that a rename to make it a generic tty gpio ioctl might be more futurerpoof ? Alan --

The cp2103 is programmed the same as the cp2101/cp2102 except for the addition of a set of four GPIO pins which can be directly controlled by the host. Access to this is done through a custom ioctl. Signed-off-by: Keith Packard <keithp@keithp.com> --- drivers/usb/serial/cp2101.c | 97 ++++++++++++++++++++++++++++++++++++++++++- drivers/usb/serial/cp2101.h | 39 +++++++++++++++++ 2 files changed, 135 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/serial/cp2101.h diff ...

Michael, Here is the proposal for a description of signals handling in pid namespaces. This applies on top of your CLONE_NEWPID patch. Regards, Nadia --- man2/clone.2 | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) Index: man-pages-3.13/man2/clone.2 =================================================================== --- man-pages-3.13.orig/man2/clone.2 2008-11-24 09:34:30.000000000 +0100 +++ man-pages-3.13/man2/clone.2 2008-11-27 09:17:53.000000000 +0100 @@ ...

Hi, Kame, others on the mailing list, I am currently attending FOSS.IN (http://foss.in), I hope to review/see these patches and other reports next week. -- Balbir --

Great work! I've not reviewed these patches in detail yet, I agree to this direction to remove cgroup_lock() at hierarcal reclaim. Actualy, I was thinking it would be better to manage some array or list at mkdir/rmdir. hmm, but should this ID be implemented in cgroup level, not in memcg level? Thanks, --

My computer was unresponsive yesterday and had to ask my to wife reset the server. The only thing I could find in the logs is below. Judging from the timestamp it was caused by the daily logrotate. The logfiles are moved from an ext3 to an ext4 filesystem. This is probably not enough for a decent bug report but I thought I report it anyway, even if it is just for statistics. my .config can be found at http://www.bencastricum.nl/.config Kind regards, Ben Nov 26 00:00:03 gateway ...

thanks, i've applied Lai's patch from email to tip/tracing/urgent. Ingo --

Is there something about git that causes (or forces) the use of patch 0/1 followed by patch 1/1? I find it terribly unwanted. thanks, -- ~Randy --

Ouch! Thanks, this patch should go straight to mainline. The version in tip uses the new ftrace_preempt_disable which is not yet in mainline. -- Steve --

good catch! Applied to tip/sched/urgent, thanks Steve! the rebalancer scans remote runqueues without holding the runqueue lock for performance reasons, so nr_running indeed has to be loaded into a local variable here. I think it could hit anywhere upstream as well, even without the branch tracer: depends on the register pressure and GCC's choices for reloading that register. If say FRAME_POINTER is enabled and we are running with some more agressive optimization or just an ...

There exists a race where we can hit a divide by zero in the scheduler and crash the system. The following patches are in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: urgent Steven Rostedt (1): sched: prevent divide by zero error in cpu_avg_load_per_task ---- kernel/sched.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) -- --

Add those interfaces, as well as helpers needed to easily manage the file format. The code is roughly broken out as follows: checkpoint/sys.c - user/kernel data transfer, as well as setup of the CR context (a per-checkpoint data structure for housekeeping) checkpoint/checkpoint.c - output wrappers and basic checkpoint handling checkpoint/restart.c - input wrappers and basic restart handling For now, we can only checkpoint the 'current' task ("self" checkpoint), and the 'pid' argument to to ...

Infrastructure to handle objects that may be shared and referenced by multiple tasks or other objects, e..g open files, memory address space etc. The state of shared objects is saved once. On the first encounter, the state is dumped and the object is assigned a unique identifier (objref) and also stored in a hash table (indexed by its physical kenrel address). From then on the object will be found in the hash and only its identifier is saved. On restart the identifier is looked up in the ...

Covers application checkpoint/restart, overall design, interfaces, usage, shared objects, and and checkpoint image format. Changelog[v8]: - Split into multiple files in Documentation/checkpoint/... - Extend documentation, fix typos and comments from feedback Signed-off-by: Oren Laadan <orenl@cs.columbia.edu> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com> --- Documentation/checkpoint/ckpt.c | 32 +++++++ ...

Create trivial sys_checkpoint and sys_restore system calls. They will enable to checkpoint and restart an entire container, to and from a checkpoint image file descriptor. The syscalls take a file descriptor (for the image file) and flags as arguments. For sys_checkpoint the first argument identifies the target container; for sys_restart it will identify the checkpoint image. A checkpoint, much like a process coredump, dumps the state of multiple processes at once, including the state of the ...

Dump the files_struct of a task with 'struct cr_hdr_files', followed by all open file descriptors. Since FDs can be shared, they are assigned an objref and registered in the object hash. For each open FD there is a 'struct cr_hdr_fd_ent' with the FD, its objref and its close-on-exec property. If the FD is to be saved (first time) then this is followed by a 'struct cr_hdr_fd_data' with the FD state. Then will come the next FD and so on. This patch only handles basic FDs - regular files, ...

Checkpointing of multiple processes works by recording the tasks tree structure below a given task (usually this task is the container init). For a given task, do a DFS scan of the tasks tree and collect them into an array (keeping a reference to each task). Using DFS simplifies the recreation of tasks either in user space or kernel space. For each task collected, test if it can be checkpointed, and save its pid, tgid, and ppid. The actual work is divided into two passes: a first scan counts ...

Restore open file descriptors: for each FD read 'struct cr_hdr_fd_ent' and lookup objref in the hash table; if not found (first occurence), read in 'struct cr_hdr_fd_data', create a new FD and register in the hash. Otherwise attach the file pointer from the hash as an FD. This patch only handles basic FDs - regular files, directories and also symbolic links. Changelog[v6]: - Balance all calls to cr_hbuf_get() with matching cr_hbuf_put() (even though it's not really ...

That's because trace_pipe does not use an iterator ;-) It is live stream. There's two cases: static read and consume. On static read we can take our time and we iterate over the data in the file. The data does not get consumed so we use an iterator to traverse the data. The consume read will consume each entry as it reads it. We do not need an iterator for this because we are always reading the head of the file. After we read the data, that data is consumed and we read the next ...

Ok. Thanks, I will correct it by covering the two cases, like in trace.c : peek_next_entry() --

if you look at it on a console where you look at code, it all looks like a straight line: 0) | sys_read() { 0) 0.331 us | fget_light(); 0) | vfs_read() { 0) | rw_verify_area() { 0) | security_file_permission() { 0) 0.306 us | cap_file_permission(); 0) 0.300 us | cap_file_permission(); 0) 8.909 us | } 0) 0.993 us | } 0) 11.649 us | } 0) ...

Yeah! I agree with all of that. That's fair. I will apply these advices, probably divided in multiple patches.... --

lets keep it default-enabled, ok? It makes sense. Ingo --

Yeah, wanted to point that out too - but i started with the more commonly used (and most critical) printout portion: the function call That extra column should be a trace_option though - default-off. (it uses up quite some screen real estate) It would have to have a width of 14 characters to be practical: ssssssss-12345 mockup: ---------------------------------------------------------------- CPU) task-PID | cost | ...

Impact: enhancement This patch applies some ideas of Ingo Molnar and Steven Rostedt. * Output leaf functions in one line with parenthesis, semicolon and duration output. * Add a second column (after cpu) for an overhead sign. if duration > 100 us, "!" if duration > 10 us, "+" else " " * Print output in us with remaining nanosec: u.n * Print duration on the right end, following the indentation of the functions. Use also visual clues: "-" on entry call (no duration to output) ...

This is the most horrid thing I've ever seen. Please just put the comm/pid in another left column and leave a plain "---" string for context switches. comm/pid only in the separator is useless, you cannot grep stuff like that, also, what's up with those '8's ? --

Note that your PID filter is in tip/tracing/core already, so Frederic can make use of it if he wishes to. Changing it to struct pid (whenever that happens) will not change its functionality. Ingo --

Ok. BTW I understand why it is better to have a "pipe" if there is no time: 0) | do_sync_read() { 0) | sock_aio_read() { 0) | __sock_recvmsg() { 0) | security_socket_recvmsg() { But I don't see why it is necessary to have one just after the time: !0) 100.319 us | cap_socket_recvmsg(); It appears to me as noise.... --

One detail. If you get a trace through the "trace" file, you will have no problem. But if you cat trace_pipe, leaf functions are considered as nested. This is because iter->buffer_iter[iter->cpu]; is very often (always?) false by using this file. I don't know why yet.... But it makes the tracer unable to check the next entry to verify if it matches its own return. --

Yes please. I like the separator better. Sure, we could add a trace_option that will let us print the name on all lines, which will make it grepable better. But this is better to see when the switch happens. Also, Frederic could use my ftrace_trace_pid to filter only on a single thread. But that will need to wait till we figure out this namespace issue. -- Steve --

Fair enough. I forgot that we do a late handover from jiffies to the real clocksource. Still a WARN_ON is more prominent and more useful for developers to get to the root cause. Setting the shift to 31 will result in wrong timer values but not brick the box. So espcially for code, which calculates the values this might be worthwhile. Thanks, tglx --

Just setting the shift value to 31 along with a WARN_ON() should be enough. We don't need to kill the clocksource in that case, as this can be nasty when it happens in the early boot code where we dont have any output. Thanks, tglx --

From: Eric Dumazet <dada1@cosmosbay.com> Networking bits look fine: Acked-by: David S. Miller <davem@davemloft.net> --

Yes I will try that definitley, but I hoped that someone maybe knows if that was a particular problem of that kernel (according to the panic log) version and chances are good they are fixed in later versions. The second problem is, that it can takes fairly long until I know if the problem is gone because sometimes it takes 2 months until a crash happens. So the second question is, how to prove if this is not hardware or how to prove it is definitley hardware. I have read the list and saw that NMI ...

I don't believe that right now. we see so many of these, including many "there's no MTRRs at all", that I am seriously suspecting that our code is just incorrect somehow and triggering too much. --

the warning here means: "the BIOS messed up but we fixed it up for you just fine". Should we print a DMI descriptor so that it can be tracked back to the bad BIOSen in question? Or should we (partially) silence the warning itself? Those BIOS bugs need fixing really: older kernels will boot up with bad MTRR settings - resulting in a super-slow system or other weirdnesses. We can tone down the message so that it doesnt show up in kerneloops.org. It's up to you. Ingo --

I actually think we're doing something wrong here, since so many platforms have this behavior. It's likely that there's an undocumented, additional check needed to determine whether a slot is hot pluggable. Matthew Garrett recently posted a patch to check for ACPI _RMV methods, which should be an improvement. I'll be putting that into linux-next soon for testing. -- Jesse Barnes, Intel Open Source Technology Center --

well we looked at existing reports and Linux was right to fix them up. Show us one that is incorrect, then we can fix it up. the "no MTRR's" are vmware/(also qemu?) guests not implementing a full CPU emulation. Ingo --

IIRC we fixed this one post-2.6.27. I didn't send the patches back to -stable because they were a bit big, but if someone were sufficiently motiviated I'm sure the backport wouldn't be that hard... Jesse --

On Thu, 27 Nov 2008 21:47:14 +0100 it might. but even if they would fix that, we would still WARN ( at least we should do our side correctly... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

I can do this backport. A few questions though... We're seeing a proliferation of this one presumably because Fedora10 uses 2.6.27.5 as a starting point? If I just backport the fixes against Greg's latest tree, do I have to do anything special to make sure they get into the Fedora kernel? Also, does kerneloops capture any of the machine information, like DMI output, etc. or does it just get the oops? It would be nice to see which machines out there have the broken BIOS that causes this ...

From: Harvey Harrison <harvey.harrison@gmail.com> Applied, thanks everyone. --

From: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: David S. Miller <davem@davemloft.net> --

Hi, Have you checked the compiler output? And on all architectures? And on all gcc versions? The reason I introduced the constant version are precisely that at least some versions of gcc at least on some architectures do NOT handle the constant folding and actually put in endianness conversion code for the constants instead of converting them at compile time. Also you are breaking sparse checking with this patch as you remove some of the necessary endianness conversions (e.g. ...

Make relatime smarter Allow atime to be updated once per day even with relatime. This lets utilities like tmpreaper (which delete files based on last access time) continue working. --- Subset of Ingo's original patch, rediffed against current git diff --git a/fs/inode.c b/fs/inode.c index 0487ddb..348fa16 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -1179,6 +1179,41 @@ sector_t bmap(struct inode * inode, sector_t block) } EXPORT_SYMBOL(bmap); +/* + * Relative atime updates ...

Maybe rename relatime_need_update to atime_need_update and factor this check into it? Except for this nitpicks this seems extremly useful --

thanks Matthew for picking this up! Acked-by: Ingo Molnar <mingo@elte.hu> Ingo --

The one problem with a 1-day default is that cron jobs like updatedb will revert to updating the atime on every single file every day. It would be better to make it slightly more than 1 day (e.g. 25h) to avoid this and at least defer atime updates to every other day for files that are not otherwise accessed except by cron. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --

Yes, that sounds like a reasonable approach. In that case I'll update the first to include the support for configuring the timeout. -- Matthew Garrett | mjg59@srcf.ucam.org --

NAK this This is a change in behaviour and you don't turn it on by default so most users will miss it. You don't need it anyway and it doesn't need to be NAK this Putting in extra flags to allow the kernel and user space to fight each other over mount defaults is a recipe for disaster. Take your userspace mount command and beat it up appropriately. If you want a mount command that defaults to relatime then ship a mount command that does. This patch really doesn't make sense. You add ...

Add support for defaulting to relatime Allow the kernel to enable relatime on all mounts by default. This can be configured at build time or by a kernel parameter or sysctl. Also add a MS_NORELATIME mount option to allow the default to be overridden for specific mount points. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- Incorporates Randy's suggestion to change default_relatime to relatime_default, along with a couple of typographical fixes diff --git ...

Doesn't updatedb only access directories, not files? I don't think relatime implies nodiratime, but certainly the two could both be specified, and that would fix one of the updatedb problems. Are there any other common cronjobs you're concerned about? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

-- Alexander van Heukelum heukelum@fastmail.fm -- http://www.fastmail.fm - A no graphics, no pop-ups email service --

applied to tip/x86/irq, thanks! Ingo --

Unfortunately that review got you off the right track ... The principle you applied was good: entry_64.S is murky, and we want to simplify the current overcomplicated assembly code flow spaghetti there. Note that if you take a closer look at rff_trace/rff_action ret_from_fork code here, you'll realize that it does all the wrong things: for example it checks the TIF flag - while later on jumping back to the ret-from-syscall path - duplicating the check needlessly. But it gets worse ...

On Thu, Nov 27, 2008 at 1:15 PM, Alexander van Heukelum Indeed, thanks (such an indirect and nested definition sometime confusing) --

applied, thanks guys! Ingo --

-- Alexander van Heukelum heukelum@fastmail.fm -- http://www.fastmail.fm - The way an email service should be --

Cyrill, could you please rework the still relevant bits against latest tip/master? Alexander's wider patch got in the way. Thanks, Ingo --

Yes, my apologies for not making that obvious. Acked-by: Paul Mundt <lethal@linux-sh.org> --

I rather trusted you on the ARM end of it: I won't be kicking up a fuss if my Acked-by ends up appearing on that part too, but really, it was for the linux/highmem.h end of it. Hugh --

Applied to trivial patches tree, thanks. -- Jiri Kosina --

On Wed, 26 Nov 2008 17:48:08 +0200 We have over 2000 ERR_PTR callsites, and WARN_ON() is a big fat porky thing, so this change would add quite a lot of kernel text&data. If this problem does occur again, I expect that the kernel will reliably dereference a small negative address and we'll get an oops, which will give us the same information as that WARN_ON would have done, no? --

John, looks like wireless is missing a select on CRYPTO somewhere. Cheers, -- 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 --

That's much better! With your comments I'd assume you reviewed this patch ;-) Thanks, Fengguang --- markers: comment marker_synchronize_unregister() on data dependency Add document and comments on marker_synchronize_unregister(): it should be called before freeing resources that the probes depend on. Based on comments from Lai Jiangshan and Mathieu Desnoyers. Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Reviewed-by: Lai Jiangshan ...

[updated patch to include Documentation/markers.txt changes] Add document and comments on marker_synchronize_unregister(): it should be called before freeing resources that the probes depend on. Based on comments from Lai Jiangshan and Mathieu Desnoyers. Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Wu Fengguang <wfg@linux.intel.com> --- diff --git a/Documentation/markers.txt b/Documentation/markers.txt index 089f613..8bf6afe ...

Thank you, Fengguang --- markers: comment marker_synchronize_unregister() on data dependency Add document and comments on marker_synchronize_unregister(): it should be called before freeing resources that the probes depend on. Based on comments from Lai Jiangshan and Mathieu Desnoyers. Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Reviewed-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Wu Fengguang <wfg@linux.intel.com> --- diff --git a/Documentation/markers.txt ...

Ack. Thanks, Miklos --

Ingo, This variable says, there is perfmon support in the kernel but initialization of the That one says that we do not have support for that particular PMU model. In the fully-featured version, there PMU description table is loaded via a kernel module. So you can be in a situation where the subsystem initialized properly but no PMU description module is loaded or none exists for this processor. That's what this second test is about. Note that if all PMU description tables are compiled in, we ...

Normally it's a better model to enforce 0 (or whatever appropiate) My recommendation would be to go with the full format from the beginning, because otherwise there is a versioning problem with glibc. -Andi -- ak@linux.intel.com --

The meaning of my last sentence is the jist of my argument: you cannot do it like this! You are using a bit of the ptrace infrastructure but unsafely, as pointed out here. and the thing is, i fail to understand the whole justification of the new sys_pfm_attach()/PFM_NO_TARGET system calls. Firstly, there's a taste issue: why didnt you add sys_pfm_detach instead of adding a butt-ugly PFM_NO_TARGET special case into sys_pfm_attach() that maps to pfm_detach?? But more importantly, ...

After looking at both I did a diff of the two functions: --- r.c 2008-11-27 14:27:54.000000000 +0100 +++ w.c 2008-11-27 14:27:52.000000000 +0100 @@ -36,10 +36,12 @@ ret = pfm_check_task_state(ctx, PFM_CMD_STOPPED, &flags); if (ret) goto skip; - switch(type) { + case PFM_RW_PMC: + ret = __pfm_write_pmcs(ctx, req, count); + break; case PFM_RW_PMD: - ret = __pfm_read_pmds(ctx, req, count); + ret = __pfm_write_pmds(ctx, req, count); break; default: ...

Because of the self IPI. You would need a NMI safe queue between NMI and self IPI, but then you could as well have the same queue between NMI and process readers. -Andi -- ak@linux.intel.com --

What if a threads reprograms the counters while another is reading them? How is the buffer reset? --

In newer Intel the counters can be reset/rearmed by accessing only a few global control msrs. But it's probably still a problem on other PMUs. On the other hand it also has PEBS which allows at least some Lockless buffers are nasty, but it works in oprofile at least. Taking out NMis in the first version at least seems like a reasonable solution. After all you can still use standard oprofile where they work just fine. -Andi -- ak@linux.intel.com --

Thomas, I think we agree as to why the user visible structures have to have fixed size. Some structures have bitfields in them (no in the current patchset yet). Here is an example: #define PFM_PMD_BV (256/sizeof(__u64)) struct pfarg_pmd_attr { __u16 reg_num; /* which register */ __u16 reg_set; /* which event set */ __u32 reg_flags; /* REGFL flags */ __u64 reg_value; /* 64-bit value */ __u64 reg_long_reset; /* ...

True. It would really need a NMI safe queue. -Andi -- ak@linux.intel.com --

Stephane, I really can not see the problem. 1) perfmon.h can have a section for kernel and user space. We have tons of examples of this in the kernel already. The user space data structures are separate, simply because they are an user space ABI and can not be changed. Kernel data structures can be completely different from the user ABI and can be changed at any given time as the code evolves. The design you are proposing is tying the in kernel data structures to the user ABI ...

We can limit the functionality here. Fail or disable the NMI watchdog are both valid solutions. Thanks, tglx --

Fair enough. Thanks, tglx --

Why would you get only one sample per irq-off region if you use NMI? I would think you could get multiple, depending on your sampling period and the size of the region. --

What about a thread doing this and another one in the middle of read the buffer? Or what about a thread trying to reset the buffer while you're processing an PMU interrupt on another CPU. I know each buffer is per-CPU, but that does not prevent two threads for trying to operate on it at the same time from different CPUs. --

Exactly the same amount which you get with the NMI/self_IPI out of an irq-off region. Thanks, tglx --

So? You can disable it on the fly when there is a perfmon user. --

Assuming that the irqs off regions are not too long (and that's usually the case) that should be enough, shouldn't it? Sure there are still CPUs with neither IBS or PEBS. -Andi -- ak@linux.intel.com --

I think that is fine as long as the interrupt handler does not need to grab locks. But that, in turn, means that the state needed/modified by the handler cannot So you're saying a thread can only access the buffer from the CPU it is running on? --

> Well, where is it checked ? Where is checked whether Oprofile runs or not ? That is done using the perfctr reservation. I saw that somewhere in the The perfctr reservation is global over all CPUs. -Andi -- ak@linux.intel.com --

Stephane, Well, if you do a structure then put the lock in it as well, so its on If its not needed now, then we can either remove it or do at least Then it is a percpu session and not system wide. Please use less Ok. Question: if you do a one CPU wide session with perfom, can you still do thread monitoring on the same CPU ? This only prevents oprofile from starting, but it does neither prevent thread sessions nor does it prevent a perfmon per cpu session on a cpu which was ...

Thomas, There is a single instance. I was just trying to regroup related fields together instead of having them as Well, the the cpumask is indeed needed but you don't see the reason why in the patchset! Perfmon in system-wide does not operate like Oprofile. In system-wide a perfmon session (context) monitors only ONE CPU at a time. Each session is independent of each other. You can therefore measure different things on different CPUs. Reservation is thus done independently for ...

thomas, It does not care whether it is Oprofile, NMI or any other subsystem. What matters is: - what PMU registers are available? - what CPU are not used for monitoring? I know that. I have used this name since the beginning, it's more legacy than anything else. Let's call this cpu-wide mode. I think people are more Nothing. AND you don't want to change affinity because you are monitoring. So the current restriction is that cpu-wide and per-thread are mutually exclusive. The only way ...

Thomas, That is a different level of resource management: register level. Both Perfmon and Oprofile can operate with fewer registers than what the hardware actually supports. Take an AMD64 CPU with 4 counters. With the NMI watchdog active, Perfmon or Oprofile will run with only 3. That's better than nothing and is sufficient for many measurments. --

What devices are there left these days that are still not working with native drivers? --

Is it really a wise idea to mix this into the signal number? Also this definition looks odd. If you want the highest bit, you should mention this explicitely with 1U<<31. If I see this correctly this information is already covered in si_code with SI_USER and SI_TKILL. SI_KERNEL is used for explicit kernel This is not used at all here? Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown --

Suka, I'm wondering if it is still safe to keep the call to task_active_pid_ns() in create_new_namespaces(): copy_namespaces() is called a couple of lines above this sequence and it calls create_new_namespaces(). So I don't see why you're now referencing p->nsproxy->pid_ns here and not in create_new_namespaces()? Regards, -- Nadia Derbey <Nadia.Derbey@bull.net> --

When can the pid argument be null? Bastian -- Another Armenia, Belgium ... the weak innocents who always seem to be located on a natural invasion route. -- Kirk, "Errand of Mercy", stardate 3198.4 --

We have such a system at work. And we need fast acces to the gpio pins when updating the LCD. I have not written/looked to deep at the code I just recall it was a bit messy and not something I would be proud of submitting to any ML. Sam --

Or when they added speakers to even allow any music to be played. -- Len Sorensen --

Are you referring to this? ^^^^^^^^^^ Without seeing the raw dump of the PCI config space, it looks to me like the memory space enable bit of the PCICMD register is unset. Probably the device driver should call pci_enable_device() at init time, though I Actually, you can "hot-add" devices that were previously removed. Just rescan the removed device's bridge by running this command: echo 1 > /sys/bus/pci/slots/fakeX/power. Onlining the bridge (even if it's already ...

On Tue, Nov 25, 2008 at 5:28 PM, Luis R. Rodriguez Cool, that saved me some work. I updated this so that the files are now up-to-date, and it can be called directly from the commit-msg hook (also handles existing Signed-off-by etc). Feel free to take whatever you like from my version. -- Bob Copeland %% www.bobcopeland.com

Hello, Yeah, it seems we'll need something which is equivalent to smp_wmb() in try_to_wake_up(). So, the original set_mb() should have stayed there while just adding the latter one. Will prep yet another take of the patch. Thanks for the detailed analysis. -- tejun --

do you really need that mutex in the ! case? --

We're not sending any signals ;-) destroy or free perhaps? --

That is quite horrible, please just open code that to keep the locking symmetric. --

Yeah, but one thing I learned from messing with rfkill is that little helper Or add an integer attribute for the fractional part (which takes some Frankly, I don't like the fact that LED_FULL survived. That's a trap waiting to be sprung on any unsuspecting maintainers adding or messing with LED support everywhere in the kernel... IMO, it'd be best to have an DEFAULT_LED_FULL_VALUE define you can use to set max_brightness where needed, and use the gcc facilities to deprecate any use of ...

Hi Hugh, For SLUB, I think you can just replace the 100 with KSYM_NAME_LEN and it will work fine. The 100 constant is already supposed to be big enough to fit the symbol and the rest. I like this approach the best but I worry it's a can of worms especially this late in the cycle. As a stop-gap measure, I'm fine with your proposed patch either as-is or with the suggestions I had for the SLUB case. Pekka --

Your fix looks fine. The maximum symbol length needs to be supported by list_locations() althought a line with a symbol like that would look a bit weird. --

That would fix the bug that my sprint_symbol patch has exposed (or introduced, according to your perspective!); but that 100 can only be big enough to fit symbol and all the rest if you assume that maximum symbol length is ... I'm not sure exactly ... somewhere around 20 bytes? If we assume that, then why does KSYM_NAME_LEN allow 128? I'll agree that 128 seems rather on the high side (I'd abhor symbols of anywhere near that length in any code I came near), but that's what's allowed, I'd be ...

Hi Hugh, (I'm adding Vegard to the cc as he pointed out the same thing.) Oh, right. I think I see where this is going. The buffer is coming from sysfs and is PAGE_SIZE long. In SLUB, we do check for overflows but list_locations() allows us to get as close as 100 bytes bytes from the edge of the page. Unfortunately, kallsyms_lookup() does: const char *kallsyms_lookup(unsigned long addr, unsigned long *symbolsize, unsigned long ...

I think you're looking at a 2.6.28-rc5 sprint_symbol() there: the world has moved on since those days. I changed it to use the supplied "buffer" instead of local "namebuf" in 2.6.28-rc6, so we have to wonder if my patch is to blame - though I don't see it. Sorry, I'm eating lunch then about to go out for a couple of hours: can't look into it now, but maybe this info will help you to make better sense of what's going on. Hugh --

Hi, (I'm jumping in as Andrew forwarded the bug to us thinking it's SLUB related.) Could be. I looked at the oops and I'm pretty sure SLUB is not at fault here. Decoding the oopsing code: [ 3866.841062] Code: df e8 39 d2 ff ff 5b 41 5c c9 c3 55 48 89 e5 41 57 49 89 cf 41 56 49 89 f6 41 55 49 89 d5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 08 <41> c6 40 7f 00 41 c6 00 00 48 81 ff 00 90 20 80 72 09 48 81 ff results in: 0000000000000000 <.text>: 0: 41 c6 40 7f 00 ...

No, playing with driver for HP LED. Now... I guess the test confused me. Because it tests for irqs_disabled(), I assumed it was okay to call from interrupt context, Works for me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

On Tue, 25 Nov 2008 15:54:22 -0800 Hmm, I'll prepare renaming patch. scan_global_lru_p() ? or under_scanning_global_lru() ? Thanks, --

Hi Ingo, thanks for the above change, I think I was in a hurry because of Thanksgiving Day week. thanks, Hiroshi Shimamoto --

wikipedia (not that that really means much) claims antennae is correct for biology and antennas is correct for electronics. That seems to match what I do, not that I really ever talk about biology myself. :) Of course I am one of those people that thing disc means optical and disk means magnetic. Or disc for spiral track and disk for circular tracks. Both seem to work consistently, although I might be wrong and some optical media may in fact use circular tracks. -- Len Sorensen --

I dunno the LTT architecture, so I'm staying out of that discussion. But, if the patch you're trying to push is to avoid thundering herd of so many threads waiting on the single file*, you've got the same problem right there. You've got at least the spinlock protecting the queue where these threads are focusing, whose cacheline is bounced gets bounced all over the CPUs. Do you have any measure of the improvements that such poll_wait_exclusive() will eventually lead to? - ...

impact: new feature move irq_desc with sparseirq if CONFIG_MOVE_IRQ_DESC is set make irq_desc to go with affinity aka irq_desc moving etc call move_irq_desc in irq_complete_move() legacy irq_desc is not moved, because they are allocated via static array v3: add calling to irq_to_desc after calling ack/eoi instead of passing desc for logical apic mode, need to add move_desc_in_progress_in_same_domain. otherwise it will not get moved. ==> also could need two phase to get irq_desc ...

Hi Reproduced with 2.6.27.7 with ec.c taken from 2.6.27.4 - after three minutes of freeze the laptop came back to normal as nothing had Regards, Fabio --

ixgbe_init_interrupt_scheme() is called from ixgbe_resume(). Build that with CONFIG_PM and without CONFIG_HOTPLUG and you've got a problem. Several helpers called by it also are misannotated __devinit. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> --- drivers/net/ixgbe/ixgbe_main.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c index 7e1cc6e..f7228ad 100644 --- ...

gentoo, just rebuild world with frame pointers ;-) --

Who says you need a distributor to recompile stuff.. there are plenty people running gentoo, and it doesn't take all that long to rebuild world on these multi-socket quad core boxen we have today ;-) Although with gcc getting ever slower and desktop software ever more bloated who knows,.. but then its your own fault if you install gnome and such, gentoo comes lean and mean from the stage3 cage. I wish more distros would be as easy to rebuild as gentoo is, its a real feature. --

My assumption is that this feature will be used to trace individual applications, and not the system as a whole. Then you only need libc to be recompiled with frame pointers on, and your own application/your own application's libraries. That is what I want to use it for, and there isn't another solution that allows me to do this. Sure I can trace userspace alone using ptrace (which has its own overhead), and the kernel alone by using ftrace, but I can't combine those traces in a meaningful ...

No not at all. It's always really useful to hear any problems like this. I'd like you to keep participating... for one thing I'd like you to test my mmap_sem patch ;) (when I finish it) --

Interesting. I tryed to demonstration /proc slowness. 1. make many process $ nice ./hackbench 120 process 10000 2. read /proc $ time ps -ef 0.16s user 0.57s system 1% cpu 46.859 total HAHAHA! That is really slow over my expected. --

Are you doing appropriate posix_fadvise to prefetch in the files before faulting, and madvise hints if appropriate? --

Right, this can be an issue. The way around it should be to minimize the length of time any single lock holder can sit on it. Compared to what we have today with: - sleep in major fault with read lock held, - enqueue writer behind it, - and make all other faults wait on the rwsem The retry logic seems to be a lot better for forward progress. --

It would be interesting to compare the performance of a threaded clamd, and of a clamd that uses multiple processes. Distributing tasks will be a bit more tricky, since it would need to use How about distributing tasks to a set of worked threads, is the overhead of using IPC instead of I understood that mmap() is not scalable, however look at http://lkml.org/lkml/2008/9/12/185, even fopen/fdopen does an (anonymous) mmap internally. That does not affect performance that much, since the ...

Yes, it would be nice to reduce mmap_sem load regardless of any other fixes or problems. I guess they're not very worried about cacheline bouncing but more about hold time (how many sockets in these systems? 4 at most?) I guess it is the pagemap stuff that they use most heavily? pagemap_read looks like it can use get_user_pages_fast. The smaps and clear_refs stuff might have been nicer if they could work on ranges like pagemap. Then they could avoid mmap_sem as well (although maps would ...

Software may just be doing a lot of mmap/munmap activity. threads + mmap is never going to be pretty because it is always going to involve broadcasting tlb flushes to other cores... Software writers shouldn't be scared of using processes (possibly with some shared memory). Actually, a lot of things get faster (like malloc, or file descriptor operations) because locks aren't needed. Despite common perception, processes are actually much *faster* than threads when doing common operations like ...

This is much less of a worry. We expect to be able to look at these things on the order of 1HZ, so cacheline bouncing becomes negligible. Latency to lock acquire however hurts and is silly considering it's just another reader. Our monitoring software here is acting as a litmus test and the real pain is felt by other threads in the same process who are also blocked trying to acquire the read lock. --

Hmm. How quantifiable is the benefit? Does it actually matter that you can read the proc file much faster? (this is for some automated workload management daemon or something, right?) Would it be possible to reduce mmap()/munmap() activity? eg. if it is due to a heap memory allocator, then perhaps do more batching or set As far as I understand, glibc does actually seperate notions of allocated virtual memory and allocated pages. By that I mean that it is very careful to return pages back to ...

Correct. I don't recall the numbers from the pathelogical cases we were seeing, but iirc, it was on the order of 10s of seconds, likely exascerbated by slower than usual disks. I've been digging through my inbox to find numbers without much success -- we've been using a variant of this patch since 2.6.11. Török however identified mmap taking on the order of several milliseconds due to this exact problem: I know our tcmalloc team had made great strides to reduce mmap_sem ...

Yeah, that's fine with me. OTOH removing config options generally seems like a good idea too, so maybe this combination should just be disallowed. Or is there a good reason for this type of config? -- Jesse Barnes, Intel Open Source Technology Center --

True, I'd forgotten that most setup_arch()s call parse_early_param (there's a general call lower down in start_kernel). I actually think start_kernel should take a char *params as a parameter, but that's a big multi-arch change I wasn't prepared to hack up just yet. OK, now have three patches which clean up cmdline handling. They're big :( Will test a little and post... Cheers, Rusty. --

special is not a useful name for a flag, by definition everything that needs a flag is special compared to the version that doesn't need a flag. The general idea of skippign the writer counts makes sense, but please give it a descriptive name that explains the not unmountable thing. And please kill your kern_mount wrapper and just set the flag manually. Also I think it should be a superblock flag, not a mount flag as you don't want thse to differ for multiple mounts of the same ...

From: Eric Dumazet <dada1@cosmosbay.com> No problem with networking part: Acked-by: David S. Miller <davem@davemloft.net> --

From: Eric Dumazet <dada1@cosmosbay.com> For networking bits: Acked-by: David S. Miller <davem@davemloft.net> --

Hum, I guess we can use regular percpu_counter for this... --

Hum.. we have a superblock flag already, but testing it in mntput()/mntget() is going to be a litle bit expensive if we add a derefence ? if (mnt && mnt->mnt_sb->s_flags & MS_SPECIAL) { ... } --

4096/192 = 21 with slub_min_objects=22 : # cat /sys/kernel/slab/filp/order 1 # time ./socket8 real 0m1.725s user 0m0.685s sys 0m12.955s with slub_min_objects=45 : # cat /sys/kernel/slab/filp/order 2 # time ./socket8 real 0m1.652s user 0m0.694s sys 0m12.367s with slub_min_objects=80 : # cat /sys/kernel/slab/filp/order 3 # time ./socket8 real 0m1.642s user 0m0.719s sys 0m12.315s I would say slub_min_objects=45 is the optimal value on ...

The way it's used in writeback is utterly stupid and should be fixed :) But otherwise agreed. --

Doesn't matter, possible cpus is always only set to what the machine supports. -Andi -- ak@linux.intel.com --

Yes, I think adding a comment to the existing code (option a) would be best. I actually have a small queue of other fixes which make swiotlb work properly for x86 PAE and HighMem but they are not particularly well baked at the moment. I'll include a patch to add a comment in that series. Ian. --

I had been facing this same issue 5-6 years ago when I tried my first DL2K. It always stopped transmitting after a few hundreds of packets on my machine while it was OK on another one. Mine was dual-athlon with an AMD chipset. A working one was a P3-933 with a ServerWorks chipset. I noticed that it would only lock up when plugged into a 64-bit slot, and it was fine in 32-bit slots (though it did work well on the P3 in a 64-bit slot). It was such a crappy chip that I finally threw it away, so I ...

I got same issue two days ago on PCI-X Fiber 1000BASE-SX D-Link Adapter DGE-550SX/dl2k driver (I report it yesterday). This card work fine in old DEC Alphaserver 800/Fedora Core 5/kernel 2.6.17. We use it for our internet connections, which is limited to approx. 50 Mb/sec by ISP, then I think there should be no bottleneck in LAN card. We just tried install new i386 based router (Core2Duo E8500/4GB RAM/ 4x Realtek 8111C and this D-Link from old Alphaserver, on Fedora 10, kernel 2.6.27.5). Router ...

On the entirely silly level... CC xx -hpa --

That would be still one byte, otherwise you wouldn't get a unique index. -Andi -- ak@linux.intel.com --

At Wed, 19 Nov 2008 12:44:23 +0100, Nando, any chance to test on your machines? thanks, --

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --

On Thu, Nov 27, 2008 at 6:25 AM, Markus Rechberger Again, it's not personal, it's the way we do things here. But you should already know that by now so whatever. What puzzles me the most here is why isn't Empia simply providing datasheets to other developers as well. I mean, even the GPU and wireless vendors know how to play well with the community now, so what's the problem? Being locked to just one developer who's unwilling to cooperate doesn't sound like a winning strategy to me. Greg, ...

I finally got a chance to play with this. Turns out asus-laptop DOES work. It however does NOT work if asus-acpi is already loaded, which for some reason udev likes to do automatically because both claim to support the same devices, but they sure aren't equal. Now once asus-acpi is unloaded and asus-laptop loaded, then it does appear to do stuff. fn+f2 does manage to do something, although not consistently or very reliably, but I suspect that may be a user space acpi events problem to do ...