From owner-freebsd-smp Sat Dec 28 08:41:55 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA16938 for smp-outgoing; Sat, 28 Dec 1996 08:41:55 -0800 (PST) Received: from netwolf.NetMasters.com (netwolf.netmasters.com [199.201.245.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA16931 for ; Sat, 28 Dec 1996 08:41:53 -0800 (PST) Received: from netwolf.NetMasters.com (localhost [127.0.0.1]) by netwolf.NetMasters.com (8.8.4/8.7.3) with ESMTP id LAA28588; Sat, 28 Dec 1996 11:41:51 -0500 (EST) Message-Id: <199612281641.LAA28588@netwolf.NetMasters.com> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-smp@freebsd.org cc: louie@wa3ymh.transsys.com Subject: psignal under SMP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Dec 1996 11:41:51 -0500 From: Michael Petry Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While showing a buddy the SMP build of FreeBSD we came across an interesting bug. I opened two windows from my work back to my dual P6-180 system at home. I compiled the program main() { foo: goto foo; } I exec'd it in the second window and was showing that things were still snappy in the primary window. I then went back to the second window and tried to kill the process. No go. Hmmm, scratched head and went back to the primary and ran a few utilities to find out what was going on. Boom!! The process in the second window dies. My buddy and I kicked the issue around for a while and then it hit us. The hard cpu process had its signal posted, but never got rescheduled to see the signals because it was happy and cozy running on the second processor. My running of some utilities were enough to force it off its cpu and cause it to be rescheduled and pickup its signal. Though this is an extreme case (no syscalls , just a hard cpu loop) We thought some more and concluded that that it would reap havoc with processes that were computing in wait of a SIGIOs on a relatively idle system. It looked to us like psignal.c would have to be made smarter to know not only if a process is runnable, but also if it is running on another CPU and be IPI'd.