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

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

Today's topics:

* ZTE MF636 USB modem is not supported - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/670a7642716afea4?hl=en
* SIIG DP CyberSerial 4S PCIe Support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bd76882c008a3efa?hl=en
* MEMORY MANAGEMENT: Remove deprecated memclear_highpage_flush(). - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/f05238e56f70754c?hl=en
* ATA 4 KiB sector issues. - 4 messages, 4 authors
http://groups.google.com/group/linux.kernel/t/94d9b232ec44429a?hl=en
* perf: Make the install relative to DESTDIR if specified - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/ef7de55975f148b0?hl=en
* x86: increase CONFIG_NODES_SHIFT max to 10 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/3f99a3f0c3aab026?hl=en
* Race condition in TTY ldisc layer in 2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0dd856e75c9c2098?hl=en
* perf: Make printing table easily - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1998ab7170f94457?hl=en
* perf: export perf_trace_regs and perf_arch_fetch_caller_regs - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/cd42e7124803ea93?hl=en
* x86, k8 nb: Enable k8_northbridges unconditionally on AMD - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/23fd80db0655edba?hl=en
* tracing: Update the comm field in the right variable in update_max_tr - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/651f6228ee70edb4?hl=en
* ftrace: Replace read_barrier_depends() with rcu_dereference_raw() - 3
messages, 1 author
http://groups.google.com/group/linux.kernel/t/33171d278770037c?hl=en
* perf tools: Fix sparse CPU numbering related bugs - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/20e9c06d997b116a?hl=en
* function-graph: Add tracing_thresh support to function_graph tracer - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/56f043a1e612a354?hl=en
* [PATCH 2/3] memcg: oom notifier - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bbf57513f577c468?hl=en
* perf_events: Improve task_sched_in() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b56952ee7476b66d?hl=en
* kprobes: Calculate the index correctly when freeing the out-of-line
execution slot - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d7466d80a07d75ae?hl=en
* perf, x86: Fix hw_perf_enable() event assignment - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/82db6d0109ff6b09?hl=en

==============================================================================
TOPIC: ZTE MF636 USB modem is not supported
http://groups.google.com/group/linux.kernel/t/670a7642716afea4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:50 am
From: Jiri Kosina

On Thu, 11 Mar 2010, Ondrej Zary wrote:

> Not sure about MF636, but MF637 works with this udev rule:
> SUBSYSTEM=="usb", SYSFS{idVendor}=="19d2", SYSFS{idProduct}=="2000", RUN+="/usr/sbin/usb_modeswitch --default-vendor 0x19d2 --default-product 0x2000 --message-content 55534243123456782000000080000c85010101180101010101000000000000"

Yes, this works for most of the ZTE modems with exception for 628 IIRC,
which needs 5553424312345678000000000000061b000000030000000000000000000000
instead.

--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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: SIIG DP CyberSerial 4S PCIe Support
http://groups.google.com/group/linux.kernel/t/bd76882c008a3efa?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:50 am
From: "Andrey Panin"

On 068, 03 09, 2010 at 07:09:21AM -0800, James Lamanna wrote:
> On Mar 9, 2010, at 6:15, "Andrey Panin" <pazke@centrinvest.ru> wrote:
>
> >On 067, 03 08, 2010 at 09:15:26PM -0800, James Lamanna wrote:
> >
> >>That's probably the case.
> >>It looks like 8250 doesn't know about this PCIe device at all.
> >>The Oxford PCI ID is not in pci_ids.h nor is the SIIG subsystem ID.
> >>I'll see if I can maybe work up a patch to support this device,
> >>since I've found
> >>the datasheet for the Oxford 4 port UART controller, but I may
> >>need some help.
> >>Or if anyone else (who has more experience with this) wants to
> >>formulate one,
> >>it would be greatly appreciated.
> >
> >Looks like you card can use existing code for Oxford Semiconductor
> >UARTs.
> >Can you test the attached patch for 2.6.33 ?
>
> Hi Andrey,
> Coincidentally I found your patch for 2.6.28 that I was able to
> backport to 2.6.24. The card seems to be working great!
> Is this patch in mainline now?

Now I'm confused, because I can't remember SIIG related patches for 2.6.28.
--
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: MEMORY MANAGEMENT: Remove deprecated memclear_highpage_flush().
http://groups.google.com/group/linux.kernel/t/f05238e56f70754c?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 6:00 am
From: "Robert P. J. Day"

Since this routine is all of static, deprecated and unreferenced, it
seems safe to delete it.

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

---

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 74152c0..c77f913 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -173,12 +173,6 @@ static inline void zero_user(struct page *page,
zero_user_segments(page, start, start + size, 0, 0);
}

-static inline void __deprecated memclear_highpage_flush(struct page *page,
- unsigned int offset, unsigned int size)
-{
- zero_user(page, offset, size);
-}
-
#ifndef __HAVE_ARCH_COPY_USER_HIGHPAGE

static inline void copy_user_highpage(struct page *to, struct page *from,

========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA

Linux Consulting, Training and Kernel Pedantry.

Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--
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: ATA 4 KiB sector issues.
http://groups.google.com/group/linux.kernel/t/94d9b232ec44429a?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Mar 11 2010 6:00 am
From: Nikanth Karthikesan

On Thursday 11 March 2010 18:34:56 Theodore Tso wrote:
> On Mar 10, 2010, at 11:19 AM, Damian Lukowski wrote:
> > I have practically no knowledge of Linux' block device drivers,
> > but is this really a partitioning issue? I think the problem is
> > with the filesystems when clustering multiple blocks without
> > knowledge of the sector alignment and sector size of the underlying
> > block device. Maybe it is a better solution to adapt the filesystem
> > buffer routine which reads/writes data from/to the block device?
>
> No, it's really a partitioning issue. If the paging subsystem wants a 4k
> block to fill a particular page, we need to read that 4k block into
> memory. If we need to swap out that 4k block, we need to write that 4k
> block to swap space, or to the memory segment's backing store. If the
> partition is misaligned by 512 bytes, this is simply not possible. The
> file system has to do what is requested of it by its users, and the
> reality is that we need to do 4k aligned reads and writes with respect to
> the beginning of the partition, far more often than not.
>
> Hence, if we want the best performance on 4k sector drives, the partition
> needs to be aligned with respect to what is most desirable for the device
> in question.
>

I guess, what he meant was, to keep filesystem blocks aligned, even if the
partition is not. Say if the partition is mis-aligned by 512-bytes, let the
filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a
case of over-engineering, possibly requiring disk format change.

Thanks
Nikanth
--
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: Thurs, Mar 11 2010 6:40 am
From: Theodore Tso

On Mar 11, 2010, at 8:57 AM, Nikanth Karthikesan wrote:
>
> I guess, what he meant was, to keep filesystem blocks aligned, even if the
> partition is not. Say if the partition is mis-aligned by 512-bytes, let the
> filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a
> case of over-engineering, possibly requiring disk format change.

Ah, yes, I agree with you; that's probably what he meant.

Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.

It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

-- Ted

--
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: Thurs, Mar 11 2010 6:50 am
From: Mike Snitzer

On Thu, Mar 11, 2010 at 9:28 AM, Theodore Tso <tytso@mit.edu> wrote:
>
> On Mar 11, 2010, at 8:57 AM, Nikanth Karthikesan wrote:
>>
>> I guess, what he meant was, to keep filesystem blocks aligned, even if the
>> partition is not. Say if the partition is mis-aligned by 512-bytes, let the
>> filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a
>> case of over-engineering, possibly requiring disk format change.
>
> Ah, yes, I agree with you; that's probably what he meant.
>
> Sure, that's theoretically possible, but it would mean changing every single filesystem, and it would require a file system format change --- or at least a file system format extension.
>
> It would seem to be way easier to simply fix the partitioning tools to do the right thing, though.

Yes, the current supported approach is to rely on partitions (parted,
fdisk) or LVM to account for 'alignment_offset'.

This avoids having a filesystem add its own padding (format change).
But e2fsprogs at least warns if a device, that it is to format, has an
alignment_offset != 0.

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

== 4 of 4 ==
Date: Thurs, Mar 11 2010 6:50 am
From: James Bottomley

On Thu, 2010-03-11 at 09:28 -0500, Theodore Tso wrote:
> On Mar 11, 2010, at 8:57 AM, Nikanth Karthikesan wrote:
> >
> > I guess, what he meant was, to keep filesystem blocks aligned, even if the
> > partition is not. Say if the partition is mis-aligned by 512-bytes, let the
> > filesystem waste 4k-512bytes and keep it's blocks aligned. But it might be a
> > case of over-engineering, possibly requiring disk format change.
>
> Ah, yes, I agree with you; that's probably what he meant.
>
> Sure, that's theoretically possible, but it would mean changing every
> single filesystem, and it would require a file system format change
> --- or at least a file system format extension.
>
> It would seem to be way easier to simply fix the partitioning tools to
> do the right thing, though.

Actually, it's a layering violation. The filesystem shouldn't need to
probe the device layout ... particularly when there are complexities
like is it logical 512 or physical, and if logical 512 on 4k does it
have an offset exponent or not.

We can transmit certain abstractions of information up the stack (like
stripe width for RAID arrays which should be the fs optimal write size),
but for this type of alignment, which can be completely solved at the
partition layer, the information should really stay there and the
filesystem should "just work".

James

==============================================================================
TOPIC: perf: Make the install relative to DESTDIR if specified
http://groups.google.com/group/linux.kernel/t/ef7de55975f148b0?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 11 2010 6:00 am
From: John Kacur

On Thu, Mar 11, 2010 at 1:57 PM, John Kacur <jkacur@redhat.com> wrote:
> Without this change, the install path is relative to
> prefix/DESTDIR
> where prefix is automatically set to $HOME
>
> This can produce unexpected results. For example
>
> make -C tools/perf DESTDIR=/home/jkacur/tmp install-man
>
> creates the directory: � � � � �/home/jkacur/home/jkacur/tmp/share/...
> instead of �the expected: � � � /home/jkacur/tmp/share/...
>
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
> �tools/perf/Documentation/Makefile | � �4 +++-
> �tools/perf/Makefile � � � � � � � | � �4 +++-
> �2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/Documentation/Makefile b/tools/perf/Documentation/Makefile
> index bdd3b7e..bd498d4 100644
> --- a/tools/perf/Documentation/Makefile
> +++ b/tools/perf/Documentation/Makefile
> @@ -24,7 +24,10 @@ DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
> �DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
> �DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
>
> +# Make the path relative to DESTDIR, not prefix
> +ifndef DESTDIR
> �prefix?=$(HOME)
> +endif
> �bindir?=$(prefix)/bin
> �htmldir?=$(prefix)/share/doc/perf-doc
> �pdfdir?=$(prefix)/share/doc/perf-doc
> @@ -32,7 +35,6 @@ mandir?=$(prefix)/share/man
> �man1dir=$(mandir)/man1
> �man5dir=$(mandir)/man5
> �man7dir=$(mandir)/man7
> -# DESTDIR=
>
> �ASCIIDOC=asciidoc
> �ASCIIDOC_EXTRA = --unsafe
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 2d53738..5da0cd0 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -216,7 +216,10 @@ STRIP ?= strip
> �# runtime figures out where they are based on the path to the executable.
> �# This can help installing the suite in a relocatable way.
>
> +# Make the path relative to DESTDIR, not to prefix
> +ifndef DESTDIR
> �prefix = $(HOME)
> +endif
> �bindir_relative = bin
> �bindir = $(prefix)/$(bindir_relative)
> �mandir = share/man
> @@ -233,7 +236,6 @@ sysconfdir = $(prefix)/etc
> �ETC_PERFCONFIG = etc/perfconfig
> �endif
> �lib = lib
> -# DESTDIR=
>
> �export prefix bindir sharedir sysconfdir
>
> --
> 1.6.6.1

Sorry, I'd like to withdraw this patch.

I see I can achieve my desired ends without changing the behaviour for
others who expect the old behaviour,
simply by setting "prefix" on the command line, eg:
make -C tools/perf prefix="" DESTDIR=/home/jkacur/tmp install-man

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/

== 2 of 2 ==
Date: Thurs, Mar 11 2010 6:20 am
From: Ingo Molnar

* John Kacur <jkacur@redhat.com> wrote:

> On Thu, Mar 11, 2010 at 1:57 PM, John Kacur <jkacur@redhat.com> wrote:
> > Without this change, the install path is relative to
> > prefix/DESTDIR
> > where prefix is automatically set to $HOME
> >
> > This can produce unexpected results. For example
> >
> > make -C tools/perf DESTDIR=/home/jkacur/tmp install-man
> >
> > creates the directory: ? ? ? ? ?/home/jkacur/home/jkacur/tmp/share/...
> > instead of ?the expected: ? ? ? /home/jkacur/tmp/share/...
> >
> > Signed-off-by: John Kacur <jkacur@redhat.com>
> > ---
> > ?tools/perf/Documentation/Makefile | ? ?4 +++-
> > ?tools/perf/Makefile ? ? ? ? ? ? ? | ? ?4 +++-
> > ?2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/perf/Documentation/Makefile b/tools/perf/Documentation/Makefile
> > index bdd3b7e..bd498d4 100644
> > --- a/tools/perf/Documentation/Makefile
> > +++ b/tools/perf/Documentation/Makefile
> > @@ -24,7 +24,10 @@ DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
> > ?DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
> > ?DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
> >
> > +# Make the path relative to DESTDIR, not prefix
> > +ifndef DESTDIR
> > ?prefix?=$(HOME)
> > +endif
> > ?bindir?=$(prefix)/bin
> > ?htmldir?=$(prefix)/share/doc/perf-doc
> > ?pdfdir?=$(prefix)/share/doc/perf-doc
> > @@ -32,7 +35,6 @@ mandir?=$(prefix)/share/man
> > ?man1dir=$(mandir)/man1
> > ?man5dir=$(mandir)/man5
> > ?man7dir=$(mandir)/man7
> > -# DESTDIR=
> >
> > ?ASCIIDOC=asciidoc
> > ?ASCIIDOC_EXTRA = --unsafe
> > diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> > index 2d53738..5da0cd0 100644
> > --- a/tools/perf/Makefile
> > +++ b/tools/perf/Makefile
> > @@ -216,7 +216,10 @@ STRIP ?= strip
> > ?# runtime figures out where they are based on the path to the executable.
> > ?# This can help installing the suite in a relocatable way.
> >
> > +# Make the path relative to DESTDIR, not to prefix
> > +ifndef DESTDIR
> > ?prefix = $(HOME)
> > +endif
> > ?bindir_relative = bin
> > ?bindir = $(prefix)/$(bindir_relative)
> > ?mandir = share/man
> > @@ -233,7 +236,6 @@ sysconfdir = $(prefix)/etc
> > ?ETC_PERFCONFIG = etc/perfconfig
> > ?endif
> > ?lib = lib
> > -# DESTDIR=
> >
> > ?export prefix bindir sharedir sysconfdir
> >
> > --
> > 1.6.6.1
>
> Sorry, I'd like to withdraw this patch.
>
> I see I can achieve my desired ends without changing the behaviour for
> others who expect the old behaviour,

The old behavior doesnt look very logical though, right?

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/

==============================================================================
TOPIC: x86: increase CONFIG_NODES_SHIFT max to 10
http://groups.google.com/group/linux.kernel/t/3f99a3f0c3aab026?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 11 2010 6:10 am
From: Greg KH

On Thu, Mar 11, 2010 at 02:23:54PM +0100, Ingo Molnar wrote:
>
> * David Rientjes <rientjes@google.com> wrote:
>
> > Some larger systems require more than 512 nodes, so increase the maximum
> > CONFIG_NODES_SHIFT to 10 for a new max of 1024 nodes.
> >
> > This was tested with numa=fake=64M on systems with more than 64GB of RAM. A
> > total of 1022 nodes were initialized.
> >
> > Successfully builds with no additional warnings on x86_64 allyesconfig.
>
> Not so here:
>
> drivers/base/node.c:169: error: negative width in bit-field ?<anonymous>?
>
> > Greg KH has queued up numa-fix-BUILD_BUG_ON-for-node_read_distance.patch
> > for 2.6.35 to fix the build error when CONFIG_NODES_SHIFT is set to 10.
> > See http://lkml.org/lkml/2010/3/10/390

Well, it will be a few days before I queue it up...

> erm. Alas I cannot merge it in the x86 tree without that fix being upstream.
> Why for v2.6.35 - shouldnt that be v2.6.34?

If it needs to go in before .35, or it should go through Ingo's trees, I
have no objection.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Thurs, Mar 11 2010 6:20 am
From: Ingo Molnar

* Greg KH <gregkh@suse.de> wrote:

> > erm. Alas I cannot merge it in the x86 tree without that fix being
> > upstream. Why for v2.6.35 - shouldnt that be v2.6.34?
>
> If it needs to go in before .35, or it should go through Ingo's trees, I
> have no objection.

It does not 'need' to be in .34 but if the fix is trivial enough then you
could give it a try?

==============================================================================
TOPIC: Race condition in TTY ldisc layer in 2.6.33
http://groups.google.com/group/linux.kernel/t/0dd856e75c9c2098?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 6:10 am
From: Greg KH

On Thu, Mar 11, 2010 at 02:32:22PM +0100, Micha? Miros?aw wrote:
> Looks like there's some race contition in switching ldiscs on USB serial
> ports. The following warnings trigger sometimes after killing and restarting
> process that changes ldisc and waits forever. In case you want to look at
> the code, there it is: http://rere.qmqm.pl/~mirq/sermmc/

If you apply git commit 638b9648ab51c9c549ff5735d3de519ef6199df3 to the
2.6.33 kernel, does it solve the issue for you?

thanks,

==============================================================================
TOPIC: perf: Make printing table easily
http://groups.google.com/group/linux.kernel/t/1998ab7170f94457?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 6:10 am
From: Arnaldo Carvalho de Melo

Em Thu, Mar 11, 2010 at 01:51:26PM +0100, Ingo Molnar escreveu:
>
> * Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:
>
> > Hi,
> >
> > Making table of matrix by printf is painful work,
> > but it can be found in perf here and there.
> > So I'd like to propose semi-automation of making table.
> > New files util/table.c provides stuffs for easy table printing.
>
> Looks quite reasonable in theory. I suspect it would be useful to see a few
> table printing places converted to this facility, to see the simplification
> factor in practice.

I'm going thru the printing routines now to get them usable by TUI/GUIs,
starting with a libnewt based browser integrating initially report and
annotate, after I get the first patch in shape for merging I'll revisit
this table class of yours :-)

- Arnaldo
--
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: export perf_trace_regs and perf_arch_fetch_caller_regs
http://groups.google.com/group/linux.kernel/t/cd42e7124803ea93?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 11 2010 6:20 am
From: Frederic Weisbecker

On Thu, Mar 11, 2010 at 04:14:44AM -0500, Christoph Hellwig wrote:
> On Thu, Mar 11, 2010 at 10:10:51AM +0100, Peter Zijlstra wrote:
> > Pretty much all modular tracepoint users I think, I just got this from a
> > pp64_defconfig build:
>
> Interesting, that doesn't happen in mainline yet.
>

Yeah, it's in -tip.

Thanks guys for this fix. I think I'm unable to remind
there are modules in the kernel, I'm not counting anymore
the number of times I forget to export symbols for modules.

May be I should start to stick posters with photos of modules
entitled "I want to believe" everywhere in my flat.
Or perhaps I'm going to buy electronic glasses that display
modules advertizing in the street. I'm not sure yet but I'll
find a way.

== 2 of 2 ==
Date: Thurs, Mar 11 2010 6:50 am
From: tip-bot for Xiao Guangrong

Commit-ID: 639fe4b12f92b54c9c3b38c82cdafaa38cfd3e63
Gitweb: http://git.kernel.org/tip/639fe4b12f92b54c9c3b38c82cdafaa38cfd3e63
Author: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
AuthorDate: Thu, 11 Mar 2010 15:30:35 +0800
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 11 Mar 2010 15:21:29 +0100

perf: export perf_trace_regs and perf_arch_fetch_caller_regs

Export perf_trace_regs and perf_arch_fetch_caller_regs since module will
use these.

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
[ use EXPORT_PER_CPU_SYMBOL_GPL() ]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <4B989C1B.2090407@cn.fujitsu.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/perf_event.c | 1 +
kernel/trace/trace_event_perf.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 5fb490c..7645fae 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1713,3 +1713,4 @@ void perf_arch_fetch_caller_regs(struct pt_regs *regs, unsigned long ip, int ski
regs->cs = __KERNEL_CS;
local_save_flags(regs->flags);
}
+EXPORT_SYMBOL_GPL(perf_arch_fetch_caller_regs);
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index f315b12..0709e4f 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -10,6 +10,7 @@
#include "trace.h"

DEFINE_PER_CPU(struct pt_regs, perf_trace_regs);
+EXPORT_PER_CPU_SYMBOL_GPL(perf_trace_regs);

static char *perf_trace_buf;
static char *perf_trace_buf_nmi;
--
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: x86, k8 nb: Enable k8_northbridges unconditionally on AMD
http://groups.google.com/group/linux.kernel/t/23fd80db0655edba?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 6:20 am
From: Borislav Petkov

From: Ingo Molnar <mingo@elte.hu>
Date: Thu, Mar 11, 2010 at 02:22:02PM +0100

> > we're getting the following oopsie with current -git. Proposed patch is below:
>
> alas, your patch doesnt always build:
>
> drivers/built-in.o: In function `agp_amd64_probe':
> amd64-agp.c:(.devinit.text+0x81d2): undefined reference to `cache_k8_northbridges'
> amd64-agp.c:(.devinit.text+0x8207): undefined reference to `k8_northbridges'
> amd64-agp.c:(.devinit.text+0x8409): undefined reference to `num_k8_northbridges'
> amd64-agp.c:(.devinit.text+0x8500): undefined reference to `k8_northbridges'

Ah, yep, this patch removes the dependency on K8_NB and it could be that
your config has CONFIG_K8_NB disabled but with CONFIG_AGP_AMD64 enabled.
Can you send me your .config pls?

--
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center
--
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: Update the comm field in the right variable in update_max_tr
http://groups.google.com/group/linux.kernel/t/651f6228ee70edb4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 6:40 am
From: tip-bot for Arnaldo Carvalho de Melo

Commit-ID: 1acaa1b2d9b5904c9cce06122990a2d71046ce16
Gitweb: http://git.kernel.org/tip/1acaa1b2d9b5904c9cce06122990a2d71046ce16
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
AuthorDate: Fri, 5 Mar 2010 18:23:50 -0300
Committer: Steven Rostedt <rostedt@goodmis.org>
CommitDate: Fri, 5 Mar 2010 21:12:08 -0500

tracing: Update the comm field in the right variable in update_max_tr

The latency output showed:

# | task: -3 (uid:0 nice:0 policy:1 rt_prio:99)

The comm is missing in the "task:" and it looks like a minus 3 is
the output. The correct display should be:

# | task: migration/0-3 (uid:0 nice:0 policy:1 rt_prio:99)

The problem is that the comm is being stored in the wrong data
structure. The max_tr.data[cpu] is what stores the comm, not the
tr->data[cpu].

Before this patch the max_tr.data[cpu]->comm was zeroed and the /debug/trace
ended up showing just the '-' sign followed by the pid.

Also remove a needless initialization of max_data.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <1267824230-23861-1-git-send-email-acme@infradead.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 032c57c..6efd5cb 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -592,7 +592,7 @@ static void
__update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
{
struct trace_array_cpu *data = tr->data[cpu];
- struct trace_array_cpu *max_data = tr->data[cpu];
+ struct trace_array_cpu *max_data;

max_tr.cpu = cpu;
max_tr.time_start = data->preempt_timestamp;
@@ -602,7 +602,7 @@ __update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
max_data->critical_start = data->critical_start;
max_data->critical_end = data->critical_end;

- memcpy(data->comm, tsk->comm, TASK_COMM_LEN);
+ memcpy(max_data->comm, tsk->comm, TASK_COMM_LEN);
max_data->pid = tsk->pid;
max_data->uid = task_uid(tsk);
max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO;
--
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: Replace read_barrier_depends() with rcu_dereference_raw()
http://groups.google.com/group/linux.kernel/t/33171d278770037c?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 11 2010 6:40 am
From: "tip-bot for Paul E. McKenney"

Commit-ID: 3f379b03fbfddd20536389a85c6456f8233d1f8d
Gitweb: http://git.kernel.org/tip/3f379b03fbfddd20536389a85c6456f8233d1f8d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
AuthorDate: Fri, 5 Mar 2010 15:03:25 -0800
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 11 Mar 2010 13:38:01 +0100

ftrace: Replace read_barrier_depends() with rcu_dereference_raw()

Replace the calls to read_barrier_depends() in
ftrace_list_func() with rcu_dereference_raw() to improve
readability. The reason that we use rcu_dereference_raw() here
is that removed entries are never freed, instead they are simply
leaked. This is one of a very few cases where use of
rcu_dereference_raw() is the long-term right answer. And I
don't yet know of any others. ;-)

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: laijs@cn.fujitsu.com
Cc: dipankar@in.ibm.com
Cc: mathieu.desnoyers@polymtl.ca
Cc: josh@joshtriplett.org
Cc: dvhltc@us.ibm.com
Cc: niv@us.ibm.com
Cc: peterz@infradead.org
Cc: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com
LKML-Reference: <1267830207-9474-1-git-send-email-paulmck@linux.vnet.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/trace/ftrace.c | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 8378357..8c5adc0 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -27,6 +27,7 @@
#include <linux/ctype.h>
#include <linux/list.h>
#include <linux/hash.h>
+#include <linux/rcupdate.h>

#include <trace/events/sched.h>

@@ -88,18 +89,22 @@ ftrace_func_t ftrace_pid_function __read_mostly = ftrace_stub;
static int ftrace_set_func(unsigned long *array, int *idx, char *buffer);

twitter

Thursday, March 11, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts