Date: Tue, 24 Oct 2006 12:56:03 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Michal Mertl <mime@traveller.cz> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: unkillable mount_smbfs processes Message-ID: <20061024095603.GH45605@deviant.kiev.zoral.com.ua> In-Reply-To: <1161644528.1054.76.camel@genius.i.cz> References: <453C88FE.8010901@yandex.ru> <1161644528.1054.76.camel@genius.i.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061024095603.GH45605>