Maciej's io-apic patch fixed the long-standing problems with my
ne2k-pci card (since at least 2.4.0-test10, and absent in 2.2.17).
Ne2k-pci card (D-Link, exact model # would require a reboot and
card pull)
Dual 366 Celeron / Abit BP6 / 128MB (Problem showed up at both 366/550)
Eth0 has over 3 mi
On Sat, 3 Feb 2001, Manfred Spraul wrote:
> I found another workaround:
> 8390.c currently calls
>
> outb_p(ENISR_ALL, e8390_base + EN0_IMR);
> enable_irq(dev->irq);
>
> and locks up after ~ 100 packets flood ping.
>
> If I reorder these calls to
>
> enable_irq(dev->irq);
>
On Sat, 3 Feb 2001, [ISO-8859-1] Gérard Roudier wrote:
> Note that tampering the IO/APIC after initializations looks extremally
> ugly to me. In my opinion, only the local APIC was intended by Intel
> designers to be accessed by CPU after initialization (I may be wrong
> here).
In "82489DX Data
Manfred Spraul wrote:
>
> But I think we can change the bug description:
>
> If an io apic io redirection entry is unmasked while the irq pin is
> active, then the io apic sends out the interrupt as edge triggered, but
> nevertheless sets the IRR bit.
>
I found another workaround:
8390.c curren
On Fri, 2 Feb 2001, Manfred Spraul wrote:
> Gérard Roudier wrote:
> >
> > So, why not using a pure software flag in memory and only tampering the
> > things if the offending interrupt is actually delivered ? If the given
> > interrupt is delivered and the software mask is set we could simply d
Gérard Roudier wrote:
>
> So, why not using a pure software flag in memory and only tampering the
> things if the offending interrupt is actually delivered ? If the given
> interrupt is delivered and the software mask is set we could simply do:
>
> - MASK the given interrupt
> - EOI it.
> - retu
On Fri, 2 Feb 2001, Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2001, Andrew Morton wrote:
> +/*
> + * It appears there is an erratum which affects at least the 82093AA
> + * I/O APIC. If a level-triggered interrupt input is being masked in
> + * the redirection entry while the interrupt is send
On Thu, 1 Feb 2001, Andrew Morton wrote:
> Your latest patch passes all my testing.
>
> 2.4.1+irq-whacker+netperf:APIC dies instantly
> 2.4.1+irq-whacker+netperf+patch: 8 million interrupts, then I got bored.
Linus, would you please apply the following patch for 2.4.2? The idea of
op
"Maciej W. Rozycki" wrote:
>
> Following is the 82489DX-ized version of the patch. I believe it's fine,
> but I would feel safer if others test it before I send it to Linus.
Your latest patch passes all my testing.
2.4.1+irq-whacker+netperf:APIC dies instantly
2.4.1+irq-whacker+netper
On Mon, 29 Jan 2001, Manfred Spraul wrote:
> I'm not totally convinced that this fixes all problems:
>
> No lockup, and but a slightly increased packet loss: every few minutes a
> block of 5-10 packets is lost. Cpu load is low (~30%), I'm running 3
> concurrent bw_tcp, the io apic computer is th
"Maciej W. Rozycki" wrote:
>
> I'll implement an 82489DX update in a few days, but for now I'd like
> everyone interested to test the following patch as much as possible. It
> applies to 2.4.0, 2.4.0-ac12 and 2.4.1-pre11 cleanly.
>
I'm not totally convinced that this fixes all problems:
No loc
Hi,
After an extensive testing I concluded the infamous APIC lock-up happens
when a level-triggered interrupt gets masked in an I/O APIC when it's in
the send pending state (bit 12 of the respective interrupt redirection
entry is set). Under this condition, the interrupt is still posted to
CPUs
12 matches
Mail list logo
