see below
> arch/i386/kernel/io_apic.c |3 ++-
> arch/x86_64/kernel/genapic.c |3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> Index: linux/arch/i386/kernel/io_apic.c
> ===
> ---
> Ingo: I think, you have to do this in x86_64, and there is probably
> send_IPI_mask used for this (but I can miss something...).
>
> I think, Marcin will not be able to do this and report before monday,
> but,
> Jean-Baptiste: of course current Ingo's or Thomas' patches are
> more urgent, so
> For me it's enough too but Thomas seems to doubt.
>
> You've written earlier that you've 2.6.23-rc1 with HARDIRQS_SW_RESEND
> prepared too. So, if this is not a great problem maybe you could try
> this first. Tomorrow Thomas may send something, so this 100HZ could
> wait yet, I hope?
Ok, i'll
> So, we still have to wait for the exact explanation...
>
> Thanks very much Marcin!
>
> I think, there is this one possible for your testing yet?:
> Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
> Date: Wed, 8 Aug 2007 13:00:37 +0200
>
> If it's not a great problem it
Ingo: I think, you have to do this in x86_64, and there is probably
send_IPI_mask used for this (but I can miss something...).
I think, Marcin will not be able to do this and report before monday,
but,
Jean-Baptiste: of course current Ingo's or Thomas' patches are
more urgent, so if you
So, we still have to wait for the exact explanation...
Thanks very much Marcin!
I think, there is this one possible for your testing yet?:
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200
If it's not a great problem it would be
For me it's enough too but Thomas seems to doubt.
You've written earlier that you've 2.6.23-rc1 with HARDIRQS_SW_RESEND
prepared too. So, if this is not a great problem maybe you could try
this first. Tomorrow Thomas may send something, so this 100HZ could
wait yet, I hope?
Ok, i'll test
see below
arch/i386/kernel/io_apic.c |3 ++-
arch/x86_64/kernel/genapic.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
Index: linux/arch/i386/kernel/io_apic.c
===
---
> Hi,
>
> I see there is a bit of complaining on this original resend temporary
> patch. But, since it seems to do a good job for some people, here is
> my proposal to limit the 'range of fire' a little bit.
>
> Marcin and Jean-Baptiste: try to test this with 2.6.23-rc2, please.
> (Unless Ingo
Hi,
I see there is a bit of complaining on this original resend temporary
patch. But, since it seems to do a good job for some people, here is
my proposal to limit the 'range of fire' a little bit.
Marcin and Jean-Baptiste: try to test this with 2.6.23-rc2, please.
(Unless Ingo or Thomas
> Jean-Baptiste: I'm not sure how much of this testing you can afford?
> If you can spare some time for this and your box isn't for
> 'production' it could be very precious to diagnose such reproducible
> bug.
Well i can continue testing patches for sure.
> Then, I'd have a few suggestions (you
Jean-Baptiste: I'm not sure how much of this testing you can afford?
If you can spare some time for this and your box isn't for
'production' it could be very precious to diagnose such reproducible
bug.
Well i can continue testing patches for sure.
Then, I'd have a few suggestions (you could
> On Tue, Aug 07, 2007 at 11:21:07AM +0200, Jean-Baptiste Vignaud wrote:
> >
> > > > * interrupts (i use irqbalance, but problem was the same without)
> > >
> > > I wonder if you tried without SMP too?
> >
> > No i did not. Do you think that th
> > * interrupts (i use irqbalance, but problem was the same without)
>
> I wonder if you tried without SMP too?
No i did not. Do you think that this can be a problem ?
To test with no SMP, do i need to recompile kernel or is there a kernel
parameter ?
> BTW, Jean-Baptiste and Chuck -
> BTW: Jean-Babtiste, could you send or point to you current configs?
> I mean at least proc/interrupts, but with dmesg and .config it would
> be even better. (I assume this last report was about the revert patch
> mentioned by Chuck, not the one below your message?)
Sure.
Last reports are
BTW: Jean-Babtiste, could you send or point to you current configs?
I mean at least proc/interrupts, but with dmesg and .config it would
be even better. (I assume this last report was about the revert patch
mentioned by Chuck, not the one below your message?)
Sure.
Last reports are with
* interrupts (i use irqbalance, but problem was the same without)
I wonder if you tried without SMP too?
No i did not. Do you think that this can be a problem ?
To test with no SMP, do i need to recompile kernel or is there a kernel
parameter ?
BTW, Jean-Baptiste and Chuck - it
On Tue, Aug 07, 2007 at 11:21:07AM +0200, Jean-Baptiste Vignaud wrote:
* interrupts (i use irqbalance, but problem was the same without)
I wonder if you tried without SMP too?
No i did not. Do you think that this can be a problem ?
To test with no SMP, do i need to recompile
Mmm, bad news, after 4 hours of intensive network stressing, one of the 2 3com
card failed with the latest fedora kernel.
Aug 6 22:31:09 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
Aug 6 22:31:09 loki kernel: eth2: transmit timed out, tx_status 00 status e601.
Aug 6 22:31:09 loki
> * Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > Before, they would print:
> >
> > eth0: transmit timed out, tx_status 00 status e601.
> > diagnostics: net 0ccc media 8880 dma 003a fifo
> > eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
> > Flags;
* Chuck Ebbert [EMAIL PROTECTED] wrote:
Before, they would print:
eth0: transmit timed out, tx_status 00 status e601.
diagnostics: net 0ccc media 8880 dma 003a fifo
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Flags; bus-master 1, dirty
Mmm, bad news, after 4 hours of intensive network stressing, one of the 2 3com
card failed with the latest fedora kernel.
Aug 6 22:31:09 loki kernel: NETDEV WATCHDOG: eth2: transmit timed out
Aug 6 22:31:09 loki kernel: eth2: transmit timed out, tx_status 00 status e601.
Aug 6 22:31:09 loki
generic problem.
(i'v updated the fedora bugzilla aswell)
did not test the "[PATCH] 8139cp dev->tx_timeout" yet.
JB
> On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote:
> > Hello, i have a very similar problem with 2.6.21 also;
> >
> >
generic problem.
(i'v updated the fedora bugzilla aswell)
did not test the [PATCH] 8139cp dev-tx_timeout yet.
JB
On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote:
Hello, i have a very similar problem with 2.6.21 also;
2 3com NICs and they are failling randomly
Hello, i have a very similar problem with 2.6.21 also;
2 3com NICs and they are failling randomly.
The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7)
I found a bug report and added details here :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960
I'm not subcribed on this list,
Hello, i have a very similar problem with 2.6.21 also;
2 3com NICs and they are failling randomly.
The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7)
I found a bug report and added details here :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960
I'm not subcribed on this list,
26 matches
Mail list logo
