From owner-freebsd-current@FreeBSD.ORG Fri Jul 5 15:37:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 818FAF47 for ; Fri, 5 Jul 2013 15:37:12 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by mx1.freebsd.org (Postfix) with ESMTP id 142ED12A8 for ; Fri, 5 Jul 2013 15:37:11 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w57so2117895wes.1 for ; Fri, 05 Jul 2013 08:37:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Kts4kNH78IcanCCW6GVTZ63pRNED9zx5VKa07q/LgGw=; b=PxQWOTdEyrWv1XTzY7Kfi1x31AGP+C39ITAPFyyj3YViR/CIJ7JYwREvFFjFyejQjr ectRgCVvnHw5+QIsGroDAS+mtQg263LvDIFz9VE05fA/HPJeH+T4sxoTGgCkdt0HDZ1C 4ecyhpNq+QiSxaryG65bFjUKOHrQ0Nf/FXSVLKDT7K36WFW0vRKNhbnPgBYYm60dSsZL VNQnSuzoUENDLxz/FR2hISaQtorQvx1tRnKcio5xcaD1QqKgT1LNA0oBdmq6y5pC8O+K R6lVxImeiD8K8A9jpsZ06l4VV9p1HV0vS3Ca9dq7sxwh07rp0YwRVOjN4P+v/Bs7+/0d pxVQ== X-Received: by 10.180.96.227 with SMTP id dv3mr6158074wib.59.1373038625232; Fri, 05 Jul 2013 08:37:05 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id ev19sm10359307wid.2.2013.07.05.08.37.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 08:37:04 -0700 (PDT) Message-ID: <51D6E81D.3090503@semihalf.com> Date: Fri, 05 Jul 2013 17:37:01 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory References: <51C4A067.7010203@semihalf.com> <20130623065706.GV91021@kib.kiev.ua> <20130623083220.GA41511@mail.bsdpad.com> <20130623143248.GA91021@kib.kiev.ua> <20130623144346.GA69378@mail.bsdpad.com> <20130623161617.GC91021@kib.kiev.ua> <20130623164425.GA77339@mail.bsdpad.com> <20130623165040.GD91021@kib.kiev.ua> <20130623170507.GA79364@mail.bsdpad.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm5UpDKhDui0X8olO1t9n+FpCICGfpGoT1HiDpvBv5m6zcZ7fs94ySM5wvnAfwdKuEotLZe Cc: Konstantin Belousov , freebsd-arm@FreeBSD.org, freebsd-current@freebsd.org, Ruslan Bukin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:37:12 -0000 On 25.06.2013 05:23, Jeff Roberson wrote: > On Sun, 23 Jun 2013, Ruslan Bukin wrote: > >> On Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: >>> On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: >>>> On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: >>>>> On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: >>>>>> >>>>>> Trying to mount root from ufs:/dev/da0 []... >>>>>> WARNING: / was not properly dismounted >>>>>> warning: no time-of-day clock registered, system time will not be >>>>>> set accurately >>>>>> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv >>>>>> global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 >>>>>> >>>>>> KDB: enter: panic >>>>>> [ thread pid 1 tid 100001 ] >>>>>> Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! >>>>>> db> bt >>>>>> Tracing pid 1 tid 100001 td 0xc547f620 >>>>>> _end() at 0xde9d0530 >>>>>> scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) >>>>>> rsp=0xde9d0514 rfp=0xc12d1b60 >>>>>> Bad frame pointer: 0xc12d1b60 >>>>>> db> >>>>> This is completely broken. It seems that witness triggered the panic, >>>>> and ddb is unable to obtain a backtrace from the normal panic(9) call. >>>>> >>>>> Show the output of the 'show alllocks'. >>>> >>>> No such command >>> Do you have witness in the kernel config ? If not, add it to the config >>> and retry. >> >> Trying to mount root from ufs:/dev/da0 []... >> WARNING: / was not properly dismounted >> warning: no time-of-day clock registered, system time will not be set >> accurately >> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global >> @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 >> >> KDB: enter: panic >> [ thread pid 1 tid 100001 ] >> Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! >> db> show alllocks >> Process 1 (kernel) thread 0xc55fc620 (100001) >> exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ >> /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 >> exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked >> @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 >> shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ >> /usr/home/br/dev/head/sys/vm/vm_map.c:1809 >> exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ >> /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 >> exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ >> /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 >> exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ >> /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 >> db> >> > > Would any of the arm users be interested in testing a larger patch that > changes the way the kernel allocations KVA? It also has some UMA code > that lessens kernel memory utilization. > > http://people.freebsd.org/~jeff/vmem.diff > > Any reports would be helpful. Is there any ETA on getting stack tracing > fixed? I suspect the pmap recursion encountered with Kostik's patch > exist in the current kernel. The other changes in this patch my fix > that as well. > > Thanks, > Jeff Hello Jeff, I apologize for a long time with no respond. The problems that I reported at the origin of this tread are no longer relevant. I've made some really extensive tests on the current HEAD and there is no track of kstack allocation failure on my ARM target now. Thanks a lot for your help! Best regards Zbyszek Bodek