From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 9 Nov 2014 14:42:39 -0500 To: 9fans@9fans.net Message-ID: <1add8901ace260cc260600d926cff629@ladd.quanstro.net> In-Reply-To: <5F410D66-F056-4DA0-BDDD-2440F5833162@corpus-callosum.com> References: <5F410D66-F056-4DA0-BDDD-2440F5833162@corpus-callosum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] arm httpd Topicbox-Message-UUID: 26abb294-ead9-11e9-9d60-3106f5b1d025 On Sun Nov 9 10:35:34 EST 2014, jas@corpus-callosum.com wrote: > Has anyone else seen the arm httpd lock up on them? I can start it, but then after a few proper responses it just sits: > > bootes 95 0:00 0:00 1436K Semacqui httpd (aside: i notice that throttle doesn't work like you'd expect, since RFMEM is not set, the stats won't be propogated to the parent. thus, this is really just a proc-local calculation, and since each forked proc only handles 1 connection, the hash is unnecessary. a local variable would do just fine.) the aside leads me to believe that there is something wrong with the segment copy on fork. since the semaphore in question is in the data segment, i'm going to guess that you're running the labs kernel, and you're hitting the page caching issue we've seen before. does this happen on an atom kernel? - erik