From owner-freebsd-stable@FreeBSD.ORG Wed Apr 25 08:18:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAB7A16A402 for ; Wed, 25 Apr 2007 08:18:38 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from serv2.vsi.ru (serv2.vsi.ru [80.82.32.11]) by mx1.freebsd.org (Postfix) with ESMTP id 43D5C13C45A for ; Wed, 25 Apr 2007 08:18:37 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from serv2.vsi.ru (localhost [127.0.0.1]) by serv2.vsi.ru (8.13.8/8.13.8) with ESMTP id l3P8IOt7085335; Wed, 25 Apr 2007 12:18:24 +0400 (MSD) (envelope-from oleg@vsi.ru) Received: (from nobody@localhost) by serv2.vsi.ru (8.13.8/8.13.8/Submit) id l3P8EKj6085124; Wed, 25 Apr 2007 12:14:20 +0400 (MSD) (envelope-from oleg@vsi.ru) X-Authentication-Warning: serv2.vsi.ru: nobody set sender to oleg@vsi.ru using -f To: Kris Kennaway Message-ID: <1177488860.462f0ddc6ce8c@webmail.vsi.ru> Date: Wed, 25 Apr 2007 12:14:20 +0400 (MSD) From: Oleg Derevenetz References: <20070313140848.GA89182@steerpike.hanley.stade.co.uk> <20070423025631.GA33256@steerpike.hanley.stade.co.uk> <20070423113912.GE2052@deviant.kiev.zoral.com.ua> <462DDB4D.8080507@delphij.net> <1177442585.462e5919c71f0@webmail.vsi.ru> <462EC294.3040001@delphij.net> <20070425035316.GB44054@xor.obsecurity.org> In-Reply-To: <20070425035316.GB44054@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Originating-IP: 80.82.33.58 Cc: freebsd-stable@freebsd.org, LI Xin , Oleg Derevenetz Subject: Re: How to report bugs (Re: 6.2-STABLE deadlock?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2007 08:18:38 -0000 Цитирую Kris Kennaway : > > Oleg Derevenetz wrote: > > > ??????? LI Xin : > > [...] > > >> I'm not very sure if this is specific to one disk controller. > Actually > > >> I got some occasional reports about similar hangs on amd64 > 6.2-RELEASE > > >> (slightly patched version) that most of processes stuck in the > 'ufs' > > >> state, under very light load, the box was equipped with amr(4) > RAID. > > >> > > >> I was not able to reproduce the problem at my lab, though, it's > still > > >> unknown that how to trigger the livelock :-( Still need some > > >> investigate on their production system. > > > > > > I reported simular issue for FreeBSD 6.2 in audit-trail for > kern/104406: > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=104406&cat= > > > > > > and there should be a thread related to this. Briefly, I suspects > that this is > > > related to nullfs filesystems on my server and when I cvsuped to > FreeBSD 6.2- > > > STABLE with Daichi's unionfs-related patches and replaced > nullfs-mounted fs > > > with unionfs-mounted (that was done 10.03.07) problem is gone (seems > to be so, > > > at least). > > > > Hmm... Seems to be different issues. The problem I have received was > a > > pgsql server (no nullfs/unionfs involved), and the hang always happen > > when it is not being heavily loaded (usually in the morning, for > > instance, and there is no special configuration, like scheduled tasks > > which can generate disk load, etc., only the entropy harvesting), so > > this is quite confusing. > > Yes, a large part of the confusion is the unfortunate tendency of > people to do the following: > > my system hangs/panics/etc > my system hangs/panics/etc too; it must be the same problem! > > What we really need is for every FreeBSD user who encounters a > hang/panic/etc to avoid jumping to conclusions -- no matter how many > superficial similarities there may seem to you -- and instead go > through the relevant steps described here: > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers- handbook/kerneldebug.html > > Until you (or a developer) have analyzed the resulting information, > you cannot definitively determine whether or not your problem is the > same as a given random other problem, and you may just confuse the > issue by making claims of similarity when you are really reporting a > completely separate problem. Not all people can do deadlock debugging, though. In my case turning on INVARIANTS and WITNESS leads to unacceptable performance penalty due to heavily loaded server. So I can only describe my case, actions and result without providing any debug information.