Date: Wed, 20 Sep 1995 21:13:55 +0900 From: kato@eclogite.eps.nagoya-u.ac.jp To: FreeBSD-gnats-submit@freebsd.org Subject: kern/729: unexpected signal 4/10/11 Message-ID: <199509201213.VAA00386@marble.eps.nagoya-u.ac.jp> Resent-Message-ID: <199509201220.FAA00843@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 729 >Category: kern >Synopsis: unexpected signal 4/10/11 >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 20 05:20:00 PDT 1995 >Last-Modified: >Originator: KATO Takenori >Organization: Dept. Earth Planet. Sci. Nagoya Univ. >Release: FreeBSD 2.2-CURRENT i386 >Environment: FreeBSD-current (after September 5) on i486DX4 box >Description: Programs catches signal 11 and terminated just after execution. If some progrma caught signal 11, such program cannot be excuted. So I have to reboot my box. Signal caught by program is usually signal 11, but somtimes it is signal 10 and as a rare case signal 4. In most case, virtual address where signal occured is in shared library (I checked it by running programs on gdb). This phenomenon has appered since September 5. Before then, this problem occurs rarely. (Many vm related code had been changed from Semtember 3 to 5.) >How-To-Repeat: I don't know how to repeat this problem on any machine. On my box, this problem happens every day! >Fix: I think this problem is due to vm bug, but I don't know complete fix. I have found three problem related vm. (1) Function splimp doesn't block disk I/O. Even though 4.4BSD derived code assumes splhigh is higher than or equals to splbio + splnet, net_imask doesn't include bio_imask (cf. isa.c). This may cause access to kmem without lock, if disk I/O intterupton occurs. In most code, splimp call in 4.4BSD has been changed into splhigh (why 'splhigh' which block ALL intterupton?), but some has not been changed yet. The next proble is one of them. My quick hack is that I add following code just above spl0() in isa_conigure: net_imask |= bio_imask; (2) In function mbinit (/sys/kern/uipc_mbuf.c), function m_clalloc is called at splimp. In m_clalloc, kmem_malloc is called. The comment of kmem_malloc in /sys/vm/vm_kern.c says that kmem_malloc should be called at splhigh. So splhigh and splx should be added before and after kmem_malloc call in m_clalloc. (3) splhigh() is misplaced in function vm_map_functon (/sys/vm/vm_map.c). I think this splhigh is added to avoid recursive lock_write call (splhigh doesn't appear in vm_map_function in 4.4BSD). To avoid recursive lock there are two way. One is block interruption as FreeBSD does and another is make submap to avoid competition of map. I think FreeBSD choose former way. In this case, splhigh should be placed BEFORE vm_map_lock, because interruption may occur between vm_map_lock and splhigh, and kmem_map is not locked. (I heard that combination of both two way makes splhigh unneccessary in NetBSD.) Applying above three fixes, the time from reboot to appearing the problem becomes long (but once proble happens, I have to reboot yet.) >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509201213.VAA00386>