From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 9 Nov 2014 15:21:24 -0500 To: 9fans@9fans.net Message-ID: <09aeb45d6625e40fba13f98b078d9d8c@ladd.quanstro.net> In-Reply-To: <075800B3-4D1C-42A6-96D3-41C4C93A4C35@corpus-callosum.com> References: <5F410D66-F056-4DA0-BDDD-2440F5833162@corpus-callosum.com> <1add8901ace260cc260600d926cff629@ladd.quanstro.net> <075800B3-4D1C-42A6-96D3-41C4C93A4C35@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: 26b51ec4-ead9-11e9-9d60-3106f5b1d025 On Sun Nov 9 14:51:37 EST 2014, jas@corpus-callosum.com wrote: > > > On Nov 9, 2014, at 1:42 PM, erik quanstrom wrote: > > > > 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? > > Only happens in the labs ARM kernel. The labs mips and 386 kernels work fine > in this situation. my thinking is that this isn't a defect in the arch-specific bits but rather a timing bug. in that case, only manifesting on certain hardware is not diagnostic. do you have any reason to believe this is not a timing bug? it does fit the pattern rarely seen on x86 systems. (actually (cf. the console appliance) there were ways to really make x86 systems suffer by forking fast enough on slow hardware.) - erik