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

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

Today's topics:

* percpu: add __percpu sparse annotations to hw_breakpoint - 4 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/5dcc5f7a17a4818e?hl=en
* request for assistance: accessing ttys from kernel space - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/cd06029f40862317?hl=en
* scripts/kallsyms build warning fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9bf6bdfb46195075?hl=en
* ftrace: unify arch_syscall_addr() implementations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
* Weird hard hangs when rendering 'some' web-sites in Firefox - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
* markup_oops.pl: add options to improve cross-sompilation environments - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
* markup_oops.pl: add options to improve cross-sompilation environments - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/c3a28c7c96253ad8?hl=en
* tracing: reduce latency and remove percpu trace_seq - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2364c2512709f3a6?hl=en
* tty: possible irq lock inversion dependency in tty_fasync - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e7fe1257ceb196f4?hl=en
* tracing: Change trace_seq to use separate buffer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/303bad7e1d71273e?hl=en
* starting emacs makes lockdep warning - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
* : bug fix, remove partial zero out - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0bd48232b337c1b8?hl=en
* infiniband limit of 32 cards per system? - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/ae5013eea7f9b81f?hl=en
* Use full path to dnsdomainname and domainname in scripts/mkcompile_h - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e0aebdfb17688691?hl=en
* gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka
spitz: fix warn_on introduced in 2.6.32-rc1) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/337ac495cfb9a0e2?hl=en
* regulator: trivial: fix typos in user-visible Kconfig text - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
* kgdb regression fixes for 2.6.33 - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* perf lock: New subcommand "perf lock", for analyzing lock statistics - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/d907e7c6d5011cd0?hl=en
* powerpc: implement arch_scale_smt_power for Power7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/891f3a14ac88e3fb?hl=en
* Linux kernel 2.6.33-rc5 bug report - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/572383a2abe784b9?hl=en

==============================================================================
TOPIC: percpu: add __percpu sparse annotations to hw_breakpoint
http://groups.google.com/group/linux.kernel/t/5dcc5f7a17a4818e?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Jan 25 2010 6:50 pm
From: Tejun Heo

On 01/26/2010 11:35 AM, Frederic Weisbecker wrote:
> No guarantee that will build. I should pull your tree and install
> sparse (yeah, shame on me, I've never installed it).

Nope, it doesn't. Please pull from the following tree to receive the
whole thing. The definitions in question are in
include/asm-generic/percpu.h.

git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git percpu-sparse-review

After installing sparse,

make C=2 arch/x86/kernel/cpu/common.o

should be enough.

Thanks.

--
tejun
--
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 4 ==
Date: Mon, Jan 25 2010 7:00 pm
From: Al Viro

On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:

> > Eh... You are leaving that noderef in place in case of array. And _that_
> > is not an address space, so casts to AS 0 won't do you any good.
>
> Any ideas on how to fix it?

BTW, before we go any further, which warnings are you getting from sparse
and which version of sparse are you using?

noderef is one thing; address_space mess is a different story. The version
I have here steps into the former, but not the latter; what are you seeing?
--
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 4 ==
Date: Mon, Jan 25 2010 7:20 pm
From: Tejun Heo

Hello,

On 01/26/2010 11:48 AM, Al Viro wrote:
> On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
>
>>> Eh... You are leaving that noderef in place in case of array. And _that_
>>> is not an address space, so casts to AS 0 won't do you any good.
>>
>> Any ideas on how to fix it?
>
> BTW, before we go any further, which warnings are you getting from sparse
> and which version of sparse are you using?
>
> noderef is one thing; address_space mess is a different story. The version
> I have here steps into the former, but not the latter; what are you seeing?

Oops, I too am seeing the noderef thing not the address space warning.

char *estacks = per_cpu(exception_stacks, cpu);

I get

arch/x86/kernel/cpu/common.c:1149:19: warning: incorrect type in initializer (different modifiers)
arch/x86/kernel/cpu/common.c:1149:19: expected char *estacks
arch/x86/kernel/cpu/common.c:1149:19: got char [noderef] *<noident>
CC arch/x86/kernel/cpu/common.o

$ rpm -qi sparse
Name : sparse Relocations: (not relocatable)
Version : 0.4.1.git1 Vendor: openSUSE
Release : 3.2 Build Date: Sat 24 Oct 2009 11:58:16 AM KST

Thanks.

== 4 of 4 ==
Date: Mon, Jan 25 2010 8:00 pm
From: Al Viro

On Tue, Jan 26, 2010 at 12:10:51PM +0900, Tejun Heo wrote:
> Hello,
>
> On 01/26/2010 11:48 AM, Al Viro wrote:
> > On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
> >
> >>> Eh... You are leaving that noderef in place in case of array. And _that_
> >>> is not an address space, so casts to AS 0 won't do you any good.
> >>
> >> Any ideas on how to fix it?
> >
> > BTW, before we go any further, which warnings are you getting from sparse
> > and which version of sparse are you using?
> >
> > noderef is one thing; address_space mess is a different story. The version
> > I have here steps into the former, but not the latter; what are you seeing?
>
> Oops, I too am seeing the noderef thing not the address space warning.

OK... So all messing around __kernel __force is actually a red herring.

Frankly, for now I'd keep it as in your patch. Yes, including workarounds
in these few places. Longer term... We probably want to implement
__attribute__((qualify(...)))/__attribute__((unqualify(...))), revert
__typeof__ for AS/noderef to what gcc is doing for normal qualifiers
(i.e. "if p is int const *, typeof(*p) v gives const int") go for explicit
__unqualify((address_space,noderef)) in there. Playing interesting games
with arrays for unqualify (i.e. creating parallel chains of type nodes
all way down to the place where original qualifier had been applied).
--
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: request for assistance: accessing ttys from kernel space
http://groups.google.com/group/linux.kernel/t/cd06029f40862317?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 6:50 pm
From: Samuel Thibault

Alan Cox, le Tue 26 Jan 2010 02:13:06 +0000, a écrit :
> > What I would like to discuss is how we can access ttys from kernel
> > space. If we could do this, it would definitely make things much easier
> > for us in speakup.
>
> Basically - use a line discipline, that lets you sit on top of a tty and
> interact with the hardware

The problem is that to my knowledge, to setup a line discipline, you
need to already have a daemon opening /dev/ttySomething and set up the
line discipline. You could as well just move all the speakup code into
the daemon. The point of speakup is to have feedback even when it is
not possible to run such daemon.

Is there another way to set up a line discipline from the kernel itself
without the need from userland intervention, even before any / is
mounted?

> > We need to be able to access the ttys as early as possible in the boot
> > sequence. Any help, suggestions, or guidance you could give us would be
> > greatly appreciated.
>
> We may need to make some special provision for that aspect - we already
> do so for the early serial console support.

Maybe the early serial console support layer could be extended a bit so
speakup can use it first during the boot? For now it's quite tied to
just printing the printk logs. drivers/accessibility/braille_console.c
does manage do make something else, but it happens that the
serial_core.c's uart_console_write puts additional \rs before \ns, which
can be a problem.

Also, for proper speech flow, speakup would need to be able to read
characters from the device.

> The ldisc is the start point then there may be some bits that need to
> be extended around it.

To me it seems like the only missing bit is how to setup the line
discipline from the kernel itself (i.e. how to "open" the device?) as
soon as it becomes safe to rely on the tty layer.

> A bigger problem is going to be the fact non USB serial is vanishing bit
> by bit.

Actually that's precisely why the speakup community is pressing for
proper tty support, in order to get PCI & USB support :)

> We do have a USB console but it's truely crazy stuff and extending it
> scares me 8)

Ideally that'll needed :/

Samuel
--
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: scripts/kallsyms build warning fix
http://groups.google.com/group/linux.kernel/t/9bf6bdfb46195075?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Américo Wang

On Tue, Jan 26, 2010 at 5:41 AM, Himanshu Chauhan
<hschauhan@nulltrace.org> wrote:
> Hi all,
>
> This is a small patch that fixes the build warning
> of scripts/kallsyms.c
>
> Regards
> Himanshu
>
> Signed-off-by: Himanshu Chauhan <hschauhan@nulltrace.org>
> ---
> scripts/kallsyms.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> index 86c3896..e3902fb 100644
> --- a/scripts/kallsyms.c
> +++ b/scripts/kallsyms.c
> @@ -108,8 +108,10 @@ static int read_symbol(FILE *in, struct sym_entry *s)
> rc = fscanf(in, "%llx %c %499s\n", &s->addr, &stype, str);
> if (rc != 3) {
> if (rc != EOF) {
> - /* skip line */
> - fgets(str, 500, in);
> + /* skip line. sym is used as dummy to
> + * shut of "warn_unused_result" warning.
> + */
> + sym = fgets(str, 500, in);
> }
> return -1;
> }

Why not use the return value to do some useful checking?
--
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: ftrace: unify arch_syscall_addr() implementations
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Paul Mundt

On Fri, Jan 22, 2010 at 09:36:17AM -0500, Steven Rostedt wrote:
> [ Added Heiko Carstens and Paul Mundt to Cc ]
>
> On Fri, 2010-01-22 at 08:43 -0500, Mike Frysinger wrote:
> > also, does the arch_syscall_addr() even really need to be weak ? or can
> > we assume that everyone is going to be sane and do it the same way ...
> >
> > Documentation/trace/ftrace-design.txt | 6 +++++-
> > arch/s390/kernel/ftrace.c | 10 ----------
> > arch/sh/kernel/ftrace.c | 9 ---------
> > arch/sparc/kernel/ftrace.c | 11 -----------
> > arch/x86/kernel/ftrace.c | 10 ----------
> > include/linux/ftrace.h | 6 ++++++
> > kernel/trace/trace_syscalls.c | 6 +++++
>
> Actually for this patch to be accepted, we need to get the acks from the
> maintainers of s390, sh, and sparc since it touches their code. Doesn't
> matter if it is just removing duplicate code. Still need their acks.
>
Acked-by: Paul Mundt <lethal@linux-sh.org>
--
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: Weird hard hangs when rendering 'some' web-sites in Firefox
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Américo Wang

On Tue, Jan 26, 2010 at 3:26 AM, David <david@unsolicited.net> wrote:
> Américo Wang wrote:
>> On Sun, Jan 24, 2010 at 11:04:33PM +0100, Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>>
>> >from 2.6.32. Please verify if it still should be listed and let me know
>>
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924
>>> Subject : Weird hard hangs when rendering 'some' web-sites in Firefox
>>> Submitter : David <david@unsolicited.net>
>>> Date : 2009-12-21 21:53 (35 days old)
>>> References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4
>>>
>>
>> Hmm, you have CONFIG_DETECT_SOFTLOCKUP=y, I have no idea what happened,
>> doing a bisect would be appreciated.
>>
>> Thanks.
>>
>>
>
> I no longer have the offending hardware, but I think that the issue was
> probably corrected by:
>
> cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd -
> drm/radeon/kms: Schedule host path read cache flush through the ring V2
>
> as the offending ATI graphics was indeed R300.
>

Ok, thanks!
--
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: markup_oops.pl: add options to improve cross-sompilation environments
http://groups.google.com/group/linux.kernel/t/a94bf88dc8c7132f?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Américo Wang

On Tue, Jan 26, 2010 at 11:11 AM, Hui Zhu <hui.zhu@windriver.com> wrote:
> Sorry guys, the prev mail still have some format trouble. I send a new mail
> for it.
>
> The markup_oops.pl have 3 troubles to support cross-compiler environment:
> 1. It use objdump directly.
> 2. It use modinfo to get the message of module.
> 3. It use hex function that cannot support 64-bit number in 32-bit arch.
>
> This patch add 3 options to markup_oops.pl:
> 1. -c CROSS_COMPILE Specify the prefix used for toolchain.
> 2. -m MODULE_DIRNAME Specify the module directory name.
> 3. Change hex function to Math::BigInt->from_hex.
>
> After this patch, parse the x8664 oops in x86, we can:
> cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m
> ./e.ko vmlinux
>
> Thanks,
> Hui
>
> Signed-off-by: Hui Zhu <teawater@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: ozan@pardus.org.tr
> Cc: Matthew Wilcox <willy@linux.intel.com>
>
> ---
> scripts/markup_oops.pl | 71
> ++++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 61 insertions(+), 10 deletions(-)
>
> --- a/scripts/markup_oops.pl
> +++ b/scripts/markup_oops.pl
> @@ -15,8 +15,46 @@ use Math::BigInt;
> # Arjan van de Ven <arjan@linux.intel.com>
>
>
> -my $vmlinux_name = $ARGV[0];
> -if (!defined($vmlinux_name)) {
> +my $cross_compile = "";
> +my $vmlinux_name = "";
> +my $modulefile = "";
> +
> +# Get options
> +my $option = 0;
> +for (my $i = 0; $i <= $#ARGV; $i++) {
> + if ($option == 0) {
> + if ($ARGV[$i] eq "-c") {
> + $option = 1;
> + }
> + elsif ($ARGV[$i] eq "-m") {
> + $option = 2;
> + }
> + elsif ($ARGV[$i] eq "-h") {
> + usage();
> + exit;
> + }
> + elsif ($i == $#ARGV) {
> + $vmlinux_name = $ARGV[$i];
> + }
> + else {
> + usage();
> + exit;
> + }
> + }
> + elsif ($option == 1) {
> + $cross_compile = $ARGV[$i];
> + $option = 0;
> + }
> + elsif ($option == 2) {
> + $modulefile = $ARGV[$i];
> + $option = 0;
> + }
> +}
> +
> +if ($vmlinux_name ne "") {
> + $vmlinux_name = $ARGV[$#ARGV];
> +}

Why not using the Perl module 'Getopt' to do this?
--
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: markup_oops.pl: add options to improve cross-sompilation environments
http://groups.google.com/group/linux.kernel/t/c3a28c7c96253ad8?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Hui Zhu

Sorry guys, the prev mail still have some format trouble. I send a new mail for it.

The markup_oops.pl have 3 troubles to support cross-compiler environment:
1. It use objdump directly.
2. It use modinfo to get the message of module.
3. It use hex function that cannot support 64-bit number in 32-bit arch.

This patch add 3 options to markup_oops.pl:
1. -c CROSS_COMPILE Specify the prefix used for toolchain.
2. -m MODULE_DIRNAME Specify the module directory name.
3. Change hex function to Math::BigInt->from_hex.

After this patch, parse the x8664 oops in x86, we can:
cat amd64m | perl ~/kernel/tmp/m.pl -c /home/teawater/kernel/bin/x8664- -m ./e.ko vmlinux

Thanks,
Hui

Signed-off-by: Hui Zhu <teawater@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: ozan@pardus.org.tr
Cc: Matthew Wilcox <willy@linux.intel.com>

---
scripts/markup_oops.pl | 71 ++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 61 insertions(+), 10 deletions(-)

--- a/scripts/markup_oops.pl
+++ b/scripts/markup_oops.pl
@@ -15,8 +15,46 @@ use Math::BigInt;
# Arjan van de Ven <arjan@linux.intel.com>

-my $vmlinux_name = $ARGV[0];
-if (!defined($vmlinux_name)) {
+my $cross_compile = "";
+my $vmlinux_name = "";
+my $modulefile = "";
+
+# Get options
+my $option = 0;
+for (my $i = 0; $i <= $#ARGV; $i++) {
+ if ($option == 0) {
+ if ($ARGV[$i] eq "-c") {
+ $option = 1;
+ }
+ elsif ($ARGV[$i] eq "-m") {
+ $option = 2;
+ }
+ elsif ($ARGV[$i] eq "-h") {
+ usage();
+ exit;
+ }
+ elsif ($i == $#ARGV) {
+ $vmlinux_name = $ARGV[$i];
+ }
+ else {
+ usage();
+ exit;
+ }
+ }
+ elsif ($option == 1) {
+ $cross_compile = $ARGV[$i];
+ $option = 0;
+ }
+ elsif ($option == 2) {
+ $modulefile = $ARGV[$i];
+ $option = 0;
+ }
+}
+
+if ($vmlinux_name ne "") {
+ $vmlinux_name = $ARGV[$#ARGV];
+}
+else {
my $kerver = `uname -r`;
chomp($kerver);
$vmlinux_name = "/lib/modules/$kerver/build/vmlinux";
@@ -177,26 +215,27 @@ my $decodestart = Math::BigInt->from_hex
my $decodestop = Math::BigInt->from_hex("0x$target") + 8192;
if ($target eq "0") {
print "No oops found!\n";
- print "Usage: \n";
- print " dmesg | perl scripts/markup_oops.pl vmlinux\n";
+ usage();
exit;
}

# if it's a module, we need to find the .ko file and calculate a load offset
if ($module ne "") {
- my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
- chomp($modulefile);
+ if ($modulefile eq "") {
+ my $modulefile = `modinfo $module | grep '^filename:' | awk '{ print \$2 }'`;
+ chomp($modulefile);
+ }
$filename = $modulefile;
if ($filename eq "") {
print "Module .ko file for $module not found. Aborting\n";
exit;
}
# ok so we found the module, now we need to calculate the vma offset
- open(FILE, "objdump -dS $filename |") || die "Cannot start objdump";
+ open(FILE, $cross_compile."objdump -dS $filename |") || die "Cannot start objdump";
while (<FILE>) {
if ($_ =~ /^([0-9a-f]+) \<$function\>\:/) {
my $fu = $1;
- $vmaoffset = hex($target) - hex($fu) - hex($func_offset);
+ $vmaoffset = Math::BigInt->from_hex("0x$target") - Math::BigInt->from_hex("0x$fu") - Math::BigInt->from_hex("0x$func_offset");
}
}
close(FILE);
@@ -212,7 +251,7 @@ sub InRange {
my ($address, $target) = @_;
my $ad = "0x".$address;
my $ta = "0x".$target;
- my $delta = hex($ad) - hex($ta);
+ my $delta = Math::BigInt->from_hex($ad) - Math::BigInt->from_hex($ta);

if (($delta > -4096) && ($delta < 4096)) {
return 1;
@@ -225,7 +264,7 @@ sub InRange {
# first, parse the input into the lines array, but to keep size down,
# we only do this for 4Kb around the sweet spot

-open(FILE, "objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";
+open(FILE, $cross_compile."objdump -dS --adjust-vma=$vmaoffset --start-address=$decodestart --stop-address=$decodestop $filename |") || die "Cannot start objdump";

while (<FILE>) {
my $line = $_;
@@ -344,3 +383,15 @@ while ($i < $finish) {
$i = $i +1;
}

+sub usage {
+ print <<EOT;
+Usage:
+ dmesg | perl $0 [OPTION] [VMLINUX]
+
+OPTION:
+ -c CROSS_COMPILE Specify the prefix used for toolchain.
+ -m MODULE_DIRNAME Specify the module directory name.
+ -h Help
+EOT
+}
+
--
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: tracing: reduce latency and remove percpu trace_seq
http://groups.google.com/group/linux.kernel/t/2364c2512709f3a6?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:10 pm
From: Lai Jiangshan

Frederic Weisbecker wrote:
> On Tue, Jan 19, 2010 at 03:34:22PM +0800, Lai Jiangshan wrote:
>> __print_flags() and __print_symbolic() use percpu trace_seq:
>>
>> 1) Its memory is preallocated, it wastes memory when we don't use tracing.
>> 2) It wastes memory for multi-cpus system.
>> 3) It disables preemption when it executes its core routine
>> "trace_seq_printf(s, "%s: ", #call);" and introduce latency
>> for more important process.
>>
>> So we move this trace_seq to struct trace_iterator.
>>
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
>> index be9ece5..348500d 100644
>> --- a/include/linux/ftrace_event.h
>> +++ b/include/linux/ftrace_event.h
>> @@ -12,9 +12,6 @@ struct dentry;
>>
>> #define FTRACE_SEQ_BUFSIZE PAGE_SIZE
>>
>> -DECLARE_PER_CPU(struct trace_seq, ftrace_event_seq);
>> -DECLARE_PER_CPU(unsigned char[FTRACE_SEQ_BUFSIZE], ftrace_event_buffer);
>> -
>> struct trace_print_flags {
>> unsigned long mask;
>> const char *name;
>> @@ -60,6 +57,10 @@ struct trace_iterator {
>> struct trace_seq seq;
>> unsigned char buffer[FTRACE_SEQ_BUFSIZE];
>>
>> + /* trace_seq for __print_flags() and __print_symbolic() */
>> + struct trace_seq tmp_seq;
>> + unsigned char tmp_buffer[FTRACE_SEQ_BUFSIZE];
>
>
>
>
> Well, I don't like much that because it's a temporary buffer
> in trace iter only used by few events.
> But the problem is indeed tricky.
>
> May be should we use a kmalloc in raw_output?
>

But we have to preallocate it before raw_output().
a kmalloc in raw_output make ftrace_dump() unhappy.

At real system, tracepoints are used more frequently,
So it is not "only used by few events."

But maybe FTRACE_SEQ_BUFSIZE is too large, 128 is enough.
--
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: tty: possible irq lock inversion dependency in tty_fasync
http://groups.google.com/group/linux.kernel/t/e7fe1257ceb196f4?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:20 pm
From: Tetsuo Handa

Hello.

I got this on 2.6.32.6 .
Config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.32.6

# cat /proc/version
Linux version 2.6.32.6 (root@tomoyo) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Tue Jan 26 11:35:08 JST 2010
# cat /proc/cmdline
root=/dev/sda1 ro ramdisk=16384 console=ttyS0,115200n8 console=tty kmemleak=off
# dmesg
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.32.6 #1
---------------------------------------------------------
swapper/0 just changed the state of lock:
(&sighand->siglock){-.....}, at: [<c10515bd>] lock_task_sighand+0x5d/0xa0
but this lock took another, HARDIRQ-unsafe lock in the past:
(&tty->ctrl_lock){+.+...}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
2 locks held by swapper/0:
#0: (rcu_read_lock){.+.+..}, at: [<c10516c0>] kill_pid_info+0x0/0x90
#1: (rcu_read_lock){.+.+..}, at: [<c1051560>] lock_task_sighand+0x0/0xa0

the shortest dependencies between 2nd lock and 1st lock:
-> (&tty->ctrl_lock){+.+...} ops: 97 {
HARDIRQ-ON-W at:
[<c106e5e2>] mark_held_locks+0x42/0x80
[<c106e6e6>] trace_hardirqs_on_caller+0xa6/0x160
[<c106e7ab>] trace_hardirqs_on+0xb/0x10
[<c1343487>] _write_unlock_irq+0x27/0x30
[<c10e517b>] f_modown+0x6b/0x80
[<c10e51d1>] __f_setown+0x41/0x50
[<c11e5e8c>] tty_fasync+0xbc/0x110
[<c10e50d8>] setfl+0x118/0x150
[<c10e557f>] do_fcntl+0xcf/0x1e0
[<c10e5788>] sys_fcntl64+0x88/0xa0
[<c1002f99>] syscall_call+0x7/0xb
SOFTIRQ-ON-W at:
[<c106e5e2>] mark_held_locks+0x42/0x80
[<c106e737>] trace_hardirqs_on_caller+0xf7/0x160
[<c106e7ab>] trace_hardirqs_on+0xb/0x10
[<c1343487>] _write_unlock_irq+0x27/0x30
[<c10e517b>] f_modown+0x6b/0x80
[<c10e51d1>] __f_setown+0x41/0x50
[<c11e5e8c>] tty_fasync+0xbc/0x110
[<c10e50d8>] setfl+0x118/0x150
[<c10e557f>] do_fcntl+0xcf/0x1e0
[<c10e5788>] sys_fcntl64+0x88/0xa0
[<c1002f99>] syscall_call+0x7/0xb
INITIAL USE at:
[<c106f6f4>] __lock_acquire+0x1b4/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c11e7427>] __proc_set_tty+0x27/0xf0
[<c11e751f>] proc_set_tty+0x2f/0x50
[<c11e62cd>] tiocsctty+0xed/0x100
[<c11e6998>] tty_ioctl+0x1b8/0x320
[<c10e5e24>] vfs_ioctl+0x74/0x90
[<c10e6a90>] do_vfs_ioctl+0x60/0x1a0
[<c10e6c1f>] sys_ioctl+0x4f/0x70
[<c1002f99>] syscall_call+0x7/0xb
}
... key at: [<c1d31c5c>] __key.13+0x0/0x8
... acquired at:
[<c106cfa2>] check_prev_add+0x212/0x7e0
[<c106d614>] check_prevs_add+0xa4/0x100
[<c106d99a>] validate_chain+0x2fa/0x520
[<c106f7e1>] __lock_acquire+0x2a1/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c11e7427>] __proc_set_tty+0x27/0xf0
[<c11e751f>] proc_set_tty+0x2f/0x50
[<c11e62cd>] tiocsctty+0xed/0x100
[<c11e6998>] tty_ioctl+0x1b8/0x320
[<c10e5e24>] vfs_ioctl+0x74/0x90
[<c10e6a90>] do_vfs_ioctl+0x60/0x1a0
[<c10e6c1f>] sys_ioctl+0x4f/0x70
[<c1002f99>] syscall_call+0x7/0xb

-> (&sighand->siglock){-.....} ops: 118136 {
IN-HARDIRQ-W at:
[<c106ec48>] mark_irqflags+0x168/0x180
[<c106f8bc>] __lock_acquire+0x37c/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c10515bd>] lock_task_sighand+0x5d/0xa0
[<c10513e1>] do_send_sig_info+0x31/0x70
[<c1051646>] group_send_sig_info+0x46/0x50
[<c1051726>] kill_pid_info+0x66/0x90
[<c10456d8>] it_real_fn+0x38/0x80
[<c105ef9f>] __run_hrtimer+0x7f/0x160
[<c105f11e>] hrtimer_run_queues+0x8e/0xb0
[<c104fa0d>] run_local_timers+0xd/0x20
[<c104f724>] update_process_times+0x34/0x60
[<c1068afa>] tick_periodic+0x2a/0x80
[<c1068b6e>] tick_handle_periodic+0x1e/0x80
[<c101880d>] local_apic_timer_interrupt+0x5d/0x60
[<c1343923>] smp_apic_timer_interrupt+0x33/0x42
[<c10038bb>] apic_timer_interrupt+0x2f/0x34
[<c10015ea>] cpu_idle+0x6a/0xc0
[<c132e168>] rest_init+0x58/0x60
[<c15129c6>] start_kernel+0x206/0x290
[<c1512095>] i386_start_kernel+0x65/0xa0
INITIAL USE at:
[<c106f6f4>] __lock_acquire+0x1b4/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c1050514>] flush_signals+0x24/0x50
[<c105068c>] ignore_signals+0x3c/0x40
[<c105b726>] kthreadd+0x26/0xd0
[<c1003a77>] kernel_thread_helper+0x7/0x10
}
... key at: [<c17130d8>] __key.12+0x0/0x8
... acquired at:
[<c106e0f8>] check_usage_forwards+0x78/0xe0
[<c106e3f9>] mark_lock_irq+0x99/0x240
[<c106eeb6>] mark_lock+0x1d6/0x370
[<c106ec48>] mark_irqflags+0x168/0x180
[<c106f8bc>] __lock_acquire+0x37c/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c10515bd>] lock_task_sighand+0x5d/0xa0
[<c10513e1>] do_send_sig_info+0x31/0x70
[<c1051646>] group_send_sig_info+0x46/0x50
[<c1051726>] kill_pid_info+0x66/0x90
[<c10456d8>] it_real_fn+0x38/0x80
[<c105ef9f>] __run_hrtimer+0x7f/0x160
[<c105f11e>] hrtimer_run_queues+0x8e/0xb0
[<c104fa0d>] run_local_timers+0xd/0x20
[<c104f724>] update_process_times+0x34/0x60
[<c1068afa>] tick_periodic+0x2a/0x80
[<c1068b6e>] tick_handle_periodic+0x1e/0x80
[<c101880d>] local_apic_timer_interrupt+0x5d/0x60
[<c1343923>] smp_apic_timer_interrupt+0x33/0x42
[<c10038bb>] apic_timer_interrupt+0x2f/0x34
[<c10015ea>] cpu_idle+0x6a/0xc0
[<c132e168>] rest_init+0x58/0x60
[<c15129c6>] start_kernel+0x206/0x290
[<c1512095>] i386_start_kernel+0x65/0xa0

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.32.6 #1
Call Trace:
[<c1041b7d>] ? printk+0x1d/0x30
[<c106e068>] print_irq_inversion_bug+0x108/0x120
[<c106e0f8>] check_usage_forwards+0x78/0xe0
[<c106e3f9>] mark_lock_irq+0x99/0x240
[<c106e080>] ? check_usage_forwards+0x0/0xe0
[<c106eeb6>] mark_lock+0x1d6/0x370
[<c106e7d0>] ? trace_hardirqs_off_caller+0x20/0xc0
[<c106ec48>] mark_irqflags+0x168/0x180
[<c106f8bc>] __lock_acquire+0x37c/0x8a0
[<c106f81c>] ? __lock_acquire+0x2dc/0x8a0
[<c1070ddd>] lock_acquire+0x7d/0xe0
[<c10515bd>] ? lock_task_sighand+0x5d/0xa0
[<c1342af9>] _spin_lock_irqsave+0x49/0x90
[<c10515bd>] ? lock_task_sighand+0x5d/0xa0
[<c10515bd>] lock_task_sighand+0x5d/0xa0
[<c1051560>] ? lock_task_sighand+0x0/0xa0
[<c10513e1>] do_send_sig_info+0x31/0x70
[<c1051646>] group_send_sig_info+0x46/0x50
[<c1051726>] kill_pid_info+0x66/0x90
[<c10516c0>] ? kill_pid_info+0x0/0x90
[<c105ef91>] ? __run_hrtimer+0x71/0x160
[<c10456d8>] it_real_fn+0x38/0x80
[<c105ef9f>] __run_hrtimer+0x7f/0x160
[<c1342fb3>] ? _spin_lock+0x53/0x80
[<c10456a0>] ? it_real_fn+0x0/0x80
[<c105f11e>] hrtimer_run_queues+0x8e/0xb0
[<c104fa0d>] run_local_timers+0xd/0x20
[<c104f724>] update_process_times+0x34/0x60
[<c1068afa>] tick_periodic+0x2a/0x80
[<c1068b6e>] tick_handle_periodic+0x1e/0x80
[<c101880d>] local_apic_timer_interrupt+0x5d/0x60
[<c1343923>] smp_apic_timer_interrupt+0x33/0x42
[<c10038bb>] apic_timer_interrupt+0x2f/0x34
[<c100a902>] ? default_idle+0x42/0xa0
[<c10015ea>] cpu_idle+0x6a/0xc0
[<c132e168>] rest_init+0x58/0x60
[<c15129c6>] start_kernel+0x206/0x290
[<c15122c0>] ? unknown_bootoption+0x0/0x130
[<c1512095>] i386_start_kernel+0x65/0xa0

--
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: tracing: Change trace_seq to use separate buffer
http://groups.google.com/group/linux.kernel/t/303bad7e1d71273e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:30 pm
From: Lai Jiangshan

Frederic Weisbecker wrote:
> On Tue, Jan 19, 2010 at 03:34:16PM +0800, Lai Jiangshan wrote:
>> @@ -3124,6 +3126,8 @@ waitagain:
>> if (cnt >= PAGE_SIZE)
>> cnt = PAGE_SIZE - 1;
>>
>> + trace_seq_reset(&iter->seq);
>> +
>
>
>
> So we actually add a trace_seq_reset here.
> This should have been in the first patch, which drops
> the memset, and eventually modified here, just to avoid
> breaking things in the middle of a patchset.
>
> Things were already broken though before the memset dropping
> patch though in other ways, so it's not that important I guess...
>
>

There is no trace_seq_reset() before this patch applied.
trace_seq_init() in the first patch, has already reset it.

Things are not broken by the first patch, if I did not misunderstand.
--
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: starting emacs makes lockdep warning
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:30 pm
From: KOSAKI Motohiro

Current linus tree made following lockdep warning when starting emacs command.
Is this known issue?

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
2.6.33-rc5 #77
---------------------------------------------------------
emacs/1609 just changed the state of lock:
(&(&tty->ctrl_lock)->rlock){+.....}, at: [<ffffffff8127c648>] tty_fasync+0xe8/0x190
but this lock took another, HARDIRQ-unsafe lock in the past:
(&(&sighand->siglock)->rlock){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
1 lock held by emacs/1609:
#0: (&(&tty->ctrl_lock)->rlock){+.....}, at: [<ffffffff8127c648>] tty_fasync+0xe8/0x190

the shortest dependencies between 2nd lock and 1st lock:
-> (&(&sighand->siglock)->rlock){-.....} ops: 50393 {
IN-HARDIRQ-W at:
[<ffffffff8108924e>] __lock_acquire+0x7ae/0x15a0
[<ffffffff8108a0df>] lock_acquire+0x9f/0x120
[<ffffffff81423012>] _raw_spin_lock_irqsave+0x52/0x90
[<ffffffff81065799>] lock_task_sighand+0x79/0x100
[<ffffffff8106600f>] do_send_sig_info+0x3f/0x90
[<ffffffff810660f0>] group_send_sig_info+0x40/0x50
[<ffffffff81066703>] kill_pid_info+0x73/0xe0
[<ffffffff81054014>] it_real_fn+0x44/0xa0
[<ffffffff81075d1e>] __run_hrtimer+0x8e/0x1e0
[<ffffffff81076116>] hrtimer_interrupt+0xe6/0x250
[<ffffffff8142a0b9>] smp_apic_timer_interrupt+0x69/0x9b
[<ffffffff81003a93>] apic_timer_interrupt+0x13/0x20
[<ffffffff81001956>] cpu_idle+0x66/0xd0
[<ffffffff814082e2>] rest_init+0x92/0xa0
[<ffffffff81b4cd84>] start_kernel+0x3b9/0x3c5
[<ffffffff81b4c310>] x86_64_start_reservations+0x120/0x124
[<ffffffff81b4c3f8>] x86_64_start_kernel+0xe4/0xeb
INITIAL USE at:
[<ffffffff81088e86>] __lock_acquire+0x3e6/0x15a0
[<ffffffff8108a0df>] lock_acquire+0x9f/0x120
[<ffffffff81423012>] _raw_spin_lock_irqsave+0x52/0x90
[<ffffffff810646dc>] flush_signals+0x2c/0x60
[<ffffffff81064743>] ignore_signals+0x33/0x40
[<ffffffff81071067>] kthreadd+0x37/0x180
[<ffffffff81003ed4>] kernel_thread_helper+0x4/0x10
}
... key at: [<ffffffff81c054a4>] __key.46539+0x0/0x8
... acquired at:
[<ffffffff81089af6>] __lock_acquire+0x1056/0x15a0
[<ffffffff8108a0df>] lock_acquire+0x9f/0x120
[<ffffffff81423012>] _raw_spin_lock_irqsave+0x52/0x90
[<ffffffff8127c1be>] __proc_set_tty+0x3e/0x150
[<ffffffff8127e01d>] tty_open+0x51d/0x5e0
[<ffffffff81142400>] chrdev_open+0x170/0x290
[<ffffffff8113c561>] __dentry_open+0x131/0x3a0
[<ffffffff8113c8e4>] nameidata_to_filp+0x54/0x70
[<ffffffff8114c098>] do_filp_open+0x948/0xcd0
[<ffffffff8113c2e9>] do_sys_open+0x69/0x140
[<ffffffff8113c400>] sys_open+0x20/0x30
[<ffffffff8100309b>] system_call_fastpath+0x16/0x1b

-> (&(&tty->ctrl_lock)->rlock){+.....} ops: 191 {
HARDIRQ-ON-W at:
[<ffffffff81087e63>] mark_held_locks+0x73/0xa0
[<ffffffff810880bb>] trace_hardirqs_on_caller+0x7b/0x1c0
[<ffffffff8108820d>] trace_hardirqs_on+0xd/0x10
[<ffffffff81423730>] _raw_write_unlock_irq+0x30/0x60
[<ffffffff8114cc63>] f_modown+0x53/0xe0
[<ffffffff8114cd1e>] __f_setown+0xe/0x20
[<ffffffff8127c667>] tty_fasync+0x107/0x190
[<ffffffff8114d842>] sys_fcntl+0x222/0x580
[<ffffffff8100309b>] system_call_fastpath+0x16/0x1b
INITIAL USE at:
[<ffffffff81088e86>] __lock_acquire+0x3e6/0x15a0
[<ffffffff8108a0df>] lock_acquire+0x9f/0x120
[<ffffffff81423012>] _raw_spin_lock_irqsave+0x52/0x90
[<ffffffff8127c1be>] __proc_set_tty+0x3e/0x150
[<ffffffff8127e01d>] tty_open+0x51d/0x5e0
[<ffffffff81142400>] chrdev_open+0x170/0x290
[<ffffffff8113c561>] __dentry_open+0x131/0x3a0
[<ffffffff8113c8e4>] nameidata_to_filp+0x54/0x70
[<ffffffff8114c098>] do_filp_open+0x948/0xcd0
[<ffffffff8113c2e9>] do_sys_open+0x69/0x140
[<ffffffff8113c400>] sys_open+0x20/0x30
[<ffffffff8100309b>] system_call_fastpath+0x16/0x1b
}
... key at: [<ffffffff82533fb8>] __key.30033+0x0/0x8
... acquired at:
[<ffffffff81087263>] check_usage_backwards+0x93/0x100
[<ffffffff81087b9a>] mark_lock+0x1ca/0x420
[<ffffffff81087e63>] mark_held_locks+0x73/0xa0
[<ffffffff810880bb>] trace_hardirqs_on_caller+0x7b/0x1c0
[<ffffffff8108820d>] trace_hardirqs_on+0xd/0x10
[<ffffffff81423730>] _raw_write_unlock_irq+0x30/0x60
[<ffffffff8114cc63>] f_modown+0x53/0xe0
[<ffffffff8114cd1e>] __f_setown+0xe/0x20
[<ffffffff8127c667>] tty_fasync+0x107/0x190
[<ffffffff8114d842>] sys_fcntl+0x222/0x580
[<ffffffff8100309b>] system_call_fastpath+0x16/0x1b

stack backtrace:
Pid: 1609, comm: emacs Not tainted 2.6.33-rc5 #77
Call Trace:
[<ffffffff810870bd>] print_irq_inversion_bug.clone.0+0x12d/0x140
[<ffffffff810871d0>] ? check_usage_backwards+0x0/0x100
[<ffffffff81087263>] check_usage_backwards+0x93/0x100
[<ffffffff8114cc4c>] ? f_modown+0x3c/0xe0
[<ffffffff81087b9a>] mark_lock+0x1ca/0x420
[<ffffffff81087e63>] mark_held_locks+0x73/0xa0
[<ffffffff81423730>] ? _raw_write_unlock_irq+0x30/0x60
[<ffffffff810880bb>] trace_hardirqs_on_caller+0x7b/0x1c0
[<ffffffff8108820d>] trace_hardirqs_on+0xd/0x10
[<ffffffff81423730>] _raw_write_unlock_irq+0x30/0x60
[<ffffffff8114cc63>] f_modown+0x53/0xe0
[<ffffffff8114cd1e>] __f_setown+0xe/0x20
[<ffffffff8127c667>] tty_fasync+0x107/0x190
[<ffffffff8114d842>] sys_fcntl+0x222/0x580
[<ffffffff8100309b>] system_call_fastpath+0x16/0x1b

==============================================================================
TOPIC: : bug fix, remove partial zero out
http://groups.google.com/group/linux.kernel/t/0bd48232b337c1b8?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 7:40 pm
From: Lai Jiangshan

Frederic Weisbecker wrote:
> On Tue, Jan 19, 2010 at 03:33:56PM +0800, Lai Jiangshan wrote:
>> partial-zero-out a struct is very dangerous, we should zero out
>> field by field directly when need.
>>
>> partial-zero-out for struct trace_iterator exists when ftrace
>> was first introduced into mainline kernel. But in this few years,
>> the code of ftrace is changed a lot, and:
>>
>> 1) partial-zero-out for struct trace_iterator has a bug now,
>> cpumask_var_t started should not be zeroed out.
>>
>> 2) I viewed the codes and found that fields below
>> "/* The below is zeroed out in pipe_read */"
>> don't need to be zeroed out or initialized now.
>>
>> So, we remove the code of "partial zero out"
>>
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
>> index 3ca9485..c6d0e1a 100644
>> --- a/include/linux/ftrace_event.h
>> +++ b/include/linux/ftrace_event.h
>> @@ -54,7 +54,6 @@ struct trace_iterator {
>> struct ring_buffer_iter *buffer_iter[NR_CPUS];
>> unsigned long iter_flags;
>>
>> - /* The below is zeroed out in pipe_read */
>> struct trace_seq seq;
>> struct trace_entry *ent;
>> int leftover;
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index 5314c90..27fecf8 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -3124,12 +3124,6 @@ waitagain:
>> if (cnt >= PAGE_SIZE)
>> cnt = PAGE_SIZE - 1;
>>
>> - /* reset all but tr, trace, and overruns */
>> - memset(&iter->seq, 0,
>> - sizeof(struct trace_iterator) -
>> - offsetof(struct trace_iterator, seq));
>> - iter->pos = -1;
>> -
>
>
>
> I'm not sure exaclty why we needed to zero the seq here.
> We already reset it in trace_seq_init().
>
> We might do it again on waitagain. I lost track how we could
> ever need to goto waitagain. It was about a tricky bug to fix
> but I'm don't remember exactly the details.
>
> That said, if trace_seq_to_user returns -EBUSY, we
> re-init the seq buffer, so it should be fine I guess.

Yes, -EBUSY is strange here.
but any way, trace_seq_init() is called.

>
> But concerning the need of setting iter->pos to -1, I'm not
> sure we need to remove it. Shouldn't it be set to 0 btw?
>

->pos is not used here, ->idx is just increased here,
so we don't need to initialize them.

==============================================================================
TOPIC: infiniband limit of 32 cards per system?
http://groups.google.com/group/linux.kernel/t/ae5013eea7f9b81f?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 7:50 pm
From: Roland Dreier

> My colleague points out the following enum in uverbs_main.c:
>
> enum {
> IB_UVERBS_MAJOR = 231,
> IB_UVERBS_BASE_MINOR = 192,
> IB_UVERBS_MAX_DEVICES = 32
> };
>
> Experimentally, we've determined that on a system where we
> plugged in 40 IB cards, OFED only reports 32 cards are present.

wow, 40 HCAs in one system !

> If that enum is indeed the limiting factor, would someone mind
> explaining (or pointing me at TFM ;) why it's limited to 32
> devices?

That dates back to when device #s had 8 bits for major and 8 bits for
minor. We got one major assigned for IB, and had to split up the 256
minors that gave us among userspace verbs, management access, etc. And
32 seemed like a pretty reasonable limit for most uses.

Nowadays I guess we should look into expanding that to dynamic device
numbers on overflow, assuming you do have a realistic situation where
someone would want to use that many adapters per system.

- R.
--
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: Mon, Jan 25 2010 8:10 pm
From: Roland Dreier

> I'm guessing that it's not just a simple kernel fix though since
> OFED has to change too, right?

Dunno about OFED. Nothing sane is hard-coding major/minor numbers
though -- so I think OFED should be OK, asuming there are no crazy
scripts that bypass udev creating device nodes etc.

I don't think that it's _totally_ trivial in the kernel -- we do need to
add some code in several places to allocate dynamic device numbers when
we run out of the static allocation (probably best to keep the legacy
device numbers for "small" < 32 adapter systems, since there may be
really small systems with static hard-coded /dev etc).

- R.

== 3 of 3 ==
Date: Mon, Jan 25 2010 8:10 pm
From: Alex Chiang

* Roland Dreier <rdreier@cisco.com>:
>
> > My colleague points out the following enum in uverbs_main.c:
> >
> > enum {
> > IB_UVERBS_MAJOR = 231,
> > IB_UVERBS_BASE_MINOR = 192,
> > IB_UVERBS_MAX_DEVICES = 32
> > };
> >
> > Experimentally, we've determined that on a system where we
> > plugged in 40 IB cards, OFED only reports 32 cards are present.
>
> wow, 40 HCAs in one system !

HP sell some pretty big systems. :)

> > If that enum is indeed the limiting factor, would someone mind
> > explaining (or pointing me at TFM ;) why it's limited to 32
> > devices?
>
> That dates back to when device #s had 8 bits for major and 8 bits for
> minor. We got one major assigned for IB, and had to split up the 256
> minors that gave us among userspace verbs, management access, etc. And
> 32 seemed like a pretty reasonable limit for most uses.

Thanks for the explanation.

> Nowadays I guess we should look into expanding that to dynamic device
> numbers on overflow, assuming you do have a realistic situation where
> someone would want to use that many adapters per system.

Think of a large scale-up ia64 box, possibly running some
virtualization stack.

I'm guessing that it's not just a simple kernel fix though since
OFED has to change too, right?

/ac
--
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: Use full path to dnsdomainname and domainname in scripts/mkcompile_h
http://groups.google.com/group/linux.kernel/t/e0aebdfb17688691?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 8:00 pm
From: Américo Wang

On Wed, Jan 20, 2010 at 11:06 PM, Glenn Sommer <glemsom@gmail.com> wrote:
> 2010/1/20 Américo Wang <xiyou.wangcong@gmail.com>:
>> On Wed, Jan 20, 2010 at 2:29 AM, Glenn Sommer <glemsom@gmail.com> wrote:
>>> With reference to: http://bugzilla.kernel.org/show_bug.cgi?id=14920
>>> I'll post my suggestion here.
>>>
>>> Currently scripts/mkcompile_h checks for "/bin/dnsdomainname" and
>>> "/bin/domainname" when trying to find the DNS name.
>>> Though, when running the executable - the full path isn't used!
>>>
>>> IMO if we check for "/bin/dnsdomainname", we should also use
>>> "/bin/dnsdomainname" - and not blindly trust /bin is the first directory in
>>> $PATH which contains a executable named "dnsdomainname"
>>>
>>>
>>> I propose to use the full path, that we know is valid. Here's my proposed patch:
>>>
>>>
>>> --- scripts/mkcompile_h.orig 2009-12-28 23:02:34.000000000 +0100
>>> +++ scripts/mkcompile_h 2009-12-28 23:03:12.000000000 +0100
>>> @@ -66,9 +66,9 @@
>>> echo \#define LINUX_COMPILE_HOST \"`hostname | $UTS_TRUNCATE`\"
>>>
>>> if [ -x /bin/dnsdomainname ]; then
>>> - echo \#define LINUX_COMPILE_DOMAIN \"`dnsdomainname | $UTS_TRUNCATE`\"
>>> + echo \#define LINUX_COMPILE_DOMAIN \"`/bin/dnsdomainname | $UTS_TRUNCATE`\"
>>> elif [ -x /bin/domainname ]; then
>>> - echo \#define LINUX_COMPILE_DOMAIN \"`domainname | $UTS_TRUNCATE`\"
>>> + echo \#define LINUX_COMPILE_DOMAIN \"`/bin/domainname | $UTS_TRUNCATE`\"
>>> else
>>> echo \#define LINUX_COMPILE_DOMAIN
>>> fi
>>>
>>>
>>> Signed-off-by: Glenn Sommer <glemsom@gmail.com>
>>
>> Makes sense, but is that possible we have 'domainname' installed in two
>> different directories?
>>
>
> Usually "domainname" should be installed in /bin.
> I'm just thinking if one does something like this:
>
> * Place shellscript named "domainname" in /home/stupiduser/scripts
> (This shellscript should output some text... Let's say
> "my-stupid-shell-script")
> * Set PATH=/home/stupiduser/scripts:$PATH
> * Compile Linux kernel
>
> Doing the above will result in scripts/mkcompile_h testing for
> /bin/domainname, but actually using
> /home/stupiduser/scripts/domainname - which is this case will output
> something wrong.
> One could argue it's your own fault then - and I agree! Doing the
> above is stupid!
>
> Anyway, if we test for the executable using a complete path - we
> should also use that complete path when running the executable!
>
>
> Alternatively, if we want it to be more flexible(and allow the above)
> - we should do something like:
>
> domainname_executable=`which domainname`
> if [ ! -z "$domainname_executable" ] && [ -x "$domainname_executable" ]; then
>

Yeah, this seems better for me.
Thanks!
--
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: gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka
spitz: fix warn_on introduced in 2.6.32-rc1)
http://groups.google.com/group/linux.kernel/t/337ac495cfb9a0e2?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 8:10 pm
From: Eric Miao

> 2) gpio_keys driver should be capable to set IRQF_TRIGGER_* and no
> settings of wake-up registers in spitz_pm.c would not be needed.
>
> On platforms with shared interrupts it would introduce possible multiple
> trigger initialization (not a big problem). But it would easily
> introduce breakage if programmer makes a mistake and configures
> interrupt with different trigger in different drivers.
>
>
> I am not sure what solution of these two is in spirit of modern kernels.
> I guess that 2. Especially because somebody may want to use gpio_keys on
> a different machine/GPIO layout that would require different
> IRQF_TRIGGER_*.
>

I prefer 2) - the ugly and hardcoded setup in spitz_pm.c should really
be removed. That's why the gpio_set_wake() and keypad_set_wake()
are introduced.

keypad_set_wake() is really specifically introduced for use by pxa27x_keypad
and no generic GPIO stuffs. So it's really annoying a GPIO will use
the PKWR as a wakeup GPIO, I'd recommend one still get this hard coded
into the platform file, with combination of WAKEUP_ON_LEVEL_HIGH (which
is specifically designed for keypad GPIOs) and keypad_set_wake().

The spitz, however, is doing a good job on this though it's using a GPIO
emulated matrix keypad, that there is a separate SPITZ_GPIO_KEY_INT,
which triggers whenever there is any key press on this matrix (I don't
know how that's designed in HW, but it seems to do that job), and
which can be setup as a GPIO wakeup.

>
> Notes:
>
> Automatic PKWR/PWER logic is impossible for PXA270. GPIO 38 can be
> programmed to use both PKWR or PWER.
>

That's a shame of pxa27x, but so far no awkward usage of this
has ever been seen.

> The gpio_keys seems to have problems with debounce - in 50% of all
> resumes, Zaurus goes back to sleep in a second or so.
>

There is a routine checking wakeup source (cause) which will put the
system back into sleep in some cases, I guess you need to check if
something weird there.
--
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: regulator: trivial: fix typos in user-visible Kconfig text
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 8:20 pm
From: Alex Chiang

Fix Kconfig text for some Wolfson Micro devices.

Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
---
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 262f62e..c565e0d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -91,14 +91,14 @@ config REGULATOR_WM831X
of PMIC devices.

config REGULATOR_WM8350
- tristate "Wolfson Microelectroncis WM8350 AudioPlus PMIC"
+ tristate "Wolfson Microelectronics WM8350 AudioPlus PMIC"
depends on MFD_WM8350
help
This driver provides support for the voltage and current regulators
of the WM8350 AudioPlus PMIC.

config REGULATOR_WM8400
- tristate "Wolfson Microelectroncis WM8400 AudioPlus PMIC"
+ tristate "Wolfson Microelectronics WM8400 AudioPlus PMIC"
depends on MFD_WM8400
help
This driver provides support for the voltage regulators of the
--
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: kgdb regression fixes for 2.6.33
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 25 2010 8:30 pm
From: Jason Wessel

I would like to get acks from the respective parties to fix these
reported regressions against kgdb in 2.6.33.

I imagine the constraints for the hw breakpoint API is possibly still
a dicey issue, so it is split into its own patch. Even without the
constraints patch it is possible to use hw breakpoints in the kernel
debugger in the same manner that has existed since 2.6.26 (only kgdb
gets to use hw breakpoints).

The regression are:
* hw breakpoints no longer work on x86 after the perf API merge
* clocksource watchdog can dead lock while in the kernel debugger
* softlockup watchdog can reboot the system while using the kernel debugger

I collected all the patches which could go into the tip branch or the
kgdb for_linus branch at the following location depending on the
status of the discussion that ensues.

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_igno

Thanks,
Jason.

---
The following changes since commit 92dcffb916d309aa01778bf8963a6932e4014d07:
Linus Torvalds (1):
Linux 2.6.33-rc5

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git for_ingo

Jason Wessel (4):
x86,hw_breakpoint,kgdb: kgdb to use hw_breakpoint API
perf,hw_breakpoint: add lockless reservation for hw_breaks
kgdb,clocksource: Prevent kernel hang in kernel debugger
softlockup: add sched_clock_tick() to avoid kernel warning on kgdb resume

arch/x86/kernel/hw_breakpoint.c | 5 +-
arch/x86/kernel/kgdb.c | 216 ++++++++++++++++++++++++++++-----------
include/linux/perf_event.h | 1 +
include/linux/sched.h | 4 +
kernel/hw_breakpoint.c | 16 +++
kernel/kgdb.c | 9 +-
kernel/softlockup.c | 15 +++
kernel/time/clocksource.c | 7 +-
8 files changed, 205 insertions(+), 68 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/

== 2 of 2 ==
Date: Mon, Jan 25 2010 8:30 pm
From: Jason Wessel

In the 2.6.33 kernel, the hw_breakpoint API is now used for the
performance event counters. The hw_breakpoint_handler() now consumes
the hw breakpoints that were previously set by kgdb arch specific
code. In order for kgdb to work in conjunction with this core API
change, kgdb must use some of the low level functions of the
hw_breakpoint API to install, uninstall, and receive call backs for hw
breakpoints.

The kgdb core needs to call kgdb_disable_hw_debug anytime a slave cpu
enters kgdb_wait() in order to keep all the hw breakpoints in sync as
well as to prevent hitting a hw breakpoint while kgdb is active.

During the architecture specific initialization of kgdb, it will
pre-allocate 4 disabled (struct perf event **) structures. Kgdb will
use these to manage the capabilities for the 4 hw breakpoint
registers. Right now the hw_breakpoint API does not have a way to ask
how many breakpoints are available, on each CPU so it is possible that
the install of a breakpoint might fail when kgdb restores the system
to the run state. The intent of this patch is to first get the basic
functionality of hw breakpoints working and leave it to the person
debugging the kernel to understand what hw breakpoints are in use and
what restrictions have been imposed as a result.

While atomic, the x86 specific kgdb code will call
arch_uninstall_hw_breakpoint() and arch_install_hw_breakpoint() to
manage the cpu specific hw breakpoints.

The arch specific hw_breakpoint_handler() was changed to restore the
cpu specific dr7 instead of the dr7 that was locally saved, because
the dr7 can be modified while in a call back to kgdb.

The net result of these changes allow kgdb to use the same pool of
hw_breakpoints that are used by the perf event API, but neither knows
about future reservations for the available hw breakpoint slots.

CC: Frederic Weisbecker <fweisbec@gmail.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: K.Prasad <prasad@linux.vnet.ibm.com>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
arch/x86/kernel/hw_breakpoint.c | 5 +-
arch/x86/kernel/kgdb.c | 206 ++++++++++++++++++++++++++++-----------
kernel/kgdb.c | 3 +
3 files changed, 152 insertions(+), 62 deletions(-)

diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 05d5fec..cbf19e0 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -466,7 +466,7 @@ static int __kprobes hw_breakpoint_handler(struct die_args *args)
{
int i, cpu, rc = NOTIFY_STOP;
struct perf_event *bp;
- unsigned long dr7, dr6;
+ unsigned long dr6;
unsigned long *dr6_p;

/* The DR6 value is pointed by args->err */
@@ -477,7 +477,6 @@ static int __kprobes hw_breakpoint_handler(struct die_args *args)
if ((dr6 & DR_TRAP_BITS) == 0)
return NOTIFY_DONE;

- get_debugreg(dr7, 7);
/* Disable breakpoints during exception handling */
set_debugreg(0UL, 7);
/*
@@ -525,7 +524,7 @@ static int __kprobes hw_breakpoint_handler(struct die_args *args)
if (dr6 & (~DR_TRAP_BITS))
rc = NOTIFY_DONE;

- set_debugreg(dr7, 7);
+ set_debugreg(__get_cpu_var(cpu_dr7), 7);
put_cpu();

return rc;
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index dd74fe7..3cb2828 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -42,6 +42,7 @@
#include <linux/init.h>
#include <linux/smp.h>
#include <linux/nmi.h>
+#include <linux/hw_breakpoint.h>

#include <asm/debugreg.h>
#include <asm/apicdef.h>
@@ -204,40 +205,38 @@ void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *regs)

static struct hw_breakpoint {
unsigned enabled;
- unsigned type;
- unsigned len;
unsigned long addr;
+ int len;
+ int type;
+ struct perf_event **pev;
} breakinfo[4];

static void kgdb_correct_hw_break(void)
{
- unsigned long dr7;
- int correctit = 0;
- int breakbit;
int breakno;

- get_debugreg(dr7, 7);
for (breakno = 0; breakno < 4; breakno++) {
- breakbit = 2 << (breakno << 1);
- if (!(dr7 & breakbit) && breakinfo[breakno].enabled) {
- correctit = 1;
- dr7 |= breakbit;
- dr7 &= ~(0xf0000 << (breakno << 2));
- dr7 |= ((breakinfo[breakno].len << 2) |
- breakinfo[breakno].type) <<
- ((breakno << 2) + 16);
- set_debugreg(breakinfo[breakno].addr, breakno);
-
- } else {
- if ((dr7 & breakbit) && !breakinfo[breakno].enabled) {
- correctit = 1;
- dr7 &= ~breakbit;
- dr7 &= ~(0xf0000 << (breakno << 2));
- }
- }
+ struct perf_event *bp;
+ struct arch_hw_breakpoint *info;
+ int val;
+ int cpu = raw_smp_processor_id();
+ if (!breakinfo[breakno].enabled)
+ continue;
+ bp = *per_cpu_ptr(breakinfo[breakno].pev, cpu);
+ info = counter_arch_bp(bp);
+ if (bp->attr.disabled != 1)
+ continue;
+ bp->attr.bp_addr = breakinfo[breakno].addr;
+ bp->attr.bp_len = breakinfo[breakno].len;
+ bp->attr.bp_type = breakinfo[breakno].type;
+ info->address = breakinfo[breakno].addr;
+ info->len = breakinfo[breakno].len;
+ info->type = breakinfo[breakno].type;
+ val = arch_install_hw_breakpoint(bp);
+ if (!val)
+ bp->attr.disabled = 0;
}
- if (correctit)
- set_debugreg(dr7, 7);
+ hw_breakpoint_restore();
}

static int
@@ -259,15 +258,23 @@ kgdb_remove_hw_break(unsigned long addr, int len, enum kgdb_bptype bptype)
static void kgdb_remove_all_hw_break(void)
{
int i;
+ int cpu = raw_smp_processor_id();
+ struct perf_event *bp;

- for (i = 0; i < 4; i++)
- memset(&breakinfo[i], 0, sizeof(struct hw_breakpoint));
+ for (i = 0; i < 4; i++) {
+ if (!breakinfo[i].enabled)
+ continue;
+ bp = *per_cpu_ptr(breakinfo[i].pev, cpu);
+ if (bp->attr.disabled == 1)
+ continue;
+ arch_uninstall_hw_breakpoint(bp);
+ bp->attr.disabled = 1;
+ }
}

static int
kgdb_set_hw_break(unsigned long addr, int len, enum kgdb_bptype bptype)
{
- unsigned type;
int i;

for (i = 0; i < 4; i++)
@@ -278,27 +285,38 @@ kgdb_set_hw_break(unsigned long addr, int len, enum kgdb_bptype bptype)

switch (bptype) {
case BP_HARDWARE_BREAKPOINT:
- type = 0;
- len = 1;
+ len = 1;
+ breakinfo[i].type = X86_BREAKPOINT_EXECUTE;
break;
case BP_WRITE_WATCHPOINT:
- type = 1;
+ breakinfo[i].type = X86_BREAKPOINT_WRITE;
break;
case BP_ACCESS_WATCHPOINT:
- type = 3;
+ breakinfo[i].type = X86_BREAKPOINT_RW;
break;
default:
return -1;
}
-
- if (len == 1 || len == 2 || len == 4)
- breakinfo[i].len = len - 1;
- else
- return -1;
-
- breakinfo[i].enabled = 1;
+ switch (len) {
+ case 1:
+ breakinfo[i].len = X86_BREAKPOINT_LEN_1;
+ break;
+ case 2:
+ breakinfo[i].len = X86_BREAKPOINT_LEN_2;
+ break;
+ case 4:
+ breakinfo[i].len = X86_BREAKPOINT_LEN_4;
+ break;
+#ifdef CONFIG_X86_64
+ case 8:
+ breakinfo[i].len = X86_BREAKPOINT_LEN_8;
+ break;
+

twitter

Monday, January 25, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts