On Thursday 25 February 2016 08:00 PM, Russell King - ARM Linux wrote:
> On Thu, Feb 25, 2016 at 07:53:39PM +0530, Vineet Gupta wrote:
>> But then ARM CONFIG_SMP on UP hardware will still crap out because there
>> is no way to send IPI to self. Same as the bug in above discussion. I'm
>> surprised
On Thu, Feb 25, 2016 at 07:53:39PM +0530, Vineet Gupta wrote:
> But then ARM CONFIG_SMP on UP hardware will still crap out because there
> is no way to send IPI to self. Same as the bug in above discussion. I'm
> surprised they way ARM guys worked around it.
We haven't worked around it - the code
On Thursday 25 February 2016 07:36 PM, Peter Zijlstra wrote:
> On Wed, Feb 24, 2016 at 10:21:25AM +0530, Vineet Gupta wrote:
What I actually meant was is it OK for irq_work_queue_on() to be called
locally
(is this a sched bug/optimization(. Further if it is OK to be called, does
>>
On Wed, Feb 24, 2016 at 10:21:25AM +0530, Vineet Gupta wrote:
> >> What I actually meant was is it OK for irq_work_queue_on() to be called
> >> locally
> >> (is this a sched bug/optimization(. Further if it is OK to be called, does
> >> it need
> >> to do behave more like irq_work_queue() i.e. ca
On Tuesday 23 February 2016 03:28 PM, Peter Zijlstra wrote:
> On Tue, Feb 23, 2016 at 10:51:42AM +0530, Vineet Gupta wrote:
>> On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote:
>>> Hi Peter,
>>>
>>> I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2
>>> and it
>>> turn
On Tuesday 23 February 2016 04:28 PM, Noam Camus wrote:
>> From: Peter Zijlstra [mailto:pet...@infradead.org]
>> Sent: Tuesday, February 23, 2016 12:40 PM
>
>> The only requirement for irq_work is that it runs after the NMI completes
>> and runs from regular IRQ context. >There are no strict int
>From: Peter Zijlstra [mailto:pet...@infradead.org]
>Sent: Tuesday, February 23, 2016 12:40 PM
>The only requirement for irq_work is that it runs after the NMI completes and
>runs from regular IRQ context. >There are no strict interrupt priority
>requirements, only that it happens.
We here alr
On Tue, Feb 23, 2016 at 03:51:23PM +0530, Vineet Gupta wrote:
> >
> > Now the distinct difference between arch_irq_work_raise() and
> > arch_send_call_function_single_ipi() is that arch_irq_work_raise()
> > should be NMI-safe.
>
> Ok - so when I implement interrupt priorities (aka NMI for ARC), t
>> What I actually meant was is it OK for irq_work_queue_on() to be called
>> locally
>> (is this a sched bug/optimization(. Further if it is OK to be called, does
>> it need
>> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
>> arch_send_call_function_single_ipi() is e
On Tue, Feb 23, 2016 at 10:51:42AM +0530, Vineet Gupta wrote:
> On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote:
> > Hi Peter,
> >
> > I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2
> > and it
> > turned out to be lot more interesting than I'd hoped for. This is
On Friday 19 February 2016 12:17 PM, Vineet Gupta wrote:
> Hi Peter,
>
> I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and
> it
> turned out to be lot more interesting than I'd hoped for. This is stock v4.4
>
> Trouble starts with an IPI to self which doesn't get deliv
Hi Peter,
I've been debugging a csd_lock_wait() deadlock on SMP+PREEMPT ARC HS38x2 and it
turned out to be lot more interesting than I'd hoped for. This is stock v4.4
Trouble starts with an IPI to self which doesn't get delivered as the inter-core
interrupt providing h/w is not capable of IPI to
12 matches
Mail list logo
