twitter: linux.kernel - 26 new messages in 14 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* kernel/time/tick-sched.c: fix warning of printk's argument format - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e10c654d051215f5?hl=en
* perf tools: Improve thread comm resolution in perf sched - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/5a72e211d4c3a87b?hl=en
* usb_serial: Kill port mutex - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0519cdc4e0b68709?hl=en
* Linux 2.6.32-rc3 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5429515fa7f071a2?hl=en
* Simplify the code in cpuid_open - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c9da500f397372d8?hl=en
* x86, timers: Check for pending timers after (device) interrupts - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/5a40b145fbdad80f?hl=en
* mtd: nand: davinci: fix to use mask_ale from pdata - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/732c30570c65d259?hl=en
* [PATCH] kmap_atomic_push - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/f3e851a04bad3a02?hl=en
* KVM: SVM: Add tracepoint for invlpga instruction - 7 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/54a203cfafbc2f0b?hl=en
* KVM: SVM: Add tracepoint for nested vmrun - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/defbb695f4d2d0cb?hl=en
* add missing include in lib/rational.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0e0f7ec52f6aab03?hl=en
* this_cpu_ops: page allocator conversion - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7c9f71f2d2d1a392?hl=en
* SLUB: Experimental new fastpath w/o interrupt disable - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c117f598ac1a99c9?hl=en
* sata_mv 0000:03:06.0: PCI ERROR; PCI IRQ cause=0x30000040 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/b72fd0fcf693fcaa?hl=en

==============================================================================
TOPIC: kernel/time/tick-sched.c: fix warning of printk's argument format
http://groups.google.com/group/linux.kernel/t/e10c654d051215f5?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Oct 8 2009 8:20 am
From: Linus Torvalds

On Thu, 8 Oct 2009, Wu Zhangjin wrote:
>
> This patch will fix the following warning:

No it won't. It will add a lot of new warnings.

The thing is, almost all architectures (including x86) have

unsigned int __softirq_pending;

but then in <asm-generic/hardirq.h> we have

unsigned long __softirq_pending;

for some unfathomable reason. Quite frankly, I think Arnd just screwed up
the "generic" version, and the fix is almost certainly to just make the
generic version match all the main architectures.

I don't have any architectures using the generic header file, though, so
I'm not going to do that change blindly. People who do should look at it
(alpha, powerpc and mips look like the only ones that might be 64-bit, but
I didn't check very carefully - just grepped for it)

Added Cc's for some people that have worked on, or used, that generic
header file. Is there any possible reason why it is "unsigned long" in
that one?

Linus

---
> kernel/time/tick-sched.c: In function 'tick_nohz_stop_sched_tick':
> kernel/time/tick-sched.c:261: warning: format '%02x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
>
> Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
> ---
> kernel/time/tick-sched.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index e0f59a2..26370b0 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -257,7 +257,7 @@ void tick_nohz_stop_sched_tick(int inidle)
> static int ratelimit;
>
> if (ratelimit < 10) {
> - printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> + printk(KERN_ERR "NOHZ: local_softirq_pending %02lx\n",
> local_softirq_pending());
> ratelimit++;
> }
> --
> 1.6.2.1
>
--
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, Oct 8 2009 8:40 am
From: Wu Zhangjin

On Thu, 2009-10-08 at 08:03 -0700, Linus Torvalds wrote:
>
> On Thu, 8 Oct 2009, Wu Zhangjin wrote:
> >
> > This patch will fix the following warning:
>
> No it won't. It will add a lot of new warnings.
>
> The thing is, almost all architectures (including x86) have
>
> unsigned int __softirq_pending;
>
> but then in <asm-generic/hardirq.h> we have
>
> unsigned long __softirq_pending;
>
> for some unfathomable reason. Quite frankly, I think Arnd just screwed up
> the "generic" version, and the fix is almost certainly to just make the
> generic version match all the main architectures.
>
> I don't have any architectures using the generic header file, though, so
> I'm not going to do that change blindly. People who do should look at it
> (alpha, powerpc and mips look like the only ones that might be 64-bit, but
> I didn't check very carefully - just grepped for it)
>
> Added Cc's for some people that have worked on, or used, that generic
> header file. Is there any possible reason why it is "unsigned long" in
> that one?
>

I'm really using a MIPS machine! there is only a "unsigned long"
definition in include/asm-generic/hardirq.h.

Regards,
Wu Zhangjin

--
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: perf tools: Improve thread comm resolution in perf sched
http://groups.google.com/group/linux.kernel/t/5a72e211d4c3a87b?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:20 am
From: tip-bot for Frederic Weisbecker

Commit-ID: 9a92b479b2f088ee2d3194243f4c8e59b1b8c9c2
Gitweb: http://git.kernel.org/tip/9a92b479b2f088ee2d3194243f4c8e59b1b8c9c2
Author: Frederic Weisbecker <fweisbec@gmail.com>
AuthorDate: Thu, 8 Oct 2009 16:37:12 +0200
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 8 Oct 2009 16:56:33 +0200

perf tools: Improve thread comm resolution in perf sched

When we get sched traces that involve a task that was already
created before opening the event, we won't have the comm event for
it.

So if we can't find the comm event for a given thread, we look at
the traces that may contain these informations.

Before:

ata/1:371 | 0.000 ms | 1 | avg: 3988.693 ms | max: 3988.693 ms |
kondemand/1:421 | 0.096 ms | 3 | avg: 345.346 ms | max: 1035.989 ms |
kondemand/0:420 | 0.025 ms | 3 | avg: 421.332 ms | max: 964.014 ms |
:5124:5124 | 0.103 ms | 5 | avg: 74.082 ms | max: 277.194 ms |
:6244:6244 | 0.691 ms | 9 | avg: 125.655 ms | max: 271.306 ms |
firefox:5080 | 0.924 ms | 5 | avg: 53.833 ms | max: 257.828 ms |
npviewer.bin:6225 | 21.871 ms | 53 | avg: 22.462 ms | max: 220.835 ms |
:6245:6245 | 9.631 ms | 21 | avg: 41.864 ms | max: 213.349 ms |

After:

ata/1:371 | 0.000 ms | 1 | avg: 3988.693 ms | max: 3988.693 ms |
kondemand/1:421 | 0.096 ms | 3 | avg: 345.346 ms | max: 1035.989 ms |
kondemand/0:420 | 0.025 ms | 3 | avg: 421.332 ms | max: 964.014 ms |
firefox:5124 | 0.103 ms | 5 | avg: 74.082 ms | max: 277.194 ms |
npviewer.bin:6244 | 0.691 ms | 9 | avg: 125.655 ms | max: 271.306 ms |
firefox:5080 | 0.924 ms | 5 | avg: 53.833 ms | max: 257.828 ms |
npviewer.bin:6225 | 21.871 ms | 53 | avg: 22.462 ms | max: 220.835 ms |
npviewer.bin:6245 | 9.631 ms | 21 | avg: 41.864 ms | max: 213.349 ms |

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1255012632-7882-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
tools/perf/builtin-sched.c | 44 +++++++++++++++++++++++++++++++++++++++-----
tools/perf/util/thread.c | 32 +++++++++++++++++++++++++-------
tools/perf/util/thread.h | 3 +++
3 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index e1df705..25b91e7 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1034,6 +1034,36 @@ add_sched_in_event(struct work_atoms *atoms, u64 timestamp)
atoms->nb_atoms++;
}

+static struct thread *
+threads__findnew_from_ctx(u32 pid, struct trace_switch_event *switch_event)
+{
+ struct thread *th;
+
+ th = threads__findnew_nocomm(pid, &threads, &last_match);
+ if (th->comm)
+ return th;
+
+ if (pid == switch_event->prev_pid)
+ thread__set_comm(th, switch_event->prev_comm);
+ else
+ thread__set_comm(th, switch_event->next_comm);
+ return th;
+}
+
+static struct thread *
+threads__findnew_from_wakeup(struct trace_wakeup_event *wakeup_event)
+{
+ struct thread *th;
+
+ th = threads__findnew_nocomm(wakeup_event->pid, &threads, &last_match);
+ if (th->comm)
+ return th;
+
+ thread__set_comm(th, wakeup_event->comm);
+
+ return th;
+}
+
static void
latency_switch_event(struct trace_switch_event *switch_event,
struct event *event __used,
@@ -1059,8 +1089,10 @@ latency_switch_event(struct trace_switch_event *switch_event,
die("hm, delta: %Ld < 0 ?\n", delta);

- sched_out = threads__findnew(switch_event->prev_pid, &threads, &last_match);
- sched_in = threads__findnew(switch_event->next_pid, &threads, &last_match);
+ sched_out = threads__findnew_from_ctx(switch_event->prev_pid,
+ switch_event);
+ sched_in = threads__findnew_from_ctx(switch_event->next_pid,
+ switch_event);

out_events = thread_atoms_search(&atom_root, sched_out, &cmp_pid);
if (!out_events) {
@@ -1126,7 +1158,7 @@ latency_wakeup_event(struct trace_wakeup_event *wakeup_event,
if (!wakeup_event->success)
return;

- wakee = threads__findnew(wakeup_event->pid, &threads, &last_match);
+ wakee = threads__findnew_from_wakeup(wakeup_event);
atoms = thread_atoms_search(&atom_root, wakee, &cmp_pid);
if (!atoms) {
thread_atoms_insert(wakee);
@@ -1386,8 +1418,10 @@ map_switch_event(struct trace_switch_event *switch_event,
die("hm, delta: %Ld < 0 ?\n", delta);

- sched_out = threads__findnew(switch_event->prev_pid, &threads, &last_match);
- sched_in = threads__findnew(switch_event->next_pid, &threads, &last_match);
+ sched_out = threads__findnew_from_ctx(switch_event->prev_pid,
+ switch_event);
+ sched_in = threads__findnew_from_ctx(switch_event->next_pid,
+ switch_event);

curr_thread[this_cpu] = sched_in;

diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 3b56aeb..8bd5ca2 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -6,15 +6,17 @@
#include "util.h"
#include "debug.h"

-static struct thread *thread__new(pid_t pid)
+static struct thread *thread__new(pid_t pid, int set_comm)
{
struct thread *self = calloc(1, sizeof(*self));

if (self != NULL) {
self->pid = pid;
- self->comm = malloc(32);
- if (self->comm)
- snprintf(self->comm, 32, ":%d", self->pid);
+ if (set_comm) {
+ self->comm = malloc(32);
+ if (self->comm)
+ snprintf(self->comm, 32, ":%d", self->pid);
+ }
self->maps = RB_ROOT;
INIT_LIST_HEAD(&self->removed_maps);
}
@@ -50,8 +52,10 @@ static size_t thread__fprintf(struct thread *self, FILE *fp)
return ret;
}

-struct thread *
-threads__findnew(pid_t pid, struct rb_root *threads, struct thread **last_match)
+static struct thread *
+__threads__findnew(pid_t pid, struct rb_root *threads,
+ struct thread **last_match,
+ int set_comm)
{
struct rb_node **p = &threads->rb_node;
struct rb_node *parent = NULL;
@@ -80,7 +84,8 @@ threads__findnew(pid_t pid, struct rb_root *threads, struct thread **last_match)
p = &(*p)->rb_right;
}

- th = thread__new(pid);
+ th = thread__new(pid, set_comm);
+
if (th != NULL) {
rb_link_node(&th->rb_node, parent, p);
rb_insert_color(&th->rb_node, threads);
@@ -91,6 +96,19 @@ threads__findnew(pid_t pid, struct rb_root *threads, struct thread **last_match)
}

struct thread *
+threads__findnew(pid_t pid, struct rb_root *threads, struct thread **last_match)
+{
+ return __threads__findnew(pid, threads, last_match, 1);
+}
+
+struct thread *
+threads__findnew_nocomm(pid_t pid, struct rb_root *threads,
+ struct thread **last_match)
+{
+ return __threads__findnew(pid, threads, last_match, 0);
+}
+
+struct thread *
register_idle_thread(struct rb_root *threads, struct thread **last_match)
{
struct thread *thread = threads__findnew(0, threads, last_match);
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 845d9b6..75bc843 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -18,6 +18,9 @@ int thread__set_comm(struct thread *self, const char *comm);
struct thread *
threads__findnew(pid_t pid, struct rb_root *threads, struct thread **last_match);
struct thread *
+threads__findnew_nocomm(pid_t pid, struct rb_root *threads,
+ struct thread **last_match);
+struct thread *
register_idle_thread(struct rb_root *threads, struct thread **last_match);
void thread__insert_map(struct thread *self, struct map *map);
int thread__fork(struct thread *self, struct thread *parent);
--
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_serial: Kill port mutex
http://groups.google.com/group/linux.kernel/t/0519cdc4e0b68709?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:30 am
From: Oliver Neukum

Am Donnerstag, 8. Oktober 2009 16:58:39 schrieb Alan Stern:
> On Thu, 8 Oct 2009, Oliver Neukum wrote:
> > Am Mittwoch, 7. Oktober 2009 23:34:12 schrieb Alan Stern:

> > > Other schemes could work, but to me it seems simplest to rely on a flag
> > > protected by a spinlock. The flag would mean "URBs are supposed to be
> > > queued unless we are suspended". It would be set by open and
> > > unthrottle, and cleared by close and throttle.
> >
> > 1. Why a spinlock?
>
> Because the amount of work involved seems too small for a mutex. But
> you could use a mutex if you wanted, since everything occurs in process
> context.

We have to submit URBs under that lock.

> > 2. Can we get by with only one flag?
>
> If all you want to do is answer a single question ("Should URBs be
> submitted") then a single flag should be all you need. Why, do you
> think more information will be necessary? You can always add more.

We have at least three reasons URBs should not be submitted.
- closure
- throttling
- suspension
Resume() should not submit if either closure or throttling are active,
neither should unthrottle() resubmit if closure or suspension are active.

Regards
Oliver

==============================================================================
TOPIC: Linux 2.6.32-rc3
http://groups.google.com/group/linux.kernel/t/5429515fa7f071a2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:30 am
From: Frans Pop

Linus Torvalds wrote:
> Once you start believing the lie, suddenly all the subtrees will start
> thinking that now _their_ kernel versions are bad, so now they'll start
> to want to make the same idiotic changes to their Makefiles, or maybe
> they'll decide that they don't want to pull tagged releases, but the "one
> after the tag so that they'll get the updated Makefile".

After sleeping on it and letting it percolate a bit I understand this
argument better, and accept it.

I'll continue to increase SUBLEVEL and add -rc0 for my own builds though,
as IMHO it still makes perfect sense for versioning and managing installed
kernel packages.

The conclusion for me is: if anyone wants -rc0, simply apply it locally.

I don't see myself ever using AUTOVERSION. The reason is that I don't want
the files in /boot and dirs in /lib/modules/ to include the commit ID.

For me the kernel *version* is what's defined in the Makefile (plus any
localversion extentions). That's how I want it installed. The AUTOVERSION
part is a *revision*: an update to the tagged version.
(I don't expect you to agree with this.)

So, unless it is made possible to include AUTOVERSION in the kernel and
display it in dmesg and as part of the full 'uname -a' info *without* it
becoming part of 'uname -r', it is not a usable option for me. Sorry.

Cheers,
FJP
--
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: Simplify the code in cpuid_open
http://groups.google.com/group/linux.kernel/t/c9da500f397372d8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:30 am
From: John Kacur

Peter picked up my patch for tip/x86/cpu that removes the bkl in
cpuid_open. Ingo subsequently merged that into tip/master.

The following patch folds back-in tglx's patch that we should have known
about if we had looked into tip/rt/bkl in the first place!

Please pick it up for tip/x86/cpu and tip/master.

From b416b75555aca5e7f066f6edd824fce4b7d08d28 Mon Sep 17 00:00:00 2001
From: John Kacur <jkacur@redhat.com>
Date: Thu, 8 Oct 2009 16:31:57 +0200
Subject: [PATCH] Simplify the code in cpuid_open

This patch folds back in tglx's 55968ede164ae523692f00717f50cd926f1382a0
to my patch that removed the bkl.

This simplifies the code, and makes it consistent with the changes to
kill the bkl in msr.c as well.

This is applied against tip/master

Signed-off-by: John Kacur <jkacur@redhat.com>
---
arch/x86/kernel/cpuid.c | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpuid.c b/arch/x86/kernel/cpuid.c
index 8bb8401..7ef24a7 100644
--- a/arch/x86/kernel/cpuid.c
+++ b/arch/x86/kernel/cpuid.c
@@ -116,18 +116,16 @@ static int cpuid_open(struct inode *inode, struct file *file)
{
unsigned int cpu;
struct cpuinfo_x86 *c;
- int ret = 0;

cpu = iminor(file->f_path.dentry->d_inode);
- if (cpu >= nr_cpu_ids || !cpu_online(cpu)) {
- ret = -ENXIO; /* No such CPU */
- goto out;
- }
+ if (cpu >= nr_cpu_ids || !cpu_online(cpu))
+ return -ENXIO; /* No such CPU */
+
c = &cpu_data(cpu);
if (c->cpuid_level < 0)
- ret = -EIO; /* CPUID not supported */
-out:
- return ret;
+ return -EIO; /* CPUID not supported */
+
+ return 0;
}

/*
--
1.6.0.6

==============================================================================
TOPIC: x86, timers: Check for pending timers after (device) interrupts
http://groups.google.com/group/linux.kernel/t/5a40b145fbdad80f?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:40 am
From: tip-bot for Arjan van de Ven

Commit-ID: 9bcbdd9c58617f1301dd4f17c738bb9bc73aca70
Gitweb: http://git.kernel.org/tip/9bcbdd9c58617f1301dd4f17c738bb9bc73aca70
Author: Arjan van de Ven <arjan@infradead.org>
AuthorDate: Thu, 8 Oct 2009 06:40:41 -0700
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 8 Oct 2009 17:27:27 +0200

x86, timers: Check for pending timers after (device) interrupts

Now that range timers and deferred timers are common, I found a
problem with these using the "perf timechart" tool. Frans Pop also
reported high scheduler latencies via LatencyTop, when using
iwlagn.

It turns out that on x86, these two 'opportunistic' timers only get
checked when another "real" timer happens. These opportunistic
timers have the objective to save power by hitchhiking on other
wakeups, as to avoid CPU wakeups by themselves as much as possible.

The change in this patch runs this check not only at timer
interrupts, but at all (device) interrupts. The effect is that:

1) the deferred timers/range timers get delayed less

2) the range timers cause less wakeups by themselves because
the percentage of hitchhiking on existing wakeup events goes up.

I've verified the working of the patch using "perf timechart", the
original exposed bug is gone with this patch. Frans also reported
success - the latencies are now down in the expected ~10 msec
range.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Tested-by: Frans Pop <elendil@planet.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091008064041.67219b13@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/irq.c | 2 ++
arch/x86/kernel/smp.c | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 74656d1..3912061 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -244,6 +244,7 @@ unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
__func__, smp_processor_id(), vector, irq);
}

+ run_local_timers();
irq_exit();

set_irq_regs(old_regs);
@@ -268,6 +269,7 @@ void smp_generic_interrupt(struct pt_regs *regs)
if (generic_interrupt_extension)
generic_interrupt_extension();

+ run_local_timers();
irq_exit();

set_irq_regs(old_regs);
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index ec1de97..d915d95 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -198,6 +198,7 @@ void smp_reschedule_interrupt(struct pt_regs *regs)
{
ack_APIC_irq();
inc_irq_stat(irq_resched_count);
+ run_local_timers();
/*
* KVM uses this interrupt to force a cpu out of guest mode
*/
--
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: mtd: nand: davinci: fix to use mask_ale from pdata
http://groups.google.com/group/linux.kernel/t/732c30570c65d259?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 8:50 am
From: "Narnakaje, Snehaprabha"

Andrew,

Could you please apply this patch to the -mm tree and thus queue it up for 2.6.32-rc series?

Thanks
Sneha

> -----Original Message-----
> From: davinci-linux-open-source-bounces@linux.davincidsp.com
> [mailto:davinci-linux-open-source-bounces@linux.davincidsp.com] On Behalf
> Of Kevin Hilman
> Sent: Thursday, October 08, 2009 11:16 AM
> To: Pedanekar, Hemant
> Cc: Artem.Bityutskiy@nokia.com; davinci-linux-open-
> source@linux.davincidsp.com; dbrownell@users.sourceforge.net; linux-
> mtd@lists.infradead.org; akpm@linux-foundation.org; dwmw2@infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] mtd: nand: davinci: fix to use mask_ale from pdata
>
> Hemant Pedanekar <hemantp@ti.com> writes:
>
> > Correct typo to use mask_ale from platform data when set to non-zero.
> >
> > Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>
> Could this fix be queued for the .32-rc series please?
>
> Thanks,
>
> Kevin
>
> > ---
> > drivers/mtd/nand/davinci_nand.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/davinci_nand.c
> b/drivers/mtd/nand/davinci_nand.c
> > index 0fad648..20b04a2 100644
> > --- a/drivers/mtd/nand/davinci_nand.c
> > +++ b/drivers/mtd/nand/davinci_nand.c
> > @@ -571,7 +571,7 @@ static int __init nand_davinci_probe(struct
> platform_device *pdev)
> > info->mask_chipsel = pdata->mask_chipsel;
> >
> > /* use nandboot-capable ALE/CLE masks by default */
> > - info->mask_ale = pdata->mask_cle ? : MASK_ALE;
> > + info->mask_ale = pdata->mask_ale ? : MASK_ALE;
> > info->mask_cle = pdata->mask_cle ? : MASK_CLE;
> >
> > /* Set address of hardware control function */
> > --
> > 1.6.2.4
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > Davinci-linux-open-source@linux.davincidsp.com
> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
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: [PATCH] kmap_atomic_push
http://groups.google.com/group/linux.kernel/t/f3e851a04bad3a02?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Oct 8 2009 9:00 am
From: Linus Torvalds

On Thu, 8 Oct 2009, Peter Zijlstra wrote:
>
> The below patchlet changes the kmap_atomic interface to a stack based
> one that doesn't require the KM_types anymore.

I think this is how we should have done it originally.

That said, if we do this, I'd hate to have the "push" and "pop" parts to
the name. They don't really add a whole lot.

Linus
--
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 3 ==
Date: Thurs, Oct 8 2009 9:10 am
From: Ingo Molnar

* Peter Zijlstra <peterz@infradead.org> wrote:

> The below patchlet changes the kmap_atomic interface to a stack based
> one that doesn't require the KM_types anymore.
>
> This significantly simplifies some code (more still than are present
> in this patch -- ie. pte_map_nested can go now)
>
> This obviously requires that push and pop are matched, I fixed a few
> cases that were not properly nested, the (x86) code checks for this
> and will go BUG when trying to pop a vaddr that isn't the top one so
> abusers should be rather visible.

Looks great IMO! Last i proposed this i think either Andrew or Avi had
second thoughts about the hard-to-calculate worst-case mapping limit -
but i dont think that's a big issue.

Lets not change the API names though - the rule is that map/unmap must
be properly nested.

Ingo
--
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/

== 3 of 3 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Peter Zijlstra

On Thu, 2009-10-08 at 17:53 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > The below patchlet changes the kmap_atomic interface to a stack based
> > one that doesn't require the KM_types anymore.
> >
> > This significantly simplifies some code (more still than are present
> > in this patch -- ie. pte_map_nested can go now)
> >
> > This obviously requires that push and pop are matched, I fixed a few
> > cases that were not properly nested, the (x86) code checks for this
> > and will go BUG when trying to pop a vaddr that isn't the top one so
> > abusers should be rather visible.
>
> Looks great IMO! Last i proposed this i think either Andrew or Avi had
> second thoughts about the hard-to-calculate worst-case mapping limit -
> but i dont think that's a big issue.

That would've been me ;-)

> Lets not change the API names though - the rule is that map/unmap must
> be properly nested.

Right, so I did that full rename just so that people wouldn't get
confused or something, but if both you and Linus think it should remain:
kmap_atomic() and kunmap_atomic(), I can certainly undo that part.

==============================================================================
TOPIC: KVM: SVM: Add tracepoint for invlpga instruction
http://groups.google.com/group/linux.kernel/t/54a203cfafbc2f0b?hl=en
==============================================================================

== 1 of 7 ==
Date: Thurs, Oct 8 2009 9:10 am
From: Avi Kivity

On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> This patch adds a tracepoint for the event that the guest
> executed the INVLPGA instruction.
> +
> + TP_printk("rip=0x%016llx asid=%d adress=0x%016llx\n",
> + __entry->rip, __entry->asid, __entry->address)
> +);
>

s/adress/address/.

Also, kvm tracepoints don't use '=' in TP_printk(), please keep it
consistent.

Yeah, I know, but I don't have any real comments to make.

--
error compiling committee.c: too many arguments to function

== 2 of 7 ==
Date: Thurs, Oct 8 2009 9:20 am
From: Avi Kivity

On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> From: Alexander Graf<agraf@suse.de>
>
> If event_inj is valid on a #vmexit the host CPU would write
> the contents to exit_int_info, so the hypervisor knows that
> the event wasn't injected.
>
> We don't do this in nested SVM by now which is a bug and
> fixed by this patch.
>

We need to start thinking about regression tests for these bugs. It
would be relatively easy to set up something with save->cr3 == cr3 (i.e.
no isolation, mmu virtualization, etc.).

--
error compiling committee.c: too many arguments to function

== 3 of 7 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Joerg Roedel

On Thu, Oct 08, 2009 at 06:01:55PM +0200, Avi Kivity wrote:
> On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> >This patch adds a tracepoint for the event that the guest
> >executed the INVLPGA instruction.
> >+
> >+ TP_printk("rip=0x%016llx asid=%d adress=0x%016llx\n",
> >+ __entry->rip, __entry->asid, __entry->address)
> >+);
>
> s/adress/address/.
>
> Also, kvm tracepoints don't use '=' in TP_printk(), please keep it
> consistent.

I had it with "key: value" formating first but decided to do it this way
because it simplifies automatic parsing of these trace events. With this
format a script can first split by spaces and get the key-value pairs by
splitting on the equal sign. This is also more robust against changes in
the format.

Joerg

== 4 of 7 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Avi Kivity

On 10/08/2009 06:18 PM, Joerg Roedel wrote:
>
>> Also, kvm tracepoints don't use '=' in TP_printk(), please keep it
>> consistent.
>>
> I had it with "key: value" formating first but decided to do it this way
> because it simplifies automatic parsing of these trace events. With this
> format a script can first split by spaces and get the key-value pairs by
> splitting on the equal sign. This is also more robust against changes in
> the format.
>
>

Automatic parsing should use the binary transport (which simply has the
TP_struct things).

--
error compiling committee.c: too many arguments to function

== 5 of 7 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Avi Kivity

On 10/08/2009 06:22 PM, Joerg Roedel wrote:
> On Thu, Oct 08, 2009 at 06:12:28PM +0200, Avi Kivity wrote:
>
>> On 10/08/2009 12:03 PM, Joerg Roedel wrote:
>>
>>> From: Alexander Graf<agraf@suse.de>
>>>
>>> If event_inj is valid on a #vmexit the host CPU would write
>>> the contents to exit_int_info, so the hypervisor knows that
>>> the event wasn't injected.
>>>
>>> We don't do this in nested SVM by now which is a bug and
>>> fixed by this patch.
>>>
>> We need to start thinking about regression tests for these bugs. It
>> would be relatively easy to set up something with save->cr3 == cr3
>> (i.e. no isolation, mmu virtualization, etc.).
>>
> Should be doable with a in-kernel regression test-suite module, I think.
> Triggering such (race-condition like) test cases from userspace is
> somewhat hard.
>
>

Isn't it sufficient, for this case, to inject a nested interrupt when
the nested idt is not mapped?

--
error compiling committee.c: too many arguments to function

== 6 of 7 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Joerg Roedel

On Thu, Oct 08, 2009 at 06:12:28PM +0200, Avi Kivity wrote:
> On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> >From: Alexander Graf<agraf@suse.de>
> >
> >If event_inj is valid on a #vmexit the host CPU would write
> >the contents to exit_int_info, so the hypervisor knows that
> >the event wasn't injected.
> >
> >We don't do this in nested SVM by now which is a bug and
> >fixed by this patch.
>
> We need to start thinking about regression tests for these bugs. It
> would be relatively easy to set up something with save->cr3 == cr3
> (i.e. no isolation, mmu virtualization, etc.).

Should be doable with a in-kernel regression test-suite module, I think.
Triggering such (race-condition like) test cases from userspace is
somewhat hard.

Joerg

== 7 of 7 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Joerg Roedel

On Thu, Oct 08, 2009 at 06:21:09PM +0200, Avi Kivity wrote:
> On 10/08/2009 06:18 PM, Joerg Roedel wrote:
> >
> >>Also, kvm tracepoints don't use '=' in TP_printk(), please keep it
> >>consistent.
> >I had it with "key: value" formating first but decided to do it this way
> >because it simplifies automatic parsing of these trace events. With this
> >format a script can first split by spaces and get the key-value pairs by
> >splitting on the equal sign. This is also more robust against changes in
> >the format.
> >
>
> Automatic parsing should use the binary transport (which simply has
> the TP_struct things).

Ok, in this case I'll change it.

Joerg

==============================================================================
TOPIC: KVM: SVM: Add tracepoint for nested vmrun
http://groups.google.com/group/linux.kernel/t/defbb695f4d2d0cb?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Oct 8 2009 9:10 am
From: Avi Kivity

On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> This patch adds a dedicated kvm tracepoint for a nested
> vmrun.
>
> Signed-off-by: Joerg Roedel<joerg.roedel@amd.com>
> ---
> arch/x86/kvm/svm.c | 6 ++++++
> arch/x86/kvm/trace.h | 33 +++++++++++++++++++++++++++++++++
> arch/x86/kvm/x86.c | 1 +
> 3 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 884bffc..907af3f 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1726,6 +1726,12 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
> /* nested_vmcb is our indicator if nested SVM is activated */
> svm->nested.vmcb = svm->vmcb->save.rax;
>
> + trace_kvm_nested_vmrun(svm->vmcb->save.rip - 3, svm->nested.vmcb,
> + nested_vmcb->save.rip,
> + nested_vmcb->control.int_ctl,
> + nested_vmcb->control.event_inj,
> + nested_vmcb->control.nested_ctl);
> +
>

It's better to pass only 'svm' as argument and have the tracepoint code
derive everything else, since (I think) argument setup is done
unconditionally, and only the actual trace_kvm call is patched out. It
may not work out due to where the trace code is compiled, but it's worth
trying.

--
error compiling committee.c: too many arguments to function

== 2 of 3 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Joerg Roedel

On Thu, Oct 08, 2009 at 05:58:22PM +0200, Avi Kivity wrote:
> On 10/08/2009 12:03 PM, Joerg Roedel wrote:
> >This patch adds a dedicated kvm tracepoint for a nested
> >vmrun.
> >
> >Signed-off-by: Joerg Roedel<joerg.roedel@amd.com>
> >---
> > arch/x86/kvm/svm.c | 6 ++++++
> > arch/x86/kvm/trace.h | 33 +++++++++++++++++++++++++++++++++
> > arch/x86/kvm/x86.c | 1 +
> > 3 files changed, 40 insertions(+), 0 deletions(-)
> >
> >diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> >index 884bffc..907af3f 100644
> >--- a/arch/x86/kvm/svm.c
> >+++ b/arch/x86/kvm/svm.c
> >@@ -1726,6 +1726,12 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
> > /* nested_vmcb is our indicator if nested SVM is activated */
> > svm->nested.vmcb = svm->vmcb->save.rax;
> >
> >+ trace_kvm_nested_vmrun(svm->vmcb->save.rip - 3, svm->nested.vmcb,
> >+ nested_vmcb->save.rip,
> >+ nested_vmcb->control.int_ctl,
> >+ nested_vmcb->control.event_inj,
> >+ nested_vmcb->control.nested_ctl);
> >+
>
> It's better to pass only 'svm' as argument and have the tracepoint
> code derive everything else, since (I think) argument setup is done
> unconditionally, and only the actual trace_kvm call is patched out.
> It may not work out due to where the trace code is compiled, but
> it's worth trying.

Hmm, struct vcpu_svm is defined in svm.c and local to that file. It is
not known in x86.c, where the tracepoints are compiled, or in svm.c
where trace.h is included. Is this tracepoint it worth it to move the
definition of vcpu_svm into a (x86-)global header?

Joerg

== 3 of 3 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Avi Kivity

On 10/08/2009 06:15 PM, Joerg Roedel wrote:
> On Thu, Oct 08, 2009 at 05:58:22PM +0200, Avi Kivity wrote:
>
>> On 10/08/2009 12:03 PM, Joerg Roedel wrote:
>>
>>> This patch adds a dedicated kvm tracepoint for a nested
>>> vmrun.
>>>
>>> Signed-off-by: Joerg Roedel<joerg.roedel@amd.com>
>>> ---
>>> arch/x86/kvm/svm.c | 6 ++++++
>>> arch/x86/kvm/trace.h | 33 +++++++++++++++++++++++++++++++++
>>> arch/x86/kvm/x86.c | 1 +
>>> 3 files changed, 40 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>>> index 884bffc..907af3f 100644
>>> --- a/arch/x86/kvm/svm.c
>>> +++ b/arch/x86/kvm/svm.c
>>> @@ -1726,6 +1726,12 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
>>> /* nested_vmcb is our indicator if nested SVM is activated */
>>> svm->nested.vmcb = svm->vmcb->save.rax;
>>>
>>> + trace_kvm_nested_vmrun(svm->vmcb->save.rip - 3, svm->nested.vmcb,
>>> + nested_vmcb->save.rip,
>>> + nested_vmcb->control.int_ctl,
>>> + nested_vmcb->control.event_inj,
>>> + nested_vmcb->control.nested_ctl);
>>> +
>>>
>> It's better to pass only 'svm' as argument and have the tracepoint
>> code derive everything else, since (I think) argument setup is done
>> unconditionally, and only the actual trace_kvm call is patched out.
>> It may not work out due to where the trace code is compiled, but
>> it's worth trying.
>>
> Hmm, struct vcpu_svm is defined in svm.c and local to that file. It is
> not known in x86.c, where the tracepoints are compiled, or in svm.c
> where trace.h is included. Is this tracepoint it worth it to move the
> definition of vcpu_svm into a (x86-)global header?
>

I was talking about all svm tracepoints, but no, it isn't worth it.
Let's leave it till later.

--
error compiling committee.c: too many arguments to function

==============================================================================
TOPIC: add missing include in lib/rational.c
http://groups.google.com/group/linux.kernel/t/0e0f7ec52f6aab03?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 9:20 am
From: "Oskar Schirmer"

On Thu, Oct 08, 2009 at 09:54:03 +0200, Sascha Hauer wrote:
>
> Hi,
>
> Here is a little patch to fix a compiler warning
>
> fixes:
>
> lib/rational.c:62: warning: data definition has no type or storage class
> lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
> lib/rational.c:62: warning: parameter names (without types) in function declaration

Oh yes, we didnt use it with modules up to now.
Thank You for the fix.

>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Acked-by: Oskar Schirmer <os@emlix.com>

> ---
> lib/rational.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/lib/rational.c b/lib/rational.c
> index b3c099b..3ed247b 100644
> --- a/lib/rational.c
> +++ b/lib/rational.c
> @@ -7,6 +7,7 @@
> */
>
> #include <linux/rational.h>
> +#include <linux/module.h>
>
> /*
> * calculate best rational approximation for a given fraction
> --
> 1.6.4.3
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>

--
oskar schirmer, emlix gmbh, http://www.emlix.com
fon +49 551 30664-0, fax -11, bahnhofsallee 1b, 37081 göttingen, germany
sitz der gesellschaft: göttingen, amtsgericht göttingen hr b 3160
geschäftsführer: dr. uwe kracke, ust-idnr.: de 205 198 055

emlix - your embedded linux partner
--
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: this_cpu_ops: page allocator conversion
http://groups.google.com/group/linux.kernel/t/7c9f71f2d2d1a392?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Christoph Lameter

On Thu, 8 Oct 2009, Tejun Heo wrote:

> > +static void setup_pageset(struct per_cpu_pageset *p, unsigned long batch);
> > +static DEFINE_PER_CPU(struct per_cpu_pageset, boot_pageset);
>
> This looks much better but I'm not sure whether it's safe. percpu
> offsets have not been set up before setup_per_cpu_areas() is complete
> on most archs but if all that's necessary is getting the page
> allocator up and running as soon as static per cpu areas and offsets
> are set up (which basically means as soon as cpu init is complete on
> ia64 and setup_per_cpu_areas() is complete on all other archs). This
> should be correct. Is this what you're expecting?

paging_init() is called after the per cpu areas have been initialized. So
I thought this would be safe. Tested it on x86.

zone_pcp_init() only sets up the per cpu pointers to the pagesets. That
works regardless of the boot stage. Then then build_all_zonelists()
initializes the actual contents of the per cpu variables.

Finally the per cpu pagesets are allocated from the percpu allocator when
all allocators are up and the pagesets are sized.

==============================================================================
TOPIC: SLUB: Experimental new fastpath w/o interrupt disable
http://groups.google.com/group/linux.kernel/t/c117f598ac1a99c9?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Oct 8 2009 9:30 am
From: Christoph Lameter

On Thu, 8 Oct 2009, Peter Zijlstra wrote:

> > preempt_enable_no_sched()
>
> NACK, delaying the reschedule is not an option

I ended up just doing a preempt_disable() at the beginning and a
preempt_disable() at the end. That should be easily reviewable.

== 2 of 2 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Christoph Lameter

On Thu, 8 Oct 2009, Peter Zijlstra wrote:

> I just don't get why Christoph is getting all upset about the
> need_resched() check in preempt_enable(), its still cheaper than poking
> at the interrupt flags.

Preempt causes too many performance issues. I keep on thinking that I
could make it easier on people to use it. Guess I better leave it simple
then.

==============================================================================
TOPIC: sata_mv 0000:03:06.0: PCI ERROR; PCI IRQ cause=0x30000040
http://groups.google.com/group/linux.kernel/t/b72fd0fcf693fcaa?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Oct 8 2009 9:40 am
From: Bernie Innocenti

El Tue, 06-10-2009 a las 14:04 -0400, Bernie Innocenti escribió:
> > I have heard same thing happened with same kind of configuration, using
> > Supermicro H8DME-2 motherboard, Opteron 2378 CPU.
> >
> >Even the controllers were on same slots.
>
> Close. Mine is a Supermicro H8DM8-2 with 2x Opteron 2374 HE CPU.

I was wrong (the BIOS DMI block is wrong). The motherboard is labeled
as H8DME-2.

--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Thursday, October 8, 2009

linux.kernel - 26 new messages in 14 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts