The card based on cx23885 PCI-e brige. Altera FPGA for CI, multistandard demods stv0367 from STM for QAM & OFDM, Xcieve xc5000 tuners and additional cx25840 for second analog input. Signed-off-by: Igor M. Liplianin <liplianin@netup.ru> --- drivers/media/video/cx23885/Kconfig | 3 +- drivers/media/video/cx23885/cx23885-cards.c | 103 ++++++++++++++++- drivers/media/video/cx23885/cx23885-core.c | 24 +++-- drivers/media/video/cx23885/cx23885-dvb.c | 172 ...

To give you an idea of the performance difference, even for mass storage class which has less protocol involvement, the native software and hardware on the platform I am using typically perform at less than 4 MB/s. I am getting this number from benchmarks of the Motorola Droid phone, which uses a similar software and hardware configuration as the Understood, I will try to implement it in this way on my setup. I do have the latest kernel booting on it now and show be able to implement this ...

Hi, with 2.6.35.2 I'm getting this reproducible Oops: [ 110.825396] BUG: unable to handle kernel NULL pointer dereference at (null) [ 110.828638] IP: [<ffffffff811247b7>] encode_attrs+0x1a/0x2a4 [ 110.828638] PGD be89f067 PUD bf18f067 PMD 0 [ 110.828638] Oops: 0000 [#1] SMP [ 110.828638] last sysfs file: /sys/class/net/lo/operstate [ 110.828638] CPU 2 [ 110.828638] Modules linked in: rtc_cmos rtc_core rtc_lib amd64_edac_mod i2c_amd756 edac_core i2c_core dm_mirror dm_region_hash dm_log ...

From: Namhyung Kim <namhyung@gmail.com> breakinfo->pev is a pointer to percpu pointer but was missing __percpu markup. Add it. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> --- arch/x86/kernel/kgdb.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c index ef10940..852b819 100644 --- a/arch/x86/kernel/kgdb.c +++ b/arch/x86/kernel/kgdb.c @@ -194,7 +194,7 @@ ...

Commit b45cfba4e9005d64d419718e7ff7f7cab44c1994 (vt,console,kdb: implement atomic console enter/leave functions) introduced the ability to atomically change the console mode with kernel mode setting but did not preserve the state of the console_blanked variable. The console_blanked variable must be restored when executing the con_debug_leave() or further kernel mode set changes (such as using chvt X) will fail to correctly set the state of console. Signed-off-by: Jason Wessel ...

From: Eric Miao <eric.y.miao@gmail.com> According to commit 22eeef4bb2a7fd225089c0044060ed1fbf091958 kgdb,arm: Individual register get/set for arm It's now replaced by DBG_MAX_REG_NUM. Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> --- arch/arm/kernel/kgdb.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c index 778c2f7..d6e8b4d 100644 --- ...

- Most archs use one callchain buffer per cpu, except x86 that needs to deal with NMIs. Provide a default perf_callchain_buffer() implementation that x86 overrides. - Centralize all the kernel/user regs handling and invoke new arch handlers from there: perf_callchain_user() / perf_callchain_kernel() That avoid all the user_mode(), current->mm checks and so... - Invert some parameters in perf_callchain_*() helpers: entry to the left, regs to the right, following the traditional (src, ...

Now that software events don't have interrupt disabled anymore in the event path, callchains can nest on any context. So seperating nmi and others contexts in two buffers has become racy. Fix this by providing one buffer per nesting level. Given the size of the callchain entries (2040 bytes * 4), we now need to allocate them dynamically. v2: Fixed put_callchain_entry call after recursion. Fix the type of the recursion, it must be an array. v3: Use a manual per cpu allocation (temporary ...

Drop the TASK_RUNNING test on user tasks for callchains as this check doesn't seem to make any sense. Also remove the tests for !current that is not supposed to happen and current->pid as this should be handled at the generic level, with exclude_idle attribute. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Stephane ...

Hi, This set factorizes a lot of callchain code and fixes concurrent callchain buffers accesses. The previous set has revealed we can't decently use the per cpu allocation api for memory that can be accessed from NMI. Hence this temporary uses a manual per cpu allocation until that gets fixed up. Built-tested on PowerPc, Arm and SuperH (can someone point me to a ready to use sparc cross compiler, like those that can be found there for other archs: ...

Dave, This group of fixes is intended for 2.6.36. This includes a fix for a warning backtrace related to pm_qos in ipw2100, a packet injection oops for ath9k_htc, a connectivity regression for ath9k_htc related to HT capabilities handling, a scanning regression in wl1251, a firmware loading error in ath9k_htc, and a patch to disable L0s for all ath5k cards (causes misc wierdness). Please let me know if there are problems! Thanks, John --- The following changes since commit ...

Thanks, I'll put the cards to sleep and take them out later. -- Ondrej Zary --

I'm not going to have much time to look at your patches, and I definitely want to test them on the NetWinder to make sure we don't regress the primary platform that this driver is supporting. I should have more time to look at them in September. --

When an ORB was canceled (Command ORB i.e. SCSI request timed out, or Management ORB timed out), or there was a send error in the initial transaction, we missed to drop one of the ORB's references and thus leaked memory. Background: In total, we hold 3 references to each Operation Request Block: - 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb() respectively, - 1 for the duration of the write transaction to the ORB_Pointer or Management_Agent register of the ...

I'm currently monitoring file open and modification with inotify. The tool works perfectly went the file is modify by using a write system call. But now, I'm using the splice system call to benefit from the zero-copy mechanism. The files are perfectly modified, but inotify system call doesn't detect it. In the read_write.c file, the modification is signalled by calling "fsnotify_modify(...)" in the vfs_write function. In the file splice.c, the function is not called when a file is ...

Dear friend, I do hope my email meet you well, I am Sgt. Scott Brain a U.S. Army in Iraq . I write you this email to ask for your agreement to receive the sum of 20 Million dollars on our behalf. My partner and I need a good partner someone we can trust to actualize this venture. The money is from oil proceeds and legal. And we are transferring it via the safe passage of a diplomatic courier. If you agree, get yourself a deal by replying to:scottbrain46@yahoo.com.hk Once you receive ...

Hi, This is a trivial change to fix the cpu_khz value returned when running on a virtualized environment. We have seen instances when the cpu_khz value is off by couple of MHz's when running on VMware's platform on AMD hardware. -- Since the TSC frequency read from hypervisor is accurate for the guest, and since the hypervisor will always clock the vcpu at the TSC frequency, there is no need to calibrate it again. To avoid any calibration errors through calibrate_cpu this patch skips ...

Your mailbox has exceeded the storage limit which is 20GB as set by your administrator,you are currently running on 20.9GB,you may not be able to send or receive new mail until you re-validate your mailbox. To re-validate your mailbox please.Click Here http://mailupdateaccountonline.cogia.net/ --

Wonderful. I cherry-picked this and things seem to be working now, thanks. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) --

Hi, I just saw the following (twice, with a reboot in between) with kernel 2.6.35 plus firewire driver patched to their state in 2.6.36-rc1, i.e. basically with a kernel according to commit e78483c5. I suspect it might also happen without firewire patches, as 2.6.35 already contains the change where firewire-core's per-transaction timer was introduced which shows up in the following log. It happened while I was testing hotplugging of FireWire disks with several ones on a bus together with ...

It says the locks nest like: (&(shost->host_lock)->rlock){-.-...} (&t->split_timeout_timer){+.-...} ... ... So shost->host_lock->rlock is a lock used in hardirq context but split_timeout_timer is a !irq-safe lock. Which means that it now worries the following can happen: softirq: spin_lock(&t->split_timeout_timer); IRQ: spin_lock(&(shost->host_lock)->rlock); spin_lock(&t->split_timeout_timer); Now, the thing is that split_timeout_timer is a fake lock ...

Not a problem. It's just a pain trying to figure out where the file 'private_data' is being used. $ git grep private_data | wc -w 37272 $ git grep private_data include | wc -w 1068 The following struct's all have a 'void *private_data' symbol in include/linux: struct ac97_codec struct c2port_device struct file struct gendisk struct ata_host struct ata_queued_cmd struct ata_device struct ata_port struct ata_port_info struct parport struct rchan struct rtc_task struct ...

The symbol 'private_data' is commonly used and makes grep'ing for specific uses difficult. Introduce the wrapper functions file_get_privdata and file_set_privdata to help with the struct file uses. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Matthew Wilcox <matthew@wil.cx> --- diff --git a/include/linux/fs.h b/include/linux/fs.h index 9a96b4d..b357a17 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -961,6 +961,16 @@ extern spinlock_t files_lock; ...

(html damaged email alert) One thing you could try is something like the below on a freshly booted machine, once without and once with the patch: cd /usr/src/linux-2.6 echo 1 > /proc/sys/vm/drop_caches grep radix /proc/slabinfo make bzImage echo 1 > /proc/sys/vm/drop_caches grep radix /proc/slabinfo --

Ah, I through that was what it did. So you basically increase the memory footprint for tiny files.. have you done any measurements on that? --

I've had a quick look at this and the idea behind it is sound. While it does change the symantics as noted in the original post, the change is only in an error path and to my eye the error code should be returned in that case - as the code currently stands a 0 is returned even if ENOMEM has occurred. It seems to me that error and result have been (wrongly) used interchangedly within these two functions (possibly be different authors). I agree that one of them should be eliminated, and error ...

From: Arnaldo Carvalho de Melo <acme@redhat.com> As part of ongoing effort to reduce the coupling with libnewt, browsers are being changed to return the exit key. The annotate browser is not returning it as expected by builtin-annotate when annotating multiple symbols (when 'perf annotate' is called without specifying a symbol name). Fix it by returning the exit key and also adding the RIGHT key as a exit key so that going to the next symbol in the TUI can work again. Cc: Frederic ...

From: Arnaldo Carvalho de Melo <infradead.org> Hi Ingo, I extracted a fix from the three patch perf/core series I sent, will rework the other, non critical patches on a new perf/core branch. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf/urgent Regards, - Arnaldo Arnaldo Carvalho de Melo (1): perf annotate tui: Fix exit and RIGHT keys handling tools/perf/util/ui/browsers/annotate.c | 3 ++- 1 files changed, 2 insertions(+), 1 ...

Adding lockdep_off() is just plain wrong, if you cannot describe the locking there's a fair chance its wrong anyway. As it stands there's only a single lockdep_off(), and that lives in NTFS it looks like it could be annotated differently, but then, who cares about NTFS anyway ;-) --

nack! --

I see. I described the fine locking after Steven comment, adding a long Changelog. http://patchwork.ozlabs.org/patch/61827/ If someone thinks this locking is buggy, please speak now ;) --

Please read history of why RCU failed in this context. I believe I did most of RCU conversions in kernel, you dont need to shout on me. And its a bit late in 2.6.36 to even think about it. I am happy that you volunteer for next RCU conversion, thanks Peter ! In the mean time, we just are going to disable BH again, I'll post a patch. --

Hi, I hit this when booting 2.6.36-rc1: ================================= [ INFO: inconsistent lock state ] 2.6.36-rc1 #2937 --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ifup-eth/3288 [HC0[0]:SC1[2]:HE1:SE0] takes: (&(&lock->lock)->rlock){+.?...}, at: [<ffffffffa0166eef>] ip6t_do_table+0x8a/0x3f1 [ip6_tables] {SOFTIRQ-ON-W} state was registered at: [<ffffffff8107b08e>] __lock_acquire+0x756/0x93c [<ffffffff8107b374>] lock_acquire+0x100/0x12d ...

Urgh,.. I think it might be correct, but wtf! Wasn't this originally RCU code, why not go back to using RCU now that we have synchronize_rcu_expedited()? As to the original issue, why not keep that bh stuff disabled for CONFIG_PROVE_LOCKING instead, that will at least let you keep lock coverage, adding lockdep_off() will hide any cycles that would involve this lock (even though its currently a leaf lock, you never know what creative things the future brings). This fancy open coded lock ...

Hi, I was testing your VFS scaling tree*, but I get the following in my dmesg: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/exit.c:1387 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by bash/2878: #0: (tasklist_lock){.+.+..}, at: [<ffffffff8103a275>] ...

On the third try it will hopefully work. Vegard ---------- Forwarded message ---------- From: Vegard Nossum <vegard.nossum@gmail.com> Date: 16 August 2010 19:01 Subject: Re: 2.6.35+vfs-scale: INFO: suspicious rcu_dereference_check() usage (kernel/exit.c:1387) To: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, David Howells <dhowells@redhat.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, LKML <linux-kernel@vger.kernel.org> Nick Piggin might ...

The attached patch should fix this. David --- From: Daniel J Blueman <daniel.blueman@gmail.com> Subject: [PATCH] Fix unprotected access to task credentials in waitid() Using a program like the following: #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> int main() { id_t id; siginfo_t infop; pid_t res; id = fork(); if (id == 0) { sleep(1); exit(0); } kill(id, SIGSTOP); alarm(1); waitid(P_PID, id, &infop, ...

Hello, This patchset contains five patches to convert block drivers implementing REQ_HARDBARRIER to support REQ_FLUSH/FUA. 0001-block-loop-implement-REQ_FLUSH-FUA-support.patch 0002-virtio_blk-implement-REQ_FLUSH-FUA-support.patch 0003-lguest-replace-VIRTIO_F_BARRIER-support-with-VIRTIO_.patch 0004-md-implment-REQ_FLUSH-FUA-support.patch 0005-dm-implement-REQ_FLUSH-FUA-support.patch I'm fairly sure about conversions 0001-0003. 0004 should be okay although multipath wasn't ...

On Mon, Aug 16 2010 at 12:52pm -0400, What tree does this patch apply to? I know it doesn't apply to That logic wasn't just about retries (at least not in the latest kernel). With commit 708e929513502fb0 the -EOPNOTSUPP checking also serves to optimize the barrier+discard case (when discards aren't Can you expand on that TODO a bit? What is the mechanism to propagate FUA down to a DM device's members? I'm only aware of propagating member devices' features up to the top-level DM device's ...

I'm not sure it's worth it. The pure REQ_FLUSH path works not and is well tested with kvm/qemu. We can still easily add a FUA bit, and even a pre-flush bit if the protocol roundtrips matter in real life benchmarking. --

From: Tejun Heo <tj@kernle.org> This patch converts md to support REQ_FLUSH/FUA instead of now deprecated REQ_HARDBARRIER. In the core part (md.c), the following changes are notable. * Unlike REQ_HARDBARRIER, REQ_FLUSH/FUA don't interfere with processing of other requests and thus there is no reason to mark the queue congested while FLUSH/FUA is in progress. * REQ_FLUSH/FUA failures are final and its users don't need retry logic. Retry logic is removed. * Preflush needs to be ...

Could you redo this for the latest git? (Sorry, I recently made the problem slightly worse by adding another "err = -ENOMEM;")... regards, dan carpenter --

From: Julia Lawall <julia@diku.dk> The error code is stored in the variable err, but it is the variable ret that is returned instead. So store the error code in ret. Err is then useless. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia ...

From: Julia Lawall <julia@diku.dk> An error code is stored in the variable error, but it is the variable result that is returned instead. So store the error code in result. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall ...

From: Julia Lawall <julia@diku.dk> Error codes are stored in err, but the return value is always 0. Return err instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- This changes the semantics of the ...

From: Julia Lawall <julia@diku.dk> An error code is stored in ret, but the return value is always 0. Return ret instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- This changes the semantics of the ...

From: Julia Lawall <julia@diku.dk> Error codes are stored in ret, but the return value is always 0. Return ret instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- This changes the semantics and has not ...

From: Julia Lawall <julia@diku.dk> Error codes are stored in err, but the return value is always 0. Return err instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- This changes the semantics and has not ...

From: Julia Lawall <julia@diku.dk> In each case, error codes are stored in rc, but the return value is always 0. Return rc instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- The changes change the ...

From: Julia Lawall <julia@diku.dk> Error codes are stored in res, but the return value is always 0. Return res instead. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ local idexpression x; constant C; @@ if (...) { ... x = -C ... when != x ( return <+...x...+>; | return NULL; | return; | * return ...; ) } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- This changes the semantics and has not ...

Thanks, looks correct to me. Acked-by: Kalle Valo <kvalo@adurom.com> Kalle --

Subject: firewire: net: fix unicast reception RCODE in failure paths The incoming request hander fwnet_receive_packet() expects subsequent datagram handling code to return non-zero on errors. However, almost none of the failure paths did so. Fix them all. (This error reporting is used to send and RCODE_CONFLICT_ERROR to the sender node in such failure cases. Two modes of failure exist: Out of memory, or firewire-net is unaware of any peer node to which a fragment or an ARP packet belongs. ...

Hi Linus, I know it's post RC1, but these are a couple of potential (if unlikely) crash fixers, patches to enable rfkill control on a single model of Dell and some Thinkpad updates that are effectively noops on current hardware but improve support for machines that aren't out yet. Nothing heartbreaking if it has to wait for .37. The following changes since commit da5cabf80e2433131bf0ed8993abc0f7ea618c73: Linux 2.6.36-rc1 (2010-08-15 17:41:37 -0700) are available in the git ...

no-kvmclock kernel parameter is missing its explanation in Documentation/kernel-parameters.txt. Add it. Signed-off-by: Jiri Kosina <jkosina@suse.cz> --- Documentation/kernel-parameters.txt | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..0f9e299 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1693,6 +1693,8 @@ and is between 256 ...

On Mon, Aug 16 2010 at 10:52am -0400, Maybe we should look to export elevator_switch() -- rather than elevator_exit() triggers a call, via kobj, to elevator_release() which doesn't have access to the request_queue to reset it. Unfortunately, commit 1abec4fdbb imposes that the elevator_exit() caller must take care to reset q->elevator to NULL -- like dasd_alloc_queue() does. Right, updating drivers/block/mg_disk.c and drivers/s390/block/dasd.c to use elevator_switch would ...

Dear All, Peter has worked hard to release LCOV-1.9 for you. Please pick your copies directly from: https://sourceforge.net/projects/ltp/files/Coverage% 20Analysis/LCOV-1.9/lcov-1.9.tar.gz/download, https://sourceforge.net/projects/ltp/files/Coverage% 20Analysis/LCOV-1.9/lcov-1.9-1.src.rpm/download, https://sourceforge.net/projects/ltp/files/Coverage% 20Analysis/LCOV-1.9/lcov-1.9-1.noarch.rpm/download or ...

Make special HID devices' Kconfig names unambiguous, obviating the need to enter the help menu of each driver in order to know what hardware device it actually supports. Cc: Jiri Kosina <jkosina@suse.cz> Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Stephane Chatty <chatty@enac.fr> Cc: Don Prince <dhprince-devel@yahoo.co.uk> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> --- drivers/hid/Kconfig | 60 ...

Commit 74450be1 (block: unify flags for struct bio and struct request) incorrectly converted @do_sync in md raid1 and raid10 make_requst() functions. @do_sync is now supposed to carry the actual flag bit and directly OR'd into bio->bi_rw but is still a bool and thus carries either 0 or 1 instead of the actual flag bit. This makes REQ_SYNC ignored on writes and flips the direction of READ_SYNCs to WRITEs. Fix it by making @do_sync unsigned integers. Signed-off-by: Tejun Heo ...

Eric, The first patch is a bit of fundamental. I'm afraid that modify it would bring changes to all latter patches in this series... So I think I would repost another round of updating patch series and hope that would be merged. How do you think about this? Thanks, Lei -----Original Message----- From: Eric Miao [mailto:eric.y.miao@gmail.com] Sent: 2010年8月16日 21:55 To: David Woodhouse Cc: Haojian Zhuang; Lei Wen; Axel Lin; linux-kernel; linux-mtd@lists.infradead.org Subject: Re: ...

Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp> --- drivers/media/video/cx23885/cx23885.h | 62 +++++++++++++++++---------------- 1 files changed, 32 insertions(+), 30 deletions(-) diff --git a/drivers/media/video/cx23885/cx23885.h b/drivers/media/video/cx23885/cx23885.h index ed94b17..55dc282 100644 --- a/drivers/media/video/cx23885/cx23885.h +++ b/drivers/media/video/cx23885/cx23885.h @@ -54,36 +54,38 @@ #define BUFFER_TIMEOUT (HZ) /* 0.5 seconds */ -#define ...

DASH doesn't support brace expansion. Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp> --- tools/perf/Makefile | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 41abb90..8fa851b 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -157,8 +157,10 @@ all:: # # Define NO_DWARF if you do not want debug-info analysis feature at all. -$(shell sh -c 'mkdir -p ...

I really hate these second rate shells, but I guess we could do this on --

Ok, I guess this one is OK :-) Will merge. --

One (obvious) alternative is to have rules triggering on the Hmm, I'm not a "perf person". Which are the sufficient use-cases/tests that one can do to play around with the Makefile? `make -C tools/perf` is probably not enough. Any hints anyone? Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at --

Em Mon, Aug 16, 2010 at 09:40:13PM +0900, Kusanagi Kouichi escreveu: Please read: f9af3a4c1f59753bdd5a49e3a34263005f96972e 8b2c551f9635bf1c5c2d38de300137998915478f 1703f2c321a8a531c393e137a82602e16c6061cb To see why we can't use '-o /dev/null' like that. - Arnaldo --

Still the same - no files. dmesg contains: ISOFS: Invalid session number or type of track ISOFS: Invalid session number ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A -- Ondrej Zary --

Maybe it's a multi-session disk where the first session is HFS with Apple software. Try mounting with -t iso9660 -o session=1. HTH Johannes --

Hi Axel, I suggest not merge your patch into mainline code. Since I have a large series of patch which reconstruct the nand flash definition, this fix would no longer be needed. Thanks, Lei -----Original Message----- From: Eric Miao [mailto:eric.y.miao@gmail.com] Sent: 2010年8月16日 20:22 To: Axel Lin Cc: linux-kernel; David Woodhouse; linux-mtd@lists.infradead.org; Lei Wen; Haojian Zhuang Subject: Re: [PATCH] [MTD] [NAND] pxa3xx: fix timing and cmdset for samsung2GbX8 Cc'ed Lei and ...

[Empty message]

I've actually reviewed some of the patches and gave my Ack. For those patches, I think they can be merged early. And overall, they look good. Yet 29 patch in a whole is still a bit too much, would be good to see them logically be separated into several --

You won $950,000.00USD and a brand New BMW X6 car. courtesy DELPHI ELECTRICAL COMPANY. Send your NAMES, Tel:, Occupation: Age:, Sex:, ADDRESS and Country to Name: Dr.Craig Mordred Email: agent.craigmordred@yahoo.com.hk Tel: +447045703812 Signed, Mr. Lee Young (Sec.) --

Now and again there has been talk on the netdev list of adding PTP support into Linux. One part of the picture is already in place, the SO_TIMESTAMPING API for hardware time stamping. This patch set offers the missing second part needed for complete IEEE 1588 support. * Why all the CCs? 1. IMHO, the patches should go through netdev. 2. A reviewer on netdev said, this should appear on lkml. 3. One driver is for PowerPC, and adds device tree stuff. 4. One driver is for the ARM Xscale ...

The eTSEC includes a PTP clock with quite a few features. This patch adds support for the basic clock adjustment functions, plus two external time stamps and one alarm. Signed-off-by: Richard Cochran <richard.cochran@omicron.at> --- Documentation/powerpc/dts-bindings/fsl/tsec.txt | 57 +++ arch/powerpc/boot/dts/mpc8313erdb.dts | 14 + arch/powerpc/boot/dts/mpc8572ds.dts | 14 + arch/powerpc/boot/dts/p2020ds.dts | 14 + ...

This patch adds support for the PTP clock found on the DP83640. The basic clock operations and one external time stamp have been implemented. Signed-off-by: Richard Cochran <richard.cochran@omicron.at> --- drivers/net/phy/Kconfig | 29 ++ drivers/net/phy/Makefile | 1 + drivers/net/phy/dp83640.c | 904 +++++++++++++++++++++++++++++++++++++++++ drivers/net/phy/dp83640_reg.h | 261 ++++++++++++ 4 files changed, 1195 insertions(+), 0 deletions(-) create mode 100644 ...

This PTP clock simply uses the NTP time adjustment system calls. The driver can be used in systems that lack a special hardware PTP clock. Signed-off-by: Richard Cochran <richard.cochran@omicron.at> --- drivers/ptp/Kconfig | 12 ++++ drivers/ptp/Makefile | 1 + drivers/ptp/ptp_linux.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++ kernel/time/ntp.c | 2 + 4 files changed, 151 insertions(+), 0 deletions(-) create mode 100644 drivers/ptp/ptp_linux.c diff --git ...

And maybe just to clarify, as I saw your response to Arnd, I'm not suggesting using PTP clocks as clocksources for the internal timekeeping core. Instead I'm trying to understand why PTP clocks need the equivalent of the existing posix clocks/timer interface. Why would only having a read-time interface not suffice? thanks -john --

On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran Hey Richard! Its very cool to see this work on lkml! I'm excited to see more work done on ptp. We had a short private thread discussion earlier (I got busy and never replied to your last message, my apologies!), but I wanted to bring up the concerns I have here as well. As I mentioned earlier, I'm not a huge fan of the char device interface for abstracted PTP clocks. If it was just the direct hardware access, similar to RTC, which ...

Thanks! --

That would be elegant... The driver will have to detect that the sglist is chained like an ouroboros to program the DMAC apropriately, is is easy to detect if an sglist is chained onto itself? Yours, Linus Walleij --

This patch adds support for the Freescale i.MX SDMA engine. The SDMA engine is a scatter/gather DMA engine which is implemented as a seperate coprocessor. SDMA needs its own firmware which is requested using the standard request_firmware mechanism. The firmware has different entry points for each peripheral type, so drivers have to pass the peripheral type to the DMA engine which in turn picks the correct firmware entry point from a table contained in the firmware image itself. The original ...

Hi, Why not implement this feature using cyclic SG lists (created with sg_chain())? This would give you endless DMA transfers without any special DMA API extensions. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | ...

Hi Linus, Thank you for the review. Sorry for so many trival mistakes in the code, but I'm staring at this code in many different variants for some time now and I'm getting blind on it. Unfortunately the specs are not open, so we are sticked to the binary microcode from Freescale. I'm pretty sure though that the SDMA engine Yes, I left this as an exercise for those who want to have this feature ;) I think it's better to have tested code in the Kernel than having a complicated list ...

Cyclic transfers are useful for audio where a single buffer divided in periods has to be transfered endlessly until stopped. After being prepared the transfer is started using the dma_async_descriptor->tx_submit function. dma_async_descriptor->callback is called after each period. The transfer is stopped using the DMA_TERMINATE_ALL callback. While being used for cyclic transfers the channel cannot be used for other transfer types. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Cc: ...

Hi, please review the approach, I can't test it due to lack of hw (btw Ming, if you have some spare minutes -- mind to pass some event as RAW and see how it goes?). It just unifdef perf_event_p4.h and export it to user space. Any complains are welcome. I've considered a separate header file without #ifdef which would consists of definitions user space may need but in result it become more messy then a few #ifdefs in shared header. -- Cyrill --- perf, x86: Export RAW events ...

It doesn't like pattern and explicit rules to be on the same line, and it seems to be more picky when matching file (or really directory) names with different numbers of trailing slashes. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- firmware/Makefile | 2 +- scripts/mkmakefile | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) --- linux-2.6.36-rc1/firmware/Makefile +++ 2.6.36-rc1-make-3.82-fixes/firmware/Makefile @@ -142,7 +142,7 @@ fw-shipped-$(CONFIG_YAM) += ...

I can confirm that the patch fixes the problem, I can compile the kernel with make-3.82. Many thanks. Andy --

Hi all, While compiling the kvm linux kernel on my ubuntu 10.04(Linux xxxx-laptop 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux), the  err below appear, How to figure out please? =err msg= In file included from drivers/platform/x86/intel_ scu_ipc.c:26: kvm/arch/x86/include/asm/mrst.h:14: warning: ‘struct sfi_table_header’ declared inside parameter list kvm/arch/x86/include/asm/mrst.h:14: warning: its scope is only this definition or declaration, which is ...

get_counters() is serialized by the xt_find_table_lock() done from get_entries(). This use a mutex to guard against changes. You are right that if we ever allow two concurrent "iptables -nvL" operations in the future (using a read lock on a rwlock instead of a mutex), then we must disable BH even for summing data from the other cpus. Thanks --

Hi Linus, please consider pulling from: git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next ...to receive one more driver that was originally posted well in advance of this window. I had some review comments that were duly resolved, but I did not handle this updated version in a timely manner. I would prefer that this driver not wait for 2.6.37 as it was prepared in time for this window. Two other fixlets are also included. None of this has seen a -next release, but ...

Cc'ed Lei and Haojian. --

Commit 22ae782f86b726f9cea752c0f269ff6dcdf2f6e1 anccidentaly removed linux/of_address.h header. Signed-off-by: Michal Simek <monstr@monstr.eu> --- arch/microblaze/include/asm/prom.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h index 5012b22..66894b5 100644 --- a/arch/microblaze/include/asm/prom.h +++ b/arch/microblaze/include/asm/prom.h @@ -22,7 +22,6 @@ #include <linux/types.h> ...

Commit dbbdee94734bf6f1db7af42008a53655e77cab8f removed of_irq_pci_swizzle but didn't use pci_swizzle_interrupt_pin instead. Signed-off-by: Michal Simek <monstr@monstr.eu> --- arch/microblaze/kernel/prom_parse.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c index d33ba17..99d9b61 100644 --- a/arch/microblaze/kernel/prom_parse.c +++ b/arch/microblaze/kernel/prom_parse.c @@ -73,7 +73,7 @@ ...

Hi Michal, Looks good, I'll pick it up. Same of the of_node patch. Note: when writing commit messages, be friendly to readers who don't immediately have access to a git tree. It is good to quote the sha1 id, but you should also quote the patch title like so: Commit "of/address: Merge all of the bus translation code" (sha1 id: dbbdee94734bf6f1db7af42008a53655e77cab8f) removed of_irq_pci_swizzle but didn't use pci_swizzle_interrupt_pin instead. No need to respin this patch, I'll fix it ...

Hi all, please be not too hard on me with this patch. it is my first one. at least give me input what needs to be better. thanks in advance Stephan From: Stephan Sperber <sperberstephan@googlemail.com> Date: Wed, 14 Jul 2010 11:23:08 +0200 Subject: [PATCH] Kconfig: deleted a word which apeared twice Deleted a word which apeared twice. Signed-off-by: Stephan Sperber <sperberstephan@googlemail.com> --- init/Kconfig | 2 +- usr/Kconfig | 2 +- 2 files changed, 2 insertions(+), ...

Typo, i.e., missing comma in argument list of call of do_osf_statfs(), was introduced by commit ebabe9a9001af0af56c0c2780ca1576246e7a74b. Signed-off-by: Michael Cree <mcree@orcon.net.nz> --- arch/alpha/kernel/osf_sys.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c index fb58150..5d1e6d6 100644 --- a/arch/alpha/kernel/osf_sys.c +++ b/arch/alpha/kernel/osf_sys.c @@ -252,7 +252,7 @@ ...

Yes, see my patch series http://lkml.org/lkml/2010/7/9/96 reworking the pmu interface. After that and some patches adding per pmu contexts adding multiple hardware pmus should be simple. uncore should not share any code with the regular pmu, since they're mostly unrelated. --

I didn't see the per pmu contexts patches, are you still working on But should they share code like collect_events, schedule_events, x86_perf_event_set_period(with some modification) etc...? --

Hi, all Here multiple x86 hw pmus means, for example, Intel "core" and "uncore" pmu. "core" pmu is to collect per cpu data, cpu-cycles, branch-misses, etc. "uncore" pmu is to collect per package data, L3 cache, Intel QPI, integrated memory controller, etc. I am going to add Intel uncore pmu support to perf. To reduce code duplicate, "uncore" pmu should reuse most of the "core" pmu code. But currently, the x86 core pmu code(arch/x86/kernel/cpu/perf_event.c) only supports one pmu, with a ...

Acked-by: Rusty Russell <rusty@rustcorp.com.au> Thanks, Rusty. --

Looks sane to me; thanks. Wants to go to stable@ too, yes? Can I have an Acked-By: from Matt and/or Eric? -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

Acked-by: Eric Miao <eric.y.miao@gmail.com> --

Hi Tejun, Thanks for the quick response. OK, let me find other ways ocfs2 can use to trace the real callers of some functions in runtime. Regards, Tao --

Now in CMWQ, workqueue threads are named as 'kworker/*'. So it is a little boring to see in the 'top'(below) and actually it isn't meaningful for the users. 12606 root 20 0 0 0 0 S 2 0.0 0:03.22 kworker/u:0 12607 root 20 0 0 0 0 S 1 0.0 0:03.69 kworker/u:4 So this patch just try to set the proper workqueue name if it does exist. Yes, workqueue now is a thread pool and the data may be not accurate but I think it is better(below) than the 'kworker*' ...

Apparently this breaks NFS file locks as well: fetchmail: starting fetchmail 6.3.17 daemon /home/nbowler/.fetchmail.pid: Bad file descriptor and this fixes all the problems for me. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) --

[Added linux-nfs to Cc] At Mon, 16 Aug 2010 15:06:26 +0800, This hits me, too. Reverting it cures the problem. (BTW, the correct commit id of the affecting patch is af7fa16506bf9b6323e862a61e14c20555152bb3 "NFS: Fix up the fsync code") Reproduced on 2.6.36-rc1. Looking at strace output, open("afo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 write(4, "#!/bin\n", 7) = 7 fsync(4) = 1 stat("afo", {st_mode=S_IFREG|0644, st_size=7, ...}) ...

NFS client runs latest git. At client side, use vim to edit a file located at NFS server. If I save the file, vim always reports 'E667: Fsync failed'. If I revert f7fa16506bf9b6323e862a61e14c20555152bb3, vim works. No kernel errors reported. Thanks, Shaohua --

Good news! Good news! Xen pv-ops dom0 is finally just starting to get merged into upstream Linux... Starting with Linux 2.6.36.... Yours sincerely, Mr. Teo En Ming (Zhang Enming) Citizenship: Singapore Citizen/Singaporean Facebook account: Teo En Ming (Zhang Enming) Facebook link:http://www.facebook.com/profile.php?id=100000750083982 Facebook photos: http://www.facebook.com/profile.php?id=100000750083982#!/profile.php?id=100000750083982&v=photos ...

Hi all, As the merge window has closed, let the flood commence. :-) Changes since 20100813: New tree; florian-viafb My fixes tree contains: spi: update for of_device to platform_device replacement The sh tree gained a conflict against Linus' tree. The ocfs2 tree lost its conflict. The v4l-dvb tree lost its conflicts. The acpi tree lost its build failure. The rr tree lost its conflicts. The alacrity tree gained a conflict against Linus' tree. The spi tree lost its ...

When the total dirty pages exceed vm_dirty_ratio, the dirtier is made to do the writeback. But this dirtier may not be the one who took the system to this state. Instead, if we can track the dirty count per-file, we could throttle the dirtier of a file, when the file's dirty pages exceed a certain limit. Even though this dirtier may not be the one who dirtied the other pages of this file, it is fair to throttle this process, as it uses that file. This patch 1. Adds dirty page accounting ...

I agree with your problem description, a single program which writes a single large file can make an interactive system suck. Creating a 25+GB Blu-Ray image will often saturate the buffer space. I played with per-fd limiting during 2.5.xx development and I had an app writing 5-10GB files. While I wanted to get I found that the effect was about the same as forcing the application to use O_DIRECT, and since it was our application I could do that. Not all badly-behaved programs are open source, ...

Hi Paul, Today's linux-next merge of the sh tree got a conflict in arch/sh/include/asm/Kbuild between commit bf56fba6703592149e1bcd19220c60eb42dff9b7 ("archs: replace unifdef-y with header-y") from Linus' tree and commit da28c597996a964a195529595c37f7aacd6dad09 ("sh: split out ptrace header for _32/_64 variants") from the sh tree. I fixed it up (see below) and can carry the fix for a while. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc ...

How precise does the timing have to be? I think i2c is self-clocking, so it's ok to see big skews? Becuase msleep() can be off by quite a bit (mdelay can too, but it's _way_ more rare, and requires either a Sure. That results in a truncated dmesg (with a 128k buffer). The thing seems to spew out something every ten seconds: ... [ 232.610044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B (SDVO_CMD_GET_ATTACHED_DISPLAYS) [ 232.624504] [drm:intel_sdvo_debug_response], SDVOB: ...

You might be hitting the infamous hotplug storm [1]. The symptoms vary by kernel version. 2.6.34 and before: udevadm --monitor shows craploads of events and, as long as X is running, X keeps reprobing the outputs which (depending on the particular bug) can suck cpu in the i2c code or cause more hotplug events. It also makes X oddly laggy. 2.6.35 and newer: The kernel is smart enough to probe outputs itself before telling X, so the events never hit userspace. But things still can ...

I started wondering why 'top' was showing an otherwise idle system as having a load average of 0.5+, and worker threads constantly using the CPU. So I did a system-wide profile, and got the attached output (look at it in a really wide terminal). There seems to be something _seriously_ wrong with i915 SDVO detect. This is on an Apple Mac Mini (hey, your favorite problem child!), and apparently it spends 20% of its non-idle CPU time just doing udelay's for the i2c SDVO connection ...

Hmm. I don't think it's a storm. The drm.debug=4 thing shows things just every 10 seconds. That seems pretty controlled. Of course, it seems to be several milliseconds worth of work then, so My version of intel-gpu-tools must be old (fedora 12). It has intel_gpu_dump and intel_reg_write and some other apps, but not the bios-dumper/reader. # intel_reg_write 0x61110 0x0 Value before: 0x4000220 Value after: 0x0 but it doesn't seem to change any behavior. Still that sdvo ...

We need to call hwmon_device_unregister() if an error is detected after sucessfully register hwmon device. Signed-off-by: Axel Lin <axel.lin@gmail.com> --- drivers/hwmon/ads7871.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/hwmon/ads7871.c b/drivers/hwmon/ads7871.c index b300a20..303db92 100644 --- a/drivers/hwmon/ads7871.c +++ b/drivers/hwmon/ads7871.c @@ -201,11 +201,13 @@ static int __devinit ads7871_probe(struct spi_device *spi) we need to ...

Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

--

That code compiled OK in -mm which includes linux-next. I assume that some last-minute merging broke things. --

Acked-by: Arnd Bergmann <arnd@arndb.de> --

On Mon, Aug 16, 2010 at 1:58 AM, Linus Torvalds That's fine. I havn't consider gcc optimization. --

On Mon, Aug 16, 2010 at 12:41 PM, Jeff Garzik <jgarzik@pobox.com> wrote: SMART Info/Logs are meta data and as you noted unchanged. Two other meta-data PIO commands I can think of: o FW update: I'm not going to risk bricking this drive to find that out. o Vendor specific selftest/diagnostic commands (I don't know if any exist - just a guess) If someone from Hitachi cares to respond publicly regarding the behavior of this "Engineering Sample", that would be appreciated and helpful. But ...

Merged, thanks. -- Matthew Garrett | mjg59@srcf.ucam.org --

This I do not know. Can You help me? Regards, Piotr Hosowicz -- "[Oleksy] dotknął naszych domów, naszych żon, naszych dzieci, naszych psów, naszych ŚWINEK MORSKICH, on po prostu wkroczył swoim głupim gadaniem w sferę prywatną, która musi być chro- niona dla dobra każdego z nas" - powiedział Kwaśniewski. NP: Patrick O'Hearn - Night Becomes Her NB: 2.6.35-git16 --

Just fix your driver code to no longer rely on the big kernel lock and then make it use the unlocked_ioctl operation. Arnd --

Thinking a bit more I guess there might be a sence to write io-apic id unconditionally, io-apic id is not latched on reset but set to 0 (at least for old apics) so if we hit id match -- this will be once, but the same time we will have additional if() for every cycle iteration, not sure it worth it. Right? -- Cyrill --

Applied, thanks. -- Jiri Kosina SUSE Labs, Novell Inc. --

cool... there's another web address that I can send to you, but need to look through and find the original e-mail first before... Justin P. Mattock --

On Sat, Aug 14, 2010 at 6:02 AM, Mathieu Lacage Applied, thanks. -- Dan --

Wel, I did some tests. I tried to get same conditions (what is not as easy). I will show here some results, which seem to be typical to me. downstream ========== netperf -t TCP_SENDFILE -H client TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to client port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.36 ...

Good, looks like hw crypto is working then ... Helmut --

Pulled, thanks a lot Steve! Ingo --

Right, but I think it doesn't need to, as its never accessed cross CPU (except maybe for /proc/sched_debug, and who cares about that). The (other) odd case is NO_HZ idle balancing, but there the actual CPU won't be updating the fields, so the remote CPU doing NO_HZ idle Right, except it breaks things a bit, at the very least you really need that update right before reading it, otherwise you can end up with >100% fractions, which are odd indeed ;-) --

There is no guarantee that the original cpu won't be doing this in with the patch, the update always happens before reading it. isn't it? update now happens during the scheduler tick (or during nohz load balancing tick). And the load balancer gets triggered with the tick. So the update (at the tick) should happen before reading it (used by load balancing triggered by the tick). Am I missing something? thanks, suresh --

hmm, true, but I thought I saw some load balancing code which was depending on SCHED_LOAD_SCALE value. Ignore this for now. Will get back to you if this indeed is a problem. thanks, suresh --

We run the load-balancer in softirq context, on -rt that's a task, and we could have ran other (more important) RT tasks between the hardirq and the softirq running, which would increase the rt_avg and could thus result in >100%. But I think we can simply retain the sched_avg_update(rq) in sched_rt_avg_update(), that is ran with rq->lock held and should be enough to avoid that case. We can retain the other bit of you patch, moving sched_avg_update() from scale_rt_power() to ...

No, it should not be dynamic; rather we should unify all the users who need a 1:1 map and just keep that page table set around. -- Sent from my mobile phone. Please pardon any lack of formatting. --

I proposed something similar to this for ia64 at one point to solve the problem of kexecing to Xen - which at that time mapped EFI to a different location to Linux. As I recall, the idea was shot-down by SGI Altix people on the basis potential performance problems. I don't recall any reasons more specific than that being given (and to be honest I was less than happy about it at the time). In the end I moved EFI in Xen to match Linux and have been able to ignore the problem ever since. ...

For the 1:1 map we probably should make all pages executable; other things need it too, but we shouldn't have it mapped in except when needed. -- Sent from my mobile phone. Please pardon any lack of formatting. --

Unfortunately I don't have a machine to test. The machine I'm using does not support EFI on x86_32:-( I'd appreciate it if anyone try it... Thanks, --

Copy/paste error, sorry. advmss 1440, and no "unreachable" Complete (correct) line: 2a00:800:752:1::5c:0/112 dev eth0 proto kernel metric 256 mtu 1500 advmss Yes, that's where the "unreachable" belonged. unreachable 2a00:800:1000:64::1 dev lo proto kernel metric 256 error -101 mtu 1500 advmss 1440 hoplimit 4294967295 Am I not allowed to add addresses to lo? That I've deconfigured this But at first it works perfectly, and then it doesn't work at all. The link is ~idle ...

I'm not using module. It's all built-in to the kernel. Hopefully this would be taken care of as well. That's why I had it in rc.S just before the lvm filesystems are mounted. Thanks, Jeff. --

The latest LVM package made an assumption that it would be set up correctly by udev (or manually in your case). We are updating the userspace libdevmapper code to handle your circumstances For those interested, originally we used mlockall() but in non-C locales on some distributions glibc is configured to map 80MB+ of locale data into memory without offering any way to unmap it. We don't need that data locked and it increased the minimum memory required to install a distribution as well as ...

The whole point of this change was to trigger the loading of dm-mod automatically for people using it as a module, based on using a known major/minor number instead of a dynamic one only known after the module has been loaded. That needs to happen regardless of whether someone is using udev or not. This can all be fixed easily enough in userspace. Alasdair --

Correct. EM extensions exist since v1.3. But implementation before Gen2 switches relied on proprietary device specific mechanism (tsi57x). Addition of Gen2 switches just pushed forward the standard implementation. The RIO standard methods may be used on 1.3 switches (tested on tsi57x) as well as the standard routing table operations that have been added Alex. --

I am not quite sure what the point is of this patch. What do you need to Do you mean if port-writes are dropped? Then they did not reach you in the first place. If a link in between is broken, the associated switch will 'complain' and send port-writes, no? Micha --

Perhaps this whole part of operating the MNT_RSP registers (sending link-request symbol is the only useful action IIRC?) can be put in a separate function for readability. Micha --

This is not 'Gen2' specific, as these error management extensions also exist in v1.2/1.3 (?) of the specification? E.g. tsi56x and tsi57x could support this functionality? Micha --

Why not make a sw_sysfs_create and sw_sysfs_remove? Is better for readability. Now you call 'sw_sysfs(dev, 0)' or 'sw_sysfs(dev, 1)'; Micha --

I was on the fence with this one. Now I have an extra vote in favor of a separate function ;) Will do. --

Yes. Because end-points should not have the "routes" attribute at all I assume that your question was "Why do not make it separate?" Both changes are specific to switches, both address sysfs and both are not big enough to justify a separate patch. I agree that make separate patches would give more clarity, so would do better description. Because there are changes that should be made to other patches in this I just do not want to have an extra member here. Not every switch will require own ...

Why not keep using the swpinfo field, as you can extract it from there? And your code actually does this. Also processor devices can have multiple ports (not only switches), it would be good to be ready for that use case. Micha --

Hello, For those who care: http://mid.gmane.org/1281691473-15481-1-git-send-email-u.kleine-koenig@pengutronix.de Kgene, do you care to ack this change as it may prod akpm in taking the fix a bit earlier? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --

or this one from earlier: http://lkml.org/lkml/2010/8/12/207 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

I don't recall any requirement to have preemption disabled when using those functions. It seems sensible to put it in the touch_{softlockup|nmi}_watchdog code. I assume the reason for having preemption disabled when using smp_processor_id() is that the code could migrate to another cpu when rescheduled? I don't see a problem with the patch, but my low level understanding of the __get_cpu_var vs. per_cpu isn't very strong. Cheers, --

Which could mean two things, either ACPI got funny on us, or Don's new These other two really are about assumptions we make on the call sites, which at the very least are violated by ACPI. Don/Ingo, remember if we require touch_*_watchdog callers to have preemption disabled? Or is the proposed patch sensible? --

Isn't that implicit? I mean the caller of touch_{softlockup|nmi}_watchdog I don't think so. Such as: ... preempt_disable() <===A touch_{softlockup|nmi}_watchdog <===B preempt_enable() <===C ... You just scroll A and C into B, but what will happen before preempt If the migration could happen, then we could touch the wrong cpu-data, Maybe we should use __raw_get_cpu_var() instead. Thanks, Yong --

Fix: acpi_os_stall calls touch_nmi_watchdog and touch_softlockup_watchdog with preemption enabled causing 'BUG: using smp_processor_id() in preemptible code'. Patch also removes double smp_processor_id call (smp_processor_id itself and in __get_cpu_var) in __touch_watchdog. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> --- diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 613bc1f..8822f1e 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -116,13 ...

Hello Igor, I assume this is an Ack? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --

Hi, sorry for the delay in answering; FROM: Xiaofan Chen [mailto:xiaofanc@gmail.com] SENT: vrijdag 13 augustus 2010 15:32 TO: Dries Van Puymbroeck CC: linux-usb@vger.kernel.org; Greg KH; Michał Nazarewicz; Michał Nazarewicz; Dries Van Puymbroeck; linux-kernel@vger.kernel.org This is actually what I based my INF file on. Maybe I should mention that in the comments in the INF? FROM: Xiaofan Chen [mailto:xiaofanc@gmail.com] SENT: zaterdag 14 augustus 2010 3:28 TO: Michal ...

Your changelog fails to mention how you fixed it.. It also reminds me how much I hate that height hack, I really should get path-compression working some day... http://programming.kicks-ass.net/kernel-patches/concurrent-pagecache/23-rc1-rt/radix-t... --

From: Eric Dumazet <eric.dumazet@gmail.com> I'm hesistent to say that we should put this kind of patch in. It will shut up lockdep for this specific case, but it also means that if we do any other kinds of locking in this sequence we will not validate it. The valuable of this is open for debate I guess. But locking is hard so I would say that disabling lockdep to kill a warning it generates should be an absolute last resort. I also don't think making the locking mechanics conditional ...

Hmm, maybe just disable BH, not for whole duration, but for each cpu. Its a bit late here and I prefer to close this problem before whole earth shout on me. Thanks [PATCH] netfilter: {ip,ip6,arp}_tables: avoid lockdep false positive After commit 24b36f019 (netfilter: {ip,ip6,arp}_tables: dont block bottom half more than necessary), lockdep can raise a warning because we attempt to lock a spinlock with BH enabled, while the same lock is usually locked by another cpu in a softirq ...

http://lkml.org/lkml/2009/8/18/169 More information in this thread: http://lkml.org/lkml/2009/8/20/190 --

Not that I´m as "valuable" as the others quoted above: I have the same That basically sums it up as far as I see. Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at --

Feel free to add my ack. -- Sent from my mobile phone. Please pardon any lack of formatting. --

Hello, Valdis! Interesting! My first thought was that this is a false positive, given that lockdep_is_held(&task_rq(p)->lock) is one of the arguments to task_subsys_state_check() and thus to rcu_dereference_check(). However... Given the "lockdep: fixing up alternatives" above, we know that cpu==1, and that the code is running on CPU 0. So init_idle() acquires the specified CPU's runqueue lock: struct rq *rq = cpu_rq(cpu); ... raw_spin_lock_irqsave(&rq->lock, flags); Then ...

--

In general, I've resisted the urge to correct grammar. Comments below. 'seeky' is not a property of the media. I think you meant on storage I'm not sure we need documentation of this tunable twice. Why not just give guidance on when it should be set to 0 in the next section supported. Looks like something is amiss. Your text was truncated somewhere. Cheers, Jeff --

Thanks. As I haven't found the patch in linux-next as of today, I'll be taking it through trivial queue. -- Jiri Kosina SUSE Labs, Novell Inc. --

Hmm... To me this seems like a really painful implementation of what the OpenFirmware-esque "Flattened Device Tree" does on many embedded systems. For example, to build an equivalent device tree using an OpenFirmware FDT file, I'd just use this: /dts-v1/; / { #address-cells = <1>; #size-cells = <1>; [...snip...] soc-bus-1@fc000000 { /* of_platform driver matches against this: */ compatible = "my-company-name,soc-bus-type"; /* Define base address and size of the bus ...

Yes, this makes sense. Originally, I was trying to avoid this due to a misguided notion of backwards compatibility - namely that devices could register themselves conditionally via .bus = HAVE_FOO_BUS, and always call the same platform_[device|driver]_register, but thinking about this more, such a compile (or run)-time decision can just as easily be made in the foo_[device|driver]_register. The impact on legacy code is the same either way, but your suggested interface is much ...

Actually you can do: const struct dev_pm_ops test = { DEFAULT_PLATFORM_PM_OPS, .prepare = my_func, ... }; where: #define DEFAULT_PLATFORM_PM_OPS \ .prepare = platform_pm_prepare, \ .complete = platform_pm_complete, \ ... In case of repeated field assignments, gcc uses the last value (as per http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html). Best Regards, Michał Mirosław --

Does it make sense to define say: #define MASK_XX (x) x & 0xFFFFFC00 and #define MASK_XY (x) x & 0xFFFF0000 Hmm, PAGE_SHIFT can't be used? Or some other #define? --

Hi, Here is the result of my direct I/O benchmarck, which mesures the time it takes to do direct I/O for 20000 pages on 2MB buffer for four types of I/O. Each I/O is issued for one page unit and each number below is the average of 25 runs. with patchset 2.6.35-rc3 Buffer I/O type average(s) STD(s) average(s) STD(s) diff(s) hugepage Sequential Read 3.87 0.16 3.88 0.20 -0.01 Sequential ...

I would try it with some of the fio workfiles that use O_DIRECT, especially the parallel ones. Perhaps people can share their favourite one. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

Thank you for looking this over! I am updating the srcu_read_lock() docbook comments to call out the potential for this problem, given that SRCU read-side critical sections can acquire mutexes, which can be held across both synchronize_srcu() and synchronize_srcu_expedited(). Seem reasonable? Thanx, Paul diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 6f456a7..58971e8 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -139,7 +139,12 @@ static ...

* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote: Hrm I think we discussed this in a past life, but would the following sequence be possible and correct ? CPU 0 read t->rcu_read_unlock_special interrupt comes in, preempts. sets t->rcu_read_unlock_special <preempted> <scheduled back> iret decrement and read t->rcu_read_lock_nesting test both old "special" value (which we have locally on the stack) and detect that rcu_read_lock_nesting is 0. We actually missed a ...

Hrm, I'm not quite convinced yet. I am not concerned about gcc moving the volatile access prior to the sequence point (as you say, this is forbidden by the C standard), but rather that: --(t->rcu_read_lock_nesting) could be split in two distinct operations: read t->rcu_read_lock_nesting decrement t->rcu_read_lock_nesting Note that in order to know the result required to pass the sequence point "&&" (the test), we only need to perform the read, not the decrement. AFAIU, gcc would be in ...

I will run this by some compiler experts. Thanx, Paul --

Yep, thanks! -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

Moving this down past the check of t->rcu_read_lock_special (which is now covered by ACCESS_ONCE()) would violate the C standard, as it would be equivalent to moving a volatile up past a sequence point. --

Hello, Miles! Could you please try David Howells's patch? It may be found at: http://lkml.org/lkml/2010/8/16/333 It should address this one. --

Hello, Greg, what about these two patches? Can I expect for them to be pulled into your patch queue for 2.6.37? -- With best wishes Dmitry --

Hi, Hope this helps http://support.microsoft.com/?id=823921 Regards --

On Sun, 08 Aug 2010 22:34:44 -0700 (PDT) You're saying to convert the sparc code to use phandles? Doing so has caused phandles to show up in asm/openprom.h (linux_dev_v2_funcs's v2_inst2pkg returns a phandle, and linux_nodeops use phandles). This is fine, except asm/openprom.h is an exported kernel header, and linux/of.h is not. I'm tempted to break the phandle/device_node/property stuff out into a separate header (that gets exported), and include that from linux/of.h and ...

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. --

Acked-by: Steffen Klassert <steffen.klassert@secunet.com> Thanks, Steffen --

Hm? I do that whenever you pull from me -- I'll pull the merge commit into my own tree. So the mtd-2.6.git tree you pulled last night, for example, was based on some "random daily thing" half-way between 2.6.35 and 2.6.26-rc1, which happened to be entitled 'Merge git://...mtd-2.6'. I try to avoid having to *merge* such a thing, but it certainly does end up in linux-next as the *base* for maintainers' tree. It's difficult to see how that could be avoided. -- David Woodhouse ...

Depending on the configuration the distribution has used it's likely expected that ata_piix (which I assume is the driver in question) is running that drive in current kernel versions. You likely need to update your boot configuration to point to the correct device. (The kernel device ordering is not related to what boot order you selected in the BIOS.) --

I'll queue these for -next. Thanks! -- Matthew Garrett | mjg59@srcf.ucam.org --

From: Joerg Roedel <joerg.roedel@amd.com> This patch fixes machine crashes which occur when heavily exercising the CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by AMD Erratum 383 and result in a fatal machine check exception. Here's the scenario: 1. On 32-bit, the swapper_pg_dir page table is used as the initial page table for booting a secondary CPU. 2. To make this work, swapper_pg_dir needs a direct mapping of physical memory in it (the low mappings). By adding ...

Peter, I will rip out the timestamp code from the -v2 patch. My first patch does not deal with a 2-1-0 sequence, so it has false positives. We do not necessarily need the timestamps if back-to-back nmis are rare. Without using timestamps the statistically lost ratio for unknown nmis will be as the ratio for back-to-back nmis, with timestamps we could catch almost every unknown nmi. So if we encounter As said, I think with timestamps we could be able to detect 100% of the unknown nmis. I guess ...

I liked the one without funny timestamps in better, the whole timestamps thing just feels too fragile. Relying on handled > 1 to arm the back-to-back filter seems doable. (Also, you didn't deal with the TSC going backwards..) --

Long running SMIs aren't nearly as rare as you'd want them to be. Hitting one in exactly the right spot will be, but given the numbers its going to happen and make us scratch our heads.. --

Robert, I think we still may miss unknown irq, consider the case when unknown nmi is latched while you handle nmi from perf and what is more interesting several counters may be overflowed. So you set delta small enough and second (unknown nmi) will be in range and -- Cyrill --

Its not supposed to happen, but then there's BIOS failure-add that frobs the TSC from SMIs and fun TSC artifacts around CPU frequency changes and people resetting TSC in S-states etc.. In short, never trust the TSC to be even remotely sane. --

Hi Marcelo, Thanks for your review and sorry for the delay reply. We disable prefetch the writable pages since 'pte prefetch' will hurt slot's dirty page tracking that it set the dirty_bitmap bit but the corresponding page Since it should disable 'prefetch' for the writable pages, so i'm not put these operations into a common function and define it in kvm_main.c file. OK, i'll separate it. --

Hi Dan, You might like to pick up http://patchwork.ozlabs.org/patch/39358/ instead.. Thanks. -- Bartlomiej Zolnierkiewicz --

In fact, we (which means basically Alan Stern and me at this point) are working with Arve on this right now. Thanks, Rafael --

Commit-ID: 18fab912d4fa70133df164d2dcf3310be0c38c34 Gitweb: http://git.kernel.org/tip/18fab912d4fa70133df164d2dcf3310be0c38c34 Author: Huang Ying <ying.huang@intel.com> AuthorDate: Wed, 28 Jul 2010 14:14:01 +0800 Committer: Steven Rostedt <rostedt@goodmis.org> CommitDate: Fri, 6 Aug 2010 14:34:45 -0400 tracing: Fix ring_buffer_read_page reading out of page boundary With the configuration: CONFIG_DEBUG_PAGEALLOC=y and Shaohua's patch: [PATCH]x86: make spurious_fault check correct ...

Commit-ID: 575570f02761bd680ba5731c1dfd4701062e7fb2 Gitweb: http://git.kernel.org/tip/575570f02761bd680ba5731c1dfd4701062e7fb2 Author: Shaohua Li <shaohua.li@intel.com> AuthorDate: Tue, 27 Jul 2010 16:06:34 +0800 Committer: Steven Rostedt <rostedt@goodmis.org> CommitDate: Fri, 6 Aug 2010 12:19:15 -0400 tracing: Fix an unallocated memory access in function_graph With CONFIG_DEBUG_PAGEALLOC, I observed an unallocated memory access in function_graph trace. It appears we find a small ...

Just an anecdote, but I remember giving a talk to a room full of admins, all of whom told me it was essential for Samba to implement "full Windows ACL compatibility" (we were in the process of coding it up at the time). I asked them to tell me the difference between object inherit, container inherit, and inherit only. Only one hand remained up (out of a room containing a couple of hundred Windows admins). I asked him where he worked, and the reply was Yeah. I think most sites set a group as ...

The cache miss would not be avoided if the TLB was hit, so it should not be accounted as part of the costs (though a TLB miss will increase cache pressure). Also, your test does not allow the cpu to pipeline anything; in reality, different workloads have different TLB miss costs: - random reads (pointer chasing) incur almost the full impact since the processor is stalled - sequential writes can be completely pipelined and suffer almost no impact Let's say this doubles the impact. So ...

Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. --

CONFIG_CROSS_COMPILE is a string option, leave it empty if you are not cross compiling. Michal. --

Thanks Michal, can see the problem now. Not sure how the "n" got there, i didn't set it manually. Was at 2.6.35-rc6 then updated to 2.6.36-rc1 taking the defaults for all the new config options that popped up. --

This patch adds support or getting and setting feature reports for bluetooth HID devices from HIDRAW. Signed-off-by: Alan Ott <alan@signal11.us> --- net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++++++-- net/bluetooth/hidp/hidp.h | 8 +++ 2 files changed, 118 insertions(+), 4 deletions(-) diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c index bfe641b..0e4880e 100644 --- a/net/bluetooth/hidp/core.c +++ b/net/bluetooth/hidp/core.c @@ -36,6 ...

Yes, they'll go in the next merge window. James --

I belive this is already discussed and agreed upon in the previous thread of discussion. Its the user space code that can modify the grange if required, so I suppose it will need to check Are u sure u are referring to threaded irq, all the processing is being done in thread This is currently not implemented, since I am not aware of any boards with this configuration. A polling method could be added in future if the need arises. --

I tested a bit different hack keeping rdmsrl but removing the if() and it works fine for me: Index: linux/arch/x86/kvm/svm.c =================================================================== --- linux.orig/arch/x86/kvm/svm.c +++ linux/arch/x86/kvm/svm.c @@ -429,8 +429,7 @@ static int svm_hardware_enable(void *gar int me = raw_smp_processor_id(); rdmsrl(MSR_EFER, efer); - if (efer & EFER_SVME) - return -EBUSY; + printk(KERN_DEBUG "svm_hardware_enable: efer %x on %d\n", efer, ...

Hrm - try to use the following (probably whitespace broken and 100% untested) hacky patch: diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 56c9b6b..bde9ee3 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -429,9 +429,11 @@ static int svm_hardware_enable(void *garbage) struct desc_struct *gdt; int me = raw_smp_processor_id(); +#if 0 rdmsrl(MSR_EFER, efer); if (efer & EFER_SVME) return -EBUSY; +#endif if ...