From owner-freebsd-arm@FreeBSD.ORG Wed Aug 21 20:42:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1BBD932B for ; Wed, 21 Aug 2013 20:42:59 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D562229A2 for ; Wed, 21 Aug 2013 20:42:58 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id fb19so1837564obc.38 for ; Wed, 21 Aug 2013 13:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2+3piHEF4y9Ap5wuJLgJ0jtm03YV5eRVQaQ/Hdglw0g=; b=NKX/cuQ30tLa4PC6j58TSmMKw+glKuuAgwZPELTB/n0uRanxr1P5LVViJFWFcZ8k5F ddNE3SNilEVr6iwKd/4e2PBJBep3a7NyXXVEi1jeTJt6Zlrp8qRUXcJUeWyM6PE95T9Y Th4RO7RPKfWK6HhysJkEn2mdhdAJFjHubHwxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2+3piHEF4y9Ap5wuJLgJ0jtm03YV5eRVQaQ/Hdglw0g=; b=VwEF1SCC87h4Afvu46Kah1kQ0+NE27mF4KtMTzr59kWlh7aoguefkB4Oq0x+w6lIdX OjO2gGLgU//erdNPoriUehxTkDLRn9iy1dcbGv54gXamP5+MdrV5T3Zp6t0ByH5vEZ43 1HDVVjcEin+blPTanUxw+Z0rZYFnitXcfNtgH31231eutC9ctMND1oqkmpS8VvPxDbXa XsmIy2KLNapAIXdc36OlUilYHrsFASQ7EveIHal8EkkFWXI82b8e1bHtYLnkY1hx9AUZ pwkQw5GJaBvMf1jKV/rN14qDGah/ipiWRJCG/+IuCWJI8ccm7SHVGFERJlAyIUlLhZft 60OQ== X-Gm-Message-State: ALoCoQnuPDy6jMrfgZNxzprm12Sy0OsbqjW4lYSjiZ/2xRzLplu4fNnMxxEA5iV27aSVZxBQL21f MIME-Version: 1.0 X-Received: by 10.60.15.106 with SMTP id w10mr4562094oec.82.1377117777982; Wed, 21 Aug 2013 13:42:57 -0700 (PDT) Received: by 10.182.236.230 with HTTP; Wed, 21 Aug 2013 13:42:57 -0700 (PDT) In-Reply-To: <81E82602-C147-429A-96BB-7DD7B7AAA38E@netsense.nl> References: <5213CD1A.7000506@martinlaabs.de> <81E82602-C147-429A-96BB-7DD7B7AAA38E@netsense.nl> Date: Wed, 21 Aug 2013 10:42:57 -1000 Message-ID: Subject: Re: Debug stalling Raspberry From: David Cornejo To: Johan Henselmans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 20:42:59 -0000 On Tue, Aug 20, 2013 at 9:48 PM, Johan Henselmans wrote: > > On 20 aug. 2013, at 22:10, Martin Laabs > wrote: > > > Hi, > > > > currently I run r254441 on a raspberry pi b and every time I run portsnap > > the cpu stopps running. > > This happens during the snapshot verify while around 25k files are > gunziped > > and sha256ed (file after file of cause). I can reproduce this but the Pi > > does not hang reproducible at the same file but the last processed file > is > > different from try to try. > > > I have exactly the same experience on BBB, also with portsnap. The only > way I could get portsnap to finish is by locating /var/db/portsnap on NFS. > > I am still testing what is causing it. I have used class 4 and class 10 > cards, both freeze. > > I have the serial console connected to screen, and nothing is displayed > during the freeze. > > I do have an error about the keyboard during startup, as Tim mention that > pressing the keyboard would continue the BBB. I have not tested that, as I > do not see a console on my HDMI monitor on the BBB. > > (r254571) > > ========= > link_elf: symbol genkbd_get_fkeystr undefined > link_elf: symbol genkbd_get_fkeystr undefined > aintc0: Spurious interrupt detected (0xffffffff) > ========= > > > Another message I got while starting up: > > ========= > lock order reversal: > 1st 0xc09aa0bc pmap (pmap) @ /usr/src/sys/arm/arm/pmap-v6.c:2967 > 2nd 0xc07c5fc0 kmem vm object (kmem vm object) @ > /usr/src/sys/vm/vm_kern.c:344 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc05293f8 lr = 0xc022db88 (db_trace_self_wrapper+0x30) > sp = 0xc2ab4930 fp = 0xc2ab4a48 > r10 = 0xc09aa0bc > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc022db88 lr = 0xc038d150 (kdb_backtrace+0x38) > sp = 0xc2ab4a50 fp = 0xc2ab4a58 > r4 = 0xc065ed14 r5 = 0xc05a6f1c > r6 = 0xc058a3b3 r7 = 0xc05abd59 > kdb_backtrace() at kdb_backtrace+0x38 > pc = 0xc038d150 lr = 0xc03a72c0 (witness_checkorder+0xddc) > sp = 0xc2ab4a60 fp = 0xc2ab4ab0 > r4 = 0xc05a7fd4 > witness_checkorder() at witness_checkorder+0xddc > pc = 0xc03a72c0 lr = 0xc0355768 (_rw_wlock_cookie+0x7c) > sp = 0xc2ab4ab8 fp = 0xc2ab4ae0 > r4 = 0x00000158 r5 = 0xc05a6f19 > r6 = 0xc07c5fd0 r7 = 0xc07c5fc0 > r8 = 0xc07c5fc0 r9 = 0x00000101 > r10 = 0x00000000 > _rw_wlock_cookie() at _rw_wlock_cookie+0x7c > pc = 0xc0355768 lr = 0xc0504794 (kmem_back+0x68) > sp = 0xc2ab4ae8 fp = 0xc2ab4b28 > r4 = 0xc07c5fc0 r5 = 0x00001000 > r6 = 0x00000000 r7 = 0xc07c5fc0 > r8 = 0x00000101 > kmem_back() at kmem_back+0x68 > pc = 0xc0504794 lr = 0xc05046f0 (kmem_malloc+0x6c) > sp = 0xc2ab4b30 fp = 0xc2ab4b48 > r4 = 0xc0661780 r5 = 0x00001000 > r6 = 0x00000000 r7 = 0x00000101 > r8 = 0xc04fd5e0 r9 = 0x00000101 > r10 = 0x00000000 > kmem_malloc() at kmem_malloc+0x6c > pc = 0xc05046f0 lr = 0xc04fd600 (page_alloc+0x20) > sp = 0xc2ab4b50 fp = 0xc2ab4b50 > r4 = 0xc09d3cc0 r5 = 0x00000001 > r6 = 0x00000000 r7 = 0xc09d3cd0 > page_alloc() at page_alloc+0x20 > pc = 0xc04fd600 lr = 0xc04fd094 (keg_alloc_slab+0xb4) > sp = 0xc2ab4b58 fp = 0xc2ab4b80 > keg_alloc_slab() at keg_alloc_slab+0xb4 > pc = 0xc04fd094 lr = 0xc04fdcd0 (keg_fetch_slab+0x148) > sp = 0xc2ab4b88 fp = 0xc2ab4bc0 > r4 = 0xc09d3cc0 r5 = 0xc09ce408 > r6 = 0x00000001 r7 = 0xc09ce360 > r8 = 0x00000000 r9 = 0xc09ce3f8 > r10 = 0x00000000 > keg_fetch_slab() at keg_fetch_slab+0x148 > pc = 0xc04fdcd0 lr = 0xc04fe0c4 (zone_fetch_slab+0x64) > sp = 0xc2ab4bc8 fp = 0xc2ab4be0 > r4 = 0x00000001 r5 = 0xc09ce360 > r6 = 0xc09d3cc0 r7 = 0xc09d3cc0 > r8 = 0x00000001 r9 = 0xc2ff4fa8 > r10 = 0x00000002 > zone_fetch_slab() at zone_fetch_slab+0x64 > pc = 0xc04fe0c4 lr = 0xc04fe150 (zone_import+0x4c) > sp = 0xc2ab4be8 fp = 0xc2ab4c28 > r4 = 0xc2ff4fac r5 = 0xc05a621a > r6 = 0x00000001 r7 = 0xc09d3cc0 > r8 = 0x00000000 > zone_import() at zone_import+0x4c > pc = 0xc04fe150 lr = 0xc04fbdc0 (uhub2: 4 ports with 4 > removable, self powered > uma_zalloc_arg+0x2a0) > sp = 0xc2ab4c30 fp = 0xc2ab4c70 > r4 = 0x00000001 r5 = 0xc05a621a > r6 = 0xc09b0e0c r7 = 0xc04fe104 > r8 = 0xc09ce360 r9 = 0xc09ce418 > r10 = 0xc09b0e00 > uma_zalloc_arg() at uma_zalloc_arg+0x2a0 > pc = 0xc04fbdc0 lr = 0xc053349c (pmap_alloc_l2_bucket+0x1b4) > sp = 0xc2ab4c78 fp = 0xc2ab4ca0 > r4 = 0xc05abd56 r5 = 0xc09999f8 > r6 = 0xc09999f4 r7 = 0xc07c0de8 > r8 = 0xc05abd56 r9 = 0xc09abaac > r10 = 0xc09abb38 > pmap_alloc_l2_bucket() at pmap_alloc_l2_bucket+0x1b4 > pc = 0xc053349c lr = 0xc0533158 (pmap_copy+0x158) > sp = 0xc2ab4ca8 fp = 0xc2ab4ce0 > r4 = 0xc09aba9c r5 = 0x20049000 > r6 = 0xc05abd56 r7 = 0x2002e000 > r8 = 0x0001b000 r9 = 0xc09964b8 > r10 = 0x0001b000 > pmap_copy() at pmap_copy+0x158 > pc = 0xc0533158 lr = 0xc050a660 (vmspace_fork+0x790) > sp = 0xc2ab4ce8 fp = 0xc2ab4d20 > r4 = 0xc09aa000 r5 = 0x00000000 > r6 = 0x2002e000 r7 = 0xc099c500 > r8 = 0xc09ab9e0 r9 = 0xc099df50 > r10 = 0x0001b000 > vmspace_fork() at vmspace_fork+0x790 > pc = 0xc050a660 lr = 0xc0327004 (fork1+0x1a4) > sp = 0xc2ab4d28 fp = 0xc2ab4d98 > r4 = 0xc2ffc960 r5 = 0x00000000 > r6 = 0xc2fc5000 r7 = 0x0000000c > r8 = 0xc2fc5320 r9 = 0xc2ffcc80 > r10 = 0xc2ab4dac > fork1() at fork1+0x1a4 > pc = 0xc0327004 lr = 0xc0326e40 (sys_fork+0x24) > sp = 0xc2ab4da0 fp = 0xc2ab4db8 > r4 = 0xc2ffcc80 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0xc2ab4e10 r9 = 0xc2fc5320 > r10 = 0x00000000 > sys_fork() at sys_fork+0x24 > pc = 0xc0326e40 lr = 0xc0538ee4 (swi_handler+0x284) > sp = 0xc2ab4dc0 fp = 0xc2ab4e58 > r4 = 0xc2ffcc80 r5 = 0x00000000 > swi_handler() at swi_handler+0x284 > pc = 0xc0538ee4 lr = 0xc052aa54 (swi_entry+0x2c) > sp = 0xc2ab4e60 fp = 0xbfffec18 > r4 = 0x00030998 r5 = 0x2080d020 > r6 = 0x00000000 r7 = 0x00000002 > r8 = 0x00000003 r9 = 0x2080d020 > swi_entry() at swi_entry+0x2c > pc = 0xc052aa54 lr = 0xc052aa54 (swi_entry+0x2c) > sp = 0xc2ab4e60 fp = 0xbfffec18 > Unable to unwind further > ========= > > > > > > There is, at least at the video console, no kernel panic. The kernel > itself > > still responds to icmp ping packages and echos the keyboard output. But > > everything else does not work. (I know this behavior from disconnected > > harddisks containing the kernel/system) > > The current consumption also dropps around 100mA. > > > > It is very interesting that this behavior is not limited to the internal > > MMC card but also occurs when the data is stored external on an usb > stick. > > > > My question is how to debug this bug since I have no idea where to start. > >> From my experience with bare metal arm systems I would start connecting > a > > jtag debugger but I am afraid getting all the symbols mapped correct to > the > > gdb. And even if this works - what should I monitor and what should I > test for? > > There might be however a more simple solution. So any suggestion is > welcome. > > > > If you can reproduce this bug I also would be very happy. > > > > Best regards, > > Martin Laabs > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > Johan Henselmans > johan@netsense.nl > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Possibly totally irrelevant, but I've noticed on a kernel from yesterday that I was getting CPU percentages in top of over 100% before it hung - earlier kernels did not exhibit this. dave c