hiren added a comment. >>! In D1711#59, @rrs wrote: > 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...
panic #3 happened on stable-10+this patch. I've setup a -head box with this patch to reproduce the problem. In any case, I'll try to get vmcore and other details tomorrow. 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"
