FreeBSD on MPC8349 (e300 core)

[Marek Woloszyn]

Peter Grehan wrote:
> Hi Marek,
>
>> We have FreeBSD 6.3 running on our Freescale MPC8349 board (e300
>> core).
>
>  Excellent !
>
>> But, unfortunately, it is not stable and we don't know what to
>> do now.
>>
>> We have added several things to FreeBSD 6.3 to make it work on our
>> board: 1. Some workarounds for OpenBIOS. 2. IMISS, DLMISS and DSMISS
>> exceptions handlers in trap_subr.S. 3. Other hardware dependent
>> stuff.
>
>  There is a SoC project this year to port to the Efika platform:
>
>    http://wiki.freebsd.org/Porting_FreeBSD_to_Efika_%28PPC_bring_up%29
>
>  The *MISS exception handlers are in that, via some patches that Andrew
> Turner contributed many moons back.

We will look into it.

>> We have noticed that there were some errors in pmap: 1. Unnecessary
>> ptegidx shift in pmap_pte_insert function (already fixed in 7.0).
>
>  Yep, needs to be MFC'd back to RELENG_6.
>
>> 2. Hash table overflows when the system works with high load - caused
>> by non-uniform PTE entries distribution in the hash table.
>
>  Have you tried increasing the size of the hash table ? That is a simple
> workaround. As you may have seen, there is no facility for overflow of
> the secondary hash bucket: that is something that could be added.
>
Yes. We have already tried that. It helps, but the PTE  usage distribution
in PTEG table is still non-uniform. For normal PTEG table size the secondary
hash bucket hits PTEGs that are already filled by  the primary hash bucket 
and then we get a panic.
>> Unfortunately we still have problems with the system. We experience
>> random processes crashes when the system is starting. It happens
>> approximately once for 20 boots. If the system does not crash at the
>> startup, everything works fine. We do not know where to look for the
>> solution: pmap? vm?
>
>  Is it a hang ? A panic ? If the latter, do you have a console trace ?
>
It's a panic. I've attached three example backtraces from sh, tail and pkill.
They have all appeared during the boot process.  We have many more core
dumps from various system tools, but they are all similar to these. Suddenly
a pointer points to 0x0 or an index in a table is invalid. Maybe something
in the kernel  overwrites user pages or maps a wrong page for a process?

We have also tried some tricks with <pmap_init(pmap_t pmap)> in pmap.c.
There is a variable <entropy> witch is initialized with timebase register
values and used to make VSID values more random. As our problem seems
to be random and the booting process is rather deterministic, we have
initialized the entropy with a constant value to check if it would have an
impact on our problem. The first chosen value 0x12345678 didn't help,
but 0x35913521chosen at random seems to help (we do not observe
any crashed at boot, but we still haven't tried any long runs). 
Never the less, we haven't found the heart of this problem and we hardly
have a clue where to look. We have been wondering if anybody else
had expierienced similar program crashes.


Ps.
I'm not sure if my last e-mail reached your server,
so i'm sending it once again.
Please don't treat it as spam.
 
Kind Regards,
Marcin Ligenza 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 225.tail.core.bt
Type: application/octet-stream
Size: 1267 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20080710/932b7c9c/225.tail.core.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 371.sh.core.bt
Type: application/octet-stream
Size: 4181 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20080710/932b7c9c/371.sh.core.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 467.pkill.core
Type: application/octet-stream
Size: 3553 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ppc/attachments/20080710/932b7c9c/467.pkill.obj