Date: Sun, 14 Jun 1998 02:55:34 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: i386/6944: bug in i386/isa/icu_ipl.s - AST gets lost, causes extreme network slowdown when cpu-bound processes present, possibly other problems Message-ID: <199806140955.CAA00381@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
>Number: 6944
>Category: i386
>Synopsis: icu_ipl.s does has a case commented as can't happen which happens
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Jun 14 03:00:01 PDT 1998
>Last-Modified:
>Originator: Matthew Dillon
>Organization:
BEST Internet Communications
>Release: FreeBSD 3.0-CURRENT i386
>Environment:
FreeBSD-current, June 14 cvs update, PPro 200 w/ PCI 10/100BaseT
and SCSI & IDE disks
>Description:
If FreeBSD is running cpu-bound processes and a network interrupt
occurs, causing an swi_net to occur, if the network swi queues an
AST (for example, if it wakes up nfsd), the AST will get lost and
the nfsd will not get the cpu until the next clock interrupt.
This can create severe NFS slowdowns as well as slowdowns to processes
being woken up from the network (or even other interrupts).
The problem is in icu_ipl.s. The situation:
cmpl $SWI_AST,%ecx
je splz_nextx /* "can't happen" */
Actually can happen. I'm not exactly sure how it happens, but the
result is that that AST gets cleared from ipending without being run.
The patch I include re-sets the bit in ipending and also sets the
bit in the temporary CPL to prevent it from trying to dispatch it
again in the routine.
This fixes the problem completely on my machine... now I can run
cpu bound programs and bring up xterms and nfsd is no longer effects
by the cpu-bound processes. I am marking the bug critical & high
priority because it's in the core interrupt code, but the bug does
not cause a fatal condition to occur (it just slows down process
wakeups massively in the face of a cpu-bound program).
>How-To-Repeat:
I noticed this trying to run an xterm on my diskless workstation
while running crack in the background on my server. The xterm took
30 seconds to come up. Killing the cpu-bound crack and the xterm
took 2 seconds to come up.
>Fix:
Notice! This patch fixes icu_ipl.s. apic_ipl.s might have the
same problem.
Index: icu_ipl.s
===================================================================
RCS file: /src/FreeBSD-CVS/ncvs/src/sys/i386/isa/icu_ipl.s,v
retrieving revision 1.3
diff -c -r1.3 icu_ipl.s
*** icu_ipl.s 1997/09/02 19:40:13 1.3
--- icu_ipl.s 1998/05/31 09:36:16
***************
*** 107,119 ****
ALIGN_TEXT
splz_swi:
cmpl $SWI_AST,%ecx
! je splz_next /* "can't happen" */
pushl %eax
orl imasks(,%ecx,4),%eax
movl %eax,_cpl
call %edx
popl %eax
movl %eax,_cpl
jmp splz_next
/*
--- 107,124 ----
ALIGN_TEXT
splz_swi:
cmpl $SWI_AST,%ecx
! je splz_nextx /* "can't happen" XXX can happen! */
pushl %eax
orl imasks(,%ecx,4),%eax
movl %eax,_cpl
call %edx
popl %eax
movl %eax,_cpl
+ jmp splz_next
+
+ splz_nextx:
+ orl $0x80000000,%eax
+ orl $0x80000000,_ipending
jmp splz_next
/*
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806140955.CAA00381>