From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 06:34:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1ED1106566C for ; Wed, 27 Jun 2012 06:34:04 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 96A378FC0A for ; Wed, 27 Jun 2012 06:34:04 +0000 (UTC) Received: (qmail 4890 invoked by uid 0); 27 Jun 2012 06:34:03 -0000 Received: from 67.206.184.147 by rms-us010.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 27 Jun 2012 02:33:59 -0400 From: "Dieter BSD" Message-ID: <20120627063400.298430@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: D8yYb/cV3zOlNR3dAHAhnPN+IGRvb0A9 Subject: Re: Freeze when running freebsd-update X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:34:05 -0000 >> Robert writes: >>> 3) the box is responsive to hitting enter at the console (it produces >>> another login: prompt) >> >> Getty is in memory and can run. >> >>> 5) if I try to login to the console, it lets me enter a username then >>> locks up totally, it does not present me with a password: prompt. >> >> Login(1) is not in memory, and the kernel cannot read it from disk >> for some reason. >> >> I can get this symptom by writing a large file to a disk on a >> controller that FreeBSD doesn't support NCQ on. I assume there >> is a logjam in the buffer cache. Something trivial like reading >> login in from disk that would normally happen in well under a >> second can take many minutes. >> >> Perhaps geli is causing a similar logjam? Does it hang forever or >> is it just obscenely slow? If it truely hangs forever it is >> probably something else. Is there disk activity after it hangs? >> Can you try it without geli? systat -vmstat might provide a clue. > > Well, it is geli. I'm unable to reproduce the freeze on the same > exact system with everything else the same except for no geli. I'm > going to move this thread over to geom, and continue it there. Thanks > for your help! It occurs to me that it will need twice as much memory for disk i/o. 1 buffer for encrypted and 1 for unencrypted. I know nothing about geli, so I don't know if it uses the buffer cache for both, or what. Could it be that the kernel isn't keeping enough memory free and manages to paint itself into a corner and not have space to store the unencrypted version of disk reads, and can't page/swap anything out to make space because it doesn't have space to store the encrypted version to write?