From owner-freebsd-mips@FreeBSD.ORG Fri Sep 3 15:32:26 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8D21065867 for ; Fri, 3 Sep 2010 15:32:25 +0000 (UTC) (envelope-from PHeyman@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CC8D28FC08 for ; Fri, 3 Sep 2010 15:32:25 +0000 (UTC) X-ASG-Debug-ID: 1283527037-5061bcf80001-1gY7mK Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id 9gF2sJ4uQpEaIKhK; Fri, 03 Sep 2010 08:17:17 -0700 (PDT) X-Barracuda-Envelope-From: PHeyman@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Fri, 3 Sep 2010 08:17:17 -0700 From: Paul Heyman X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: "jmallett@FreeBSD.org" , Patrick Mahan Date: Fri, 3 Sep 2010 08:17:16 -0700 X-ASG-Orig-Subj: RE: Re: Now partially booting on our CN58XX eval board Thread-Topic: Re: Now partially booting on our CN58XX eval board Thread-Index: ActLdII+EePiKSS2TsWePfTLUJgQvwAADo6k Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C8C5A64@SJ-EXCH-1.adaranet.com> References: <4C81066B.9040902@multi-media-tech.com> In-Reply-To: <4C81066B.9040902@multi-media-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1283527037 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: "freebsd-mips@freebsd.org" Subject: RE: Re: Now partially booting on our CN58XX eval board X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 15:32:26 -0000 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 To: Patrick Mahan CC: freebsd-mips@freebsd.org On Fri, Aug 27, 2010 at 11:16, Patrick Mahan 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 mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mips To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"