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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message