>
> The version I would up testing is below, and it doesn't work.
> I still get "No irq handler for vector" warnings as well as
> a couple of complaints from lock/irq debugging.The debugging
> doesn't worry me. The fact that I don't have a good way to ensure
> I have no more irqs in flight doe
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
>> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>>> Ingo would it be reasonable to get a wait queue so I can wait for an
>>> irq that needs the delayed disable action to actually become masked?
>>
>> th
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Ingo would it be reasonable to get a wait queue so I can wait for an
>> irq that needs the delayed disable action to actually become masked?
>
> that might make sense, but what will do the wakeup - incid
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> Ingo would it be reasonable to get a wait queue so I can wait for an
>> irq that needs the delayed disable action to actually become masked?
>
> that might make sense, but what will do the wakeup - incid
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ingo would it be reasonable to get a wait queue so I can wait for an
> irq that needs the delayed disable action to actually become masked?
that might make sense, but what will do the wakeup - incidental IRQ
arriving on the new CPU? Isnt that a
Ingo would it be reasonable to get a wait queue so I can wait for an
irq that needs the delayed disable action to actually become masked?
There are a lot of practical reasons while I cannot reprogram an
unmasked irq. However if we can wait it should be able to get all of
the convoluted irq migra
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> btw, I tested in on ( CPU and no way to reproduce the bug, (no messages
> appeared and load average was quite as high as exspected).
> Going to test an a 16 CPU (the same who triggered the bug at the beginning)
> immediatelly when it will be free.
T
Ingo thanks for the review.
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> When making the interrupt vectors per cpu I failed to handle a case
>> during irq migration. If the same interrupt comes in while we are
>> servicing the irq but before we
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> When making the interrupt vectors per cpu I failed to handle a case
> during irq migration. If the same interrupt comes in while we are
> servicing the irq but before we migrate it the pending bit in the
> local apic IRR register will be set fo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, February 05, 2007 3:03 PM
>Nope. irq routines are a stack. if apic_in_service_vector could return
>the wrong value. ack_APIC_irq() which use the same information would
>acknowledge the wrong irq. If there
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 05, 2007 12:37 PM
>
>
>>The only corner case I can see that might potentially happen is
>>"apic_in_service_vector() != irq_vector[irq]" and if that i
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, February 05, 2007 12:37 PM
>The only corner case I can see that might potentially happen is
>"apic_in_service_vector() != irq_vector[irq]" and if that is the case
>we don't want to migrate, because the pre
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> How about let apic_hangle_pending_vector take the irq too?
>
>>We can't compute the vector by reading the hardware registers after
>>we have acknowledged the irq.
>
>>I hope that was the answer you w
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> How about let apic_hangle_pending_vector take the irq too?
>We can't compute the vector by reading the hardware registers after
>we have acknowledged the irq.
>I hope that was the answer you were looking for I'm not quite certain
>what you mea
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> Eric,
>
> How about let apic_hangle_pending_vector take the irq too?
We can't compute the vector by reading the hardware registers after
we have acknowledged the irq.
I hope that was the answer you were looking for I'm not quite certain
what you mean b
Eric,
How about let apic_hangle_pending_vector take the irq too?
I wonder if there any chance that you have two IRQ_MOVE_PENDING?
BYW, Andi, Do you want to try "reuse vector when do the irq-balance
between CPUS"?
If So, I will update the patch that you dropped some months ago.
YH
-
To unsub
CTED]>, linux-kernel@vger.kernel.org,
"Lu, Yinghai" <[EMAIL PROTECTED]>,
Luigi Genoni <[EMAIL PROTECTED]>, Ingo Molnar <[EMAIL PROTECTED]>,
Natalie Protasevich <[EMAIL PROTECTED]>, Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2/2] x86_64 ir
On Saturday 03 February 2007 11:22, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> >> Once the migration operation is complete we know we will receive
> >> no more interrupts on this vector so the irq pending state for
> >> this irq will no longer be updated. If the irq is
Andi Kleen <[EMAIL PROTECTED]> writes:
>> Once the migration operation is complete we know we will receive
>> no more interrupts on this vector so the irq pending state for
>> this irq will no longer be updated. If the irq is not pending and
>> we are in the intermediate state we immediately free
> Once the migration operation is complete we know we will receive
> no more interrupts on this vector so the irq pending state for
> this irq will no longer be updated. If the irq is not pending and
> we are in the intermediate state we immediately free the vector,
> otherwise in we free the vec
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>> > Once the migration operation is complete we know we will receive
>> > no more interrupts on this vector so the irq pending state for
>> > this irq will no longer be updated. If the irq is not pending and
>> > we are in the intermediate state we im
> > Once the migration operation is complete we know we will receive
> > no more interrupts on this vector so the irq pending state for
> > this irq will no longer be updated. If the irq is not pending and
> > we are in the intermediate state we immediately free the vector,
> > otherwise in we fr
On Fri, 02 Feb 2007 18:39:15 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > So is this a for-2.6.20 thing? The bug was present in 2.6.19, so
> > I assume it doesn't affect many people?
>
> If it's not to late, and this patch isn't too scary.
Andrew Morton <[EMAIL PROTECTED]> writes:
> So is this a for-2.6.20 thing? The bug was present in 2.6.19, so
> I assume it doesn't affect many people?
If it's not to late, and this patch isn't too scary.
It's a really rare set of circumstances that trigger it, but the
possibility of being hit i
On Fri, 02 Feb 2007 17:35:31 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> When making the interrupt vectors per cpu I failed to handle a case
> during irq migration. If the same interrupt comes in while we are
> servicing the irq but before we migrate it the pending bit in the
> local api
25 matches
Mail list logo
