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
> ===
> --- linux.orig/arch/i386/kernel/i
> 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
> 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 t
> 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 w
> 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
> 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 c
> 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 - it
> 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
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 ke
> * 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-mas
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;
> >
>
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,
13 matches
Mail list logo