On Wed, 14 Feb 2001, Roeland Th. Jansen wrote:
> On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> > Please test it extensively, as much as you can, before I submit it for
> > inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
> > message, please
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote:
> other observations -- approx 6000 ints from the ne2k card/sec.
> MIS shows approx 1% that goes wrong with a ping flood.
oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes :
CPU0 CPU1
19:
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> Please test it extensively, as much as you can, before I submit it for
> inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
> message, please report it to me immediately -- it means the code failed.
On Wed, 14 Feb 2001, Andrew Morton wrote:
> Tell me, please: what tradeoffs are involved in this patch?
> Obviously it works around a pretty fatal problem, but
> what are we giving away?
The change decreases performance a bit. For well-behaved systems the
loss is fifteen instructions: a local
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff.
Works fine on the dual-PII. No "Aieee!!!" messages at all.
After sending a few gigs across the
"Maciej W. Rozycki" wrote:
Hi,
After performing various tests I came to the following workaround for
APIC lockups which people observe under IRQ load, mostly for networking
stuff.
Works fine on the dual-PII. No "Aieee!!!" messages at all.
After sending a few gigs across the ethernet,
On Wed, 14 Feb 2001, Andrew Morton wrote:
Tell me, please: what tradeoffs are involved in this patch?
Obviously it works around a pretty fatal problem, but
what are we giving away?
The change decreases performance a bit. For well-behaved systems the
loss is fifteen instructions: a local
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
Please test it extensively, as much as you can, before I submit it for
inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
message, please report it to me immediately -- it means the code failed.
ok,
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote:
other observations -- approx 6000 ints from the ne2k card/sec.
MIS shows approx 1% that goes wrong with a ping flood.
oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes :
CPU0 CPU1
19:
On Wed, 14 Feb 2001, Roeland Th. Jansen wrote:
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
Please test it extensively, as much as you can, before I submit it for
inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
message, please report it
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> There is also an additional debugging/statistics counter provided in
> /proc/cpuinfo that counts interrupts which got delivered with its trigger
> mode mismatched. Check it out to find if you get any misdelivered
> interrupts
"Maciej W. Rozycki" wrote:
>
> Hi,
>
> After performing various tests I came to the following workaround for
> APIC lockups which people observe under IRQ load, mostly for networking
> stuff. I believe the test should work in all cases as it basically
> implements a manual replacement for EOI
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
There is also an additional debugging/statistics counter provided in
/proc/cpuinfo that counts interrupts which got delivered with its trigger
mode mismatched. Check it out to find if you get any misdelivered
interrupts at
13 matches
Mail list logo
