Now partially booting on our CN58XX eval board

[Paul Heyman]

Juli

Thanks for the pointer regarding limiting the bootmem to 512M. I modified what gets passed to cvmx_bootmem_phy_alloc in the max_addr parameter.

That gets us past the panic and brings the kernel up to a prompt.
No failure conditions observed on the console
>From the shell prompt all seems well.

But when we try and ping in or out we seem to get a panic from the ethernet controller.
It does not happen all of the time. It usually take 50 - 200 pings to cause the problem.
I have isolated it to a few places in cvm_oct_tasklet_rx function in ethernet-rx.c.

1. At line 293 . it looks like the entire packet is stored in the work entry. I can see the panic in the code, but on the console it also indicates a NULL ptr being passed to cvmx_phys_to_ptr. Not sure if the NULL pointer is caused by the panic. This is what is on the console

root at -2-/root# WARNING:
cvmx_phys_to_ptr() passed a zero address
panic: cvm_oct_tasklet_rx: not yet implemented; copy in small packet.
KDB: enter: panic
[ thread pid 0 tid 100016 ]
Stopped at      kdb_enter+0x50: lui     at,0x8358
db>

2. At line 406 of the same file. Calling cvm_oct_mem_fill_fpa results in a TLB miss (store).



Any ideas

Thanks for your help

Paul Heyman
pheyman at adaranetworks.com


-------- Original Message --------
Subject:        Re: Now partially booting on our CN58XX eval board
Date:   Fri, 27 Aug 2010 12:57:18 -0700
From:   Juli Mallett <jmallett at FreeBSD.org><mailto:jmallett at FreeBSD.org>
To:     Patrick Mahan <pmahan at adaranet.com><mailto:pmahan at adaranet.com>
CC:     freebsd-mips at freebsd.org<mailto:freebsd-mips at freebsd.org> <freebsd-mips at freebsd.org><mailto:freebsd-mips at freebsd.org>



On Fri, Aug 27, 2010 at 11:16, Patrick Mahan <pmahan at adaranet.com><mailto:pmahan at adaranet.com> wrote:
> I have an engineer that thinks this would be fun to resolve, so I am letting
> him run with this for now.  Is this an address coming from the mii layer?

I looked at the code and Warner's output a few weeks ago and it seems
to be an address coming from the command queue code
(cvmx-cmd-queue.{c,h} in the Simple Executive) or maybe it was the FPA
code.  I think I told Warner that it was happening because mbufs are
put into the FPA and we don't have a way to create an ephemeral
mapping given a physical address that is not direct-mappable.  Making
it so that your system won't allocate mbufs above 0x2.... is a quick
hack to test that theory and a reasonable workaround for o32 (since
Octeon really makes more sense with n64 kernels, at minimum) so I'd
suggest modifying the memory setup code in octeon_machdep.c to not add
any memory above 512M or whatever.

If you have an engineer with some time, though, I'd suggest having
them work on COMPAT_FREEBSD32 for o32, which should be around a day or
two worth of work and would let you use an n64 kernel.  :)

Juli.
_______________________________________________
freebsd-mips at freebsd.org<mailto:freebsd-mips at freebsd.org> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"<mailto:freebsd-mips-unsubscribe at freebsd.org>