From owner-freebsd-smp Fri Nov 17 16:47: 4 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E0AE037B479; Fri, 17 Nov 2000 16:47:01 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAI0klB10380; Fri, 17 Nov 2000 16:46:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 17 Nov 2000 16:47:30 -0800 (PST) From: John Baldwin To: John Baldwin Subject: RE: cvs commit: src/sys/kern kern_timeout.c Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18-Nov-00 John Baldwin wrote: > > On 18-Nov-00 John Baldwin wrote: >> jhb 2000/11/17 16:21:01 PST >> >> Modified files: >> sys/kern kern_timeout.c >> Log: >> Release sched_lock very briefly to give interrupts a chance to fire if we >> are in softclock() for a long time. The old code already did an >> splx()/slphigh() pair here, I just missed adding in the equivalent mutex >> operations on sched_lock earlier. > > Before this I could get processes to hang (the box was still up, but one > process was stuck, tying up its pty) though the box was still fine (I could > login and do stuff) if I ran a buildworld -j X where X > 1. With this I > built > a kernel with -j 8 and am currently chugging through a -j 64 world. Grrrr. Spoke too soon. :( It took longer, but I have one hung process (though the rest of the buildworld is still chugging along). I notice the problem because I have one sh process that has been a zombie for a way too long. It's parent is a make doing a make cleandir, and the parent is in SSLEEP on "pipewr". I notice that when the kernel tsleep()'s with "pipewr", it does a tsleep() with PCATCH, so I am betting that there it is still related to the CURSIG() stuff in msleep(). Since this doesn't happen very often, I'm guessing that this comes about when a process is switched out because it blocked on Giant. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message