FreeBSD on CuBox-i-4x4 (with HDMI patch)

Svatopluk Kraus onwahe at gmail.com
Mon Aug 3 09:56:12 UTC 2015


On Sun, Aug 2, 2015 at 10:57 AM, Ulrich Grey <usenet at ulrich-grey.de> wrote:
> On Tue, 28 Jul 2015 15:13:31 +0200
> Svatopluk Kraus <onwahe at gmail.com> wrote:
>
>> On Tue, Jul 28, 2015 at 9:18 AM, Ulrich Grey <usenet at ulrich-grey.de> wrote:
>> > 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 at wqtest:/usr/obj/usr/src/sys/IMX6  arm armv6hf
>> >
>> > To boot I have used this patch from Mikaël Urankar:
>> > http://mikael.urankar.free.fr/FreeBSD/arm/patches/sysutils_u-boot-cubox-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 is 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 = 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 in a chroot
> (print/texlive-full, java/openjdk8 with tests enabled, 'make index' in /usr/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 abnormally, 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: giving 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 100048)
>         dev mmcsd0s2a
> timed out
>
> Waiting (max 60 seconds) for system process `syncer' to stop...Syncing disks, 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 seconds) 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 Giving up on 37
> buffers 1 0 0 Cannot remove swap device da1s1b (error=12), skipping. Uptime: 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


More information about the freebsd-arm mailing list