From owner-freebsd-arm@freebsd.org Mon Aug 3 09:56:12 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C1A79B1C35 for ; Mon, 3 Aug 2015 09:56:12 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 283231E91 for ; Mon, 3 Aug 2015 09:56:12 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by ioeg141 with SMTP id g141so139942196ioe.3 for ; Mon, 03 Aug 2015 02:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V856gW2NG4f1EEUjX5MpD6MZXH5XUQk4kOTezbrnZxE=; b=ctoz6+BGoKv28bI6eXwWk++USkY9pZEoRSirot80F5V+SDdeRUKO41BOzjidu5Tjbw 0UWCe3Zpk4Kxsv8+bc7ntKnm6MPo/BiF85VFZbwA0upY9PddAmnTtfZY9eYdGhk+/Ck2 P5q+6AUGz3VJfk5KbKLx9xtmAkg9zIWU3WadAhBGTPBMIjU+Bx4WU2dhB18Y3xYtuRRJ RPQOzN6jL66c2yP3efI15rOh2Kuve3aAeS97oIat78URQWbmOnV8BZsg0/UEsb1kg7sR NN9s1KbpFozF68PmU6LYALyNx+gsUpgV9a/J0dOh5IgGoR5xjDUJbfelrkx1e3XMFFhd Q8vg== MIME-Version: 1.0 X-Received: by 10.107.128.28 with SMTP id b28mr19620349iod.84.1438595771318; Mon, 03 Aug 2015 02:56:11 -0700 (PDT) Received: by 10.64.148.84 with HTTP; Mon, 3 Aug 2015 02:56:11 -0700 (PDT) In-Reply-To: <20150802085712.2db3bd374534c27f8810390c@ulrich-grey.de> References: <20150728071854.357c89785e048ae6d64c1c70@ulrich-grey.de> <20150802085712.2db3bd374534c27f8810390c@ulrich-grey.de> Date: Mon, 3 Aug 2015 11:56:11 +0200 Message-ID: Subject: Re: FreeBSD on CuBox-i-4x4 (with HDMI patch) From: Svatopluk Kraus To: Ulrich Grey Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:56:12 -0000 On Sun, Aug 2, 2015 at 10:57 AM, Ulrich Grey wrote: > On Tue, 28 Jul 2015 15:13:31 +0200 > Svatopluk Kraus wrote: > >> On Tue, Jul 28, 2015 at 9:18 AM, Ulrich Grey wro= te: >> > Hello, >> > >> > I have the opportunity to test freebsd on a CuBox-i-4x4 >> > http://solid-run.com/product/cubox-i-4x4/. >> > >> > uname -ap >> > FreeBSD wqtest 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r285875M: Sun Jul = 26 14:55:10 UTC >> > 2015 gwgpi@wqtest:/usr/obj/usr/src/sys/IMX6 arm armv6hf >> > >> > To boot I have used this patch from Mika=C3=ABl Urankar: >> > http://mikael.urankar.free.fr/FreeBSD/arm/patches/sysutils_u-boot-cubo= x-hummingboard.patch >> > >> > Because I got an "No valid device tree blob found" error, in /boot/dtb= I >> > copied imx6q-cubox-i.dtb to imx6q-cubox-i4p.dtb. >> > >> > Now I can boot, but only half of the memory and one of two USB ports i= s recognized. >> > >> > I have compiled some ports on the text console without problems. >> > If I compile in a xfce4-terminal, I get a panic: >> > >> > pmap_remove_pages: pmap 0xcad291b4 va 0x200ab000 pte1 0 >> > panic: bad pte1 >> > cpuid =3D 2 >> > KDB: enter: panic >> > [ thread pid 28202 tid 100131 ] >> > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >> > >> > But that may be related to the dtb-file. >> > >> >> >> Is it reproducible? I really would like to debug this panic. For >> beginning, it would be nice to see 'show pmap' output from ddb. If >> it's reproducible, I could prepare some debug patch to try to get some >> more info about it. Trying to run kernel with INVARIANTS option on is >> worth it too. > > I tried to reproduce the panic. > First, I have built a kernel with INVARIANTS/INVARIANT_SUPPORT activated. > Then I have build some huge ports in xfce4-terminal windows in parallel i= n a chroot > (print/texlive-full, java/openjdk8 with tests enabled, 'make index' in /u= sr/ports). > Nothing remarkable and no panic occurred. > Thanks that you have tried. > After 2 days I have used the old kernel without INVARIANTS. > I have built devel/llvm-devel in a chroot environment. > After the build finished successfully, the system was very slow. > During shutdown I had a problem I have never seen before: > # > Aug 2 07:45:35 cutest shutdown: halt by root: > 90 second watchdog timeout expired. Shutdown terminated. > Sun Aug 2 07:47:11 UTC 2015 > Aug 2 07:47:11 cutest init: /bin/sh on /etc/rc.shutdown terminated abnor= mally, going to > single user mode > > Aug 2 07:47:12 cutest syslogd: exiting on signal 15 > > Waiting (max 60 seconds) for system process `vnlru' to stop...fsync: givi= ng up on dirty > 0xc75db120: tag devfs, type VCHR > usecount 1, writecount 0, refcount 87 mountedhere 0xc74f7800 > flags (VI_ACTIVE) > v_object 0xc75e1460 ref 0 pages 18606 cleanbuf 1 dirtybuf 84 > lock type devfs: EXCL by thread 0xc715fa20 (pid 17, syncer, tid 10004= 8) > dev mmcsd0s2a > timed out > > Waiting (max 60 seconds) for system process `syncer' to stop...Syncing di= sks, vnodes > remaining...1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1= 1 1 1 1 1 1 1 1 > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 timed out Waiting (max 60 sec= onds) for system > process `bufdaemon' to stop...done Syncing disks, buffers remaining... 39= 1 37 37 37 37 1 > 37 37 37 1 37 37 1 37 37 0 37 1 37 1 37 1 37 37 0 37 1 37 1 37 1 37 0 Giv= ing up on 37 > buffers 1 0 0 Cannot remove swap device da1s1b (error=3D12), skipping. Up= time: 1d13h5m57s > > The operating system has halted. > Please press any key to reboot. > > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ... > > Script done on Sun Aug 2 08:06:29 2015 > # > I had to break power supply. > But no panic occurred. > I never see something like that before, however it does not mean too much. On the other hand, I have a problem with swap device one or two times which was unable to unswap swapped programs. If I remember it correctly, the scenario was that the programs were swapped in the beginning of long term job (buildworld on rpi for example) and after that the swap device was not used a few days. And then, when the job finished and I wanted to used swapped programs, it happened. Svata