On Tue, Oct 24, 2006 at 01:02:08AM +0200, Michal Mertl wrote: > Andrey V. Elsukov wrote: > > Hi, > > > > 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. > > > > ps, top and trace output from ddb attached. > > > 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 > > > > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > > 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 > > > > > Probably unrelated... > > Do you run with the alternative pseudo-terminal implementation > (kern.pts.enable=1)? > > 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. > > CCing: kib_at_ 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_conf.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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC