From owner-freebsd-current@FreeBSD.ORG Tue Oct 24 09:56:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 457F816A403 for ; Tue, 24 Oct 2006 09:56:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E27943D46 for ; Tue, 24 Oct 2006 09:56:09 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k9O9cXGo044205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 12:38:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k9O9u4td069465; Tue, 24 Oct 2006 12:56:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k9O9u3Bp069464; Tue, 24 Oct 2006 12:56:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Oct 2006 12:56:03 +0300 From: Kostik Belousov To: Michal Mertl Message-ID: <20061024095603.GH45605@deviant.kiev.zoral.com.ua> References: <453C88FE.8010901@yandex.ru> <1161644528.1054.76.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: <1161644528.1054.76.camel@genius.i.cz> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: "Andrey V. Elsukov" , freebsd-current Subject: Re: unkillable mount_smbfs processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 09:56:10 -0000 --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 01:02:08AM +0200, Michal Mertl wrote: > Andrey V. Elsukov wrote: > > Hi, > >=20 > > My system is CURRENT (~15.10.2006). > > When I try mounting a smbfs from windows server then > > mount_smbfs command is don't finished. And i can't > > interrupt or kill these processes. > >=20 > > ps, top and trace output from ddb attached. >=20 > > last pid: 2146; load averages: 0.00, 0.00, 0.00 up 0+05:28:50 = 13:07:20 > > 32 processes: 1 running, 31 sleeping > > CPU states: % user, % nice, % system, % interrupt, = % idle > > Mem: 25M Active, 269M Inact, 73M Wired, 23M Cache, 53M Buf, 36M Free > > Swap: 1024M Total, 16K Used, 1024M Free > > =20 > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMA= ND > > 859 root 1 -8 0 6120K 1528K devdrn 0:00 0.00% mount= _smbfs > > 946 root 1 -8 0 6120K 1000K devdrn 0:00 0.00% mount= _smbfs > >=20 >=20 >=20 > Probably unrelated... >=20 > Do you run with the alternative pseudo-terminal implementation > (kern.pts.enable=3D1)? >=20 > A situation like this - something stuck in devdrn, has been reported > before. The problem reported was with portupgrade and xterm > (gnome-terminal) being stuck (on exit?). I had the problem too until I > switched back to the default ptys. >=20 > CCing: kib@ who I believe has been around the changes before the first > report. The "devdrn" state was introduced by Tor Egge commit into sys/kern/kern_con= f.c, rev. 1.199. It prevents access to the freed kernel memory. Basically, some thread has declared use of the cdev, and thread that executing destroy_devl= () waits until all cdev users release it. Tty subsystem has problems with locking/reference counting. (At least) workarounds for them are under development now. In your case, smb_dev calls destroy_dev() from the d_close() routine. Since devfs_close() takes the thread reference on the device, that causes deadlock. --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPeMsC3+MBN1Mb4gRAhORAKDoyEGqF/tAcycaEns/lm1VgGYpBgCeJs/D fFPBcl7URxDcBMfoS67Z65w= =Tfir -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v--