>
> 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
[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?
>>
>>
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 -
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 - incidental IRQ
[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?
that might make
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 does.
So
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 -
* 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
"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.
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
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 migrate it
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.
Thanks.
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
* 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 bit
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 - incidental IRQ
* 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
-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
"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
-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
"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
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
"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
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
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
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 by
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 mean by
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 were looking for
-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
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 is the case
we
-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
* 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 for
>, 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 irq: H
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
> 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
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 vector
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 the
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 not pending
@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 irq: Handle irqs pending in IRR during irq
migration.
Resent-Date: Sat, 03 Feb
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
> > 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
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
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
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
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 for that irq.
After migrating the irq to another cpu and or
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 for that irq.
After migrating the irq to another cpu and or
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 apic
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 is
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.
It's
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
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 immediately
52 matches
Mail list logo
