Hi folks, I'm looking for a way to pass a correct "root" parameter to the kernel from the bootloader, independently on the number of attached disks. My machine (VIA EPIA SN-1800) has four SATA ports and one CF card slot. The CF slot is visible as an IDE device. The BIOS is configured for booting from the CF card, and Grub2 has absolutely no problems booting the kernel. The problem I'm facing is that if there are no SATA disks attached, my CF card gets called /dev/sda, while if I attach two SATA ...

From: Stefani Seibold <stefani@seibold.net> This is a complete reimplementation of the new kfifo API, which is now really generic, type save and type definable. The API is still stable, no code which use the current kfifo API must be modified! Here are the results of the text section usage: Example 1: kfifo_put/_get kfifo_in/out current kfifo dynamic allocated 0x000002a8 0x00000291 0x00000299 in place 0x00000291 ...

From: Stefani Seibold <stefani@seibold.net> User of the kernel fifo should never bypass the API and directly access the fifo structure. Otherwise it will be very hard to maintain the API. Signed-off-by: Stefani Seibold <stefani@seibold.net> --- drivers/char/nozomi.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/char/nozomi.c b/drivers/char/nozomi.c index a663800..d578449 100644 --- a/drivers/char/nozomi.c +++ b/drivers/char/nozomi.c @@ -1741,8 ...

From: Stefani Seibold <stefani@seibold.net> Replace the old kfifo API files kfifo.c and kfifo.h with the new generic version and fix the kerneldoc API template file. Signed-off-by: Stefani Seibold <stefani@seibold.net> --- Documentation/DocBook/kernel-api.tmpl | 1 - include/linux/kfifo.h | 844 +++++++++++++++++++++++++++++++++ kernel/kfifo.c | 602 +++++++++++++++++++++++ 3 files changed, 1446 insertions(+), 1 deletions(-) create mode 100644 ...

From: Stefani Seibold <stefani@seibold.net> This is a complete reimplementation of the new kfifo API, which is now really generic, type save and type definable. The API is still stable, no code which use the current kfifo API must be modified! Here are the results of the text section usage: Example 1: kfifo_put/_get kfifo_in/out current kfifo dynamic allocated 0x000002a8 0x00000291 0x00000299 in place 0x00000291 ...

From: Stefani Seibold <stefani@seibold.net> Replace the old kfifo API files kfifo.c and kfifo.h with the new generic version and fix the kerneldoc API template file. Signed-off-by: Stefani Seibold <stefani@seibold.net> --- Documentation/DocBook/kernel-api.tmpl | 1 - include/linux/kfifo.h | 844 +++++++++++++++++++++++++++++++++ kernel/kfifo.c | 602 +++++++++++++++++++++++ 3 files changed, 1446 insertions(+), 1 deletions(-) create mode 100644 ...

The ftrace_dump_on_oops kernel parameter, sysctl and sysrq let one dump every cpu buffers when an oops or panic happens. It's nice when you have few cpus but it may take ages if have many, plus you miss the real origin of the problem in all the cpu traces. Sometimes, all you need is to dump the cpu buffer that triggered the opps, most of the time it is our main interest. This patch modifies ftrace_dump_on_oops to handle this choice. The ftrace_dump_on_oops kernel parameter, when it comes ...

Fix: fs/built-in.o: In function `sys_inotify_init1': summary.c:(.text+0x347a4): undefined reference to `anon_inode_getfd' found by kautobuild with arms bcmring_defconfig, which ends up with INOTIFY_USER enabled (through the 'default y') but leaves ANON_INODES unset. However, inotify_user.c uses anon_inode_getfd(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- fs/notify/inotify/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/notify/inotify/Kconfig ...

i mean, how many different definitions of inline are necessary? #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \ !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4) # define inline inline __attribute__((always_inline)) # define __inline__ __inline__ __attribute__((always_inline)) # define __inline __inline __attribute__((always_inline)) #endif rday -- ======================================================================== Robert ...

In the original code we used -ENODEV as the number of bytes to copy_to_user() and we didn't release the locks. Signed-off-by: Dan Carpenter <error27@gmail.com> diff --git a/drivers/char/pcmcia/cm4000_cs.c b/drivers/char/pcmcia/cm4000_cs.c index c9bc896..90b199f 100644 --- a/drivers/char/pcmcia/cm4000_cs.c +++ b/drivers/char/pcmcia/cm4000_cs.c @@ -1026,14 +1026,16 @@ static ssize_t cmm_read(struct file *filp, __user char *buf, size_t count, xoutb(0, REG_FLAGS1(iobase)); /* clear ...

From 6f9df3bc6571d6545c552151f408d69265e15f92 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 18 Apr 2010 10:25:19 -0700 Subject: [PATCH 1/7] sched: add a comment to get_cpu_idle_time_us() The exported function get_cpu_idle_time_us() has no comment describing it; add a kerneldoc comment Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- kernel/time/tick-sched.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git ...

From 166b7526ccfea8b44626b6023ff5b0a8eb869bb3 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 18 Apr 2010 10:33:02 -0700 Subject: [PATCH 2/7] sched: introduce a function to update the idle statistics Currently, two places update the idle statistics (and more to come later in this series). This patch creates a helper function for updating these statistics. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- kernel/time/tick-sched.c | 29 ...

From 526a9f347d5a953f37b67b4b2afb39d7b4d77a92 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 18 Apr 2010 10:49:30 -0700 Subject: [PATCH 5/7] sched: eliminate the ts->idle_lastupdate field Now that the only user of ts->idle_lastupdate is update_ts_time_stats(), the entire field can be eliminated. In update_ts_time_stats(), idle_lastupdate is first set to "now", and a few lines later, the only user is an if() statement that assigns a variable either to "now" ...

From c4dd11703034f2ecbc3180603663fab14c292d7c Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 18 Apr 2010 10:57:43 -0700 Subject: [PATCH 6/7] sched: introduce get_cpu_iowait_time_us() For the ondemand cpufreq governor, it is desired that the iowait time is microaccounted in a similar way as idle time is. This patch introduces the infrastructure to account and expose this information via the get_cpu_iowait_time_us() function. Signed-off-by: Arjan van de ...

This patch fixes all coding style issues found by checkpatch.pl. Signed-off-by: Farid Hammane <farid.hammane@gmail.com> --- drivers/i2c/i2c-dev.c | 30 +++++++++++++++--------------- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c index f4110aa..a22b16c 100644 --- a/drivers/i2c/i2c-dev.c +++ b/drivers/i2c/i2c-dev.c @@ -35,7 +35,7 @@ #include <linux/i2c.h> #include <linux/i2c-dev.h> #include <linux/jiffies.h> -#include ...

The following patches are the beginning of an effort to move work done for the OLPC XO 1.5 machine into the mainline. What's here is basic support for the VX855 chipset, I2C, and the OLPC panel display. What's coming in the future is a reworking of the viafb driver into something resembling a proper multifunction device, GPIO support, and camera support. But I'd like to start here. CHANGES FROM THE FIRST POSTING include fixes in response to a number of Florian's comments and the removal of ...

As suggested by Florian: make both mode-setting paths use the same code. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net> --- drivers/video/via/accel.c | 78 +++++++++++++++++++-------------------------- 1 files changed, 33 insertions(+), 45 deletions(-) diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c index a52147c..7c1d9c4 100644 --- ...

From: Paul Fox <pgf@laptop.org> [jc: no signoff, added my own] Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net> --- drivers/video/via/via_i2c.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c index 8f8e0bf..fe5535c 100644 --- a/drivers/video/via/via_i2c.c +++ b/drivers/video/via/via_i2c.c @@ ...

From: Chris Ball <cjb@laptop.org> The i2c transactions involved in detecting LVDS (9 seconds) and TMDS (16 seconds) add an extra 25 seconds to viafb load time on the XO-1.5. [jc: minor merge conflict fixed, removed ifdefs] Signed-off-by: Chris Ball <cjb@laptop.org> --- drivers/video/via/hw.c | 7 +++++++ drivers/video/via/lcd.c | 7 +++++++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c index 4aff0f7..bd5d5ce ...

This patch is a painful merge of change a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by Harald Welte. Harald's changelog read: The VX800/VX820 and the VX855/VX875 chipsets have a different 2D acceleration engine called "M1". The M1 engine has some subtle (and some not-so-subtle) differences to the previous engines, so support for accelerated framebuffer on those chipsets was disabled ...

This was part of Harald's "make viafb a first-class citizen using pci_driver" patch, but somehow got dropped when that patch went into mainline. Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: ScottFang@viatech.com.cn Cc: JosephChan@via.com.tw Signed-off-by: Jonathan Corbet <corbet@lwn.net> --- drivers/video/via/viafbdev.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c index ...

The merge window for Linux 2.6.34 closed in the first week of March, with the important XFS features already landing in February. Not surprisingly the XFS merge activity in March has been rather slow, with only about a dozen bug fixes patches making it towards Linus' tree in that time. On the other hand active development for the 2.6.35 merge window has been very active. Most importantly there was a lot of work on the transaction and log subsystems. Starting with a large patchset to clean ...

Hi, The following series of patches tries to fix the spinlock contention reported by Chris Manson: His benchmark exposes problems of the current code: - In the worst case, the algorithm used by update_queue() is O(N^2). Bulk wake-up calls can enter this worst case. The patch series fix that. Note that the benchmark app doesn't expose the problem, it just should be fixed: Real world apps might do the wake-ups in another order than perfect FIFO. - The part of the code that runs ...

This patch cacheline aligns the spinlock for sysv semaphores: Without the patch, the spinlock and sem_otime [written by every semop that modified the array] and sem_base [read in the hot path of try_atomic_semop()] can be in the same cacheline. --- include/linux/sem.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/include/linux/sem.h b/include/linux/sem.h index 8a4adbe..f2961af 100644 --- a/include/linux/sem.h +++ b/include/linux/sem.h @@ -79,6 +79,7 @@ struct ...

We now have to to include linux/slab.h explicitly for kmalloc & friends. Files that build against host headers already get their prototypes via um_malloc.h, linux/slab.h may even be unavailable. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> --- arch/um/drivers/line.c | 1 + arch/um/os-Linux/helper.c | 1 - 2 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c index 64cda95..7a656bd 100644 --- a/arch/um/drivers/line.c +++ ...

Hey all, It seems that something in the 2.6.34 merge cycle has broken suspend to RAM on my Dell Latitude D830. While suspend has been rock solid for several release cycles, as of 2.6.34-rc4 it locks up on suspend. All of the pm_test options up to processor work fine, precluding a driver issue. Unfortunately, I've been unable to get any useful output from the serial console during suspend. I'll try bisecting and report back when I have more details. Let me know what else I can do to ...

Hmm. I tested this patch with my favourite non-scientific desktop load test: do web browsing while doing a kernel compile with "make -j16" (after doing a "git clean -dqfx" and "ccache -C" to get rid of old object files and ccache). This is on a dual-core (with SMT, so 4 threads) Core i5, so "make -j16" overcommits the CPU's quite a bit. And quite frankly, I think your patch makes things much worse. I don't have numbers, but it felt much choppier and slower to do scrolling in ...

CFS fix place entity spread issue (v2) Huge CFS vruntime spread (18 minutes) has been observed with LTTng while simply running Xorg on a uniprocessor machine. Detailed explanation in my ELC2010 presentation at: http://www.efficios.com/elc2010 (includes slides, ad-hoc CFS instrumentation patches and wakeup latency test program) Changelog since v1: * Keep max(se->vruntime, vruntime). It's needed to ensure that tasks already within the spread window do not get an extra unfair vruntime ...

Hi Farid, Ironically, your patch itself triggers 5 checkpatch errors. I'll fix them. Thanks for the patch, consider it applied. -- Jean Delvare --

(reposted because I remember kernel.org mentioning that HTML email is verboten or something like that---Sorry!) I know that on the user-space side any open handles can be seen in the /proc/<pid>/fd directory (<pid> is whatever process you're interested in). Assuming you're talking about reading this from kernel space, I'd look at what the procfs filesystem is doing and learn from that. Sockets and block/char devices are listed like any other file, the list --

Get the Linux kernel source and look at what the procfs filesystem is doing to get that information. Look under fs/proc. fs/proc/base.c(2508) seems to contain the inode structures for /proc/pid/fd and /proc/pid/fdinfo, locate the inode operations structure and locate the functions. Drill down through the function calls and you'll eventually find how to read what file handles are open. A quick glance tells me that the calls go several layers deep including a call through a function pointer ...

Hi, From reading the code (kernel/irq stuffs), it seems that at least some handle_edge_irq based interrupts are not replayed when enabling if desc->chip->retrigger == NULL and on a platform where CONFIG_HARDIRQS_SW_RESEND is not set (which for now is only defined for (some?) arm and avr32). Depending on the pic this problem might be masked if multiple interrupts are received between disable_irq and enable_irq (maybe other conditions exist with controllers i don't know). I happen to program a ...

So you are having a level interrupt device and the irq line is handled by an edge type handler ? Why not configuring the irq line for level and in the first place ? Thanks, tglx --

Hi Jerome, On my laptop with a HD3650 GPU, during resume from RAM I get the below errors - [ 80.484213] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting [ 80.484218] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing FA30 (len 493, WS 0, PS 4) @ 0xFA71 [ 81.497547] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting [ 81.497552] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing FA30 (len 493, ...

OK. Next question is how these files are being written. If you 'strace' the process, do you see ordinary write() calls being used, or is the file perhaps being written via mmap()? --

Did you test with commit b80c3cb628f0ebc241b02e38dd028969fb8026a2 (NFS: Ensure that writeback_single_inode() calls write_inode() when syncing)? That fixed the above problem on my setup. Cheers Trond --

(strace output is at <http://www.esperi.org.uk/~nix/temporary/strace-kdelibs-nfs-EBUSY.log.lzma> if you want to look for yourself, but it's about 70Mb unlzmaed, so I can understand if you run very fast in the opposite direction...) The files are all ELF object files: build/CMakeFiles/CMakeTmp/CMakeFiles/cmTryCompileExec.dir/.nfs000000000031c7510000159b: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped ... which means they're being written by gas, and that writes them ...

Hello. I try to send and receive ethernet packets on very low level in my kernel module. When i change (add or delete entry) routin table (via route command) my network is freeze for ~15 seconds and my application can't send and receive any packets. Is it normal or bug somewhere in my application? Can i change this behavior of route system? Maybe change some timeouts, or immediately flush route (rt_flush() ?) table? Thanks. --

Can you diff dmesg with/without this? It shouldn't do anything unless you have multiple framebuffer drivers. --

Good catch!!! Queued for 2.6.35. --

I think David Miller will take it. Karsten --

Hello, Acked-by: Tejun Heo <tj@kernel.org> Hmm... through which tree should this go through? I can route it through percpu but maybe taking the usual isdn patch path would be better? Thanks. -- tejun --

True, I could put a #ifdef CONFIG_NO_HZ around that leg of the switch statement. Or am I still missing your point? Thanx, Paul --

Which is exactly the purpose of the "if" statement comparing the two constants, right? ;-) Thanx, Paul --

Well, I must confess that it confused me when I added the spin_unlock()... Thanx, Paul --

Hi, Christoph. I don't want to force using '_node' postfix on UMA users. Maybe they don't care getting page from any node and event don't need to alloc_pages_node have multiple meaning as you said. So some of users Yes, now it's totally different. On UMA, It's any node but on NUMA, local node. My concern is following as. alloc_pages_node means any node but it has nid argument. Why should user of alloc_pages who want to get page from any node pass nid argument? It's rather ...

Yeah, then, remove alloc_pages_any_node(). I can't really see the point of any_/exact_node. alloc_pages() and alloc_pages_node() are The name is fine. Just clean up the users and make the intended usage clear in documentation and implementation (ie. trigger a big fat warning) and make all the callers use named constants instead of -1 for special meanings. Thanks. -- tejun --

There are two issues here: stack utilisation and poor IO patterns in direct reclaim. They are different. The poor IO patterns thing is a regression. Some time several years ago (around 2.6.16, perhaps), page reclaim started to do a LOT more dirty-page writeback than it used to. AFAIK nobody attempted to work out why, nor attempted to try to fix it. Doing writearound in pageout() might help. The kernel was in fact was doing that around 2.5.10, but I took it out again because it ...

On Sat, 17 Apr 2010 20:32:39 -0400, Andrew Morton I for one am looking very seriously at this problem together with Bruce. We plan to have a discussion on this topic at the next LSF meeting -- Best Regards Sorin Faibish Corporate Distinguished Engineer Network Storage Group EMC² where information lives Phone: 508-435-1000 x 48545 Cellphone: 617-510-0422 Email : sfaibish@emc.com --

Right. It's intended that the great majority of writeout be performed by the fs flusher threads and by the write()r in balance_dirty_pages(). Writeout off the LRU is supposed to be a rare emergency case. Yeah, but it's all bandaids. The first thing we should do is work out why writeout-off-the-LRU increased so much and fix that. Handing writeout off to separate threads might be used to solve the stack consumption problem but we shouldn't use it to "solve" ...

On Sun, 18 Apr 2010 17:30:36 -0400, James Bottomley Let's work together to get this done. This is a very good idea. I will try to bring some facts about the current state by instrumenting the kernel to sample with higher time granularity the dirty pages dynamics. This will allow us expose better the problem or lack of. :) -- Best Regards Sorin Faibish Corporate Distinguished Engineer Network Storage Group EMC² where information lives Phone: 508-435-1000 x ...

Eric, sorry for not seeing this earlier, but it looks like the last patch I emailed out did not include all the tiny changes I made prior to asking Linus to pull this (which he ended up not doing). For example this fix to the include Kbuild file was there. You could look at: http://git.kernel.org/?p=linux/kernel/git/roland/infiniband.git;a=commit;h=cfe60a43c34... to see what was actually in my pull request. There may be other trivial tweaks worth ...

Thanks for the explanation. Your last example makes perfect sense for I get some gain numbers but obviously the workloads makes a huge difference. From a scheduler perspective, I assume an average/representative gain is best rather than an optimistic or pessimistic one? We'll have different gains for SMT2 and SMT4, so we could change the gain dynamically based on which SMT mode we are in. Does that seem like Yes for an average workload, 4 SMT threads are slower than 2 ...

This isn't quite right. mutex critical sections must guarantee eventual forward progress against the class of other potential acquirers of the mutex otherwise the system will become either deadlocked or livelocked. James --

On Fri, 09 Apr 2010 23:27:30 +0200 OK, I'm certainly exposing my relative lack of understanding of framebuffer issues (I'm here to add a camera driver, remember? :), but...is this really something that older chipsets can't handle? Or is If it's really not acceptable, then it will stay out, but I would rather get it merged. I will leave it in the series for now; it can come out later if need be. Thanks, jon --

[Getting back to the older stuff...] On Fri, 09 Apr 2010 22:34:16 +0200 I've spent a bit of time looking at this. What's really needed is a better way of abstracting the chip types so that we can maybe get rid of all those switch statements throughout the driver. For the purposes of getting this work in, I'm not quite prepared to make that change, though I could certainly consider doing it in the future. In the absence of that, the only course of action which makes sense is to simply ...

Hi! i agree with that step by step strategy. I always felt conservative about making too big changes. After all, it is hard to find people who actually own and use all those various models of graphics chips, and even more so: who want to try + test recent mainline and check for regressions :( VIA's resources are extremely limited, and they can barely complete the work required for new products... I know it's unfortunate, but VIA is a very small company. Regards, Harald -- - ...