Michael Chan writes:
> From: Stephen Hurd
>
> Add support for the UART device present in Broadcom TruManage capable
> NetXtreme chips (ie: 5761m 5762, and 5725).
>
> This implementation has a hidden transmit FIFO, so running in single-byte
> interrupt mode results in too many interrupts. The UA
Adrian Hunter writes:
> On 31/08/12 11:15, Andrew Morton wrote:
>> On Fri, 31 Aug 2012 01:07:24 -0700 Michel Lespinasse
>> wrote:
>>
>>> On Fri, Aug 31, 2012 at 1:01 AM, Adrian Hunter
>>> wrote:
This breaks tools/perf build in linux-next:
../../lib/rbtree.c: In function 'rb_in
d reference to `dma_mapping_error'
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> This one is very debatable: probably the parts using the DMA API should
>> be factored out, instead of disabling the whole USB gadget subsystem.
>
> Indeed. How does th
Felipe Balbi writes:
> On Wed, Jun 26, 2013 at 05:37:19PM +0530, George Cherian wrote:
>> On 6/26/2013 3:46 PM, Felipe Balbi wrote:
>> >Hi,
>> >
>> >On Wed, Jun 26, 2013 at 02:59:14PM +0530, George Cherian wrote:
>> >>There can be configurations in which DWC3 is hoooked up only to USB2 PHY.
>> >>
On 6 March 2013 12:33, Maxime Ripard wrote:
> Hi,
>
> Just noticed this in 3.9-rc1 on an iMX28 (ARM) board with a config
> based on mxs_defconfig. I'm using the patchset "Add tested id switch
> and vbus connect detect support for Chipidea" from Peter Chen in its
> 10th version [1], rebased on top
Shawn Guo writes:
> On Wed, May 08, 2013 at 02:51:33PM +0300, Alexander Shishkin wrote:
>> Fabio Estevam writes:
>>
>> > Since commit ab78029 (drivers/pinctrl: grab default handles from device
>> > core),
>> > we can rely on device core
Alexander Shishkin writes:
> Shawn Guo writes:
>
>> On Wed, May 08, 2013 at 02:51:33PM +0300, Alexander Shishkin wrote:
>>> Fabio Estevam writes:
>>>
>>> > Since commit ab78029 (drivers/pinctrl: grab default handles from device
>>> >
Jiri Slaby writes:
> On 05/08/2013 11:07 AM, Alexander Shishkin wrote:
>> Jiri Slaby writes:
>>
>>> From: Jeff Mahoney
>>>
>>> The chipidea driver currently has needless ifneq rules in the makefile
>>> for things that should be config optio
Wolfram Sang writes:
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
Acked-by: Alexander Shishkin
> ---
> drivers/usb/chipidea/core.c |5 -
> 1 file changed, 5 deletion
Jiri Slaby writes:
> From: Jeff Mahoney
>
> The chipidea driver currently has needless ifneq rules in the makefile
> for things that should be config options.
Please elaborate on the "should be" part.
> This can be problematic,
> especially in the IMX case, since the OF_DEVICE dependency will
Fabio Estevam writes:
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
> we can rely on device core for handling pinctrl.
>
> So remove devm_pinctrl_get_select_default() from the driver.
>
> Cc: Thierry Reding
> Cc:
> Signed-off-by: Fabio Estevam
> ---
> drive
Silviu-Mihai Popescu writes:
> Convert use of devm_request_and_ioremap() to the newly introduced
> devm_ioremap_resource() which provides more consistent error handling.
You mean, you've run coccinelle? Remember to mention it, then.
> devm_ioremap_resource() provides its own error messages so
Jiri Slaby writes:
> On 05/16/2013 11:36 AM, Alexander Shishkin wrote:
>> The benefit from compiling it on non-arm (or non-imx) architectures for
>> me is compilation testing. We don't have a whole lot of architectures
>> with CONFIG_OF so it's nice to give it a st
ar Waßmann
Good one, thanks.
Acked-by: Alexander Shishkin
Greg, this is -stable material, applicable starting from v3.6.
> ---
> drivers/usb/chipidea/core.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers
On 7/21/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
again, probably displaying my abject ignorance, but i wrote a
trivial module that tries to "var % 15", and i get:
WARNING: "__moddi3" undefined!
...which comes from libgcc1 which you obviously don't want to link against.
Does (var &
On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
v & 0x0F <=> v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Regards,
--
Alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On 9/2/07, Philippe De Muyter <[EMAIL PROTECTED]> wrote:
> Hi all,
Hi,
> Can someone give me some hint or link for the following question :
>
> I have several processes blocked in 'D' state, and I surmise they are
> waiting for a semaphore (in the `down' routine). How is it possible :
> - to veri
On 1/11/07, Aubrey <[EMAIL PROTECTED]> wrote:
Firstly I want to say I'm working on no-mmu arch and uClinux.
After much of file operations VFS cache eat up all of the memory.
At this time, if an application request memory which order > 3, the
kernel will report failure.
uClinux use a memory mappe
Sebastian Andrzej Siewior writes:
> From: Sebastian Andrzej Siewior
>
> Since commit 4d4c47412464 ("perf/x86/intel/bts: Fix BTS PMI detection")
> my box goes boom on boot:
>
> | node #0, CPUs: #1 #2 #3 #4 #5 #6 #7
> | BUG: unable to handle kernel NULL pointer dereference at 00
Alexander Shishkin writes:
> Sebastian Andrzej Siewior writes:
>
>> From: Sebastian Andrzej Siewior
>>
>> Since commit 4d4c47412464 ("perf/x86/intel/bts: Fix BTS PMI detection")
>> my box goes boom on boot:
>>
>> | node #0, CPUs:
scheduled and receive the actual trace data.
Fix this by making intel_bts an "exclusive" PMU.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/bts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/b
s
that may prevent this, but those would be hardware-specific). However,
the exclusivity code is written so that only one event from any of the
"exclusive" PMUs is allowed in a context.
Fix this by making the exclusive event filter explicitly match two events'
PMUs.
Signed-o
hy on systems that allow coexistance of PT and BTS it still works,
see ccbebba4c6 for more context).
Alexander Shishkin (2):
perf/x86/intel/bts: Make it an exclusive PMU
perf: Limit matching exclusive events to one PMU
arch/x86/events/intel/bts.c | 3 ++-
kernel/events/core.c| 2 +-
2
[adding Felipe for his sudden interest in the subject matter]
Chunyan Zhang writes:
> +static struct stm_ftrace *trace_output;
What you want is a possibility to have different ftrace outputs, not
different STM outputs for ftrace (again, STM core already does this).
In other words, here, you wan
day to the
architectures that deliver PMIs as IRQs. Mathieu?
[1]
https://git.kernel.org/cgit/linux/kernel/git/ash/linux.git/log/?h=perf-aux-sampling
Alexander Shishkin (6):
perf: Move mlock accounting to ring buffer allocation
perf: Add api to (de-)allocate AUX buffers for kernel counters
p
eds to use perf_event_disable to make sure that the
counter is not active while it copies data out.
Signed-off-by: Alexander Shishkin
---
kernel/events/internal.h| 19 +++
kernel/events/ring_buffer.c | 83 +
2 files changed, 102 insertions(+)
orry about it. This also serves the
additional purpose of slightly cleaning up perf_mmap().
Signed-off-by: Alexander Shishkin
---
kernel/events/core.c| 67 +++
kernel/events/internal.h| 5 +-
kernel/events/ring_buffer.c | 127 +
the event that is being
annotated with regards to filtering (exclude_{hv,idle,user,kernel}) and
enabled state (disabled, enable_on_exec) to make sure that the sampler
is not tracking any out of context activity. One sampler can be used
for multiple events.
Signed-off-by: Alexander Shishkin
---
If PMU callbacks are executed in hardirq context, the address filter
sync code needs to disable interrupts when taking its spinlock to be
consistent with the rest of its users. This may happen if the PMU is
used in AUX sampling.
Signed-off-by: Alexander Shishkin
---
kernel/events/core.c | 5
This patch adds a helper for looking up a registered pmu by its type.
Signed-off-by: Alexander Shishkin
---
kernel/events/core.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2e8a0e389b..b64a5c611f 100644
these critical sections, so that
AUX sampling won't take place there.
Signed-off-by: Alexander Shishkin
---
kernel/events/core.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index fdb20fdeb1..f6582df1c9 100644
--- a/ker
Peter Zijlstra writes:
> On Fri, Sep 23, 2016 at 02:27:21PM +0300, Alexander Shishkin wrote:
>> In order to be able to allocate perf ring buffers in non-mmap path, we
>> need to make sure we can still account the memory to the user and that
>> they don't exceed thei
Peter Zijlstra writes:
> On Fri, Sep 23, 2016 at 05:27:22PM +0300, Alexander Shishkin wrote:
>> > Afaict there's no actual need to hide the AUX buffer for this sampling
>> > stuff; the user knows about all this and can simply mmap() the AUX part.
>>
>> Ye
Peter Zijlstra writes:
> Well, we could 'force' inject a VMA into the process's address space, we
> do that for a few other things as well. It also makes for less
> exceptions with the actual core dumping.
Threads then will end up with the same buffer (through sharing the mm),
but they can't rea
Peter Zijlstra writes:
> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>> > At which point we _should_ start failing fork(), which is a somewhat
>> > unexpected, and undesirable side-effect.
>>
>> I'm n
Peter Zijlstra writes:
> On Mon, Sep 26, 2016 at 11:27:08AM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>>
>> > Well, we could 'force' inject a VMA into the process's address space, we
>> > do that for a few other things as well.
Alexander Shishkin writes:
> If PMU callbacks are executed in hardirq context, the address filter
> sync code needs to disable interrupts when taking its spinlock to be
> consistent with the rest of its users. This may happen if the PMU is
> used in AUX sampling.
Hi Mathieu,
I
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=f1e1c9e5e357c05253affb13be29285c5cb56bf0
On 26 September 2016 at 22:19, Boris Ostrovsky
wrote:
> Otherwise we will try to dereference ds which has not been allocated.
>
> Signed-off-by: Boris Ostrovsky
> ---
> arch/x86/events/in
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> Hi,
>>
>> There were more bugs since the previous version, plus the BTS barriers got
>> fixed. With these patches, my testcase keeps running and no spurious NMI
>> warnings pop up any more.
>
>
Vince Weaver writes:
> On Wed, 7 Sep 2016, Alexander Shishkin wrote:
>
>> Sure. And yes, I did catch a warning, which calls for one more patch
>> (below). Also one unrelated thing in PEBS that Peter fixed.
>
> Does that fix this which I just got on my skylake machine (4.
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> Ingo Molnar writes:
>>
>> > * Alexander Shishkin wrote:
>> >
>> >> Hi,
>> >>
>> >> There were more bugs since the previous version, plus the BTS barriers
>
Vince Weaver writes:
> On the skylake machine with the original 5 patches I got this after
> continuing to fuzz. Sorry about the lack of frame pointer, next
> compile will have it enabled.
>
> If it matters, prior to this I hit the unrelated
> [25510.278199] WARNING: CPU: 1 PID: 25405 at kernel
Vince Weaver writes:
> Hello
>
> I'm running 4.8-rc6 git from this morning (with the various perf fixes).
>
> Fuzzing on Skylake I still managed to trigger the following warning.
I was sure that I'd sent the fix for this one in the earlier series, but
somehow I missed it. Sending now.
Thanks,
-
This patch moves intel_bts enabling/disabling directly to the PMI
handler.
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/core.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
least theoretically.
Alexander Shishkin (3):
perf/x86/intel/pt: Fix an off-by-one in address filter configuration
perf/x86: Tighten up the kernel_ip() check
perf/x86/intel/pt: Do validate the size of a kernel address filter
arch/x86/events/intel/pt.c | 13 +
arch/x86/events/perf_event.h
sized filters don't pass the filter
validation.
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/
this calculation.
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 5ec0100e3f..834ce
bits (like 0xf00d) throws a #GP.
In the interest of improving everybody's kernel address checks, this
patch adds address validation to kernel_ip().
Cc: sta...@vger.kernel.org # 4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/perf_event.h | 2
this calculation.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 1f94963a28..861a7
Hi again,
Apologies for the botched recipient list in the previous one. So I
moved the virt_addr_valid() inside pt.c as well to save cycles in the
LBR code.
These are 3 bugs that Adrian found; all 3 seem like good -stable
candidates.
Alexander Shishkin (3):
perf/x86/intel/pt: Fix an off-by
bits (like 0xf00d) throws a #GP.
This patch adds address validation for the user supplied kernel filters.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 7 ++-
1 file changed, 6 insertions(+), 1 del
sized filters don't pass the filter
validation.
Cc: sta...@vger.kernel.org # v4.7
Reported-by: Adrian Hunter
Signed-off-by: Alexander Shishkin
---
arch/x86/events/intel/pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/
Greg KH writes:
>> git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git
>> tags/stm-for-greg-20160701
>
> I'm already all caught up with stm patches, right? If not, can you
> resend the pull requests?
Yes, you are all caught up with stm/intel_th indeed. Thank you for
confirming though!
han just the CPU number so that
>> individual drivers can make the right configuration when setting
>> up a session.
>>
>> Signed-off-by: Mathieu Poirier
>> Cc: Alexander Shishkin
>
> Yeah, no objection to this.
Sure, but I'd like a commit message that actually describes *what*
information and *why*.
Regards,
--
Alex
Vince Weaver writes:
> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
> WARN_ON_ONCE(atomic_read(
Thanks! I'll get back to you with something better.
On 23 August 2016 at 23:55, Vince Weaver wrote:
> On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>
>> Vince Weaver writes:
>>
>> > On Tue, 23 Aug 2016, Alexander Shishkin wrote:
>> >
>> >> R
ssing. Thanks!
> This patch uses this_cpu_ptr instead of get_cpu_ptr, since preemption is
> already disabled by the caller.
>
> Fixes: 95ff4ca26c49 ("perf/core: Free AUX pages in unmap path")
> Cc: Alexander Shishkin
> Cc: Peter Zijlstra
> Signed-off-by: Will Deacon
Reviewed-by: Alexander Shishkin
Regards,
--
Alex
Alexander Shishkin writes:
> The intel_bts driver is using a cpu-local 'started' variable to order
> callbacks and PMIs and make sure that AUX transactions don't get messed
> up. However, the ordering rules in regard to this variable is a complete
> mess, which recen
Alexander Shishkin writes:
> Alexander Shishkin writes:
>
>> Signed-off-by: Alexander Shishkin
>
> Ok, this one is broken, please disregard.
Vince, can you try the following (with the other two in this series)?
---
>From 68713194b3df8e565c4d319a80e9e7338fa1ec13 Mon Sep
l be only used within the kernel. So the correct error
> code would then be -EOPNOTSUPP.
>
> With this commit, the perf tool then reports:
>
> failed to mmap with 95 (Operation not supported)
>
> which is more clear.
Acked-by: Alexander Shishkin
Curious as to why does the tool allow this.
Regards,
--
Alex
Zhou Chengming writes:
> The else branch are broken for taskctx:
This is not a good way to open a commit message.
> two events can on the same taskctx, but on different cpu.
How?
Regards,
--
Alex
Bhumika Goyal writes:
> On Thu, Oct 12, 2017 at 2:12 PM, Bhumika Goyal wrote:
>> This is a followup patch for:
>> https://patchwork.kernel.org/patch/649/ and
>> https://lkml.org/lkml/2017/10/11/375
>>
>> Make config_item_type structures const as they are either passed to a
>> function having
Alexey Budankov writes:
Here (above the function) you could include a comment describing what
happens when this is called, locking considerations, etc.
> +static int
> +perf_cpu_tree_insert(struct rb_root *tree, struct perf_event *event)
> +{
> + struct rb_node **node;
> + struct rb_node
Alexey Budankov writes:
> On 29.05.2017 15:03, Alexander Shishkin wrote:
>> Alexey Budankov writes:
>>
>> Here (above the function) you could include a comment describing what
>> happens when this is called, locking considerations, etc.
>
> I can put the s
ead
> xhci_hcd :00:15.0: xHC not responding in xhci_irq, assume controller is
> dead
> xhci_hcd :00:15.0: HC died; cleaning up
> usb 1-1: USB disconnect, device number 2
...
For this reason, we need to resize the RTIT_BAR on Denverton to its
actual size, which in this case is
onger periods of time, making the buildup of AUX
records an unnecessary annoyance.
Alexander Shishkin (4):
perf: Allow suppressing AUX records
tools, perf_event.h: Synchronize
perf tools: Add 'suppress_aux' attribute bit definition and fallback
perf intel-pt, intel-bts: Suppress usel
ds an attribute bit that enables suppressing such records.
Signed-off-by: Alexander Shishkin
Cc: Markus Metzger
Cc: Adrian Hunter
---
include/uapi/linux/perf_event.h | 3 ++-
kernel/events/core.c| 5 +
kernel/events/ring_buffer.c | 12 ++--
3 files changed, 17 insertions(
I've just added attr::suppress_aux bit to the kernel header, adding
it to the tools' header too.
Signed-off-by: Alexander Shishkin
---
tools/include/uapi/linux/perf_event.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/perf_event.
This adds support for suppress_aux, the switch that enables suppressing
not-so-useful PERF_RECORD_AUX records. Also handle kernels where it's
not supported.
Signed-off-by: Alexander Shishkin
---
tools/perf/util/evsel.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/perf
This makes use of the shiny new attr::suppress_aux that suppresses the
AUX records that don't carry any 'interesting' information for the
decoders, that is PERF_RECORD_AUX[flag==OVERWRITE], which just stack up
in the DATA buffer for no good reason.
Signed-off-by: Alexander Shish
Hi Greg,
Here are the fixes for char-misc-testing warnings introduced by my
STM/Intel TH patchset.
Alexander Shishkin (2):
stm class: Mark src::link __rcu
intel_th: Fix integer mismatch warnings
drivers/hwtracing/intel_th/msu.c | 2 +-
drivers/hwtracing/stm/core.c | 9
Source device's link is protected with srcu, mark it as such to have
proper build-time validation of accesses to this field. The update
side that's dereferencing it under an update lock also needs an
accessor to dereference this field to keep sparse happy.
Signed-off-by: Alexande
Use unsigned long in place of size_t to operate on buffer sizes and
offsets to clean up the 32 bit build.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/msu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/intel_th/msu.c b/drivers
Arnd Bergmann writes:
> The newly added MSU portion of the intel_th driver causes a harmless
> compile warning on 32-bit kernels:
>
> drivers/hwtracing/intel_th/msu.c: In function 'msc_single_to_user':
> include/linux/kernel.h:724:17: warning: comparison of distinct pointer types
> lacks a cast
Stephen Rothwell writes:
> Caused by commit
>
> 7bd1d4093c2f ("stm class: Introduce an abstraction for System Trace Module
> devices")
>
> from the char-misc tree interacting with commit
>
> f71933438300 ("configfs: remove old API")
>
> I have reverted the target-updated commit for today. I
to the new api, all the while making the
code quite a bit smaller and easier on the eyes.
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/stm/policy.c | 105 ++---
1 file changed, 24 insertions(+), 81 deletions(-)
diff --git a/drivers/hwtracing
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> +for (at = base; at < top; at++) {
>> +/*
>> + * Note that right now *this* BTS code only works if
>> + * attr::exclude_kernel is set, but let's keep this extra
Ingo Molnar writes:
> * Alexander Shishkin wrote:
>
>> BTS leaks kernel addresses even in userspace-only mode due to imprecise IP
>> sampling, so sometimes syscall entry points or page fault handler addresses
>> end up in a userspace trace.
>>
>> Now, inte
Andi Kleen writes:
> Alexander Shishkin writes:
>> +return sprintf(page, "%lu\n", val);
>> +case 1:
>> +cpuid(0x15, &eax, &ebx, &ecx, &edx);
>
> Surely this needs to be protected by a cpuid level check?
> Broa
works around the old (DS) driver and disables the new
(intel_bts) for the unprivileged users on systems where perf paranoia
level prohibits kernel tracing.
Not sure if these should be treated as bugfixes.
Alexander Shishkin (2):
perf/x86/intel/ds: Work around BTS leaking kernel addresses
per
plies kernel tracing, regardless of the
"exclude_kernel" attribute setting.
Signed-off-by: Alexander Shishkin
---
arch/x86/kernel/cpu/perf_event_intel_bts.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_bts.c
b/arch/x86/kernel/cp
pass through the records to know how many there are
of the valid ones, but considering the small size of the buffer, this extra
pass adds very little overhead to the nmi handler. This way we won't end
up with awkward IP samples with zero IPs in the perf stream.
Signed-off-by: Alexander Shi
Andy Shevchenko writes:
> On Mon, Aug 24, 2015 at 5:32 PM, Alexander Shishkin
> wrote:
>> + /* trim the buffer to the supplied boundary */
>> + len = strlen(buffer);
>> + if (len >= attr->perf_err_size) {
>> +
Takao Indoh writes:
> perf_event_create_kernel_counter is used to enable perf events in kernel
> without buffer for logging its events. This patch add new fucntion which
> enable perf events with ring buffer. Intel PT logger uses this to enable
> Intel PT and some associated events with its log b
Takao Indoh writes:
> +/* intel_pt */
> +static struct perf_event_attr pt_attr_pt = {
> + .config = 0x400, /* bit10: TSCEn */
Doesn't it make sense to make these things configurable via sysfs or
whatnot?
> +static int pt_log_buf_nr_pages = 128; /* number of pages for log buffer */
Alexander Shishkin writes:
> Since hw::itrace_started is now set in pmu::start to signal the beginning of
> the trace, do so also in the intel_bts driver.
>
> Signed-off-by: Alexander Shishkin
Peter, seems like you overlooked this one. Its counterpart to is in Linus'
master
From: Dan Carpenter
devm_ioremap() returns NULL on error, it doesn't return an ERR_PTR,
which is what the current code does. This patch corrects these
checks.
Signed-off-by: Dan Carpenter
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/intel_th/gth.c | 4 ++--
drivers/hwtr
Hi Greg,
Here are two small fixes for issues that robots found in my latest
patches in linux-next.
Alexander Shishkin (1):
stm class: Select configfs
Dan Carpenter (1):
intel_th: Check for NULL instead of ERR_PTR
drivers/hwtracing/intel_th/gth.c | 4 ++--
drivers/hwtracing/intel_th/msu.c
STM policy handling is basically configfs, I honestly don't know how we
ended up without a Kconfig dependency, but thanks to randconfig testing,
it's now caught.
Reported-by: Jim Davis
Reported-by: kbuild test robot
Signed-off-by: Alexander Shishkin
---
drivers/hwtracing/stm/Kconfi
Mathieu Poirier writes:
> For some tracers the event carries information to be embedded
> in the private structure returned by setup_aux().
You need to mention here what these tracers are and which bits of
event's information they need in their setup_aux(). Right now I can look
it up in this pat
Mathieu Poirier writes:
> Adding an ETB10 specific auxiliary area setup operation to be
> used by the perf framework when events are initialised.
>
> Part of this operation involves modeling the mmap'ed area based
> on the specific ways a sink buffer gathers information.
It really doesn't seem t
Mathieu Poirier writes:
> +static int etm_event_pmu_start(struct perf_event *event)
> +{
> + int cpu, ret;
> + cpumask_t mask;
> + struct coresight_device *csdev;
> +
> + cpumask_clear(&mask);
> + if (event->cpu != -1)
> + cpumask_set_cpu(event->cpu, &mask);
> +
Mathieu Poirier writes:
> +static void *etm_setup_aux(struct perf_event *event, void **pages,
> +int nr_pages, bool overwrite)
> +{
> + int cpu;
> + cpumask_t *mask;
> + struct etm_event_data *event_data = NULL;
> + struct coresight_device *csdev;
> +
> +
Mathieu Poirier writes:
> Implementing perf related APIs to activate and terminate
> a trace session. More specifically dealing with the sink
> buffer's internal mechanic along with perf's API to start
> and stop interactions with the ring buffers.
A matter of preference, but I'd say that it wo
Mathieu Poirier writes:
> /**
> + * struct cs_buffer - keep track of a recording session' specifics
> + * @cur: index of the current buffer
> + * @nr_pages:max number of pages granted to us
> + * @nr_bufs: number of clustered pages
> + * @offset: offset within the current buffer
> +
Mathieu Poirier writes:
> On 30 September 2015 at 03:58, Alexander Shishkin
> wrote:
>> Most of these things can also be bypassed, as at least initially perf
>> events won't be using trigger/sequencer configurations, so we could
>> simply clear all these things o
Mathieu Poirier writes:
> On 30 September 2015 at 05:33, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> Calling function 'smp_call_function_single()' to unlock the
>>> tracer and calling it right after to perform the default
>>
Mathieu Poirier writes:
> On 30 September 2015 at 05:50, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> +static void *etm_setup_aux(int cpu, void **pages,
>>> + int nr_pages, bool overwrite)
>>>
Mathieu Poirier writes:
> On 30 September 2015 at 02:52, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> This patchset aims to integrate configuration and control of
>>> the Coresight tracers with the perf sub-system.
>>>
>>>
pshot option 'e' can be specified in
-S to enable this behavior:
root@elsewhere:~# perf record -e intel_pt// -Se sleep 1
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.085 MB perf.data ]
Signed-off-by: Alexander Shishkin
---
tools/perf/Documentation/
1 - 100 of 1531 matches
Mail list logo
