status of AVILA and CAMBRIA code

[John Hay]

Hi Guys,

What is the status of AVILA and CAMBRIA builds in our tree? Have anybody
had success recently? From the lists I can see that other people have
also asked in September 2013, but I cannot figure out if there was any
successes at that stage. :-)

Currently we have some AVILA based systems running using FreeBSD-9 from
January 2012. They are doing ok, but with the AVILAs be EOLed, we were
thinking of using CAMBRIAs in the interrim and then start looking for
some embedded board that can boot standalone, have an ethernet port
and 3 X wifi (MiniPCI or something) and is supported by FreeBSD. :-)
But that for another email.

So I thought the easiest will be to just build a CAMBRIA kernel from
the same Jan 2012 tree and then share the user level binaries between
the two. It look ok at first but then at random times, I would see
"athX: ath_rx_proc: no mbuf!" messages and sometimes the wifi would
stop receiving with a "athX: ath_rx_proc: couldn't restart RX after
RXEOL; resetting" "ath_rx_proc: unable to start recv logic". I looked
with netstat -m, but did not see an obvious problem, so decided it is
time for an upgrade.

So I tried the latest current and latest 10-stable, but both AVILA and
CAMBRIA kernels does not even print anything on the serial ports.

I then tried various older builds finding various problems:

Somewhere shortly after 2013-08-16 the kernel will panic with "Fatal
kernel mode data abort: 'Alignment Fault 3'. I did not check if it
was fixed later in the tree before the kernels stopped outputting to
the serial port.

On 2013-04-15 the kernel will stop after writing the gcc version 4.2.1
message.

On 2013-03-20 creation of mdX ram disks for /etc and /var broke with
a "mdmfs: newfs err 38" message. You can get past that by setting
the vfs.unmapped_buf_allowed=0 tunable.

On 2012-01-25 svn 230553 remounting partitions rw->ro started to take
so long that the longest AVILA watchdog setting will still reset the
machine before the remounting is finished. Undoing that commit gets
one past that. We normally keep the CF mounted ro and when we need to
make changes mount it rw, make the change and then mount it ro again.

Somewhere along the line the ethernet npe0 device also broke, writing
"npe0: npestart_locked: too many fragments 0". But I did not test the
npe0 device with every build and only realised it this morning, so I
do not know where it broke. :-)

-- 
John Hay -- jhay at meraka.csir.co.za / jhay at meraka.org.za