On Thu, Dec 22, 2016 at 06:56:28AM +0800, Jin, Yao wrote:
> Could you see the inline if you use the addr2line command? For example,
> addr2line -e -i
I'm sorry, I don't have this profile anymore. I'll try again once we sort out
the problems of the DWARF error messages everywhere.
/* Steinar */
On Wed, Dec 21, 2016 at 11:09:42AM +0100, Milian Wolff wrote:
> Just to check - did you really compile your code with frame pointers? By
> default, that is not the case, and the above will try to do frame pointer
> unwinding which will then fail. Put differently - do you any stack frames at
> al
On Wed, Dec 21, 2016 at 08:53:33AM +0800, Jin, Yao wrote:
> I just pull my repo with the latest perf/core branch, and apply the patch
> one by one (git am 0001/0002/.../0005), they can be applied. Maybe you have
> to do like that because the mails are probably coming out of order.
OK. I applied ev
On Tue, Dec 20, 2016 at 11:37:46AM -0300, Arnaldo Carvalho de Melo wrote:
>> Woot. Is this available in git somewhere? (Or if not, what do I apply it on
>> top of?)
> Normally you get it from tip, i.e. from:
>
> git//git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core
I suppose perf/cor
On Tue, Dec 20, 2016 at 10:54:50AM -0300, Arnaldo Carvalho de Melo wrote:
> Have you guys looked at this:
>
> http://lkml.kernel.org/r/1481121822-2537-1-git-send-email-yao@linux.intel.com
>
> I have to review it and maybe you will help me with that ;-)
Woot. Is this available in git somewher
On Tue, Dec 20, 2016 at 02:27:10PM +0100, Milian Wolff wrote:
> It is not even possible with that, perf report is lacking the steps required
> to add inline frames - it will only add "real" frames it gets from either of
> the unwind libraries.
>
> I have a WIP patch available for this functional
Hi Peter,
I can't find a good point of contact for perf, so I'm contacting you based on
the MAINTAINERS file; feel free to redirect somewhere if you're not the right
person.
I'm trying to figure out how to deal with perf report when there are inlined
functions; they don't generally seem to show u
On Wed, Feb 24, 2016 at 02:30:08PM -0500, Sasha Levin wrote:
> I'm seeing the following warning while fuzzing:
> [ 1595.188189] WARNING: CPU: 3 PID: 26063 at mm/page_alloc.c:3207
> __alloc_pages_nodemask+0x960/0x29e0()
> [ 1595.188287] Modules linked in:
> [ 1595.188316] CPU: 3 PID: 26063 Comm: sy
On Mon, Feb 15, 2016 at 03:07:06AM +0100, Linus Lüssing wrote:
> Steinar, can you check whether this fixes the bridge issues you reported on
> bugzilla #99081? Not quite sure whether it is the same as yours as you
> do not seem to have any such call traces.
It doesn't immediately sound like the sa
On Wed, Feb 03, 2016 at 11:09:16PM +0100, Steinar H. Gunderson wrote:
> Trying again; sending v4 as a reply to your email.
Did the v4 sending work for you?
/* Steinar */
--
Software Engineer, Google Switzerland
On Thu, Feb 04, 2016 at 11:17:26AM +0100, Bjørn Mork wrote:
> Then use Mutt to reply, but include the patch inline instead of
> attaching it. I believe this is discussed in the Mutt section of
> Documentation/email-clients.txt
Thanks; if that works (even though it changes the “From” line and such
On Thu, Feb 04, 2016 at 12:15:50AM +0200, Felipe Balbi wrote:
>> Since I've now been bitten by this several times: Is there any sort of best
>> practice for integrating git with MUAs? What I'm doing right now is
>> cut-and-paste from mutt to get the to/cc/in-reply-to headers right, and
>> that's su
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Wed, Feb 03, 2016 at 01:23:17PM -0800, Greg Kroah-Hartman wrote:
> Attachments don't work, you know better than that :(
Since I've now been bitten by this several times: Is there any sort of best
practice for integrating git with MUAs? What I'm doing right now is
cut-and-paste from mutt to get
On Mon, Jan 25, 2016 at 09:03:57AM +0100, Steinar H. Gunderson wrote:
> I did git rebase --ignore-date HEAD^ just to reset the date. Sending it as an
> attachment just to be sure.
Hi Greg,
Did this work for you? Is there anything else I should do to this patch?
/* Steinar */
--
So
ing it as an
attachment just to be sure.
/* Steinar */
--
Software Engineer, Google Switzerland
>From e56d9235b343c5e70061e977639cc7dddeae8164 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Mon, 25 Jan 2016 09:02:34 +0100
Subject: [PATCH v3] Add support for usbfs zerocopy
On Wed, Jan 06, 2016 at 04:22:12PM +0100, Peter Stuge wrote:
>>> Our interface for zero copy reads/writes is O_DIRECT, and that requires
>>> not special memory allocation, just proper alignment.
>> But that assumes you are using I/O using read()/write(). There's no way you
>> can shoehorn USB isoch
On Tue, Jan 05, 2016 at 10:49:49PM -0800, Christoph Hellwig wrote:
> This is a completely broken usage of the mmap interface. if you use
> mmap on a device file you must use the actual mmap for the data
> transfer.
Really? V4L does exactly the same thing, from what I can see. It's just a way
of a
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Tue, Jan 05, 2016 at 04:11:43PM -0800, Greg Kroah-Hartman wrote:
>> Add a new interface for userspace to preallocate memory that can be
>> used with usbfs. This gives two primary benefits:
> Please 'version' your patches, so that I have a chance to figure out
> what patch is what, and what chang
On Tue, Jan 05, 2016 at 04:31:09PM -0500, Alan Stern wrote:
> Thank you. So it looks like I was worried about nothing.
>
> Steinar, you can remove the try_module_get/module_put lines from your
> patch. Also, the list_del() and comment in usbdev_release() aren't
> needed -- at that point we know
e found at:
http://sundtek.de/support/devio_mmap_v0.4.diff
Signed-off-by: Steinar H. Gunderson
Signed-off-by: Markus Rechberger
Acked-by: Alan Stern
---
drivers/usb/core/devio.c | 227 +-
include/uapi/linux/usbdevice_fs.h | 1 +
2 files ch
On Fri, Oct 24, 2014 at 01:37:51AM +0200, Steinar H. Gunderson wrote:
>> I'm currently testing the patch below and will submit with proper
>> tested by attributions later today.
> We applied this patch in a reboot today (on top of 3.17.1), and so far,
> things seem to be go
On Sun, Oct 26, 2014 at 02:58:36PM +0100, Mike Galbraith wrote:
> Can you try the below?
I can bake it into the kernel the next time I boot, but that is unlikely to
be anytime soon, I'm afraid. I'm maybe a bit surprised nobody else can
reproduce my issue; I assume it won't help if I give out shell
On Fri, Oct 24, 2014 at 06:38:41PM +0200, Mike Galbraith wrote:
>>> Whew, good, futex.c is hard. Heads up chess guys .
>> I wonder whether the barrier fix which got into 3.17 late fixes that
>> issue as well.
> Yes, it did.
This is only about the lockup, right, not that the threads bounce around
On Tue, Oct 21, 2014 at 02:31:44PM +0100, Thomas Graf wrote:
> I'm currently testing the patch below and will submit with proper
> tested by attributions later today.
We applied this patch in a reboot today (on top of 3.17.1), and so far,
things seem to be going much better.
/* Steinar */
--
Hom
On Fri, Oct 17, 2014 at 07:25:17AM +0100, Thomas Graf wrote:
> I think the only option at this point is to re-add the nltable lock to
> netlink_lookup() so we can drop the synchronize_net() until we find a
> way to RCUify socket destruction. I will cook up a patch today unless
> somebody can come u
On Fri, Oct 17, 2014 at 02:34:30AM +0200, Steinar H. Gunderson wrote:
> e341694e3eb57fcda9f1adc7bfea42fe080d8d7a looks like it might cause something
> like this (it certainly added the synchronize_net() call). Cc-ing people on
> that commit; quoting the entire rest of the message for
Hi,
We recently upgraded a machine from 3.14.5 to 3.17.1, and a Perl script we're
running to poll SNMP suddenly needed ten times as much time to complete.
ps shows that it keeps being in state D (ie., I/O), and strace with -ttT
shows this curious pattern:
02:11:33.106973 socket(PF_NETLINK, SOCK_R
On Fri, Oct 17, 2014 at 02:21:32AM +0200, Steinar H. Gunderson wrote:
> Hi,
>
> We recently upgraded a machine from 3.14.5 to 3.17.1, and a Perl script we're
> running to poll SNMP suddenly needed ten times as much time to complete.
e341694e3eb57fcda9f1adc7bfea42fe080d8d7a lo
On Wed, Oct 08, 2014 at 01:04:01PM -0400, Linus Torvalds wrote:
> So like Thomas, I would suspect a race condition in the futex use, and
> then the exact futex implementation details are just exposing it
> incidentally.
FWIW, Stockfish does not use futex directly; it uses pthreads (or Win32
thread
On Wed, Oct 08, 2014 at 06:14:18PM +0200, Thomas Gleixner wrote:
> It looks far more like an issue with the stocking fish code, but hell
> with futexes one can never be sure.
OK, maybe we should move to a more recent Stockfish version first of all;
the specific benchmark was about that specific bi
On Wed, Oct 08, 2014 at 05:37:44PM +0200, Mike Galbraith wrote:
> Seems you opened a can of futex worms...
Awesome.
> I don't see that on the 2 x E5-2697 box I borrowed to take a peek. Once
> I got stockfish to actually run to completion by hunting down and brute
> force reverting the below, I s
On Sat, Oct 04, 2014 at 09:50:04AM -0500, Chuck Ebbert wrote:
> Try playing with /proc/sys/kernel/sched_migration_cost_ns. This sets
> the number of nanoseconds the kernel will wait before considering
> moving a thread to another CPU. I have mine set to 5000.
I can't get any good effect out of
On Sat, Oct 04, 2014 at 06:41:15AM -0700, Andi Kleen wrote:
> - something else gets scheduled on these logical CPUs, so
> the scheduler tries to balance to run queue lengths
>
> You could check that with perf timechart or perf sched record/map
> or kernelshark.
I've never read any of these maps b
On Fri, Oct 03, 2014 at 11:11:52PM +0200, Marc Burkhardt wrote:
> As I understand your mail, you problem is quite similar, isn't it?
I guess it depends on how often your process migrates. If it happens, like,
every second, it's not a big problem (and probably is expected).
If it happens all the ti
Hi,
I did a chess benchmark of my new machine (2x E5-2650v3, so 20x2.3GHz
Haswell-EP), and it performed a bit worse than comparable Windows setups.
It looks like the scheduler somehow doesn't perform as well with
hyperthreading; HT is on in the BIOS, but I'm only using 20 threads
(chess scales sub
On Fri, Jun 07, 2013 at 02:44:19PM -0400, Steven Rostedt wrote:
> Do know if you have CONFIG_NET_NS set in your .config?
Sorry, I forgot to answer this: No, it is not set.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Jun 07, 2013 at 02:26:08PM -0400, Steven Rostedt wrote:
> On Fri, 2013-06-07 at 19:52 +0200, Steinar H. Gunderson wrote:
> Ah, that's because of this: module_init(ipgre_init); Where it makes it
> into:
>
> :
>0: 55 push
On Fri, Jun 07, 2013 at 12:12:23PM -0400, Steven Rostedt wrote:
>> Ffffa0e76000 u ip_tunnel_init_net [ip_gre]
> What do you get if you do an objdump -Dr ip_gre.ko
>
> And then look for ipgre_init, and then subtract 0xb053 (45139) from its
> address. As that is: a0e81055 - a0e
On Fri, Jun 07, 2013 at 11:15:00AM -0400, Steven Rostedt wrote:
> net: Remove __net_init/exit from exported functions
>
> If CONFIG_NET_NS is not set then __net_init is the same as __init and
> __net_exit is the same as __exit. These functions will be removed from
> memory after the module loads o
On Thu, Jun 06, 2013 at 11:06:48PM -0400, Steven Rostedt wrote:
> Note the faulting address is 0xa0e52001, which is around the
> above address, be interesting to know what was at that location.
Doh, I looked at the wrong place in kallsyms:
a0e52000 u ip_tunnel_init_net [ip_gre]
On Thu, Jun 06, 2013 at 11:06:48PM -0400, Steven Rostedt wrote:
> Note the faulting address is 0xa0e52001, which is around the
> above address, be interesting to know what was at that location.
Aha, the plot thickens:
root 6095 0.0 0.0 6632 596 ?DJun06 0:00 /sbin/
On Thu, Jun 06, 2013 at 08:59:48PM -0700, Eric Dumazet wrote:
> Steinar, please make sure you recompiled your modules, because this
> looks like you loaded old modules.
I compiled the kernel using make-kpkg, so I don't see how that would happen.
Also, the timestamps indicate everything is fine:
-
On Thu, Jun 06, 2013 at 11:06:48PM -0400, Steven Rostedt wrote:
> Note the faulting address is 0xa0e52001, which is around the
> above address, be interesting to know what was at that location.
Is there any way I can figure this out? The machine in question is still
running. kallsyms doesn
Hi,
In 3.10.0-rc4, I get this on boot:
[ 16.871043] BUG: unable to handle kernel NULL pointer dereference at
0003
[ 16.879453] IP: [] 0xa0e52001
[ 16.884995] PGD 0
[ 16.887313] Oops: [#1] SMP
[ 16.890904] Modules linked in: ip_gre(+) gre ip_tunnel psmouse ide
On Wed, Jun 05, 2013 at 03:16:05PM -0400, Ilia Mirkin wrote:
>> It dies every time. 3.9.0 is fine.
> You need the patch at https://lkml.org/lkml/2013/5/19/75
Ah, I'm already down at 3.9.4 again; I mainly reported this in case it was
unknown. (But a patch from May 19 not being in 3.10-rc4 is maybe
Hi,
I have a setup with an LSI2008 controller running md (RAID-1 and RAID-6) with
LVM on top, and I'm seeing this on boot, pretty much under fsck:
[ 15.235697] [ cut here ]
[ 15.235738] md: resync of RAID array md1
[ 15.235740] md: minimum _guaranteed_ speed: 1000 K
On Sun, Jan 06, 2013 at 08:48:36PM -0700, David Ahern wrote:
>> Why would the two be different?
> I will make a guess that is processor dependent. On an E5540 with
> 3.4.11-1.fc16.x86_64, 3.6.10-2.fc16.x86_64, and 3.8 I get the same
> failure message.
>
> But on a E5620, it works fine with 3.4 and
On Fri, Jan 04, 2013 at 05:16:27PM -0700, David Ahern wrote:
> Known problem. Pick one of: update perf to 3.7, add H to the command
> (-e cycles:ppH) or apply this patch:
> https://lkml.org/lkml/2012/12/28/384
I spoke too soon. This works for cycles, but not for branch-misses:
pannekake:~> sudo
On Fri, Jan 04, 2013 at 05:16:27PM -0700, David Ahern wrote:
> Known problem. Pick one of: update perf to 3.7, add H to the command
> (-e cycles:ppH) or apply this patch:
> https://lkml.org/lkml/2012/12/28/384
Oh, thinking of it, I've actually read about this flamew^Wdiscussion :-)
Thanks!
/* St
[Please Cc me on any replies; I'm not subscribed to lkml]
Hi,
I recently upgraded from 3.6.5 to 3.7.1 to get around some MM issues that
have been bothering me. However, it appears it broke PEBS:
pannekake:/usr/src/linux-3.7.1# perf record -a -e cycles:pp
Error: sys_perf_event_open() syscall
[Please Cc on reply]
Hi,
I recently bought an USB MIDI interface from ESI (called “ESI MIDI Mate”). It
claims to work with Linux, but doesn't -- I've already asked the manufacturer
for an explanation, but as I was impatient, I hacked a bit on the drivers to
actually make it work...
The /proc/bus
53 matches
Mail list logo
