From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 29 19:39:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9151065698 for ; Tue, 29 Sep 2009 19:39:33 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF608FC0A for ; Tue, 29 Sep 2009 19:39:32 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id DD1EC489B8; Tue, 29 Sep 2009 20:39:31 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4Ezw+uNgHjS; Tue, 29 Sep 2009 20:39:19 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 9F074489B6; Tue, 29 Sep 2009 20:39:18 +0100 (BST) Message-ID: <4AC2624D.30200@tomjudge.com> Date: Tue, 29 Sep 2009 19:38:53 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Mark Tinguely References: <200909291908.n8TJ8UA2042239@casselton.net> In-Reply-To: <200909291908.n8TJ8UA2042239@casselton.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, mlfbsd@kanar.ci0.org Subject: Re: Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 19:39:33 -0000 Mark Tinguely wrote: > I don't know anything about the code other than what I read today ... > > It appears from you boot traces the owin[0].owin_xlate_[lo | hi] values > should be fine in iq80321.c - an "VERBOSE_INIT_ARM" would confirm it. > > You might want to test if the "sc" pointer in iq80321.c has the same value > as the global "i80321_softc" pointer. You can add those print statements > to an "VERBOSE_INIT_ARM". It will tell you if something changed the global > pointer or if something overwrote the owin values in the structure. > > If global pointer or owin was changed before the pci attach code, you > can put the appropriate test into the earlier (obio, uart, itimer, iopwdtimer) > attach. None of these attaches use the global "i80321_softc" pointer. > > --Mark. > Hi Mark, Here is the log of a verbose_init_arm with added debug for owin[0].owin_xlate_[lo|hi]: RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #30: Tue Sep 29 19:02:49 UTC 2009 root@rita.nodomain:/data/arm_build/arm/usr/src/sys/EM-7210 CPU: i80219 400MHz step A-0 (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 536870912 (512 MB) avail memory = 503738368 (480 MB) iq0: on motherboard i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000 i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000 i80219: I/O Processor, acting as PCI host i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020 i80321: BANK0 = 0x10000000 BANK1 = 0x10000000 i80321: Reserve space for private devices (Inbound Window 1) hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000 i80321: RAM access (Inbound Window 2) hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000 i80321: Reserve space for private devices (Outbound Window 1) xlate_hi:0x00000000 xlate_lo:0x80000000 obio0 on iq0 uart0: <16550 or compatible> on obio0 uart0: [FILTER] uart0: console (115200,n,8,1) itimer0: on iq0 iopwdog0: on iq0 pcib0: on iq0 pci0: on pcib0 Device 1 routed to irq 27 Device 2 routed to irq 30 Device 3 routed to irq 29 Device 5 routed to irq 30 Device 5 routed to irq 29 Device 5 routed to irq 27 em0: port 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 27 at device 1.0 on pci0 em0: Start: 0x00000000 em0: End: 0x0001FFFF em0: Size: 0x00020000 Fatal kernel mode data abort: 'External Linefetch Abort (P)' trapframe: 0xc00faae0 FSR=00000406, FAR=Invalid, spsr=200000d3 r0 =c00d0400, r1 =cd5bf000, r2 =00000010, r3 =0000000a r4 =c317e008, r5 =cd5bf000, r6 =c00d0400, r7 =c1302070 r8 =c317e008, r9 =c0071180, r10=c317e000, r11=c00fab50 r12=c00fab54, ssp=c00fab2c, slr=c106a96c, pc =c106a968 [thread pid 0 tid 100000 ] Stopped at e1000_init_script_state_82541+0x24c: blx r7 db> The only places i can see owin used is in i80321.c and iq80312.c and they only written to in i80312.c if the controller is a slave not a host: if (!sc->sc_is_host) { sc->sc_owin[0].owin_xlate_lo = sc->sc_iwin[1].iwin_base_lo; sc->sc_owin[0].owin_xlate_hi = sc->sc_iwin[1].iwin_base_hi; } I will see if I can compare the global softc with the ones returned by the get function. Thanks Tom