rrs added a comment. Hiren:
Ok looking at kern_timeout.c thats a call to class->lc_lock(c_lock, lock_status); If my 10.x matches yours. And the call inside that kern_rwlock.c:757 is v = rw->rw_lock; owner = (struct thread *)RW_OWNER(v); I would imagine v is probably a freed lock or some such.. not sure. If you have a vmcore sending the registers would be helpful. And for that matter if you have a vmcore if you could get in the frame of kern_timeout and tell me what c_lock c_func are that would be helpful. I have not tested this with my test framework for locks that pass in a lock.. If the c_func is not some private thing but something in BSD I can puzzle out what sub-system is using the callout this way and try to reproduce a test that will blow up this way on me as well. Assuming of course its not the caller that has freed the lock ahead of the callout system running... REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
