On Tue, 25 Oct 2005, Philip Kizer wrote: > On Oct 19, 2005, at 11:54, Robert Watson wrote: >> This appears to be a problem with file descriptor passing and garbage >> collection. I've seen one report of a lock order reversal along these >> lines, but it was not believed to be symptomatic of an actual hang, just an >> architectural issue. This could be a sign that we need to address the >> source of the reversal, although it sounds like you don't get a reversal >> warning? >> >> Could I have you try the following DDB commands also: >> >> show alllocks >> traceall > > OK, this is a new hang with almost all I had before (looks like I did > forgot the "print sysctllock", will I need to be sure and include it for > a complete diagnosis?) and those two as well: > > http://www.nostrum.com/hang/hang.trace-2005-10-25-0.txt > > [Or would you prefer I include it directly rather than sparing the list > the output?] URL is fine, and useful, thanks! There are a couple of possible sources, so if this is reproduceable and you don't mind trying some diagnostic patches, I've attached a first one below. This checks for the case where the looping in the unp_gc() routine becomes unbounded due to a possible lack of synchronization in the handling of marking and counting of marking. It needs INVARIANTS to be compiled in to work; if it fires, this will suggest an avenue to explore. Robert N M Watson Index: uipc_usrreq.c =================================================================== RCS file: /data/fbsd-cvs/ncvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.156 diff -u -r1.156 uipc_usrreq.c --- uipc_usrreq.c 23 Sep 2005 12:41:06 -0000 1.156 +++ uipc_usrreq.c 25 Oct 2005 10:04:36 -0000 _at__at_ -1613,6 +1613,7 _at__at_ LIST_FOREACH(fp, &filehead, f_list) fp->f_gcflag &= ~(FMARK|FDEFER); do { + KASSERT(unp_defer >= 0, ("unp_gc: unp_defer %d", unp_defer)); LIST_FOREACH(fp, &filehead, f_list) { FILE_LOCK(fp); /*Received on Tue Oct 25 2005 - 08:07:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC