> BTW, I note that "extern struct pstore_info *psinfo" locates in
> fs/pstore/internal.h. So users out of directory "fs/pstore/" can not use
> pstore to
> record messages. We do not want other kernel users to use pstore, right? And
> can we
> break this?
Yes we can make some interface visible
On Thu, 19 Jun 2014, Steven Rostedt wrote:
> > I don't think there is a need for a global stop_machine()-like
> > synchronization here. The printing CPU will be sending IPI to the CPU N+1
> > only after it has finished printing CPU N stacktrace.
>
> So you plan on sending an IPI to a CPU then
On Thu, 19 Jun 2014 18:51:13 +0200, Jiri Olsa wrote:
> On Thu, Jun 19, 2014 at 10:09:59PM +0900, Namhyung Kim wrote:
>> 2014-06-19 (목), 15:02 +0200, Jiri Olsa:
>> > On Thu, Jun 19, 2014 at 09:56:44PM +0900, Namhyung Kim wrote:
>> > > [SNIP]
>> > > > @@ -35,6 +35,7 @@ struct symbol_conf symbol_conf
On Thu, Jun 19, 2014 at 03:39:47PM -0700, H. Peter Anvin wrote:
> On 06/19/2014 01:01 PM, Greg KH wrote:
> > On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH
> >> wrote:
> >> + BUG_ON(f1->context != f2->context);
> >
> >
On Fri, 20 Jun 2014 01:27:26 +0200 (CEST)
Jiri Kosina wrote:
>
> I don't think there is a need for a global stop_machine()-like
> synchronization here. The printing CPU will be sending IPI to the CPU N+1
> only after it has finished printing CPU N stacktrace.
So you plan on sending an IPI to
On Sun, Jun 01, 2014 at 03:20:55AM -0700, Vincent Heuken wrote:
> This patch simply fixes the style errors in panel.c
> that scripts/checkpatch.pl reported
Which style errors? Please be specific.
And break the patch up into only doing one type of fix at a time,
otherwise it's hard to review.
The mm-of-the-moment snapshot 2014-06-19-16-33 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Thu, 2014-06-19 at 19:24 -0400, Pranith Kumar wrote:
> (dropping some CCs)
>
> On 06/19/2014 05:00 PM, Paul E. McKenney wrote:
> > On Wed, Jun 18, 2014 at 12:49:42PM -0700, Joe Perches wrote:
> >>
> >> I believe the function doesn't work well.
> >>
> >> static void
> >>
On Tue, Jun 17, 2014 at 02:40:27PM +0200, Martin Kepplinger wrote:
> Fix the sparse error: cast removes address space of expression and
> add __user annotation to the driver's ethtool_ioctl().
>
> Signed-off-by: Martin Kepplinger
> ---
> I think I forgot to change the declaration on top.
In case the Device Tree blob passed by the boot agent supplies both an
'interrupts-extended' and an 'interrupts' property in order to allow for
older kernels to be usable, prefer the new-style 'interrupts-extended'
property which convey a lot more information.
This allows us to have bootloaders
Hi Jiri,
On Thu, 19 Jun 2014 18:49:21 +0200, Jiri Olsa wrote:
> On Thu, Jun 19, 2014 at 12:38:51PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Jun 19, 2014 at 01:41:12PM +0200, Jiri Olsa escreveu:
>> > Separating ops out of 'struct ui_browser' into
>> > 'struct ui_browser_ops'.
>>
>> You
On Sun, Jun 01, 2014 at 10:19:31PM -0400, James A Shackleford wrote:
> The function iwctl_siwscan() is defined in iwctl.c as:
> int iwctl_siwscan(struct net_device *dev,
> struct iw_request_info *info,
> struct iw_point *wrq,
> char *extra)
> {
>
On Thu, 19 Jun 2014, Steven Rostedt wrote:
> > > > The idea basically is to *switch* what arch_trigger_all_cpu_backtrace()
> > > > and arch_trigger_all_cpu_backtrace_handler() are doing; i.e. use the
> > > > NMI
> > > > as a way to stop all the CPUs (one by one), and let the CPU that is
> > >
(dropping some CCs)
On 06/19/2014 05:00 PM, Paul E. McKenney wrote:
> On Wed, Jun 18, 2014 at 12:49:42PM -0700, Joe Perches wrote:
>>
>> I believe the function doesn't work well.
>>
>> static void
>> rcu_torture_stats_print(void)
>> {
>> int size = nr_cpu_ids * 200 + 8192;
>> char *buf;
On Thu, Jun 19, 2014 at 5:50 PM, Dave Airlie wrote:
> On 20 June 2014 04:19, Greg KH wrote:
>> On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote:
>>> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH wrote:
>>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>>> >> On Wed, Jun 18,
On Fri, 20 Jun 2014 01:03:28 +0200 (CEST)
Jiri Kosina wrote:
> On Thu, 19 Jun 2014, Steven Rostedt wrote:
>
> > > The idea basically is to *switch* what arch_trigger_all_cpu_backtrace()
> > > and arch_trigger_all_cpu_backtrace_handler() are doing; i.e. use the NMI
> > > as a way to stop all
On Thu, Jun 19, 2014 at 02:19:50PM -0700, Andrew Morton wrote:
> On Wed, 18 Jun 2014 18:12:44 +0200 Philippe De Muyter wrote:
>
> > some combinations of filesystem and block device (at least vfat on mmc)
> > yield -EROFS instead of -EACCES when the device is read-only. Retry
> > mounting with
On Thu, 2014-06-19 at 15:39 -0700, H. Peter Anvin wrote:
> On 06/19/2014 01:01 PM, Greg KH wrote:
> > On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
> >> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH
> >> wrote:
> >> + BUG_ON(f1->context != f2->context);
> >
> > Nice,
On Thu, Jun 19, 2014 at 02:32:03PM -0700, j...@joshtriplett.org wrote:
> On Thu, Jun 19, 2014 at 04:16:34PM -0500, Christoph Lameter wrote:
> > This looks very much like the CONFIG_PREEMPT problem in not so
> > extreme form. Maybe we need to add another config option:
> >
> >
> Wow that's junk issued by an Exchange server ... Alan, really ...
Blame evolution. It apparently thinks that if you follow up to your own
email from one address it should randomly switch to another.
> Do you have CONFIG_LBD turned on? That's supposed to let us go up to
> about 16TB before we
On Thu, 19 Jun 2014, Steven Rostedt wrote:
> > The idea basically is to *switch* what arch_trigger_all_cpu_backtrace()
> > and arch_trigger_all_cpu_backtrace_handler() are doing; i.e. use the NMI
> > as a way to stop all the CPUs (one by one), and let the CPU that is
> > sending the NMIs
Hi Paul,
On Thu, 19 Jun 2014 15:47:01 -0400 Paul Moore wrote:
>
> I want to avoid use a -rcX release as the foundation of any of my trees; the -
> rc releases aren't as stable and it goes against what we're trying to do with
> the different Linux Security trees. Unfortunately, based on what
On Thu, 19 Jun 2014 23:56:36 +0200 (CEST)
Jiri Kosina wrote:
> I agree this is less intrusive than having printk() use two versions of
> the buffers and perform merging, OTOH, it doesn't really seem to be
> fully clean and systematic solution either.
I'm not sure why you consider it not
On Sun, Jun 15, 2014 at 01:35:21AM +0200, Rickard Strandqvist wrote:
> Before when there was an error a uninitialized variable would be returnd.
> Now it returns -ENODEV
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/staging/imx-drm/ipu-v3/ipu-common.c |4 ++--
This file isn't even
On 06/18/2014 03:59 PM, Andy Lutomirski wrote:
>
> This may break make vdso_install with binutils before 2.17.50.0.17.
> On the other hand, make vdso_install was probably never useful with
> earlier binutils, since the installed files are AFAIK completely
> useless without build-id.
>
How does
On Sat, May 31, 2014 at 11:30:15PM +0300, Tair Rzayev wrote:
> Make jpeg_dqt[][] static
>
> Signed-off-by: Tair Rzayev
> ---
> drivers/staging/media/solo6x10/solo6x10-jpeg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please always use scripts/get_maintainer.pl to determine who to
On Sat, May 31, 2014 at 05:29:53PM -0600, Daniel Dressler wrote:
> This patch was made following Greg Kroah-Hartman's
> newbie guide. It is not intended to make any
> logical alterations to codeflow. Of note to reviews
> this patch switch's a call to kzalloc to kcalloc on
> line 2837
>
> Neil
Kevin,
On Thu, Jun 19, 2014 at 11:43 AM, Kevin Hilman wrote:
> Doug Anderson writes:
>
>> The original code for the exynos i2c controller registered for the
>> "noirq" variants. However during review feedback it was moved to
>> SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
On 06/18/2014 03:59 PM, Andy Lutomirski wrote:
> This series makes me sad. It brings the 64-bit vdso back above 4kB,
> like it was in 3.15. It's also just silly, but it seems to be
> needed to keep binutils happy when debugging the vdso.
Oh well... it is only a single page across the entire
On 06/19/2014 01:01 PM, Greg KH wrote:
> On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH wrote:
>> + BUG_ON(f1->context != f2->context);
>
> Nice, you just crashed the kernel, making it impossible to debug or
> recover
On Thu, Jun 19, 2014 at 12:21:44PM -0400, Theodore Ts'o wrote:
> On Thu, Jun 19, 2014 at 12:08:01PM -0400, Theodore Ts'o wrote:
> > > The other issue, not sure, not a lot of detail. It may be fixed by the
> > > pull
> > > request I sent out yesterday. You can try pulling in:
> > >
> > >
6b208e3f6e35 ("mm: memcg: remove unused node/section info from
pc->flags") deleted the lookup_cgroup_page() function but left a
prototype for it.
Kill the vestigial prototype.
Signed-off-by: Greg Thelen
---
include/linux/page_cgroup.h | 1 -
1 file changed, 1 deletion(-)
diff --git
On Thursday, June 19, 2014 9:24:10 AM PDT, Josef Bacik wrote:
On 05/16/2014 05:50 PM, Daniel Phillips wrote:
We would like to offer Tux3 for review for mainline merge. We
have prepared a new repository suitable for pulling:
On Mon, Jun 02, 2014 at 09:11:42AM -0700, Chaitanya Hazarey wrote:
> Removed dead code, commented out printks and DMESG.
>
> Signed-off-by: Chaitanya Hazarey
This patch does not apply :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, May 29, 2014 at 01:45:21PM -0700, Chaitanya Hazarey wrote:
> Removed dead code from the file.
>
> Signed-off-by: Chaitanya Hazarey
> ---
> drivers/staging/rtl8192u/r8192U_wx.c | 18 +-
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git
On Thu, May 29, 2014 at 01:45:17PM -0700, Chaitanya Hazarey wrote:
> Fixed a misplaced brace in the r8192_wx_set_scan_type function.
>
> Signed-off-by: Chaitanya Hazarey
> ---
> drivers/staging/rtl8192u/r8192U_wx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
On Thu, Jun 19, 2014 at 11:32:41PM +0200, Thomas Gleixner wrote:
>
>
> On Thu, 19 Jun 2014, Paul E. McKenney wrote:
>
> > On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas
On Thu, Jun 19, 2014 at 5:19 PM, Stephen Boyd wrote:
> On 06/18/14 13:55, Hai Li wrote:
>> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c
>> b/drivers/gpu/drm/msm/msm_fbdev.c
>> index 4f4e7b4..2522f51 100644
>> --- a/drivers/gpu/drm/msm/msm_fbdev.c
>> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
>> @@
On 20 June 2014 02:09, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 12:14:55PM -0400, Theodore Ts'o wrote:
>> Is this a known problem?
>>
>> On my T540p, occasionally the display will go black and then be
>> completely locked. One time when this happened, the display started
>> glitching and
On Thursday, June 19, 2014 2:26:48 AM PDT, Lukáš Czerner wrote:
On Thu, 19 Jun 2014, Pavel Machek wrote:
Date: Thu, 19 Jun 2014 10:21:29 +0200
From: Pavel Machek
To: James Bottomley
Cc: Daniel Phillips , Dave Chinner
,
linux-kernel@vger.kernel.org, linux-fsde...@vger.kernel.org,
...
Make it match the bindings and the implementation.
Signed-off-by: Thomas Gleixner
---
arch/arm/boot/dts/spear320.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/arm/boot/dts/spear320.dtsi
===
---
The sdhci compatible does neither match the documentation nor the
implementaion in the drivers and the i2c1 is missing an interrupt
assignment.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Thu, 19 Jun 2014, Steven Rostedt wrote:
> This is my proposal to print the NMI stack traces from an RCU stall safely.
> Here's the gist of it.
>
> Patch 1: move the trace_seq out of the tracing code. It's useful for other
> purposes too. Like writing from an NMI context.
>
> Patch 2: Add a
Hi,
I triggered the following bug on v3.16-rc1 when I did mbind() testing
where multiple processes repeat calling mbind() for a shared mapped file
(causing pingpong of page migration.)
In my investigation, it seems that some vma accidentally has vma->vm_start
= 0, which makes new_vma_page()
Signed-off-by: Thomas Gleixner
---
arch/arm/boot/dts/spear320.dtsi |5 +
1 file changed, 5 insertions(+)
Index: linux/arch/arm/boot/dts/spear320.dtsi
===
--- linux.orig/arch/arm/boot/dts/spear320.dtsi
+++
When the spidev module tries to access the user space memory passed in via
an IOCTL the compat_ptr function should be called to ensure
compatibility between kernel space and user space.
Signed-off-by: Dan Sneddon
---
drivers/spi/spidev.c | 10 ++
1 file changed, 6 insertions(+), 4
The uarts only work when the parent is ras_ahb_clk. The stale 3.5
based ST tree does this in the board file.
Add it to the clk init function. Not pretty, but the mess there is
amazing anyway.
Signed-off-by: Thomas Gleixner
---
drivers/clk/spear/spear3xx_clock.c | 14 ++
1 file
This code is broken since commit 5df33a62c (SPEAr: Switch to common
clock framework). Sigh...
The first patch fixes that issue and the second one makes the uarts1/2
usable.
Quality stuff that.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62c (SPEAr: Switch to common clock framework).
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
---
drivers/clk/spear/spear3xx_clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
On 20 June 2014 04:19, Greg KH wrote:
> On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote:
>> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH wrote:
>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH
>> >> wrote:
>> >> > On Wed, Jun
On Thu, 19 Jun 2014, Kevin Hilman wrote:
> Nicolas Pitre writes:
>
> > On Thu, 19 Jun 2014, Kevin Hilman wrote:
> >
> >> I think this should probably be officialized since we've taken away the
> >> ability for magic-number checking tools (like 'file') to distinguish
> >> between big- and
Hello,
So, this patch should do. Joe, Vivek, can one of you guys please
verify that the oops goes away with this patch?
Jens, the original thread can be read at
http://thread.gmane.org/gmane.linux.kernel/1720729
The fix converts blkg->refcnt from int to atomic_t. It does some
overhead but
On Thu, Jun 19, 2014 at 02:38:44PM -0400, Jeff Moyer wrote:
> Mel Gorman writes:
>
> > The existing CFQ default target_latency results in very poor performance
> > for larger numbers of threads doing sequential reads. While this can be
> > easily described as a tuning problem for users, it is
This is my proposal to print the NMI stack traces from an RCU stall safely.
Here's the gist of it.
Patch 1: move the trace_seq out of the tracing code. It's useful for other
purposes too. Like writing from an NMI context.
Patch 2: Add a per_cpu "printk_func" that printk calls. By default it
From: "Steven Rostedt (Red Hat)"
Being able to divert printk to call another function besides the normal
logging is useful for such things like NMI handling. If some functions
are to be called from NMI that does printk() it is possible to lock up
the box if the nmi handler triggers when another
From: "Steven Rostedt (Red Hat)"
The trace_seq functions are rather useful outside of tracing. Instead
of having it be dependent on CONFIG_TRACING, move the code into lib/
and allow other users to have access to it even when tracing is not
configured.
Signed-off-by: Steven Rostedt
---
From: "Steven Rostedt (Red Hat)"
When trigger_all_cpu_backtrace() is called on x86, it will trigger an
NMI on each CPU and call show_regs(). But this can lead to a hard lock
up if the NMI comes in on another printk().
In order to avoid this, when the NMI triggers, it switches the printk
routine
The driver is broken for spear320 since commit 80515a5a(ARM: SPEAr3xx:
shirq: simplify and move the shared irq multiplexor to DT). Clearly
never tested on spear320.
Aside of that it's an unreadable overengineered trainwreck with lots
of obscure "functionality".
Make it work and clean it up.
No point in having them in a separate header file. Make the init
functions static.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 52 +
include/linux/irqchip/spear-shirq.h | 64
2 files changed, 45
The ras3 block on spear320 claims to have 3 interrupts. In fact it has
one and 6 reserved interrupts. Account the 6 reserved to this block so
it has 7 interrupts total. That matches the datasheet and the device
tree entries.
Broken since commit 80515a5a(ARM: SPEAr3xx: shirq: simplify and move
the
The struct member is pointless and a nismomer as well.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
Index: linux/drivers/irqchip/spear-shirq.c
Calculate the status mask at compile time, not at runtime.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
Index: linux/drivers/irqchip/spear-shirq.c
The struct members of the shirq block struct are named to confuse the
hell out of the casual reader. Clean it up.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 106 +-
1 file changed, 53 insertions(+), 53 deletions(-)
Index:
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/irqchip/spear-shirq.c
===
--- linux.orig/drivers/irqchip/spear-shirq.c
+++
None of the chips has a ACK register. The code brainlessly fiddles
with the enable register, so it might even reenable a disabled
interrupt at least on spear300.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 35 +--
1 file changed, 1
No point in doing a full irq lookup, when the desc pointer is
available.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux/drivers/irqchip/spear-shirq.c
"ack" is actually a mask in the parent irq. The demultiplexer and the
handlers run with interrupts disabled. No point in masking and
unmasking the parent.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c |6 --
1 file changed, 6 deletions(-)
Index:
I don't know if there are less efficient ways to code that. Get rid of
the loop mess and use efficient code.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
Index: linux/drivers/irqchip/spear-shirq.c
Only spear300 has an actual mask register for the RAS interrupts. Add
an irq chip pointer to the shirq struct and initialize spear300 with
the actual implementation and the others with dummy_irq_chip. The
disabled RAS3 block has no irq chip assigned, so we can check for this
and remove the
Order the ras blocks in the order of interrupts not alphabetically.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
Index: linux/drivers/irqchip/spear-shirq.c
The extra register data structure is pointless. Move the offsets of
the status and the mask register into the shirq block structure.
Signed-off-by: Thomas Gleixner
---
drivers/irqchip/spear-shirq.c | 61 +++---
1 file changed, 16 insertions(+), 45
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 10:37:17PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > On Thu, Jun 19, 2014 at 09:29:08PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> > > >
On Thu, Jun 19, 2014 at 09:29:26PM +0400, Evgeniy Polyakov wrote:
> Hi Scott
>
> I've added Greg to copy.
>
> 18.06.2014, 00:42, "Scott Alfter" :
> > Some preliminary work at making use of this driver led me to implement
> > CRC-16 checks on read and write to deal with the occasional glitchiness
On Thu, Jun 19, 2014 at 04:16:34PM -0500, Christoph Lameter wrote:
> This looks very much like the CONFIG_PREEMPT problem in not so
> extreme form. Maybe we need to add another config option:
>
> CONFIG_REALLY_REALLY_NO_PREEMPT
>
> to get the fastest code possible and those cond_rescheds removed
On Thu, Jun 19, 2014 at 09:33:26AM +, Cox, Alan wrote:
> On Thu, 2014-06-19 at 10:30 +0100, Alan Cox wrote:
> > The block code has 32bit cleanness problems with the iterator. This
> > prevents things like partitioning a 32GB volume on a 32bit system.
> >
> > I hit this with a volume of
2014-06-20 1:06 GMT+04:00 Andrew Morton :
> On Thu, 19 Jun 2014 15:56:56 -0500 (CDT) Christoph Lameter
> wrote:
>
>> On Thu, 19 Jun 2014, Andrey Ryabinin wrote:
>>
>> > I see no reason why calls to other debugging subsystems (LOCKDEP,
>> > DEBUG_ATOMIC_SLEEP, KMEMCHECK and FAILSLAB) are hidden
On Thu, 2014-06-19 at 15:29 -0400, Nicholas Krause wrote:
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
[]
> @@ -59,7 +58,8 @@ static bool fw_download_code(struct net_device *dev, u8
> *code_virtual_address,
>
On Thu, Jun 19, 2014 at 01:17:02PM -0700, j...@joshtriplett.org wrote:
> On Thu, Jun 19, 2014 at 04:12:46PM -0400, Pranith Kumar wrote:
> > Use __this_cpu_read() instead of per_cpu_ptr() for optimized access.
> >
> > Last time when Shan Wei posted this, you wanted before/after code for ARM
> >
On Wed, 18 Jun 2014 18:12:44 +0200 Philippe De Muyter wrote:
> some combinations of filesystem and block device (at least vfat on mmc)
> yield -EROFS instead of -EACCES when the device is read-only. Retry
> mounting with MS_RDONLY set, just like for the EACCES case, instead of
> failing
On 06/18/14 13:55, Hai Li wrote:
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
> index 4f4e7b4..2522f51 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -19,6 +19,11 @@
>
> #include "drm_crtc.h"
> #include
Checks for Null return from dev_skb_alloc if it returns Null,
fw_download returns false. Otherwise it returns true.Also
removed rt_status due to returning true of false directly.
Signed-off-by: Nicholas Krause
---
drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 7 ---
1 file changed,
From: Arnaldo Carvalho de Melo
There was a brown paper bag bug in the patch that introduced a reference
implementation on using 'perf probe' made wannabe tracepoints that broke fd ->
pathname resolution, fix it:
[root@zoo ~]# perf probe 'vfs_getname=getname_flags:65
This looks very much like the CONFIG_PREEMPT problem in not so
extreme form. Maybe we need to add another config option:
CONFIG_REALLY_REALLY_NO_PREEMPT
to get the fastest code possible and those cond_rescheds removed from the
critical paths?
Or better
CONFIG_PREEMPT_HALF_WAY
to enable those
From: Jiri Olsa
Removing ev_name argument from perf_evsel__hists_browse function,
because it's not needed. We can get the name out of the 'struct
perf_evsel' which is passed as argument as well.
Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo
From: Davidlohr Bueso
There are a number of benchmarks that do single runs and as a result
does not really help users gain a general idea of how the workload
performs. So the user must either manually do multiple runs or just use
single bogus results.
This option will enable users to specify
From: Davidlohr Bueso
This option is available through perf-bench, use it instead and free the
local option.
Signed-off-by: Davidlohr Bueso
Cc: Aswin Chandramouleeswaran
Cc: Hitoshi Mitake
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1402942467-10671-6-git-send-email-davidl...@hp.com
From: Davidlohr Bueso
Explicitly free the thread array ('pth_tab').
Signed-off-by: Davidlohr Bueso
Cc: Aswin Chandramouleeswaran
Cc: Hitoshi Mitake
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1402942467-10671-5-git-send-email-davidl...@hp.com
Signed-off-by: Arnaldo Carvalho de Melo
---
From: Davidlohr Bueso
Instead of reinventing the wheel, we can use err(2) when dealing with
fatal errors. Exit code is now always EXIT_FAILURE (1).
Signed-off-by: Davidlohr Bueso
Cc: Aswin Chandramouleeswaran
Cc: Hitoshi Mitake
Cc: Jiri Olsa
Link:
On Thu, Jun 19, 2014 at 04:11:47PM -0500, Christoph Lameter wrote:
> The aim of having percpu data is to have the ability for a processor to
> access memory dedicated to that processor in the fastest way possible by
> avoiding synchronization. You are beginning to add synchronization
> elements
From: Jiri Olsa
The ui_browser__gotorc function needs offset from 'y' member, so the row
index has to begin with 0, which happens by accident in current code,
because we display only one header line.
The bug shows when we want to display more than 1 header lines like
columns headers in
From: Davidlohr Bueso
-o, --only-prefault Show only the result with page faults before mem*
-n, --no-prefault Show only the result without page faults before mem*
Makes no sense to call together. Applies to both memset and memcpy.
Signed-off-by: Davidlohr Bueso
Cc: Aswin
From: Arnaldo Carvalho de Melo
Minor hint to speed up problem resolution and get 'trace' working for
non root users.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc:
Hi Ingo,
Please conseider pulling,
- Arnaldo
The following changes since commit a10d60c08cc3bbea9195e2b36440f557373623eb:
sh, perf: Use common PMU interrupt disabled code (2014-06-19 19:37:51 +0200)
are available in the git repository at:
From: Arnaldo Carvalho de Melo
The thread->priv value is already obtained a few lines earlier from the
thread__trace() call. Leftovers from before thread__trace().
Cc: Adrian Hunter
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
From: Arnaldo Carvalho de Melo
No need to use two strcmp calls per syscall entry, do it just once, when
reading the per syscall info.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter
On Thu, 2014-06-19 at 23:04 +0200, Federico Di Pierro wrote:
> This is a very small patch that fixes 3 little coding style problems.
> I'm using linux-next.
Hello Federico.
Your patch is word wrapped and can't be applied.
Please read Documentation/SubmittingPatches and
On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> On Thu, Jun 19, 2014 at 03:31:56PM -0500, Christoph Lameter wrote:
> > On Thu, 19 Jun 2014, Paul E. McKenney wrote:
> >
> > > That is a separate issue, but unnecessary calls to cond_resched()
> > > should of course be removed -- no argument there.
>
Thanks Joe,
I need to read my patches more carefully.
Nick :)
On Thu, Jun 19, 2014 at 4:53 PM, Joe Perches wrote:
> On Thu, 2014-06-19 at 16:20 -0400, Nick Krause wrote:
>> Hey Guys,
>> So Sorry about wasting your time with bad patchs.
>> I feel bad about that. I hope this patch is O.K.
>> now.
On Thu, 2014-06-19 at 11:43 -0700, James Bottomley wrote:
> On Thu, 2014-06-19 at 09:33 +, Cox, Alan wrote:
> > NrybXǧv^){.n+{~^b^nrzh& Gh(階ݢj"mzޖfh~m
>
> Wow that's junk issued by an Exchange server ... Alan, really ...
I'm guessing that would be your client (Evolution) trying to
On Thu, 19 Jun 2014, Tejun Heo wrote:
> On Thu, Jun 19, 2014 at 03:42:07PM -0500, Christoph Lameter wrote:
> > In that case special care needs to be taken to get this right. True.
> >
> > I typically avoid these scenarios by sending an IPI with a pointer to the
> > data structure. The
101 - 200 of 1522 matches
Mail list logo
