linux.kernel - 8 new messages in 7 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
Today's topics:
* net: reserve ports for applications using fixed port numbers - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/4bfac061273c81ff?hl=en
* virtio-console fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3ae9e8f15a508f1a?hl=en
* USB mass storage and ARM cache coherency - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
* evdev keyboard driver stopped working after upgrading from Kernel 2.6.33-rc8
to 2.6.33 (official release) - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bb5c7f92e8ee00b8?hl=en
* : Sparc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/afff88a962aa146f?hl=en
* cpufreq: fix a lockdep warning - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6194c4ad93a2e620?hl=en
* cxgb3: fix hot plug removal crash - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/70159f363a739e22?hl=en
==============================================================================
TOPIC: net: reserve ports for applications using fixed port numbers
http://groups.google.com/group/linux.kernel/t/4bfac061273c81ff?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 12:30 am
From: Cong Wang
David Miller wrote:
> Eric B., could you look over the first two patches (which touch the
> sysctl core) and give some review and ACK/NACK?
>
ping Eric W. Biederman ... :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: virtio-console fixes
http://groups.google.com/group/linux.kernel/t/3ae9e8f15a508f1a?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 12:30 am
From: Amit Shah
Hey Linus,
While Rusty is away, I'm pushing these two small cleanup patches
directly to you.
There's no functional change; only stylistic fixes for better
readability.
The following changes since commit eaa5eec739637f32f8733d528ff0b94fd62b1214:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../bp/bp
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/amit/virtio-console.git master
Amit Shah (2):
virtio: console: Fix type of 'len' as unsigned int
virtio: console: Use better variable names for fill_queue operation
drivers/char/virtio_console.c | 29 ++++++++++++++++-------------
1 files changed, 16 insertions(+), 13 deletions(-)
Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: USB mass storage and ARM cache coherency
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 12:30 am
From: James Bottomley
On Thu, 2010-03-04 at 13:00 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-03-03 at 11:10 +0530, James Bottomley wrote:
> > On Wed, 2010-03-03 at 16:10 +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2010-03-03 at 12:47 +0900, FUJITA Tomonori wrote:
> > > > The ways to improve the approach (introducing PG_arch_2 or marking a
> > > > page clean on dma_unmap_* with DMA_FROM_DEVICE like ia64 does) is up
> > > > to architectures.
> > >
> > > How does the above work ? IE, the dma unmap will flush the D side but
> > > not the I side ... or is the ia64 flush primitive magic enough to do
> > > both ?
> >
> > The point is that in a well regulated system, the I cache shouldn't need
> > extra flushing in the kernel. We should only be faulting in R-X pages.
> > If we're operating on RWX pages (i.e. self modifying code), it's the job
> > of userspace to keep I/D coherency.
> >
> > So the only case the kernel needs to worry about is the R-X fault case
> > for executable text code.
>
> Still, you do need to flush I when a page cache page is recycled.
Technically not if we've got all the I flushing when mapped executable
sorted out. This is one of the dangers of over flushing ... if we start
flushing where we don't need it "just to be sure" we end up papering
over holes in the operating system and make catching actual bugs in
operations a lot harder.
The other thing you might not appreciate in ppc land is that for a lot
of other systems (well, like parisc) flushing a dirty cache line is
incredibly expensive (because we halt the CPU to wait for the memory
eviction), so ideally we want to flush as late as possible to give the
natural operations a chance to clean most of the cache lines. Flushing
a clean cache line on parisc as well as invalidations are fast
operations. That's why the kmap makes the most sense to us for
implementing PIO ops ... it's the farthest point we can flush the cache
at (because beyond it we've lost the mapping the VIPT cache requires to
flush).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: evdev keyboard driver stopped working after upgrading from Kernel 2.6.
33-rc8 to 2.6.33 (official release)
http://groups.google.com/group/linux.kernel/t/bb5c7f92e8ee00b8?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Mar 4 2010 12:30 am
From: Zeno Davatz
On Thu, Mar 4, 2010 at 9:03 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Thu, 2010-03-04 at 08:55 +0100, Zeno Davatz wrote:
>
>> Ok, I will try that. Can you give a short input of how I should start bisecting?
>
> git bisect start
> git bisect good v2.6.33-rc8
> git bisect bad v2.6.33
>
> build and test each iteration, should be quick/painless if it's rc8.
So I do:
git bisect start
git bisect good v2.6.33-rc8
make
copy bzImge
lilo
reboot
see if it works
correct?
best
Zeno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Thurs, Mar 4 2010 12:40 am
From: Zeno Davatz
On Thu, Mar 4, 2010 at 9:03 AM, Mike Galbraith <efault@gmx.de> wrote:
> On Thu, 2010-03-04 at 08:55 +0100, Zeno Davatz wrote:
>
>> Ok, I will try that. Can you give a short input of how I should start bisecting?
>
> git bisect start
> git bisect good v2.6.33-rc8
> git bisect bad v2.6.33
>
> build and test each iteration, should be quick/painless if it's rc8.
Ok I think I am getting it. Forget my last mail.
Best
Zeno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: : Sparc
http://groups.google.com/group/linux.kernel/t/afff88a962aa146f?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 12:30 am
From: David Miller
1) Fix long standing bootup wedge wrt. NMIs, we need to disable NMIs
when we enter the firmware for two reasons. One so we don't
deadlock on the PROM spinlock if we try to print things to the
firmware console from an NMI. Two, because many of OpenFirmware's
routines do not like to be interrupted at all. The latter can
cause garbage characters over serial consoles and crashes.
I'll be pushing this one to -stable.
2) Kill off the dinky sys_perfctr, perf_events should be used.
3) Fix some driver builds by providing big-endian io{read,write}*().
Please pull, thanks a lot!
The following changes since commit 3a5b27bf6f29574d667230c7e76e4b83fe3014e0:
Linus Torvalds (1):
Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git master
David S. Miller (4):
sparc: Provide io{read,write}{16,32}be().
sparc: Update defconfigs.
sparc64: Kill off old sys_perfctr system call and state.
sparc64: Make prom entry spinlock NMI safe.
arch/sparc/configs/sparc32_defconfig | 56 ++++++++++++++---
arch/sparc/configs/sparc64_defconfig | 34 ++++++----
arch/sparc/include/asm/io_32.h | 4 +
arch/sparc/include/asm/io_64.h | 4 +
arch/sparc/include/asm/perfctr.h | 4 +-
arch/sparc/include/asm/system_64.h | 15 +----
arch/sparc/include/asm/thread_info_64.h | 25 ++-----
arch/sparc/kernel/entry.h | 1 -
arch/sparc/kernel/process_64.c | 23 -------
arch/sparc/kernel/rtrap_64.S | 54 +---------------
arch/sparc/kernel/sys32.S | 1 -
arch/sparc/kernel/sys_sparc_64.c | 104 -------------------------------
arch/sparc/kernel/syscalls.S | 23 +------
arch/sparc/kernel/systbls.h | 2 -
arch/sparc/kernel/systbls_64.S | 4 +-
arch/sparc/kernel/traps_64.c | 9 ---
arch/sparc/prom/p1275.c | 12 ++--
17 files changed, 99 insertions(+), 276 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: cpufreq: fix a lockdep warning
http://groups.google.com/group/linux.kernel/t/6194c4ad93a2e620?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Mar 4 2010 12:30 am
From: Amerigo Wang
There is no need to do sysfs_remove_link() or kobject_put() etc.
when policy_rwsem_write is held, move them after releasing the lock.
This fixes the lockdep warning:
halt/4071 is trying to acquire lock:
(s_active){++++.+}, at: [<c0000000001ef868>] .sysfs_addrm_finish+0x58/0xc0
but task is already holding lock:
(&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [<c0000000004cd6ac>] .lock_policy_rwsem_write+0x84/0xf4
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Dave Jones <davej@redhat.com>
---
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 67bc2ec..e196084 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1113,6 +1113,8 @@ static int __cpufreq_remove_dev(struct sys_device *sys_dev)
unsigned int cpu = sys_dev->id;
unsigned long flags;
struct cpufreq_policy *data;
+ struct kobject *kobj;
+ struct completion *cmp;
#ifdef CONFIG_SMP
struct sys_device *cpu_sys_dev;
unsigned int j;
@@ -1141,10 +1143,11 @@ static int __cpufreq_remove_dev(struct sys_device *sys_dev)
dprintk("removing link\n");
cpumask_clear_cpu(cpu, data->cpus);
spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
- sysfs_remove_link(&sys_dev->kobj, "cpufreq");
+ kobj = &sys_dev->kobj;
cpufreq_cpu_put(data);
cpufreq_debug_enable_ratelimit();
unlock_policy_rwsem_write(cpu);
+ sysfs_remove_link(kobj, "cpufreq");
return 0;
}
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home