Maybe this is something that just "everyone already knows" but I can't find documentation about it. In several kernels I've tried, most recently 2.6.30, the drivers for NTSC tuner cards with AV inputs have their left-right channels swapping coming out of the ALSA drivers. Both the RF and AV inputs are like this. However, with the bt878/msp3445 combination, switching back and forth from RF and AV can actually induce swapping channels *back* to their original assignments (and back and forth, etc, ...

Provide local_irq_{save,restore}_nmi() which will allow us to help architectures that implement NMIs using IRQ priorities like SPARC64 does. Sparc uses IRQ prio 15 for NMIs and implements local_irq_disable() as disable <= 14. However if you do that while inside an NMI you re- enable the NMI priority again, causing all kinds of fun. A more solid implementation would first check the disable level and never lower it, however that is more costly and would slow down the rest of the kernel for ...

Since we can call cpu_clock() from NMI context fix up the IRQ disabling to conform to the new rules. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: David S. Miller <davem@davemloft.net> --- kernel/sched_clock.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c index 5b49613..ef159ee 100644 --- a/kernel/sched_clock.c +++ b/kernel/sched_clock.c @@ -241,9 +241,9 @@ unsigned long long cpu_clock(int ...

Peter, I've respun the local_irq_*_nmi() interface addition, sparc64 implementation, and trace/sched_clock annotations against Linus's tree. I've tested all of the tracers in various different configurations on sparc64 and I haven't triggered any of the bug checks or crashes yet so it should be good. It can also be pulled from: master.kernel.org:/pub/scm/linux/kernel/git/davem/trace-2.6.git And it would be nice to see this upstream soon so I can build upon it :-) You'll need to ...

Toggling the link carrier is a non sense and is the grossest locking I can think of. Moreover, it's giving a completely inaccurate status to userspace who could for example decide to turn the interface down on carrier off detection. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> --- .../rtl8187se/ieee80211/ieee80211_softmac_wx.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/staging/rtl8187se/ieee80211/ieee80211_softmac_wx.c ...

Needed for panic and kdb, since we need to avoid taking the mode_config mutex. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/drm_fb_helper.c | 42 +++++++++++++++++++++++++++++++++----- 1 files changed, 36 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 6929f5b..962eadb 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -242,18 +242,22 @@ static int ...

At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/char/vt.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/char/vt.c b/drivers/char/vt.c index ...

Hi, now we have a lot of student applications and to assure that we get enough slots for all students we want to actually mentor, we need to assign mentors to the students until MONDAY at the latest. In addition, applications which are obviously spam should be marked ineligible, also until MONDAY at the latest. Incomplete proposals should only be ranked down, not marked ineligible. Please check which students are interesting for you to mentor, and feel free to mentor more than one ...

How can Pedro find out what physical addresses are in use on his system? Alan Stern --

Ingo, Please pull the latest tip/tracing/core tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git tip/tracing/core Lai Jiangshan (1): tracing: Fix uninitialized variable of tracing/trace output ---- kernel/trace/trace.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --------------------------- commit aa27497c2fb4c7f57706099bd489e683e5cc3e3b Author: Lai Jiangshan <laijs@cn.fujitsu.com> Date: Mon Apr 5 ...

Subject: [PATCH] Staging: comedi: Fixed brace, KERN_, 80 characters issues in ni_labpc.c This is a patch to ni_labpc.c file that fixes all the brace and 80 character warnings and it also fixes some of the KERN_ facility warnings found by the checkpatch.pl tool. The two errors about indent warning are there because I do not understand what they want and so I left it in the orginal code and they happened to get pulled in the patch. Signed-off-by: Jakob Penzien <supermine290@gmail.com> --- ...

Hi, Refresh of jump labeling patches aginst -tip tree. For bacground see: http://marc.info/?l=linux-kernel&m=125858436505941&w=2 I believe I've addressed all the reviews from v5. Changes in v6: * I've moved Steve Rostedt's 'ftrace_dyn_arch_init()' to alternative.c to put it into a common area for used by both ftrace and jump labels. By default we put a 'jmp 5' in the nop slot. Then, when we detect the best runtime no-op we patch over the 'jmp 5' with the appropriate nop. * build time ...

add x86 support for jump label. I'm keeping this patch separate so its clear to arch maintainers what was required for x86 support this new feature. hopefully, it wouldn't be too painful for other arches. Signed-off-by: Jason Baron <jbaron@redhat.com> --- arch/x86/include/asm/jump_label.h | 31 +++++++++++++++++++++ arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/jump_label.c | 53 +++++++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+), 1 deletions(-) ...

Move Steve's code for finding the best 5-byte no-op from ftrace.c to alternative.c. The idea is that other consumers (in this case jump label) want to make use of that code. I've created a global: 'char ideal_nop[5]', that is setup during setup_arch that can be used. Signed-off-by: Jason Baron <jbaron@redhat.com> --- arch/x86/include/asm/alternative.h | 14 +++++++ arch/x86/include/asm/jump_label.h | 10 ++---- arch/x86/kernel/alternative.c | 71 ...

Add a jump_label_text_reserved(void *start, void *end), so that other pieces of code that want to modify kernel text, can first verify that jump label has not reserved the instruction. Signed-off-by: Jason Baron <jbaron@redhat.com> --- arch/x86/kernel/kprobes.c | 3 +- include/linux/jump_label.h | 6 +++ kernel/jump_label.c | 83 ++++++++++++++++++++++++++++++++++++++++++++ kernel/kprobes.c | 3 +- 4 files changed, 93 insertions(+), 2 deletions(-) diff --git ...

Make use of the jump label infrastructure for tracepoints. Signed-off-by: Jason Baron <jbaron@redhat.com> --- include/linux/tracepoint.h | 34 +++++++++++++++++++--------------- kernel/tracepoint.c | 8 ++++++++ 2 files changed, 27 insertions(+), 15 deletions(-) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index f59604e..c18b9c0 100644 --- a/include/linux/tracepoint.h +++ b/include/linux/tracepoint.h @@ -16,6 +16,7 @@ #include <linux/types.h> ...

Hi Jason, Good!:-) So now, it might be a good time to integrate those text_reserved() functions. BTW, how many jumps would you expect modifying at once? Since the text_poke_smp() uses stop_machine() for each modifying text, I found that it can cause a delay issue if it is called so many times... (e.g. a systemtap testcase sets ~5000 probes at once) Thank you, -- Masami Hiramatsu e-mail: mhiramat@redhat.com --

[ CCing Eric ] Jason, As we were chatting about this, it looks like you are modifying vmlinux section outside the knowledge of compiler. So theoritically associated relocation section knowledge is no more valid and it can be a problem during i386 relocatable kernels where we read the section's relocation inforamtion and perform the relocations at runtime. I know you have tested this on i386 and it works for you. I guess it works because all the entries in the section are same and we ...

I'm counting 934 jump label locations in the vmlinux, i have compiled, 675 of them being 'kmalloc'. Batch mode for text_poke_smp()? -Jason --

Unused hook. Remove. Signed-off-by: Eric Paris <eparis@redhat.com> --- This is a resend of the broken patch I sent earlier. It was the last patch in the series and I had uncommitted changes in my repo which fixed the borkeness. James you should apply all of the patches I originally sent except the last one. Use this one instead. include/linux/security.h | 14 -------------- kernel/acct.c | 20 +++++--------------- security/capability.c | 6 ------ ...

That isn't entirely true. The BIOS usually allocates a 256 MB ACPI/PCI hole that is under the 4GB. So end up with 3.7 GB, then the 256MB hole, and then right above the 4GB you the the remaining memory: 4.3GB. --

Hello everyone, *Changes from Previous Version* This is the second version of the FunctionFS patchset. 1. A new wait_event_interruptible_locked() macro (in 6 variants) has been added and used in the f_fs.c instead of an open-coding it. This, again, was suggested by Greg. As a side effect of the above, also a patch for fs/timerfd.c is provided that uses the new facility (hence I'm ccing it to fsdevel and timerfd folks as well). 2. The __init/__exit tags from various ...

The Function Filesystem (FunctioFS) lets one create USB composite functions in user space in the same way as GadgetFS lets one create USB gadgets in user space. This allows creation of composite gadgets such that some of the functions are implemented in kernel space (for instance Ethernet, serial or mass storage) and other are implemented in user space. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Marek Szyprowski ...

This adds an example user-space FunctionFS driver which implements a source/sink interface used for testing. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> --- tools/usb/ffs-test.c | 554 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 554 insertions(+), 0 deletions(-) create mode 100644 tools/usb/ffs-test.c diff --git a/tools/usb/ffs-test.c ...

__init, __initdata and __exit tags have have been removed from various files to make it possible for gadgets that do not use the __init/__exit tags to use those. Files in question are related to: * the core composite framework, * the mass storage function (fixing a section mismatch) and * ethernet driver (ACM, ECM, RNDIS). Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> --- ...

Hi First of all sorry for my english... I'm gabriele from italy and i have this problem with *Ubuntu 9.10* and my *laptot O.book 2.1 Belinea*: when i try to use or test webcam with cheese or camorama or emesene, etc (or doing gstreamer-properties)... my internet connection disconnect and crash the wifi card. To restore all wireless' functions i must remove laptop's battery and boot normally . If i don't remove battery first of reboot my laptop the wireless card connect normally with the ...

Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus This will get a few small fixes that have trickled in: Chien Tung (1): RDMA/nes: Correct cap.max_inline_data assignment in nes_query_qp() Dan Carpenter (1): IB/mlx4: Check correct variable for allocation failure Jani Nikula (1): IB/cm: Fix device_create() return value check Roland Dreier (1): Merge branches 'cma', 'misc', 'mlx4' and 'nes' into ...

It has 4 GB. Pedro --

It seems to me that in usbcore you can positively know that a buffer will be mapped. However if the mapping is not done in usbcore you cannot know what the HCD driver will do to a buffer, in particular you don't know whether it will be processed by PIO or mapped for DMA. Maybe I understand this wrongly. Which code exactly were you refering to? Regards Oliver --

Not true. Consider: The driver allocates a 16-byte buffer (xbuf) divided up into four sets of four bytes, and sets urb[i].transfer_buffer_dma = xbuf_dma + 4*i; Then usb_submit_urb(urb[i]) will copy the appropriate four bytes to a bounce buffer and map the bounce buffer. Accesses to the other parts of xbuf won't violate the cacheline rules, because xbuf isn't mapped for DMA -- only the bounce buffer is. When urb[i] completes, the bounce buffer contents will be copied back to the ...

This patch writen by Peter Jones and Mike Christie expands on the iBFT firmware driver to support v1.03 of the spec. The spec in question is available at: ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03... Linux kernel has support for the iBFT 1.0 spec and this update to 1.03 adds three more things: - There is now a ACPI table either called 'iBFT' or 'IBFT' that should be parsed. - If running with UEFI, only look at the ACPI table. - If not ...

From: Peter Jones <pjones@redhat.com> - Use struct acpi_table_ibft instead of struct ibft_table_header - Don't do reserve_ibft_region() on UEFI machines (section 1.4.3.1) - If ibft_addr isn't initialized when ibft_init() is called, check for ACPI-based tables. Author: Peter Jones <pjones@redhat.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> --- drivers/firmware/iscsi_ibft.c | 30 ++++++++++++++++++------------ ...

This is a re-submitted patch to the ni_labpc.c file that fixes up over 80 characters warnings found by the checkpatch.pl tool Signed-off-by: Maurice Dawson <mauricedawson2699@googlemail.com> --- drivers/staging/comedi/drivers/ni_labpc.c | 258 ++++++++++++++++------------ 1 files changed, 147 insertions(+), 111 deletions(-) diff --git a/drivers/staging/comedi/drivers/ni_labpc.c b/drivers/staging/comedi/drivers/ni_labpc.c index 4eaf31f..becbe47 100644 --- ...

Hi all Then please read Ted'd email. Thanks -zj ---------- Forwarded message ---------- From: tytso@mit.edu Date: Tue, 6 Apr 2010 10:21:03 -0400 Subject: Re: [PATCH] ext4: memory leakage in ext4_mb_init() To: jing zhang <zj.barak@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com>, "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>, linux-ext4 <linux-ext4@vger.kernel.org>, Andreas Dilger <adilger@sun.com>, Dave Kleikamp <shaggy@linux.vnet.ibm.com> Well, the ...

zcrypt doesn't even allow to read/write the files it opens. So seeking on it shouldn't fall back to defaults either but should be disallowed as well. Signed-off-by: Jan Blunck <jblunck@suse.de> --- drivers/s390/crypto/zcrypt_api.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c index ba50fe0..18a986d 100644 --- a/drivers/s390/crypto/zcrypt_api.c +++ b/drivers/s390/crypto/zcrypt_api.c @@ -301,7 ...

osst_read()/osst_write() modify file->f_pos directly instead of the ppos given to them. The VFS later updates the file->f_pos and overwrites it with the value of ppos. Signed-off-by: Jan Blunck <jblunck@suse.de> --- drivers/scsi/osst.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c index acb8358..9dc0b9a 100644 --- a/drivers/scsi/osst.c +++ b/drivers/scsi/osst.c @@ -3586,7 +3586,7 @@ if (SRpnt) printk(KERN_ERR ...

Seems that Alexey Dobriyan missed this usage of the file argument when removing it from ->proc_handler in commit 8d65af789f3e2cf4cfbdbf71a0f7a61ebcd41d38. Signed-off-by: Jan Blunck <jblunck@suse.de> --- arch/frv/kernel/sysctl.c | 18 ++++++++++-------- 1 files changed, 10 insertions(+), 8 deletions(-) diff --git a/arch/frv/kernel/sysctl.c b/arch/frv/kernel/sysctl.c index 035516c..05afc05 100644 --- a/arch/frv/kernel/sysctl.c +++ b/arch/frv/kernel/sysctl.c @@ -47,8 +47,9 @@ static void ...

The inode's i_size is not protected by the big kernel lock. Therefore it does not make sense to recommend taking the BKL in filesystems llseek operations. Instead it should use the inode's mutex or use just use i_size_read() instead. Add a note that this is not protecting file->f_pos. Signed-off-by: Jan Blunck <jblunck@suse.de> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Frédéric Weisbecker ...

st_open() suggests that llseek() doesn't work: "We really want to do nonseekable_open(inode, filp); here, but some versions of tar incorrectly call lseek on tapes and bail out if that fails. So we disallow pread() and pwrite(), but permit lseeks." Instead of using the fallback default_llseek() the driver should use noop_llseek() which leaves the file->f_pos untouched but succeeds. Signed-off-by: Jan Blunck <jblunck@suse.de> --- drivers/scsi/st.c | 1 + 1 files changed, 1 insertions(+), ...

This is an implementation of ->llseek useable for the rare special case when userspace expects the seek to succeed but the (device) file is actually not able to perform the seek. In this case you use noop_llseek() instead of falling back to the default implementation of ->llseek. Signed-off-by: Jan Blunck <jblunck@suse.de> --- fs/read_write.c | 17 +++++++++++++++++ include/linux/fs.h | 1 + 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/fs/read_write.c ...

This test is not doing anything since it is always false if the mISDN_read() is called from vfs_read(). Besides that the driver uses nonseekable_open() and is not using off or file->f_pos anywhere. Signed-off-by: Jan Blunck <jblunck@suse.de> --- drivers/isdn/mISDN/timerdev.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/isdn/mISDN/timerdev.c b/drivers/isdn/mISDN/timerdev.c index 5b7e9bf..0a8b440 100644 --- a/drivers/isdn/mISDN/timerdev.c +++ ...

This is the first linux kernel patch i have ever made, i don't even know the C programming language except reading the syntax (basic) It didn't compile on my machine due to invalid configuration of something on my machine, because i have not yet learned how to configure the compiler. Signed-off-by: Gunnar Gudvardarson <gunni@wave.is> --- drivers/staging/asus_oled/asus_oled.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/asus_oled/asus_oled.c ...

Are you saying there is a 20% CPU usage even when the joystick interface is not open? This should not happen (and this is not happening on my laptop). The polling should happen only when a userspace app opens the joystick interface (like running neverball). So I'd tend to think it's more due to a misconfiguration of the system (like xserver using the joystick interface as a pointer device) or it's a bug in the way we set up the polling. Could you investigate and let ...

lis3lv02d driver creates emulated joystick interface for events reported by the sensor. Because of HW, this has to be implemented as polled input device, with 20Hz frequency. This is reported to create 20% CPU usage increase (and proportionaly higher power consumption) just for the ipolldevd kernel thread (which is used to read the sensor). As most users probably only use the freefall functionality of the driver and not the joystick interface, provide means for disabling the ...

I've also never seen this problem on my HP 2510p. --

I haven't seen the bug recur since March 23rd, although I'm running the same kernel (vanilla 2.6.33). The X server has been updated slightly to Debian's xserver-xorg-core 1.7.6. --

Hi All, I want to write someting to the NAND flash, which is not a part of partitioning. say , out of 128 MB , I am using 64 MB which I have partitioned using MTD, but I have to access the other 64 MB. Can any one help me or give me any ideas ? Is it possible to write using assmbly code. I am using MIPS board. Thanks In advance !!! Prabhu --

Hi Jeff I was able to try this on the machine just before I left. Unfortunately 2.6.34-rc3 does not fix the problem - it behaves exactly like 2.6.33. In terms of error messages, there is nothing more displayed beyond that which I reported in the initial email except for this: SStatus 113, SControl 300 As far as I can tell, that (plus the previously reported details) is all that's printed by the kernel in connection with the failure. I'll look into the alternative console methods to ...

It would be nice to get this into the tree in some form as a pile of the driver stuff pending from Intel depends upon it. It's currently slotted into arch/x86 as the IPC interface is very much part of the hardware, so don't be fooled by its apparent PCI interface. -- From: Sreedhara DS <sreedhara.ds@intel.com> The IPC is used to bridge the communications between kernel and SCU on some embedded Intel x86 platforms. (Some API tweaking Alan Cox) Signed-off-by: Sreedhara DS ...

Changes from the previous version: - Update to latest Linus' tree; - Address Eric B.'s concern, copy the whole bitmap instead of set one by one. -------------> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports which allows users to reserve ports for third-party applications. The reserved ports will not be used by automatic port assignments (e.g. when calling connect() or bind() with port number 0). Explicit port allocation behavior is unchanged. There are still some miss ...

the function name implies that it is used to parse unsigned long, so It seems that ledding white space should be allowed, so this check These functions have so much lines of code. I think you can make them less. Please refer to strsep(). -- Regards， Changli Gao(xiaosuo@gmail.com)

From: Octavian Purdila <opurdila@ixiacom.com> As we are about to add another integer handling proc function a little bit of cleanup is in order: add a few helper functions to improve code readability and decrease code duplication. In the process a bug is also fixed: if the user specifies a number with more then 20 digits it will be interpreted as two integers (e.g. 10000...13 will be interpreted as 100.... and 13). Behavior for EFAULT handling was changed as well. Previous to this patch, ...

From: Octavian Purdila <opurdila@ixiacom.com> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports which allows users to reserve ports for third-party applications. The reserved ports will not be used by automatic port assignments (e.g. when calling connect() or bind() with port number 0). Explicit port allocation behavior is unchanged. Signed-off-by: Octavian Purdila <opurdila@ixiacom.com> Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Neil Horman ...

Hi and thanks for reviewing. My intention was to signal that the argument is unsigned long and that the sign come separate in neg, but I am OK with changing the function name to Leading white space is skipped with proc_skip_space before calling this I don't think it will work out, \0 is an accepted trailer for many of the We need negatives in proc_dointvec, again we can change the function name if it will clear things up. Hmm, the input its pretty permissive and maybe this ...

From: Xin Xiaohui <xiaohui.xin@intel.com> Add a device to utilize the vhost-net backend driver for copy-less data transfer between guest FE and host NIC. It pins the guest user space to the host memory and provides proto_ops as sendmsg/recvmsg to vhost-net. Signed-off-by: Xin Xiaohui <xiaohui.xin@intel.com> Signed-off-by: Zhao Yu <yzhao81@gmail.com> Reviewed-by: Jeff Dike <jdike@linux.intel.com> --- memory leak fixed, kconfig made, do_unbind() made, mp_chr_ioctl() cleaned up ...

From: Xin Xiaohui <xiaohui.xin@intel.com> The vhost-net backend now only supports synchronous send/recv operations. The patch provides multiple submits and asynchronous notifications. This is needed for zero-copy case. Signed-off-by: Xin Xiaohui <xiaohui.xin@intel.com> --- drivers/vhost/net.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++-- drivers/vhost/vhost.c | 115 ++++++++++++++++------------ drivers/vhost/vhost.h | 15 ++++ 3 files changed, 278 insertions(+), 55 ...

Hello! this function was removed in the past but I've not clear all the details. While testing LLTng, I wrote the patch, in attachment, that re-adds it again. The clocksource_get_next returns the first clock source available (without looking at the rating). In my environment, a clock source is a TMU channel (e.g. TMU1) and, indeed, clocksource_get_next works fine. Let me know if it makes sense or if I'm missing something. Best Regards, Giuseppe

need_active_balance() gates the asymmetric packing based due to power save logic, but for packing we don't care. This marks the type of balanace we are attempting to do perform from f_b_g() and stops need_active_balance() power save logic gating a balance in the asymmetric packing case. Signed-off-by: Michael Neuling <mikey@neuling.org> --- kernel/sched_fair.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) Index: ...

With the asymmetric packing infrastructure, fix_small_imbalance is causing idle higher threads to pull tasks off lower threads. This is being caused by an off-by-one error. Signed-off-by: Michael Neuling <mikey@neuling.org> --- I'm not sure this is the right fix but without it, higher threads pull tasks off the lower threads, then the packing pulls it back down, etc etc and tasks bounce around constantly. --- kernel/sched_fair.c | 2 +- 1 file changed, 1 insertion(+), 1 ...

The POWER7 core has dynamic SMT mode switching which is controlled by the hypervisor. There are 3 SMT modes: SMT1 uses thread 0 SMT2 uses threads 0 & 1 SMT4 uses threads 0, 1, 2 & 3 When in any particular SMT mode, all threads have the same performance as each other (ie. at any moment in time, all threads perform the same). The SMT mode switching works such that when linux has threads 2 & 3 idle and 0 & 1 active, it will cede (H_CEDE hypercall) threads 2 and 3 in the idle loop and the ...

Some CPUs perform better when tasks are run on lower thread numbers. In the case of POWER7, when higher threads are idled, the core can run in lower SMT modes and hence perform better. This creates a new sd flag to prefer lower threads. Based heavily on patch from Peter Zijlstra. Signed-off-by: Michael Neuling <mikey@neuling.org> --- Peter: Since this is based mainly off your initial patch, it should have your signed-off-by too, but I didn't want to add without your permission. Can I ...

size is returned according free range. Will be used to find free ranges for early_memtest and memory corruption check Do not mess it up with mm/lmb.c yet. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/mm/Makefile | 2 + arch/x86/mm/lmb.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 90 insertions(+), 0 deletions(-) create mode 100644 arch/x86/mm/lmb.c diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index a4c7683..8ab0505 ...

It will be used lmb_to_bootmem converting It is an wrapper for reserve_bootmem, and x86 64bit is using special one. Also clean up that version for x86_64. We don't need to take care of numa path for that, bootmem can handle it how Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/mm/init_32.c | 6 ------ arch/x86/mm/init_64.c | 20 ++------------------ mm/bootmem.c | 6 ++++++ 3 files changed, 8 insertions(+), 24 deletions(-) diff --git ...

lmb_init() will connect them back. Add nr_regions in struct lmb_region to track region array size. So later We can install dynamically allocated region array to that pointer Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- include/linux/lmb.h | 3 ++- mm/lmb.c | 9 ++++++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/include/linux/lmb.h b/include/linux/lmb.h index f3d1433..e14ea8d 100644 --- a/include/linux/lmb.h +++ b/include/linux/lmb.h @@ ...

We don't need to expose e820_any_mapped() anymore Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/kernel/e820.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index be6e1e6..471784b 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -47,9 +47,10 @@ EXPORT_SYMBOL(pci_mem_start); /* * This function checks if any part of the range <start,end> is mapped * with type. + * ...

We can remove #ifdef in mm/page_alloc.c and change that function to static Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- include/linux/mm.h | 2 -- mm/nobootmem.c | 21 +++++++++++++++++++++ mm/page_alloc.c | 24 ------------------------ 3 files changed, 21 insertions(+), 26 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 7774e1d..2a14361 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1161,8 +1161,6 @@ int ...

Move apterture_valid back to .c and early path still use e820_any_mapped() So later we can make e820_any_mapped() to _init Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/gart.h | 22 ---------------------- arch/x86/kernel/aperture_64.c | 22 ++++++++++++++++++++++ drivers/char/agp/amd64-agp.c | 39 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 60 insertions(+), 23 deletions(-) diff --git a/arch/x86/include/asm/gart.h ...

lmb_memory_size() will return memory size in lmb.memory.region. lmb_free_memory_size() will return free memory size in lmb.memory.region. So We can get exact reseved size in specified range. Set the size right after initmem_init(), because later bootmem API will get area above 16M. (except some fallback). Later after we remove the bootmem, We could call that just before paging_init(). Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/e820.h | 2 ++ ...

and some functions in e820.c that are not used anymore Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/include/asm/e820.h | 14 - arch/x86/kernel/e820.c | 42 --- include/linux/early_res.h | 23 -- kernel/early_res.c | 584 ------------------------------------------- 4 files changed, 0 insertions(+), 663 deletions(-) delete mode 100644 include/linux/early_res.h delete mode 100644 kernel/early_res.c diff --git a/arch/x86/include/asm/e820.h ...

Introduce nobootmem.c to hold wrapper for CONFIG_NO_BOOTMEM=y. that will remove related #ifdef in bootmem.c Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- mm/Makefile | 8 +- mm/bootmem.c | 151 +---------------------- mm/nobootmem.c | 389 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 397 insertions(+), 151 deletions(-) create mode 100644 mm/nobootmem.c diff --git a/mm/Makefile b/mm/Makefile index 52492f9..2ab3039 100644 --- ...

We can remove #ifdef in mm/page_alloc.c Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- mm/bootmem.c | 7 +++++++ mm/nobootmem.c | 5 +++++ mm/page_alloc.c | 9 --------- 3 files changed, 12 insertions(+), 9 deletions(-) diff --git a/mm/bootmem.c b/mm/bootmem.c index 2741c34..ff55ad7 100644 --- a/mm/bootmem.c +++ b/mm/bootmem.c @@ -23,6 +23,13 @@ #include "internal.h" +#ifndef CONFIG_NEED_MULTIPLE_NODES +struct pglist_data __refdata contig_page_data = { + ...

lmb.c is memory related, so move it to mm/. It is suggested by Ingo Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- lib/Makefile | 2 -- mm/Makefile | 2 ++ {lib => mm}/lmb.c | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename {lib => mm}/lmb.c (100%) diff --git a/lib/Makefile b/lib/Makefile index 2e152ae..a463a4d 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -85,8 +85,6 @@ obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o lib-$(CONFIG_GENERIC_BUG) ...

Generic version __lmb_find_area() is going from high to low, and for 32bit active_region for 32bit does include high pages need to replace the limit with lmb.default_alloc_limit, aka get_max_mapped() with this patch, x86 32bit could use generic version of __lmb_find_area() Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- mm/page_alloc.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 79bd44b..256aed0 100644 --- ...

1. replace find_e820_area with lmb_find_area 2. replace reserve_early with lmb_reserve_area 3. replace free_early with lmb_free_area. 4. NO_BOOTMEM will switch to use lmb too. 5. use _e820, _early wrap in the patch, in following patch, will replace them all 6. because lmb_free_area support partial free, we can remove some special care 7. Need to make sure that lmb_find_area() is called after fill_lmb_memory() so adjust some calling later in setup.c::setup_arch() -- corruption_check and ...

to workaround wrong BIOS memory map. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/kernel/e820.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 14d0a1a..73dc6a7 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -1044,6 +1044,47 @@ static int __init parse_memmap_opt(char *p) } early_param("memmap", parse_memmap_opt); +static void ...

get_free_all_memory_range is for CONFIG_NO_BOOTMEM=y, and will be called by free_all_memory_core_early(). It will use early_node_map aka active ranges subtract lmb.reserved to get all free range, and those ranges will convert to slab pages. -v3: use __lmb_find_base() to get range free buffer. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Jan Beulich <jbeulich@novell.com> --- include/linux/lmb.h | 2 + mm/lmb.c | 86 ...

They will check if the region array is big enough. __check_and_double_region_array will try to double the region array if that array spare slots is not big enough. Old array will be copied to new array. Arch code should set lmb.default_alloc_limit accordingly, so the new array is in accessiable address. -v2: change get_max_mapped() to lmb.default_alloc_limit according to Michael Ellerman and Ben change to lmb_reserve_area and lmb_free_area according to Michael Ellerman -v3: ...

Seperate those three functions and could be shared by related callers. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- mm/lmb.c | 63 +++++++++++++++++++++++++++++++++++-------------------------- 1 files changed, 36 insertions(+), 27 deletions(-) diff --git a/mm/lmb.c b/mm/lmb.c index ab3d85f..5483d69 100644 --- a/mm/lmb.c +++ b/mm/lmb.c @@ -684,16 +684,41 @@ static __init struct range *find_range_array(int count) } #ifdef CONFIG_NO_BOOTMEM -static void __init ...

It will return free memory size in specified range. We can not use memory_size - reserved_size here, because some reserved area may not be in the scope of lmb.memory.region. Use lmb.memory.region subtracting lmb.reserved.region to get free range array. then count size of all free ranges. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- include/linux/lmb.h | 1 + mm/lmb.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 ...

It will return memory size in specified range according to lmb.memory.region Try to share some code with lmb_free_memory_size() by passing get_free to __lmb_memory_size(). Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- include/linux/lmb.h | 1 + mm/lmb.c | 18 +++++++++++++++++- 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/include/linux/lmb.h b/include/linux/lmb.h index b874dc0..8332934 100644 --- a/include/linux/lmb.h +++ b/include/linux/lmb.h @@ ...

So We can construct one generic __find_lmb_area() later Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- mm/lmb.c | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-) diff --git a/mm/lmb.c b/mm/lmb.c index 65b62dc..392d805 100644 --- a/mm/lmb.c +++ b/mm/lmb.c @@ -393,7 +393,7 @@ u64 __init lmb_alloc_base(u64 size, u64 align, u64 max_addr) return alloc; } -u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr) +static u64 __init ...

For whole patchset: Acked-by: Lai Jiangshan <laijs@cn.fujitsu.com> --

This patch adds variants of rcu_dereference() that handle situations where the RCU-protected data structure cannot change, perhaps due to our holding the update-side lock, or where the RCU-protected pointer is only to be fetched, not dereferenced. These are needed due to some performance concerns with using rcu_dereference() where it is not required, aside from the need for lockdep/sparse checking. The new rcu_access_pointer() primitive is for the case where the pointer is be fetch and not ...

Update examples and lists of APIs to include these new primitives. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- Documentation/RCU/NMI-RCU.txt | 39 ++++++++++++++++++++++----------------- Documentation/RCU/checklist.txt | 7 ++++--- Documentation/RCU/lockdep.txt | 28 ++++++++++++++++++++++++++-- Documentation/RCU/whatisRCU.txt | 6 ++++++ 4 files changed, 58 insertions(+), 22 deletions(-) diff --git a/Documentation/RCU/NMI-RCU.txt ...

There's no difference between your two versions of rcu_access_pointer(), so you could move that whole construct outside of the #ifdef'ed section. Other than that: Acked-by: David Howells <dhowells@redhat.com> --

I'm surprised you didn't just roll this in to patch 2. Acked-by: David Howells <dhowells@redhat.com> --

Good point, will rework and resubmit. Thanx, Paul --

I will do so when I resubmit. I am finally growing more comfortable with "git rebase -i", but still some ways to go. It has been a long journey from the old punched-card cabinets of my youth. ;-) --

This patch adds variants of rcu_dereference() that handle situations where the RCU-protected data structure cannot change, perhaps due to our holding the update-side lock, or where the RCU-protected pointer is only to be fetched, not dereferenced. These are needed due to some performance concerns with using rcu_dereference() where it is not required, aside from the need for lockdep/sparse checking. The new rcu_access_pointer() primitive is for the case where the pointer is be fetch and not ...

Update examples and lists of APIs to include these new primitives. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- Documentation/RCU/NMI-RCU.txt | 39 ++++++++++++++++++++++----------------- Documentation/RCU/checklist.txt | 7 ++++--- Documentation/RCU/lockdep.txt | 28 ++++++++++++++++++++++++++-- Documentation/RCU/whatisRCU.txt | 6 ++++++ 4 files changed, 58 insertions(+), 22 deletions(-) diff --git a/Documentation/RCU/NMI-RCU.txt ...

From: Darren Hart <dvhltc@us.ibm.com> In the early days we passed the mmap sem around. That became the "int fshared" with the fast gup improvements. Then we added "int clockrt" in places. This patch unifies these options as "flags" and cleans up various calls which had fshared in their signature but no longer used it. V4: Fix an operator precedence bug Signed-off-by: Darren Hart <dvhltc@us.ibm.com> --- kernel/futex.c | 215 +++++++++++++++++++++++++++----------------------------- 1 ...

From: Darren Hart <dvhltc@us.ibm.com> Add a non-pi TID value based futex locking mechanism. This enables the use of adaptive spinning which was problematic with the basic FUTEX_WAIT operation. V5: Handle timeout inside adaptive lock spin (needs optimization) Fix task_struct ref counting Allow CLOCK_RT and default to CLOCK_MONOTONIC for FUTEX_LOCK Cleanup futex_lock ret handling (EINTR) cruft Remove notion of aggressive adaptive spinning Continue spinning if owner ...

Any ideas as to how I can capture it? Since the SATA disc interfaces stop working long before they are mounted none of the early boot messages make it to disc. All the interesting bits are therefore scrolled into the bit bucket. A serial console might be doable (is there documentation about how to set one up?) but that would take some time to arrange - I'm only physically at the machine in question sporadically and I'd have to rustle up another PC For sure. In terms of the detailed ...

Right, if nfnetlink will use flex_array, CONFIG_NETFILTER_NETLINK will need to depend on or select CONFIG_FLEX_ARRAY. --

export some symbols for nfnetlink_queue use export some symbols for nfnetlink_queue use. Signed-off-by: Changli Gao <xiaosuo@gmail.com> ---- lib/Makefile | 4 ++-- lib/flex_array.c | 5 +++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/Makefile b/lib/Makefile index 0a6ab6f..0700e74 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -12,7 +12,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ idr.o int_sqrt.o extable.o prio_tree.o \ sha1.o irq_regs.o ...

The following patchset implements additional per-cgroup IO controller stats. Some of these should be enabled for debugging only. These stats have helped us debug issues with earlier IO controller versions and should be useful now as well. We've been using these stats for monitoring and debugging problems after the fact as these stats can be collected and stored for later use. The stats added in this patchset are: 1) io_merged - This includes both the number of bios merged into requests ...

These stats are useful for getting a feel for the queue depth of the cgroup, i.e., how filled up its queues are at a given instant and over the existence of the cgroup. This ability is useful when debugging problems in the wild as it helps understand the application's IO pattern w/o having to read through the userspace code (coz its tedious or just not available) or w/o the ability to run blktrace (since you may not have root access and/or not want to disturb performance). Signed-off-by: ...

How about blkiocg_update_avg_queue_size_stats()? A different io policy can choose to take this sample at higher rate and not necessarily when queue is set active. Can we group this function near blkiocg_update_blkio_group_dequeue_stats() curr_blkg is redundant? How about just use "io" keyword instead of "request" as you have been During reset_stats, why are you not resetting the stats for average queue depth? This reset_stat is mean to reset all the debug stats we have collected so ...

I pulled up blkiocg_update_blkio_group_dequeue_stats() to where this Using your calculations from the other thread, since this is at a much coarser granularity than ns, I'm not sure we should be worrying about The avg_queue_size stats (sum and samples) are being reset - see the memset. The current count of how many IOs are queued should not be reset since that will mess up the accounting and hit the BUG_ONs when --

fix the panic issue when calling flex_array_alloc() without __GFP_ZERO. memset is called with the wrong address, then kernel panics. Signed-off-by: Changli Gao <xiaosuo@gmail.com> ---- lib/flex_array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/flex_array.c b/lib/flex_array.c index 66eef2e..6fbb514 100644 --- a/lib/flex_array.c +++ b/lib/flex_array.c @@ -99,7 +99,7 @@ struct flex_array *flex_array_alloc(int element_size, unsigned int total, ret->element_size ...

Hi all, Changes since 20100408: Dropped tree: tmio-mmc (long unresolved conflicts and unable to fetch) hwlat (at the maintainers request) My fixes tree contains: a patch for a pktcdvd build error from Arnd Bergmann The s390 tree lost its conflict. The kvm tree still lost its build failure. The net tree lost 3 conflicts and its build failure, but gained another conflict against Linus' tree. The wireless tree lost 3 conflicts, but gained another against the wireless-current ...

Fix coding style in security/ Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com> --- security/selinux/selinuxfs.c | 44 ++++++++++++++++++++-------------------- security/selinux/ss/mls.c | 2 +- security/selinux/ss/policydb.c | 4 +- security/selinux/ss/services.c | 12 +++++----- 4 files changed, 31 insertions(+), 31 deletions(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index cd191bb..0293843 100644 --- ...

that include some minor fixes and addresses all comments. Changelog: (most based on Vivek Goyal's comments) o renamed blkiocg_reset_write to blkiocg_reset_stats o more clarification in the documentation on io_service_time and io_wait_time o Initialize blkg->stats_lock o rename io_add_stat to blkio_add_stat and declare it static o use bool for direction and sync o derive direction and sync info from existing rq methods o use 12 for major:minor string length o define io_service_time better to ...

that include some minor fixes and addresses all comments. Changelog: (most based on Vivek Goyal's comments) o renamed blkiocg_reset_write to blkiocg_reset_stats o more clarification in the documentation on io_service_time and io_wait_time o Initialize blkg->stats_lock o rename io_add_stat to blkio_add_stat and declare it static o use bool for direction and sync o derive direction and sync info from existing rq methods o use 12 for major:minor string length o define io_service_time better to ...

2.6.33's Documentation has the same wrong information. So, I CC'ed to stable. If people believe this information, they'll usr cgroup.procs file and will see cgroup doesn'w work as expected. The patch itself is against -mm. == Writing to cgroup.procs is not supported now. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- Documentation/cgroups/cgroups.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: ...

On Fri, 09 Apr 2010 11:22:00 +0800 ok. BTW, does anyone work on this ? == Writing to cgroup.procs is not supported now. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- Documentation/cgroups/cgroups.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: mmotm-temp/Documentation/cgroups/cgroups.txt =================================================================== --- mmotm-temp.orig/Documentation/cgroups/cgroups.txt +++ ...

Aye. Oleg suggested a redesign of the last patch (putting the lock in signal_struct instead of sighand_struct), but I haven't got time to work --

1. To support 4M/1024 scatter-gather list entry, reorganize struct ARCMSR_CDB and struct CommandControlBlock 2. To modify arcmsr_probe 3. In order to help fix F/W issue, add the driver mode for type B card 4. To improve AP's behavior while F/W resets 5. To unify struct MessageUnit_B's members' naming in all OS drivers' 6. To improve error handlers, arcmsr_bus_reset(), arcmsr_abort() 7. To fix the arcmsr_queue_command() in bus reset stage, just let the commands pass down to FW, don't ...

Good catch, applied for 2.6.34. -- Jens Axboe --

Thanks Divyesh. Looks good to me. I think cfq_slice_expired() is covering that case (in a non-intutive way). So even if you are idling on an empty queue when we start forced dispatch, it will continue to remain the active queue (because during flush of other queues, we are not making them active queues). And once the flush is over, we will call cfq_slice_expired() which will expire the active queue we were idling on. I suspect that additional cfq_slice_expired() call may be redundant ...

Hi John, Today's linux-next merge of the wireless tree got a conflict in drivers/net/wireless/iwlwifi/iwl-4965.c between commit ece6444c2fe80dab679beb5f0d58b091f1933b00 ("iwlwifi: need check for valid qos packet before free") from the wireless-current tree and commit 74bcdb33e99f49ef5202dd2f8109945b4570edc2 ("iwlwifi: move agn only tx functions from iwlcore to iwlagn") from the wireless tree. Just context changes. I fixed it up (see below) and can carry the fix for a while. -- ...

Signed-off-by: David S. Miller <davem@davemloft.net> --- arch/sparc/mm/Makefile | 2 +- arch/sparc/mm/gup.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 185 insertions(+), 1 deletions(-) create mode 100644 arch/sparc/mm/gup.c diff --git a/arch/sparc/mm/Makefile b/arch/sparc/mm/Makefile index 79836a7..e3cda21 100644 --- a/arch/sparc/mm/Makefile +++ b/arch/sparc/mm/Makefile @@ -4,7 +4,7 @@ asflags-y := -ansi ccflags-y := -Werror ...

They are pointless and make it harder to use RCU page table freeing and share code with other architectures. BTW, this is the second time this has happened, see commit 3c936465249f863f322154ff1aaa628b84ee5750 Signed-off-by: David S. Miller <davem@davemloft.net> --- arch/sparc/Kconfig | 4 ---- arch/sparc/include/asm/pgalloc_64.h | 32 +++++++++++++++----------------- arch/sparc/mm/tsb.c | 11 +++++++++++ 3 files changed, 26 insertions(+), 21 ...

While I guess this patch works OK, I have to say that I'm worried by the need for it at all; it seems to be papering over a more serious problem. reserve_top_address() is supposed to be called very early, before anything has used or referenced FIXADDR_TOP. If we're seeing problems with FIXADDR_TOP changing after it has been used, then it means that reserve_top_address() is being called too late. Fixing that would be the real fix. --

Well, the first question is "do we need the reservetop= kernel parameter"? Zach added it, I think, so that VMI could be loaded dynamically as a module. Given that VMI is deprecated anyway, I wonder if we can just drop support for modular VMI and remove the reservetop= kernel parameter. Or are there other uses for it? J --

(adding linux-ide to CC) A complete dmesg is definitely useful. Posting one from the failing kernel would be preferred, though. That will show us libata boot messages as well as the failures you are seeing, in full detail. Also, please try the latest 2.6.34-rc kernel, as that has several fixes for both pata_via and sata_via which did not make 2.6.33. Jeff --

Hi all, Today's linux-next merge of the net tree got a conflict in net/core/ethtool.c between commit 5a0e3ad6af8660be21ca98a971cd00f331318c05 ("include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h") from Linus' tree and commit 97f8aefbbfb5aa5c9944e5fa8149f1fdaf71c7b6 ("net: fix ethtool coding style errors and warnings") from the net tree. Just context changes. I fixed it up (see below) and can carry the fix for a while. -- ...

--

Francois attached a patch to the bugzilla entry that ignores the failure to enable MWI on the device. That may get the NIC up and running, but that area of the driver doesn't seem to have changed since 2.6.32, so perhaps this is just a canary -- I'm betting that the cache line size is not getting set properly, and it probably affects more than just this NIC. --

Thanks for the update. --

Thanks, closing. Rafael --

Yes. The other half of it is that the priv_root dentry being stuck in the dcache for as long as the flie system is mounted is a guaranteed since REISERFS_SB(sb) holds a reference to it until reiserfs_kill_sb is called. -Jeff -- Jeff Mahoney SuSE Labs --

If you don't mind, please. If you send them my way I'll run them on my machines too. --

What's the straight-line performance impact of all this? And how about concurrency, I wonder. mutexes of course are double the atomics, and you've added a refcount which is two more again for those paths using it. Page faults are very important. We unfortunately have some databases doing a significant amount of mmap/munmap activity too. I'd like to see microbenchmark numbers for each of those (both anon and file backed for page faults). kbuild does quite a few pages faults, that would be ...

You think this would affect the mmap/munmap times in any significant OK, I'll dig out that fault test used in the whole mmap_sem/rwsem thread I'll try and get some perf stat runs to get some insight into this. But the numbers were: time make O=defconfig -j48 bzImage (5x, cache hot) without: avg: 39.2018s +- 0.3407 with: avg: 38.9886s +- 0.1814 --

They're actually not _too_ heavy because they just setup and tear down vmas. No flushing or faulting required (well, in order to make any _use_ of them you need flushing and faulting of course). I have some microbenchmarks like this and the page fault test I Well that's interesting. Nice if it is an improvement not just some anomoly. I'd start by looking at TLB flushes maybe? For testing, it would be nice to make the flush sizes equal so you get more of a comparison of the straight line ...

Have you tried compiling this for NOMMU? David --

No, I will eventually, I'm sure there's something to fix. --

Really? I see the comment in the powerpc code, but powerpc was already using RCU before gup_fast(), and AFAIKS it is indeed using it so that it can handle faults by getting the linux pte with find_linux_pte ? I would have thought this should be a well used method for handling software TLB faults. But anyway this looks like a nice abstraction. --

Hi, Peter. We have second defense rule by page_check_address. Before anon_vma is detached, pte of pages on the anon_vma should be zeroed. So can't page_check_address close the race? Thanks for good trial for good feature. -- Kind regards, Minchan Kim --

--

Why? IIUC. page->mapping dereference in page_lock_anon_vma() makes four story. 1. the anon_vma is valid -> do page_referenced_one(). 2. the anon_vma is invalid and freed to buddy -> bail out by page_mapped(), no touch anon_vma 3. the anon_vma is kfreed, and not reused -> bail out by page_mapped() 4. the anon_vma is kfreed, but reused as another anon_vma -> bail out by page_check_address() Now we have to consider 5th story. 5. the anon_vma is exchanged another anon_vma by ...

Hehe, page_referenced() already can take unstable VM_LOCKED value. So, In worst case we make false positive pageout, but it's not disaster. I think. Anyway "use after free" don't happen by this blutal code. However, I think you pointed one good thing. before Rik patch, we don't have page->mapping reassignment. then, we didn't need rcu_dereference(). but now it can happen. so, I think rcu_dereference() is better. Perhaps, I'm missing something. diff --git a/mm/rmap.c b/mm/rmap.c index ...

Hi, Kosaki. On Fri, Apr 9, 2010 at 4:29 PM, KOSAKI Motohiro OFF-TOPIC: I think you pointed out good thing, too. :) You mean although application call mlock of any vma, few pages on the vma can be swapout by race between mlock and reclaim? Although it's not disaster, apparently it breaks API. Man page " mlock() and munlock() mlock() locks pages in the address range starting at addr and continuing for len bytes. All pages that contain a part of the specified address range are ...

I'm surprising this mail. you were pushing much patch in this area. I believed you know all stuff ;) My answer is, it don't need to fix, because it's not bug. The point is that this one is race issue. not "pageout after mlock" issue. If pageout and mlock occur at the exactly same time, the human can't observe which event occur in first. it's not API violation. Thanks. --

Yes, I think this is indeed required. I'll do a new version of the patch that includes the comment updates requested by Andrew. --

Hi, Kosaki. I don't want to make noise due to off-topic. So I open new thread. If I disappoint you, sorry for that. If it might happen, it's obviously API violation, I think. int main() { mlock(any vma, CURRENT|FUTURE); system("cat /proc/self/smaps | grep "any vma"); .. } result : 08884000-088a5000 rw-p 00000000 00:00 0 [any vma] Size: 4 kB Rss: 4 kB ... Swap: 4 kB ... Apparently, user expected that "If ...

Measuring ITLB_FLUSH on Intel nehalem using: perf stat -a -e r01ae make O=defconfig-build/ -j48 bzImage -linus 5825850 +- 2545 (100%) +patches 5891341 +- 6045 (101%) +below 5783991 +- 4725 ( 99%) (No slab allocations yet) Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- include/asm-generic/tlb.h | 122 ++++++++++++++++++++++++++++++---------------- 1 file changed, 82 insertions(+), 40 deletions(-) Index: ...

Did no profiling at all, back when I wrote this I was in a hurry to get this working for -rt. But yes, those things do look like something we want to look into, we can easily add a head structure to these pages like we did for the RCU batches. But as it stands I think we can do those things as incrementals on top of this, no? What kind of workload would you recommend I use to profile this? --

Gah, you're right, thanks! --

Reviewed-by: Rik van Riel <riel@redhat.com> --

OK. Here is the sequence of events that I am concerned about: 1. CPU 0 invokes page_lock_anon_vma() [13/13], and executes the assignment to anon_vma. It has not yet attempted to acquire the anon_vma->lock mutex. 2. CPU 1 invokes page_unlock_anon_vma() [13/13], which in turn calls anon_vma_put() [5/13], which atomically decrements ->ref, finds it zero, invokes anon_vma_free() [13/13], which finds ->ref still zero, so acquires ->lock and immediately releases it, and then calls ...

Hi Jeff, Thanks for verify the patch, you are correct, since I am using the wireless-testing version of the kernel, you will need to make the changes in order to get the patch apply. Sorry for the trouble. Regards --

Dave, This fix is intended for 2.6.34. It resolves an issue involving an Oops on boxes w/ iwl4965 hardware, apparently introduced by another recent patch. The thread describing the issue and the resolution is here: http://marc.info/?l=linux-kernel&m=127074721531649&w=2 In order to avoid reverting that patch, please accept this fix instead. As usual, please let me know if there are problems! Thanks, John --- The following changes since commit ...

Looks good Acked-by: Chris Wright <chrisw@sous-sol.org> --

On Thu, 08 Apr 2010 17:07:55 -0700 This one looks good: Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Thanks, -- Jesse Barnes, Intel Open Source Technology Center --

thanks. please check Subject: [PATCH] intel-iommu: Don't call domain_exit if can not attach with iommu when intel_iommu=off or iommu=pt is used, will work well. root cause: domain is initialized after trying attached it, if it can not be attached, don't call domain_exit yet. it will cause kernel crash in domain_exit() after patch will will get error instead of crash. [ 1781.910241] IOMMU: no free domain ids [ 1781.910244] Allocating domain for 0000:d0:1f.5 failed SIOCSIFFLAGS: ...

Applied, without the ifdef and slightly cleaned up. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

On Thu, 08 Apr 2010 20:22:57 +0200 To me it seems like -ENOMEM could be a bit confusing here; there's a lot of things that could go wrong with that same error return. That said, I did some digging around, and -ENOMEM does seem to be the Indeed. Fixed. Thanks, jon --

On Fri, 09 Apr 2010 22:23:06 +0200 In fact, I already came to this conclusion and have added a patch to have both functions use the same code. Thanks, jon --

On Fri, 09 Apr 2010 06:21:18 +0200 Ah, good point, the separate write is superfluous. Removed. Harald's initial patch included a mechanism for remapping register writes on the fly depending on which engine was in use; these defines were used for that purpose. Your reworking of the 2D code obliterated that patch, and made it mostly unnecessary. I kept the defines around, though, because I thought that documenting the registers can only be a good thing. Thanks, jon --

Hi Jon, in your later patch "[PATCH 06/16] viafb: complete support for VX800/VX855 accelerated framebuffer" you reintroduce initializing those bits to 0. That's fine but I can't see a reason for preserving this bits here as it adds useless overhead unless the hardware itself changed some of those bits and behaves differently according to those bits. Additionally the first 2 bits are not reserved but provide a rotation where 00 is what we want (no rotation). And if you rip code off ...

The patch itself looks good. However I have a few minor issues below this obsoletes /* Init 2D engine reg to reset 2D engine */ writel(0x0, engine + VIA_REG_KEYCONTROL); As in the previous patch I'd appreciate a default of printk(KERN_ALERT "viafb_xy: FIXME"); I have to admit to be consistent a few switches that are already there All of these defines are unused. I admit that it is my fault. I've not yet found a way I like to use them as the meaning of the same hardware address ...

On Thu, 08 Apr 2010 20:42:17 +0200 That would make sense. But if somebody who is closer to the hardware than That's a good point. I put in a check. Thanks, jon --

Hi Jon, Well it's not only mode setting its for each hardware accelerated ...if you insist on it its okay with me. I still disagree but its The code (and the spec regarding the reserved bits also) is obviously identical so please don't ignore it. If you decide to put it in a separate function please do so for both blit engines especially if they really do the same as in this case. As you say they are mostly identical and that's by design. Please keep them in sync if possible. They ...

What will happen if someone with no VX855 will try to enter 1200x900 mode? Probably the world won't be destroyed but I have a really ugly feeling that the driver is not well prepared for this situation. Haven't tested yet as I'm waiting for the official forward port but I think it might be better to reschedule this patch for later or add some PLL values that are supposed to work (using/executing the formulas in the VIA open source X driver) Otherwise it looks fine. Thanks, --

I don't know I2C too well and this patch has certainly its issues (the FIXMEs, the hardcoded VIAFB_NUM_I2C, probably others) but in general it looks okay. Therefore I think it should be merged and the issues should be fixed afterwards. Thanks, --

I agree to revert, too. I guess nobody see my NAK for original mail (;_;) --

I can try it, or if you have a particular patch set try to apply it to 2.6.33. It is not 100% reproducible however. Richard --

Sorry, I didn't realized this, can we use (defined(CONFIG_TRACING) && --

I never said this would be easy ;) Maybe it's close to impossible :( I had hoped modifying the "atomic" macros for the arch in question in a way that they use a handle instead of a pointer to the "atomic" variable in a compatible way and then modifying the code that uses these macros in a way that theses handles are created by additional macros that with other archs can be uses optionally (in a compatible way: returning the appropriate pointer) could work. But of course you are correct that ...

You are completing missing the point Linux + glibc platforms don't "need" futex - you need fast user space locks. Futex is an implementation of those locks really based around platforms with atomic instructions. People were doing fast user space locks before Linus was even born and on machines without atomic operations. Seperate out - the purpose for which the system exists (fast user locking) - the interfaces by which it must be presented (posix pthread mutex) Nope. Glibc allows you to ...

the Blackfin already has such an instruction (TESTSET), but since it has restrictions (cannot be used safely on cached memory), we found it unusable as a generic solution. this is why we went to the userspace fixed atomic code region. the only time we use this instruction is with the Blackfin SMP port, and only as an inter-core lock (so it has a fixed address and there is only one such lock). i think you underestimate the task of customizing every userspace point that may want atomic ...

Found it in Wikipedia. I'm working on the text... Thanks a lot ! -Michael --

Of course you are right, but IMHO this is why FUTEX was invented (and AFAIK, Linux himself did the first implementation). With FUTEX there is a standard way of speeding up Posix compatible thread locking (by implementing the user space part of FUTEX in the pthread part of libc and defining a Kernel interface for the fast thread locking/unlocking functions that is not (much ?) more arch depending than other Kernel interfaces. Of course you are right that my suggestion in fact contradicts to ...

Probably no, because only br_netpoll_cleanup() will be called Yes? netpoll_send_skb() needs to see IFF_IN_NETPOLL is set, so we can't clear this bit before calling it. Yes? The first messages explains the reason for the second message. Thanks. --

It seems nice overall. Thank you for your work. I have a few minor comments. IIUC, writing to cgroup.procs isn't supported yet. So, I think we don't have to Is this line necessary ? We say the similar thing above("A PageCache page is hmm, chapter 2 is used as "2. Memory Control" already :( Otherwise, it looks good to me. Thanks, Daisuke Nishimura. --

On Fri, 9 Apr 2010 11:11:45 +0900 Ouch....I have to fix (our internal) user manual, too..... Thanks, -Kame --

Looks good to me. Reviewed-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Thanks, --

Reorganize alloc/free_pcpu_chunk() such that chunk struct alloc/free live in pcpu_alloc/free_chunk() and the rest in pcpu_create/destroy_chunk(). While at it, add missing error handling for chunk->map allocation failure. This is to allow alternate chunk management implementation for percpu nommu support. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: David Howells <dhowells@redhat.com> Cc: Graff Yang <graff.yang@gmail.com> Cc: Sonic Zhang <sonic.adi@gmail.com> --- Add code to ...

Thanks all. Updated patch will be sent out soon. Best regards, --

Full bootlog attached to https://bugzilla.kernel.org/show_bug.cgi?id=15744 Snippets: [ 0.000000] BIOS-e820: 00000000bfe55c00 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved) [ 0.000000] BIOS-e820: ...

It is used for a custom FPGA implementing a watchdog timer and some other functionality. This is not a matter of supporting such a device in Linux, it is a matter of explicitly excluding non-VGA devices from using VGA memory space. If that is the decision, it might be worthwhile mentioning it somewhere in the documentation, to prevent others from ever using that memory space in an embedded system (and to save them the time needed to find out about it and to identify and implement a ...

bootlog? what is the address used for AHCI? YH --

It's not. Any differences between 32 and 64 bits in this area are just plain wrong. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

[Adding Guenter Roeck as he was commenting on something writing to the VGA area...] Do we have any evidence of any such system? Either which way, the patch looks saner... -hpa --

Quite. We really need to consider if that kind of devices should be supported. -hpa --

This doesn't help, my AHCI still fails to initialize in the same way. -andy --

No they're not. The 0xa0000...0xbffff range has been a legacy video area since the very first PC (although the first PC only used 0xb0000..0xbffff, 0xa0000..0xbffff was declared reserved at that time.) I'm wondering what those legitimate reasons are. This is particularly so since it affects our ability to deal with very early errors, long before we have enumerated anything. At this point we can at least lay down bytes in the video area and hope the user can see them. -hpa --

Depending on your definition of "PC". Quite a few early MSDOS systems had video elsewhere. Some embedded systems without video use the space for other stuff. Lots of ISA 386/486 PCs had cards borrowing the unused bits Thats why you have the bios equipment byte and video queries. --

_CRS report those range are used devices under the peer root bus. and in e820_reserve_resources_late, we are using insert_resource_expand_to_fit() to register E820_RESERVED region. could be that insert_resource_expand_to_fit doesn't work in that case. like in the tree when we have [ 0.704003] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.705002] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff] [ 0.706002] pci_root PNP0A03:00: host ...

Please check Subject: [PATCH] x86: reserve [0xa0000, 0x100000] in e820 Update e820 at first, and later put them resource tree. -V2: reserved that early, no PCI BAR can use it, force them to get new one Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: Andy Isaacson <adi@hexapodia.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/setup.h | 1 - arch/x86/kernel/e820.c ...

I hate to break it to you, but 64-bit DMA support is optional for an xHCI implementation. There's a bit in HCCPARAMS that tells whether the host supports it (see the HCC_64BIT_ADDR macro in xhci.h). The xHCI driver currently doesn't do anything with that bit, although it should. What makes you think that? I've seen URB buffers with 64-bit DMA addresses. I can tell when the debug polling loop runs and I look at the DMA addresses the xHCI driver is feeding to the hardware: Dev 1 endpoint ...

It is a bug you will only see if you attempt to bring up two iio devices with event interfaces at the same time. I've no idea if anyone has a, non-dev board where this is happening. If you trigger the bug the second devices probe will fail. So moderately horrible but the problem is fairly self contained. By the look of it two people have run into the bug (or spotted the problem during code review?) so probably worth pushing the fix in sooner rather than later. Thanks, Jonathan --

shrink_zone on my box isn't 500 bytes, but lets try the easy stuff first. This is against .34, if you have any trouble applying to .32, just add the word noinline after the word static on the function definitions. This makes shrink_zone disappear from my check_stack.pl output. Basically I think the compiler is inlining the shrink_active_zone and shrink_inactive_zone code into shrink_zone. -chris diff --git a/mm/vmscan.c b/mm/vmscan.c index 79c8098..c70593e 100644 --- ...

FWIW akpm suggested that I add: /* * Rather then using noinline to prevent stack consumption, use * noinline_for_stack instead. For documentaiton reasons. */ #define noinline_for_stack noinline --

Why is accounting of each frequency needed? pcc-cpufreq driver can do every frequency in a range and supports hundreds of different frequencies, thus it does not depend on CPU_FREQ_TABLE. Would the average frequency be enough to track/account? This would avoid the static interface of listing each available freq. It would also count "boosted" frequency case which is avail on most recent Can the frequency change somewhere in the middle between cpuacct_charge is called? What guarantees that the ...

Hi Mauro, Excellent, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=15744 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl --

From: Peter Zijlstra <peterz@infradead.org> Subject: Re: High priority threads causing severe CPU load imbalances I made a patch for my understanding the load_balance()'s behavior. This patch reduced CPU load imbalances but not perfect. --- Cpu0 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 90.1%us, 0.0%sy, 0.0%ni, 9.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 :100.0%us, ...

Confirming - the second version of the patch fixes all the network-related RCU complaints I've been able to trigger...

nod. My only point was that if only one can spin, and sleeps when the owner is not on CPU, then you virtually guarantee worst case performance under certain conditions (ie: multiple threads coming in at various times) If all spin, and they sleep only on owner block, then the 'unfairness' is potentially more evenly distributed via hardware (and stealing) and when the owner is blocked. Best, --

Agreed. However from your earlier mail it seemed addressing this scenario was within the scope of consideration. There are two ways to deal with this condition, either reactive in the sense we do so after the lock holder has been preempted and subsequently find we're spinning in sibling thread context attempting to acquire the lock. Or proactively where we provide a time bounded deferral of lock holder preemption with the assumption the lock hold path overhead has negligible effect ...

For the second hunk, do you think ep->out->... and so on? That would be more in-line with code present in 2.6.33. Tvrtko --

At Fri, 9 Apr 2010 07:51:35 +0100, Ah, crap. Sorry, that's just messing up. The revised (compiled but untested) patch is below. thanks, Takashi --- diff --git a/sound/usb/usbmidi.c b/sound/usb/usbmidi.c index 2c59afd..9e28b20 100644 --- a/sound/usb/usbmidi.c +++ b/sound/usb/usbmidi.c @@ -986,6 +986,8 @@ static void snd_usbmidi_output_drain(struct snd_rawmidi_substream *substream) DEFINE_WAIT(wait); long timeout = msecs_to_jiffies(50); + if ...

Indeed. I have found this to be a persistent problem and I really wish there were more interest in debugging this. I have tried bringing the community's resources to bear on this issue several[1] times, and each time we fail to get enough of the right eyes looking at it or developer interest simply vanishes. I've started putting together a list[2] of pertinent threads/patches/bugs/data in hopes that this will lower the energy barrier of getting up to speed on this issue. Hopefully this will ...

That didn't change the behaviour for me, sorry. (I made sure to go through a full power down session before trying the patched kernel) Regards, -- Tony Vroon UNIX systems administrator London Internet Exchange Ltd, Trinity Court, Trinity Street, Peterborough, PE1 1DA Registered in England number 3137929 E-Mail: tony@linx.net

All of config space, but not raw access to all bits. So the MSI/MSI-X capability writes need to be intermediated. There's bits in the header too. And it's not just PCI, it's extended config space as well, drivers may care about finding their whizzybang PCIe capability and doing someting with it (and worse...they are allowed to put device specific registers there, and worse yet...they do!). thanks, -chris --

Just so you know what you got into, here are the kvm requirements: - msi interrupts delivered via eventfd (these allow us to inject interrupts from uio to a guest without going through userspace) - nonlinear iommu mapping (i.e. map discontiguous ranges of the device address space into ranges of the virtual address space) - dynamic iommu mapping (support guest memory hotplug) - unprivileged operation once an admin has assigned a device (my preferred implementation is to have all operations ...

Mea culpa. --

Specifically, intermediated access to config space. For example, need to know about MSI/MSI-X updates in config space. thanks, -chris --

Commit-ID: 5958f1d5d722df7a9e5d129676614a8e5219bacd Gitweb: http://git.kernel.org/tip/5958f1d5d722df7a9e5d129676614a8e5219bacd Author: Borislav Petkov <borislav.petkov@amd.com> AuthorDate: Wed, 31 Mar 2010 21:56:41 +0200 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Fri, 9 Apr 2010 14:05:23 -0700 x86, cpu: Add AMD core boosting feature flag to /proc/cpuinfo By semi-popular demand, this adds the Core Performance Boost feature flag to /proc/cpuinfo. Possible use case for this ...

Commit-ID: d65ad45cd82a0db9544469b8c54f5dc5cafbb2d8 Gitweb: http://git.kernel.org/tip/d65ad45cd82a0db9544469b8c54f5dc5cafbb2d8 Author: Borislav Petkov <borislav.petkov@amd.com> AuthorDate: Wed, 31 Mar 2010 21:56:43 +0200 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Fri, 9 Apr 2010 14:05:50 -0700 x86: Unify APERF/MPERF support Initialize this CPUID flag feature in common code. It could be made a standalone function later, maybe, if more functionality is ...

Commit-ID: 679370641e3675633cad222449262abbe93a4a2a Gitweb: http://git.kernel.org/tip/679370641e3675633cad222449262abbe93a4a2a Author: Mark Langsdorf <mark.langsdorf@amd.com> AuthorDate: Wed, 31 Mar 2010 21:56:45 +0200 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Fri, 9 Apr 2010 14:07:47 -0700 powernow-k8: Fix frequency reporting With F10, model 10, all valid frequencies are in the ACPI _PST table. Cc: <stable@kernel.org> # 33.x 32.x Signed-off-by: Mark Langsdorf ...

Okay I built a linus head and it booted on the previously broken machine. with CONFIG_NO_BOOTMEM=y Dave. --

Can you double-check your current diffs - maybe something got corrupted. mmap_region installs the vma with vma_link(), and the last thing vma_link() does with my patch is that "anon_vma_prepare()". Maybe with all the patches flying around, you had a reject or something, and you lost that one anon_vma_prepare()? Or maybe I screwed up somewhere and sent you the wrong patch. Here it is again, just in case. [ I have a horrible cold, and can hardly think straight. So who knows, ...

--

From: Linus Torvalds <torvalds@linux-foundation.org> Yep, yours along with the SLUB debugging piece just survived one hibernation cycle without a problem. Also, no SIGBUS-killed processes, all seems fine. Will continue stressing it though... Let me know what you want me to do next. -- Regards/Gruss, Boris. --

From: Linus Torvalds <torvalds@linux-foundation.org> It looks like this way we mangle the anon_vma chains somehow. From what I can see and if I'm not mistaken, we save the anon_vmas alright but end up in what seems like an endless list_for_each_entry() loop having grabbed anon_vma->lock in page_lock_anon_vma() and we can't seem to yield it through page_unlock_anon_vma() at the end of page_referenced_anon() so it has to be that code in between iterating over each list entry... I could be ...

We can fix it on the other side, by changing anon_vma_merge to actually link all the anon_vma structs into the VMA. An added benefit is that we are already holding the required lock (mmap_sem) exclusively in that code path. I'll cook up a patch and I'll mail it out after a little testing. --

I've looked it over 5 times, can't find anything wrong with it. Your approach looks like it should work just fine. Reviewed-by: Rik van Riel <riel@redhat.com> --

This comment makes my head hurt. In fact, the whole anon_vma thing hurts my head. Can we have some better high-level documentation on what happens for all the cases. - split (mprotect, or munmap in the middle): anon_vma_clone: the two vma's will have the same anon_vma, and the anon_vma chains will be equivalent. - merge (mprotect that creates a mergeable state): anon_vma_merge: we're supposed to have a anon_vma_chain that is a superset of the two chains of the merged ...

The key is that merging is only possible if the primary anon_vmas are equivalent. This only happens if we split a vma in two and clone the old vma's anon_vma_chain into the new vma. So the chains are equivalent. Or anon_vma_prepare() finds a mergeable anon_vma, in which case this will be the singleton on the vma's chain. If a split vma is merged, the old anon_vma_chains are equivalent, we drop one completely and the one that stays has not changed. If a mergeable vma (singleton ...

Push down the bkl from procfs's ioctl main handler to its users. Only three procfs users implement an ioctl (non unlocked) handler. Turn them into unlocked_ioctl and push down the Devil inside. v2: PDE(inode)->data doesn't need to be under bkl Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: John Kacur ...

On Fri, 9 Apr 2010 14:51:04 +0800 I grabbed this. Did we decide that this needed to be backported into 2.6.33.x? If so, some words explaining the reasoning would be needed. Come to that, it's not obvious that we need this in 2.6.34 either. What is the user-visible impact here? --

Acked-by: Roland McGrath <roland@redhat.com> Thanks, Roland --

As far as I can tell I'm still waiting for those updated patches... -hpa --

Perhaps Dave meant the stable-queue? http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git Then again, 2.6.34-rc3 needs testing too! :-) Christian. -- BOFH excuse #98: The vendor put the bug there. --

Agreed. Thanks, Roland --

I'm not sure a fallback plan is welcome. What we want is a single implementation. If archs already have their own hardlockup detectors, then good for them as they have this fallback implementation already. For those who haven't it or who want to profit from a generic code that does a good deal of the error prone work for them already, they can just implement a basic perf support for the cpu-cycle events. Perf events gives a chance to provide a generic support for hardlockup detection ...

Cheers, Don --

Yeah but high-prio doesn't mean that it is scheduled often. It means that once it is in a runnable state (TASK_RUNNING), it will have a higher priority to get into the cpu (lower prio tasks will have less time in the cpu than the higher prio until the higher prio get to sleep). Especially here this is a SCHED_FIFO class, so usual tasks (SCHED_OTHER) won't ever run until it goes to sleep. But when it goes to sleep, it doesn't need the cpu, so other tasks can run. And it is only woken up ...

Acked-by: Roland McGrath <roland@redhat.com> Thanks, Roland --

Acked-by: Roland McGrath <roland@redhat.com> Thanks, Roland --

In v2.6.34-rc3-500-g0eddb51 this isn't possible because the calls from task_sig() and do_task_stat() are under siglock. Is that locking removed by another pending change? Thanks, Roland --

Acked-by: Roland McGrath <roland@redhat.com> Thanks, Roland --

Acked-by: Roland McGrath <roland@redhat.com> I'm not thrilled about the field name, but whatever. We now have three atomic counts with subtly different meanings, and no comments anywhere really explaining it all. * live: created and not yet begun to exit * count: not yet reaped We should never export those at all. In fact, I would not even make it a separate inline. We're here to simplify the lifetime rules, not give new ways to complicate them. If anybody wants to keep a signal_struct ...

I am using btrfs, so yes, I was expecting things to be better. Unfortunately, the improvement seems to be non-existent under high IO/fsync load. - Ben --

This requires support at the hardware level. (You can't have CPU code running to decode IR pulses when your CPU is "asleep".) I know of two video chips supported under linux that provide such a function. Wake-up from IR for these chips will rely on the kernel PCIe or USB infrastructure supporting PCIe or USB Power Managment Events from hardware. It will take a huge amount of work and time to get the respective linux video drivers to properly support suspend/resume properly. If you're ...

Hi, I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? Cheers James

You probably need to tell the USB system to leave the MSMCE's power turned on during suspend. Maybe the MSMCE driver can tell the USB -- Jon Smirl jonsmirl@gmail.com --

Thanks for the info Mauro. Cheers James

The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. Regards, Andy --