Date: Sat, 16 Feb 2002 01:02:09 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Mark Santcroos <marks@ripe.net>, freebsd-current@FreeBSD.ORG Subject: Re: Ethernet tunnel device Message-ID: <3C6E2011.65DDAD2A@mindspring.com> References: <20020211032336.A2135@kashmir.etowns.net> <20020211170131.A79104@laptop.6bone.nl> <20020212074327.A3466@laptop.6bone.nl> <20020213111358.A3235@kashmir.etowns.net> <20020213111937.A10146@Odin.AC.HMC.Edu> <3C6B0BFD.F27F040F@mindspring.com> <20020216004146.A57907@laptop.6bone.nl> <3C6DD38B.BF38EC80@mindspring.com> <20020215214430.A7255@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: > I think there's something else going on. You can hold open a vmnet > device by the simple expedient of "cat /dev/vmnet0" and when I tested > with a Linux cat and killed it with a "kill -9" it closed the descriptor > properly. Some things I haven't tried, but though might have an effect > were using fork or linux threads to create multiple refrences to the > device and then closing them oddly. My next suggestion would be breaking to the kernel debugger, and finding out who holds the reference to the thing by walking through everything. The "lsof" program might end up being useful. Pretty clearly, if it happens, and the process is truly gone, then there is a resource track cleanup that's missing (perhaps it's a reference that results from the Linux mmap resource track cleanup not releasing it?). In any case, it might also help to put in printf's that spew each time a reference to that particular device is created or destroy; _that_, at least, would tell you about the unmatched reference that is being left around. If there were no reference around, then it wouldn't be a problem, and if it were something simple, your Linux "cat" test would have done the job in reproducing it. Short of asking the VMWare people for help, there's not really any way I'm going to be able to get you closer to the problem then by eliminating what can't be causing the symptoms you are seeing. I guess let us know if the printf's lead nowhere. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C6E2011.65DDAD2A>