Vivek Goyal wrote:
> Did you also check IRR bits on LAPIC. May be some interrupt is already
> being served and your new interrupts has been queued on LAPIC and IRR bit
> on LAPIC is set?
That's it. Whenever the IO-APIC IRR bit is set, I see the LAPIC IRR bit set,
too.
I never see any ISR bits
On Wed, Aug 08, 2007 at 08:15:32PM +0200, Martin Wilck wrote:
> Vivek Goyal wrote:
>
> > But the issue here seems to be that LAPIC state got clear but IRR bit
> > at IOAPIC bit is not cleared because IOAPIC vector information was deleted
> > in first kernel and now upon receiving EOI, it does not
On Wed, Aug 08, 2007 at 08:15:32PM +0200, Martin Wilck wrote:
Vivek Goyal wrote:
But the issue here seems to be that LAPIC state got clear but IRR bit
at IOAPIC bit is not cleared because IOAPIC vector information was deleted
in first kernel and now upon receiving EOI, it does not know
Vivek Goyal wrote:
Did you also check IRR bits on LAPIC. May be some interrupt is already
being served and your new interrupts has been queued on LAPIC and IRR bit
on LAPIC is set?
That's it. Whenever the IO-APIC IRR bit is set, I see the LAPIC IRR bit set,
too.
I never see any ISR bits set.
Martin Wilck <[EMAIL PROTECTED]> writes:
> Vivek Goyal wrote:
>
>> Got this oops while testing your patch when I did
>> "echo c > /proc/sysrq-trigger"
>
> That's bad :-(
>
> ...
>> Unable to handle kernel NULL pointer dereference at RIP:
> [<>]
>>[]
Eric W. Biederman wrote:
>>> irqpoll is working now.
>> Yes. I'd give a lot to know what went wrong when I tried that in April.
>> It'd have saved me many hours of work if I had discovered this workaround
>> before.
>
> Yes that is odd.
Got it. At that time I was using "noirqdebug" because we
Eric W. Biederman wrote:
>> I think a lot would be gained if disable_IO_APIC() would just mask the IRQs
>> (like the function in my patch does), and perhaps fix the dest ID, instead of
>> totally clearing the registers.
>
> Even masked we still won't see the EOI, because then we are in i8259
>
Vivek Goyal wrote:
> But the issue here seems to be that LAPIC state got clear but IRR bit
> at IOAPIC bit is not cleared because IOAPIC vector information was deleted
> in first kernel and now upon receiving EOI, it does not know this EOI belongs
> to which vector.
I am making another
Vivek Goyal wrote:
> Got this oops while testing your patch when I did
> "echo c > /proc/sysrq-trigger"
That's bad :-(
...
> Unable to handle kernel NULL pointer dereference at RIP:
[<>]
>[] handle_edge_irq+0x5c/0x127
> [] do_IRQ+0xf1/0x15f
> []
Martin Wilck <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
>> Ok. Later in the thread it sounds like you have retried this and
>> irqpoll is working now.
>
> Yes. I'd give a lot to know what went wrong when I tried that in April.
> It'd have saved me many hours of work if I had
Eric W. Biederman wrote:
> Ok. Later in the thread it sounds like you have retried this and
> irqpoll is working now.
Yes. I'd give a lot to know what went wrong when I tried that in April.
It'd have saved me many hours of work if I had discovered this workaround
before.
>>> Have you done any
Martin Wilck <[EMAIL PROTECTED]> writes:
> Hello Eric,
>
>> How bad is it if you just run with irqpoll in the kdump kernel?
>> If running with irqpoll is usable that is probably preferable
>> to putting in a hardware work around we can survive without.
>
> Yes, I tried that. No effect.
Ok.
On Wed, Aug 08, 2007 at 10:06:13AM -0400, Chip Coldwell wrote:
> On Wed, 8 Aug 2007, Vivek Goyal wrote:
>
> > On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
> > >
> > > Can you explain how, on the front side bus, the IO-APIC knows whether
> > > a CPU has accepted the INT message?
On Wed, 8 Aug 2007, Vivek Goyal wrote:
> On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
> >
> > Can you explain how, on the front side bus, the IO-APIC knows whether
> > a CPU has accepted the INT message? There is no response
> > to the INT message on the bus, except for the EOI
Hi Vivek,
>>> How bad is it if you just run with irqpoll in the kdump kernel?
>>> If running with irqpoll is usable that is probably preferable
>>> to putting in a hardware work around we can survive without.
>> Yes, I tried that. No effect.
>>
>
> Martin, at least irpoll should have worked. I
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
> PATCH/RFC: [kdump] fix APIC shutdown sequence
>
> This patch fixes a problem that we have encountered
> with kdump under high I/O load on some machines.
> The machines showing the errors have an Intel ICH7
> chip
On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
[..]
>
> Such a situation has never been observed in the "good" case.
> So, we do have some evidence, not just bare speculation.
>
> >> 2. The crashing CPU itself disables its local APIC
> >>before the IO-APIC, leaving a short
On Wed, Aug 08, 2007 at 11:03:17AM +0200, Martin Wilck wrote:
> Hello Eric,
>
> > How bad is it if you just run with irqpoll in the kdump kernel?
> > If running with irqpoll is usable that is probably preferable
> > to putting in a hardware work around we can survive without.
>
> Yes, I tried
Hello Eric,
> How bad is it if you just run with irqpoll in the kdump kernel?
> If running with irqpoll is usable that is probably preferable
> to putting in a hardware work around we can survive without.
Yes, I tried that. No effect.
> Have you done any looking at moving where the kernel
Hello Andrew,
thanks a lot for looking at this patch.
> Please feed the diff through scripts/checkpatch.pl. It finds a lot of issues.
I should have read the latest version of SubmittingPatches :-(
I didn't expect you to pick up this patch so quickly, if I did
I'd have cleaned it more
Hello Andrew,
thanks a lot for looking at this patch.
Please feed the diff through scripts/checkpatch.pl. It finds a lot of issues.
I should have read the latest version of SubmittingPatches :-(
I didn't expect you to pick up this patch so quickly, if I did
I'd have cleaned it more
Hello Eric,
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Yes, I tried that. No effect.
Have you done any looking at moving where the kernel
On Wed, Aug 08, 2007 at 11:03:17AM +0200, Martin Wilck wrote:
Hello Eric,
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Yes, I tried that. No
On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
[..]
Such a situation has never been observed in the good case.
So, we do have some evidence, not just bare speculation.
2. The crashing CPU itself disables its local APIC
before the IO-APIC, leaving a short time window
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
PATCH/RFC: [kdump] fix APIC shutdown sequence
This patch fixes a problem that we have encountered
with kdump under high I/O load on some machines.
The machines showing the errors have an Intel ICH7
chip set with a 6702PXH PCI
Hi Vivek,
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Yes, I tried that. No effect.
Martin, at least irpoll should have worked. I am assuming your
On Wed, 8 Aug 2007, Vivek Goyal wrote:
On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
Can you explain how, on the front side bus, the IO-APIC knows whether
a CPU has accepted the INT message? There is no response
to the INT message on the bus, except for the EOI which
On Wed, Aug 08, 2007 at 10:06:13AM -0400, Chip Coldwell wrote:
On Wed, 8 Aug 2007, Vivek Goyal wrote:
On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote:
Can you explain how, on the front side bus, the IO-APIC knows whether
a CPU has accepted the INT message? There is no
Martin Wilck [EMAIL PROTECTED] writes:
Hello Eric,
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Yes, I tried that. No effect.
Ok. Later in the
Eric W. Biederman wrote:
Ok. Later in the thread it sounds like you have retried this and
irqpoll is working now.
Yes. I'd give a lot to know what went wrong when I tried that in April.
It'd have saved me many hours of work if I had discovered this workaround
before.
Have you done any
Martin Wilck [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Ok. Later in the thread it sounds like you have retried this and
irqpoll is working now.
Yes. I'd give a lot to know what went wrong when I tried that in April.
It'd have saved me many hours of work if I had discovered this
Vivek Goyal wrote:
Got this oops while testing your patch when I did
echo c /proc/sysrq-trigger
That's bad :-(
...
Unable to handle kernel NULL pointer dereference at RIP:
[]
IRQ [8025afd0] handle_edge_irq+0x5c/0x127
[8020e1ae]
Vivek Goyal wrote:
But the issue here seems to be that LAPIC state got clear but IRR bit
at IOAPIC bit is not cleared because IOAPIC vector information was deleted
in first kernel and now upon receiving EOI, it does not know this EOI belongs
to which vector.
I am making another experiment
Eric W. Biederman wrote:
I think a lot would be gained if disable_IO_APIC() would just mask the IRQs
(like the function in my patch does), and perhaps fix the dest ID, instead of
totally clearing the registers.
Even masked we still won't see the EOI, because then we are in i8259
mode. So
Eric W. Biederman wrote:
irqpoll is working now.
Yes. I'd give a lot to know what went wrong when I tried that in April.
It'd have saved me many hours of work if I had discovered this workaround
before.
Yes that is odd.
Got it. At that time I was using noirqdebug because we had a FW
Martin Wilck [EMAIL PROTECTED] writes:
Vivek Goyal wrote:
Got this oops while testing your patch when I did
echo c /proc/sysrq-trigger
That's bad :-(
...
Unable to handle kernel NULL pointer dereference at RIP:
[]
IRQ [8025afd0]
A couple of questions.
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Have you done any looking at moving where the kernel initalizes
io_apics? One of
On Mon, 06 Aug 2007 17:08:05 +0200
Martin Wilck <[EMAIL PROTECTED]> wrote:
> PATCH/RFC: [kdump] fix APIC shutdown sequence
>
> This patch fixes a problem that we have encountered
> with kdump under high I/O load on some machines.
> The machines showing the errors have an
On Tue, 7 Aug 2007, Vivek Goyal wrote:
> On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
>
> > 1. If, under SMP, the IO-APIC logical destination field is
> >set by the IRQ balancing code to one of the "other"
> >CPUs (i.e. not the crashing_cpu), and an IRQ arrives
> >on
Hello Vivek,
thank you very much for looking at this problem, and for your
comments.
>> The error is caused by IRQs arriving while the APIC
>> subsystem is deactivated in machine_crash_shutdown().
>>
>> Apparently, the IO-APIC gets stuck if it sends an IRQ
>> message to a Local APIC and never
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
> PATCH/RFC: [kdump] fix APIC shutdown sequence
>
> This patch fixes a problem that we have encountered
> with kdump under high I/O load on some machines.
> The machines showing the errors have an Intel ICH7
> chip
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
PATCH/RFC: [kdump] fix APIC shutdown sequence
This patch fixes a problem that we have encountered
with kdump under high I/O load on some machines.
The machines showing the errors have an Intel ICH7
chip set with a 6702PXH PCI
Hello Vivek,
thank you very much for looking at this problem, and for your
comments.
The error is caused by IRQs arriving while the APIC
subsystem is deactivated in machine_crash_shutdown().
Apparently, the IO-APIC gets stuck if it sends an IRQ
message to a Local APIC and never receives an
On Tue, 7 Aug 2007, Vivek Goyal wrote:
On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote:
1. If, under SMP, the IO-APIC logical destination field is
set by the IRQ balancing code to one of the other
CPUs (i.e. not the crashing_cpu), and an IRQ arrives
on the
On Mon, 06 Aug 2007 17:08:05 +0200
Martin Wilck [EMAIL PROTECTED] wrote:
PATCH/RFC: [kdump] fix APIC shutdown sequence
This patch fixes a problem that we have encountered
with kdump under high I/O load on some machines.
The machines showing the errors have an Intel ICH7
chip set
A couple of questions.
How bad is it if you just run with irqpoll in the kdump kernel?
If running with irqpoll is usable that is probably preferable
to putting in a hardware work around we can survive without.
Have you done any looking at moving where the kernel initalizes
io_apics? One of
PATCH/RFC: [kdump] fix APIC shutdown sequence
This patch fixes a problem that we have encountered
with kdump under high I/O load on some machines.
The machines showing the errors have an Intel ICH7
chip set with a 6702PXH PCI Express-to-PCI Bridge
(8086:032c) containing an IO-APIC.
The bug
PATCH/RFC: [kdump] fix APIC shutdown sequence
This patch fixes a problem that we have encountered
with kdump under high I/O load on some machines.
The machines showing the errors have an Intel ICH7
chip set with a 6702PXH PCI Express-to-PCI Bridge
(8086:032c) containing an IO-APIC.
The bug
48 matches
Mail list logo
