Roman,
Having finally found the original mail, I concur.
it looks like you have 'leaked' mutexes.
(and the witness code accesses all mutexes even after the driver has
unloaded... (*boom*))
I have not looked at the locks yet but you may be able to take advantage
of netgraph's inherrant locking a
I can't find this code, where is it?
On Wed, 17 Apr 2002, Maksim Yevmenkin wrote:
> Roman Kurakin wrote:
>
> > #if __FreeBSD_version >= 50
> > mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF);
> > mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF);
>
Roman Kurakin wrote:
> #if __FreeBSD_version >= 50
> mtx_init (&d->queue.ifq_mtx, "cp_queue", MTX_DEF);
> mtx_init (&d->hi_queue.ifq_mtx, "cp_queue_hi", MTX_DEF);
> #endif
my guess would be that you forgot to call mtx_destroy() for
queue and hi_queue mutexes.
Hi,
Call stack looks like this:
witness_destroy
mtx_destroy
fdtree
exit1
sys_exit
syscall
syscall_with_err_pushed
This is all information I have at that moment.
I could also send full texts of driver.
I also have question about ng_rmtype (&typestruct) function.
It seems that no one uses it. Th
I'm sorry I have not tried it for some time (a couple of months)
I do not know what has been broken.
I will try look tomorrow.
It only uses mutex in a few places so I will hopefully find what has
changed..
Can you give more information (e.g. stack trace?)
On Tue, 16 Apr 2002, Roman Kurakin wrot
Hi,
I am workin with 5.Current branch and I have some problems while
unloading
my driver or better to say after it done all unload stuff. If I comment
kernel options
that allow better debuging of MUTEX (WITNESS*) all works, but if I turn
them on
I will get kernel fault. (sppp + witness als
