From owner-freebsd-current@FreeBSD.ORG Sat May 1 23:32:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98AB1106564A for ; Sat, 1 May 2010 23:32:34 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0328FC0C for ; Sat, 1 May 2010 23:32:33 +0000 (UTC) Received: from vbook.fbsd.ru ([77.232.23.6]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o41NWRMC010891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 May 2010 03:32:30 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O8MAc-0000mJ-8w; Sun, 02 May 2010 03:32:26 +0400 From: Vladimir Grebenschikov To: Kostik Belousov In-Reply-To: <20100430104934.GL2391@deviant.kiev.zoral.com.ua> References: <1272620170.9401.14.camel@localhost> <1272624229.2142.8.camel@localhost> <20100430104934.GL2391@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Sun, 02 May 2010 03:32:24 +0400 Message-ID: <1272756744.2586.55.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Jeff Roberson , current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 23:32:34 -0000 Hi > > Ehh, looks like fresh kernel is not too stable, it holds after some tim= e > > of activity. > >=20 > > DDB may be activated, but even 'call cpu_reset' does nothing here. > >=20 > > Looks like it is not related to SUJ, it happens even with SUJ disabled. > Does reverting r207410 + r207412 help ? No, it does not helps, even without this revs system locks hard time-to-tim= e, usually=20 under heavy load (CPU + Disk). For example 'portupgrade -f cups\*' usually makes system to lock. Few times I had working DDB while such lockup, but did not see there anythi= ng suspicious. Ideas will be very appreciated. I have SMP i386 system. --=20 Vladimir B. Grebenschikov vova@fbsd.ru