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
11 matches
Mail list logo