On Mon, Feb 11, 2013 at 05:10:58PM +0100, Roger Pau Monne wrote:
> Replace llist_for_each_entry_safe with a while loop and
> llist_del_first.
>
> llist_for_each_entry_safe can trigger a bug in GCC 4.1, so it's best
> to remove it and use a while loop and llist_del_first (which is
> already in
On Wed, Feb 13, 2013 at 3:44 PM, Mimi Zohar wrote:
> On Wed, 2013-02-13 at 15:13 +0200, Kasatkin, Dmitry wrote:
>> On Wed, Feb 13, 2013 at 2:56 PM, Mimi Zohar wrote:
>> > On Wed, 2013-02-13 at 14:31 +0200, Kasatkin, Dmitry wrote:
>> >> On Mon, Feb 11, 2013 at 10:11 PM, Vivek Goyal wrote:
>> >
The original code was generating an lsl instructions using the value
of ARM_R8 (skb_headlen, possibly uninitialized if no skb_headlen
access was required) as a shift amount.
Signed-off-by: Nicolas Schichan
---
Resent due to missing Signed-off-by
arch/arm/net/bpf_jit_32.c | 15 +++
On Wed, Feb 13, 2013 at 08:45:47AM -0800, Greg KH wrote:
>
> I can take these through my tty tree, but it would be very good if I
> actually had the ack from the PPS maintainer...
>
> Rodolfo, any objection for me taking these?
No. It's ok for me. If you wish you can add my «Acked-by» sign.
On 13.02.2013 09:28, Holger Hoffstätte wrote:
> On 12.02.2013 21:42, Sarah Sharp wrote:
> > [..]
> > I think I see the issue. Your host controller reports the Inactive
> > state after a USB disconnect. My host controllers go to the RxDetect
> > state on a disconnect.
> >
> > The patches that
On Wed, 2013-02-13 at 09:20 -0800, H. Peter Anvin wrote:
> Problem:
>
> Someone adds SYS_CAP_RAWIO to some places it definitely does not
> belong.
>
> Solution:
>
> Break all the *appropriate* (as defined)uses of SYS_CAP_RAWIO?
Problem:
CAP_SYS_RAWIO has been used in a bunch of arguably
On Wed, Feb 13, 2013 at 05:26:27PM +0200, Kasatkin, Dmitry wrote:
> On Wed, Feb 13, 2013 at 4:38 PM, Vivek Goyal wrote:
> > On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote:
> >> It should not be the only line in the policy.
> >> Can you share full policy?
> >
> > I verified by
On Wed, 2013-02-13 at 17:11 +0100, Sebastian Andrzej Siewior wrote:
> 3.2-rt is a long term supported kernel, which lacks two RT features
> from 3.6: SLUB support and the split softirq lock implementation.
>
> SLUB has a way better performance than SLAB on RT and the split
> softirq lock
On 02/13/2013 12:27 AM, Paolo Bonzini wrote:
On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially
when coupled with file DAC.
Either way, I think you are at best deluded and more like you just
completely wrong about CAP_SYS_RAWIO being "less dangerous on non-x86
machines".
The original code was generating an lsl instructions using the value
of ARM_R8 (skb_headlen, possibly uninitialized if no skb_headlen
access was required) as a shift amount.
---
arch/arm/net/bpf_jit_32.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git
Documentation/blockdev/nbd.txt contained some documentation which was
horribly outdated and probably still dates from the original patch that
added NBD support to the kernel.
This patch removes the useless and outdated bits. The tools on
nbd.sf.net are fully documented in manpages, which is where
On 02/13/2013 12:27 AM, Paolo Bonzini wrote:
On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially
when coupled with file DAC.
"File DAC"?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe
On 02/12/2013 10:41 PM, Matthew Garrett wrote:
On Tue, 2013-02-12 at 22:33 -0800, H. Peter Anvin wrote:
That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl()
which means you can reprogram your northbridge, at which point you most
definitely *can* modify the running kernel.
On Wed, 13 Feb 2013, John Kacur wrote:
>
> Thanks Steven. That looks way better than the previous revert.
I can't tell as I haven't seen the previous revert. And looks good is
not really a good review criteria.
The patch is converting _all_ the spin_locks in acpi to raw spinlocks,
which will
On Wed, Feb 13, 2013 at 08:55:29AM -0800, Dan Magenheimer wrote:
> For completeness, I thought I should add some planning items
> that ARE new functionality. In my opinion, these can wait
> until after promotion, but mm developers may have different
> opinions:
>
> ZCACHE FUTURE NEW
Unify board-dt-tegra{30,114} to the Tegra20 DT board file, "tegra.c".
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/Makefile|4 +--
arch/arm/mach-tegra/board-dt-tegra114.c | 46
arch/arm/mach-tegra/board-dt-tegra30.c | 60
This is the preparation to unify "board-dt-tegra{20,30,114}.c" to a
single file "tegra.c".
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/Makefile |2 +-
.../arm/mach-tegra/{board-dt-tegra20.c => tegra.c} |0
2 files changed, 1 insertion(+), 1 deletion(-)
Refactored tegra{20,30,114}_init_early() so that we have the unified
tegra_init_early().
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/board-dt-tegra114.c |2 +-
arch/arm/mach-tegra/board-dt-tegra20.c |2 +-
arch/arm/mach-tegra/board-dt-tegra30.c |4 ++--
Hi,
I just sent reworked version of the code. I am looking forward for comments.
Sorry, I have no time to fix your next requests:
1) It's a bit clunky having two device types on the same character device. Is
there a better way to do this?
2) + mutex_lock(_chr_dev_lock);
This locking is very
Joel Becker writes:
> On Tue, Nov 20, 2012 at 04:43:37AM -0800, Eric W. Biederman wrote:
>> --- a/fs/ocfs2/file.c
>> +++ b/fs/ocfs2/file.c
>> @@ -1116,7 +1116,8 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr
>> *attr)
>> (unsigned long
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Wednesday, February 13, 2013 11:22 AM
> To: KY Srinivasan
> Cc: H. Peter Anvin; x...@kernel.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
>
On 13 February 2013 16:28, Paul Turner wrote:
> On Wed, Feb 13, 2013 at 12:54 AM, Vincent Guittot
> wrote:
>> When a RT task is scheduled on an idle CPU, the update of the rq's load is
>> not done because CFS's functions are not called. Then, the idle_balance,
>> which is called just before
On 13/02/13 16:53, Michael S. Tsirkin wrote:
> On Wed, Feb 13, 2013 at 03:28:52PM +, Marc Zyngier wrote:
>> On 13/02/13 15:08, Pawel Moll wrote:
>>> On Wed, 2013-02-13 at 14:25 +, Marc Zyngier wrote:
Using readl() to read the magic value and then memcmp() to check it
fails on BE,
On Wed, Feb 13, 2013 at 3:10 AM, Ingo Molnar wrote:
>
>
> Setting up Logical Volume Management: [ 13.14] BUG: spinlock lockup
> suspected on CPU#1, lvm.static/139
> [ 13.14] BUG: spinlock lockup suspected on CPU#1, lvm.static/139
> [ 13.14] lock: 0x97fe9fc0, .magic: dead4ead,
On Wed, Feb 13, 2013 at 08:44:04AM -0500, Mimi Zohar wrote:
[..]
> > I see it is more logical if it is "appraise_type=optional",
> > which means that we might have no xattr value, hash or signature.
> > It if happens to be a signature, then IMA_DIGSIG flag will be set.
>
> Right,
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Subject: Re: [PATCH] staging/zcache: Fix/improve zcache writeback code, tie
> to a config option
>
> On Mon, Feb 11, 2013 at 01:43:58PM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> >
> > > So, how
On Wed, Feb 13, 2013 at 03:28:52PM +, Marc Zyngier wrote:
> On 13/02/13 15:08, Pawel Moll wrote:
> > On Wed, 2013-02-13 at 14:25 +, Marc Zyngier wrote:
> >> Using readl() to read the magic value and then memcmp() to check it
> >> fails on BE, as bytes will be the other way around (by
From: Sedat Dilek
Date: Wed, 13 Feb 2013 13:41:21 +0100
> On Wed, Feb 13, 2013 at 12:20 PM, James Hogan wrote:
>> I get the following build error on next-20130213 due to the following
>> commit:
>>
>> commit f05de73bf82fbbc00265c06d12efb7273f7dc54a ("skbuff
On 02/12/2013 11:12 PM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Tue, 12 Feb 2013 17:35:56
> +0100:
>
>> However I'd like to avoid changing the body of those two functions at
>> all if possible, since I hope the PCIe driver rework will be merged in
>> 3.10, and that will allow the Harmony
On Thu, 13 Dec 2012, Steven Rostedt wrote:
> I didn't get a chance to test the latest IPI patch series on the 40 core
> box, and only had my 4 way box to test on. But I was able to test it
> last night and found some issues.
>
> The RT_PUSH_IPI doesn't get automatically set because just doing
On Wed, 13 Feb 2013, Steven Rostedt wrote:
> We hit the following bug with 3.6-rt:
>
> [5.898990] BUG: scheduling while atomic: swapper/3/0/0x0002
> [5.898991] no locks held by swapper/3/0.
> [5.898993] Modules linked in:
> [5.898996] Pid: 0, comm: swapper/3 Not tainted
On Tue, Feb 12, 2013 at 08:56:07AM -0500, George Spelvin wrote:
> The standard N_TTY line discipline used to not use the tty->disc_data
> field, so N_PPS felt free to use it. That has now changed, requiring
> that N_PPS use a different method to find its private data.
>
> (In the current, buggy,
> On Wed, Feb 13, 2013 at 02:36:32PM +0100, Linus Walleij wrote:
> > On Tue, Feb 12, 2013 at 5:56 AM, Suman Anna wrote:
> >
> > > I have hosted the series at [3].
> > > [3]
> > > https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
> >
> > Suman, I suggest you ask Stepgen Rothwell to
On Wed, 13 Feb 2013, Steven Rostedt wrote:
> The lock was converted from a raw to a sleeping lock due to some
> previous issues, and tests that showed it didn't seem to matter.
> Unfortunately, it did matter for one of our boxes.
Yep. The other issues are functions like kfree() called under that
On Tue, 2013-02-12 at 10:58 +0800, Haojian Zhuang wrote:
> do_initcalls() could call all driver initialization code in kernel_init
> thread. It means that probe() function will be also called from that
> time. After this, kernel could access console & release __init section
> in the same thread.
>
From: Christoph Lameter
Pass a kmem_cache_cpu pointer into unfreeze partials so that a different
kmem_cache_cpu structure than the local one can be specified.
Reported-by: Thomas Gleixner
Signed-off-by: Christoph Lameter
[bigeasy@linutronix: remove unused n2]
Signed-off-by: Sebastian Andrzej
From: Thomas Gleixner
Make SLUB RT aware and remove the restriction in Kconfig.
Signed-off-by: Thomas Gleixner
[bigeasy@linutronix: fix a few conflicts]
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/slub_def.h |2 +-
init/Kconfig |1 -
mm/slub.c
From: Thomas Gleixner
Make SLUB RT aware and remove the restriction in Kconfig.
Signed-off-by: Thomas Gleixner
[bigeasy@linutronix: fix a few conflicts]
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/slub_def.h |2 +-
init/Kconfig |1 -
mm/slub.c
From: Thomas Gleixner
SYSTEM_RUNNING might be too late for enabling interrupts. Allocations
with GFP_WAIT can happen before that. So use this as an indicator.
Signed-off-by: Thomas Gleixner
[bigeasy@linutronix: fix !page conflict]
Signed-off-by: Sebastian Andrzej Siewior
---
mm/slub.c | 13
From: Gilad Ben-Yossef
We have lots of infrastructure in place to partition multi-core systems
such that we have a group of CPUs that are dedicated to specific task:
cgroups, scheduler and interrupt affinity, and cpuisol= boot parameter.
Still, kernel code will at times interrupt all CPUs in the
From: Christoph Lameter
As Steven Rostedt has pointer out: Rescheduling could occur on a differnet
processor
after the determination of the per cpu pointer and before the tid is retrieved.
This could result in allocation from the wrong node in slab_alloc.
The effect is much more severe in
On 13/02/13 15:46, Pawel Moll wrote:
> On Wed, 2013-02-13 at 15:28 +, Marc Zyngier wrote:
Fix it by encoding the magic as an integer instead of a string.
So I'm not completely sure this is the right fix,
>>>
>>> It seems right, however...
>>>
- Using __raw_readl() instead. Is
From: Gilad Ben-Yossef
Add the on_each_cpu_cond() function that wraps on_each_cpu_mask() and
calculates the cpumask of cpus to IPI by calling a function supplied as a
parameter in order to determine whether to IPI each specific cpu.
The function works around allocation failure of cpumask
* Jon Hunter [130213 08:10]:
> On 02/13/2013 09:57 AM, Jon Hunter wrote:
> > On 02/13/2013 03:28 AM, Sourav Poddar wrote:
> >
> > A quick look at the data manual shows that omap4430 and omap4460 has the
> > same pin mux options for i2c. Furthermore, the data manual shows only
> > one mux option
On Wed, Feb 13, 2013 at 08:31:00AM -0800, Randy Dunlap wrote:
> This warning is still present in linux-next (20130213).
>
> Acked-by: Randy Dunlap
>
> Thanks.
>
> Someone please merge... (kvm@ cc added)
There's a fix already in tip for this:
http
From: Thomas Gleixner
SYSTEM_RUNNING might be too late for enabling interrupts. Allocations
with GFP_WAIT can happen before that. So use this as an indicator.
Signed-off-by: Thomas Gleixner
[bigeasy@linutronix: fix !page conflict]
Signed-off-by: Sebastian Andrzej Siewior
---
mm/slub.c | 13
From: Gilad Ben-Yossef
flush_all() is called for each kmem_cache_destroy(). So every cache being
destroyed dynamically ends up sending an IPI to each CPU in the system,
regardless if the cache has ever been used there.
For example, if you close the Infinband ipath driver char device file, the
From: Christoph Lameter
Pass a kmem_cache_cpu pointer into unfreeze partials so that a different
kmem_cache_cpu structure than the local one can be specified.
Reported-by: Thomas Gleixner
Signed-off-by: Christoph Lameter
[bigeasy@linutronix: remove unused n2]
Signed-off-by: Sebastian Andrzej
Hi Dave,
On 02/12/2013 01:49 PM, Dave Jones wrote:
On Wed, Feb 06, 2013 at 09:02:07AM -0800, dirk.brande...@gmail.com wrote:
Won't you also need to patch drivers/cpufreq/acpi-cpufreq.c to not load
on the processors that you want this driver to run on ?
Dave
For the case where both
On Wed, Feb 13, 2013 at 06:35:10PM +0900, Chanwoo Choi wrote:
> This patch move defined constants to header file(max77693-private.h)
> because of mask/unmask selectively interrupt of MUIC device according
> to attribute of H/W board.
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Myungjoo Ham
'Twas brillig, and Andreas Mohr at 13/02/13 16:13 did gyre and gimble:
> [not sure about CCs - I readded both initramfs-tools and lkml]
Sorry about CC's I read mail via gmane's NNTP interface and it mangles
the address for the initramfs list which makes it a pain to reply-all
properly. If someone
On Wed, Feb 13, 2013 at 11:46:29AM +0100, Jean Delvare wrote:
> Mark M. Hoffman stopped working on the Linux kernel several years
> ago, so he should no longer be listed as a driver maintainer. I'm not
> even sure if his e-mail address still works.
>
> I can take over 3 drivers he was responsible
On 02/13/2013 12:02 AM, Laxman Dewangan wrote:
> On Tuesday 12 February 2013 11:16 PM, Stephen Warren wrote:
>> On 02/12/2013 08:17 AM, Laxman Dewangan wrote:
>>> Initialise the parent of UARTs to PLLP and disabling clock by
>>> default.
>>
>> This patch wasn't tested, was it? Without the patch I
On 02/13/2013 10:21 AM, Michal Simek wrote:
> 2013/2/7 Rob Herring :
>> From: Rob Herring
>>
>> In cases where we have multiple nodes of the same type, we may need the
>> node pointer to know which node was matched. Passing the node pointer
>> also keeps the init function from having to match the
explicitly cast to it.
>
> So, we'll do just that. We will consider it an unsigned long
> long, and cast to it explicitly.
>
> Signed-off-by: Dave Hansen
This warning is still present in linux-next (20130213).
Acked-by: Randy Dunlap
Thanks.
Someone please merge... (kvm@ cc
On Wed, Feb 13, 2013 at 02:07:52PM +, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: H. Peter Anvin [mailto:h...@zytor.com]
> > Sent: Tuesday, February 12, 2013 7:31 PM
> > To: Greg KH
> > Cc: KY Srinivasan; x...@kernel.org; linux-kernel@vger.kernel.org;
> >
2013/2/7 Rob Herring :
> From: Rob Herring
>
> In cases where we have multiple nodes of the same type, we may need the
> node pointer to know which node was matched. Passing the node pointer
> also keeps the init function from having to match the node a 2nd time.
>
> Signed-off-by: Rob Herring
>
On Wed, Feb 13, 2013 at 04:30:32PM +0100, Paolo Bonzini wrote:
> Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
> > 3.7-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Dave Chinner
> >
> > commit
From: Thomas Gleixner
We can't rely on ksoftirqd anymore and we need to check the tasks
which run a particular softirq and if such a task is pi blocked ignore
the other pending bits of that task as well.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
From: Thomas Gleixner
rcu_read_unlock_special() checks in_serving_softirq() and leaves early
when true. On RT this is obviously wrong as softirq processing context
can be preempted and therefor such a task can be on the gp_tasks
list. Leaving early here will leave the task on the list and
From: Thomas Gleixner
We really want to find code which calls __raise_softirq_irqsoff() and
runs neither in hardirq context nor in a local_bh disabled
region. This is even wrong on mainline as that code relies on random
events to take care of it's newly raised softirq.
Signed-off-by: Thomas
From: Thomas Gleixner
We can't rely on ksoftirqd anymore and we need to check the tasks
which run a particular softirq and if such a task is pi blocked ignore
the other pending bits of that task as well.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
From: Thomas Gleixner
Split out the inner handling function, so RT can reuse it.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/softirq.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git
From: Thomas Gleixner
We really need to iterate through all softirqs to find a potentially
blocked runner.
T1 runs softirq X (that cleared pending bit for X)
Interrupt raises softirq Y
T1 gets blocked on a lock and lock owner is not runnable
T1 schedules out
CPU goes idle and complains
From: Thomas Gleixner
We really want to find code which calls __raise_softirq_irqsoff() and
runs neither in hardirq context nor in a local_bh disabled
region. This is even wrong on mainline as that code relies on random
events to take care of it's newly raised softirq.
Signed-off-by: Thomas
From: Thomas Gleixner
This code triggers the new WARN in __raise_softirq_irqsoff() though it
actually looks at the softirq pending bit and calls into the softirq
code, but that fits not well with the context related softirq model of
RT. It's correct on mainline though, but going through
From: Christoph Lameter
As Steven Rostedt has pointer out: Rescheduling could occur on a differnet
processor
after the determination of the per cpu pointer and before the tid is retrieved.
This could result in allocation from the wrong node in slab_alloc.
The effect is much more severe in
From: Christoph Lameter
The variables accessed in slab_alloc are volatile and therefore
the page pointer passed to node_match can be NULL. The processing
of data in slab_alloc is tentative until either the cmpxhchg
succeeds or the __slab_alloc slowpath is invoked. Both are
able to perform the
From: Thomas Gleixner
The 3.x RT series removed the split softirq implementation in favour
of pushing softirq processing into the context of the thread which
raised it. Though this prevents us from handling the various softirqs
at different priorities. Now instead of reintroducing the split
3.4-rt which lacks two RT features from 3.6: SLUB support and the
split softirq lock implementation.
SLUB has a way better performance than SLAB on RT and the split
softirq lock implementation is necessary especially for realtime
networking applications.
The following patch series backports
From: Thomas Gleixner
Avoid the percpu softirq_runner pointer magic by using a task flag.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/sched.h |1 +
kernel/softirq.c | 20 +++-
2 files changed, 4 insertions(+), 17
[not sure about CCs - I readded both initramfs-tools and lkml]
> I think you actually want both: ehci-pci and ehci-platform (tho' perhaps
> the module deps mean only the -pci one is needed)
Err, yeah, that's probably more precise.
> Either way I already posted a patch about this a while back:
From: Thomas Gleixner
This code triggers the new WARN in __raise_softirq_irqsoff() though it
actually looks at the softirq pending bit and calls into the softirq
code, but that fits not well with the context related softirq model of
RT. It's correct on mainline though, but going through
From: Christoph Lameter
The variables accessed in slab_alloc are volatile and therefore
the page pointer passed to node_match can be NULL. The processing
of data in slab_alloc is tentative until either the cmpxhchg
succeeds or the __slab_alloc slowpath is invoked. Both are
able to perform the
From: Thomas Gleixner
The 3.x RT series removed the split softirq implementation in favour
of pushing softirq processing into the context of the thread which
raised it. Though this prevents us from handling the various softirqs
at different priorities. Now instead of reintroducing the split
From: Thomas Gleixner
We really need to iterate through all softirqs to find a potentially
blocked runner.
T1 runs softirq X (that cleared pending bit for X)
Interrupt raises softirq Y
T1 gets blocked on a lock and lock owner is not runnable
T1 schedules out
CPU goes idle and complains
From: Thomas Gleixner
Avoid the percpu softirq_runner pointer magic by using a task flag.
Signed-off-by: Thomas Gleixner
[bigeasy@linutronix: different PF_IN_SOFTIRQ bit]
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/sched.h |1 +
kernel/softirq.c | 20
From: Thomas Gleixner
Split out the inner handling function, so RT can reuse it.
Signed-off-by: Thomas Gleixner
---
kernel/softirq.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index
3.2-rt is a long term supported kernel, which lacks two RT features
from 3.6: SLUB support and the split softirq lock implementation.
SLUB has a way better performance than SLAB on RT and the split
softirq lock implementation is necessary especially for realtime
networking applications.
The
From: Andi Kleen
Recent Intel CPUs like Haswell and IvyBridge have a new alternative MSR
range for perfctrs that allows writing the full counter width. Enable this
range if the hardware reports it using a new capability bit.
This lowers the overhead of perf stat slightly because it has to do
From: Andi Kleen
Add support for the Haswell extended (fmt2) PEBS format.
It has a superset of the nhm (fmt1) PEBS fields, but has a longer record so
we need to adjust the code paths.
The main advantage is the new "EventingRip" support which directly
gives the instruction, not off-by-one
This is based on v7 of the full Haswell PMU support, but
ported to the latest perf/core and stripped down to the
bare bones
Only for very extremly basic usage.
Most interesting new features are not in this patchkit
(full version is
From: Andi Kleen
Add basic PEBS support for Haswell.
The constraints are similar to SandyBridge with a few new events.
v2: Readd missing pebs_aliases
v3: Readd missing hunk. Fix some constraints.
v4: Fix typo in PEBS event table (Stephane Eranian)
Reviewed-by: Stephane Eranian
Signed-off-by:
From: Andi Kleen
Add basic Haswell PMU support.
Similar to SandyBridge, but has a few new events and two
new counter bits.
There are some new counter flags that need to be prevented
from being set on fixed counters, and allowed to be set
for generic counters.
Also we add support for the
From: Andi Kleen
This avoids some problems with spurious PMIs on Haswell.
Haswell seems to behave more like P4 in this regard. Do
the same thing as the P4 perf handler by unmasking
the NMI only at the end. Shouldn't make any difference
for earlier family 6 cores.
Tested on Haswell, IvyBridge,
On 02/13, Andrey Vagin wrote:
>
> This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
>
> This request is used to retrieve information about a signal with the
> specified sequence number. A siginfo_t structure is copied from the child
> to location data in the parent.
>
> The low 16 bits of
On 02/13/2013 09:57 AM, Jon Hunter wrote:
>
> On 02/13/2013 03:28 AM, Sourav Poddar wrote:
>> Booting 3.8-rc6 on omap4 panda results in the following error
>>
>> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
>> [0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at
Il 13/02/2013 16:55, Alex Bligh ha scritto:
>> > But as far as I can test with free servers, the FUA bits have no
>> > advantage over flush. Also, I wasn't sure if SEND_FUA without
>> > SEND_FLUSH is valid, and if so how to handle this combination (treat it
>> > as writethrough and add FUA to all
On 01/29/2013 04:51 PM, Andrew Morton wrote:
> On Tue, 29 Jan 2013 15:40:22 -0600
> Seth Jennings wrote:
>
>> This patch promotes the slab-based zsmalloc memory allocator
>> from the staging tree to lib/
>
> Hate to rain on the parade, but... we haven't reviewed zsmalloc
> yet. At least, I
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
> Booting 3.8-rc6 on omap4 panda results in the following error
>
> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
> [0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
> [0.473937] omap_i2c 48072000.i2c: did
Paolo,
On 13 Feb 2013, at 13:00, Paolo Bonzini wrote:
> But as far as I can test with free servers, the FUA bits have no
> advantage over flush. Also, I wasn't sure if SEND_FUA without
> SEND_FLUSH is valid, and if so how to handle this combination (treat it
> as writethrough and add FUA to all
On Wed, Feb 13, 2013 at 04:58:30PM +0100, Christian Gmeiner wrote:
> During the development of this driver an in-house register
> documentation was used. The last weeks some integration tests
> were done and this problem was found. It turned out that
> the released register documentation is wrong.
On Wed, 2013-02-13 at 09:38 -0500, Vivek Goyal wrote:
> On Wed, Feb 13, 2013 at 03:36:45PM +0200, Kasatkin, Dmitry wrote:
> > It should not be the only line in the policy.
> > Can you share full policy?
>
> I verified by putting some printk.
If anyone is interested in posting a patch to display
On Tue, Feb 12, 2013 at 1:40 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.4.31 release.
> There are 36 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Tue, Feb 12, 2013 at 1:36 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.0.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Tue, Feb 12, 2013 at 1:34 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.7.8 release.
> There are 61 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On Wed, Feb 13, 2013 at 06:46:01PM +0530, Naveen Krishna Ch wrote:
[ ... ]
>
> Hello Guenter,
>
> I've rebase my adc driver on top of your (OF for IIO patch)
>
> My setup is like the below one. kindly, help me find the right device
> tree node params
>
> One ADC controller with 8 channels,
>
Il 13/02/2013 16:35, Douglas Gilbert ha scritto:
>>
>> Ping? I'm not even sure what tree this should host these patches...
>
> You are whitelisting SCSI commands so obviously the SCSI tree
> and the patch spills over into the block tree.
Yeah, an Acked-by is in order but it's not clear from whom
This patch depends on "genalloc: add devres support, allow to find
a managed pool by device", which provides the of_get_named_gen_pool
and dev_get_gen_pool functions.
Signed-off-by: Philipp Zabel
Acked-By: Javier Martin
Acked-by: Grant Likely
---
This patch adds three exported functions to lib/genalloc.c:
devm_gen_pool_create, dev_get_gen_pool, and of_get_named_gen_pool.
devm_gen_pool_create is a managed version of gen_pool_create that keeps
track of the pool via devres and allows the management code to automatically
destroy it after
401 - 500 of 1450 matches
Mail list logo
