Date: Fri, 3 Sep 2010 08:17:16 -0700 From: Paul Heyman <PHeyman@adaranet.com> To: "jmallett@FreeBSD.org" <jmallett@FreeBSD.org>, Patrick Mahan <PMahan@adaranet.com> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: RE: Re: Now partially booting on our CN58XX eval board Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C8C5A64@SJ-EXCH-1.adaranet.com> In-Reply-To: <4C81066B.9040902@multi-media-tech.com> References: <4C81066B.9040902@multi-media-tech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Juli
Thanks for the pointer regarding limiting the bootmem to 512M. I modified w=
hat 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 ethern=
et-rx.c.
1. At line 293 . it looks like the entire packet is stored in the work entr=
y. 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@-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@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@FreeBSD.org><mailto:jmallett@FreeBSD.org>
To: Patrick Mahan <pmahan@adaranet.com><mailto:pmahan@adaranet.com>
CC: freebsd-mips@freebsd.org<mailto:freebsd-mips@freebsd.org> <freebsd-=
mips@freebsd.org><mailto:freebsd-mips@freebsd.org>
On Fri, Aug 27, 2010 at 11:16, Patrick Mahan <pmahan@adaranet.com><mailto:p=
mahan@adaranet.com> wrote:
> I have an engineer that thinks this would be fun to resolve, so I am lett=
ing
> 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@freebsd.org<mailto:freebsd-mips@freebsd.org> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mips
To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"<mai=
lto:freebsd-mips-unsubscribe@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32AB5C9615CC494997D9ABB1DB12783C024C8C5A64>