From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 29 14:53:29 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 910781065694 for ; Tue, 29 Sep 2009 14:53:29 +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 3FC768FC24 for ; Tue, 29 Sep 2009 14:53:29 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id EEC86489B3; Tue, 29 Sep 2009 15:53:27 +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 9GyjLu3s35SY; Tue, 29 Sep 2009 15:53:17 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 1B68F489AE; Tue, 29 Sep 2009 15:53:16 +0100 (BST) Message-ID: <4AC21F44.6060004@tomjudge.com> Date: Tue, 29 Sep 2009 14:52:52 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Olivier Houchard References: <4AC106AA.9000305@tomjudge.com> <20090928202132.GA15236@ci0.org> <4AC16B5A.8090407@tomjudge.com> <20090929093825.GA26424@ci0.org> In-Reply-To: <20090929093825.GA26424@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.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 14:53:29 -0000 Olivier Houchard wrote: > On Tue, Sep 29, 2009 at 02:05:14AM +0000, Tom Judge wrote: > >> Hi Olivier, >> >> I have switched out the std file and am now using std.i80219 but am >> still having issues. >> >> I think the problems are the pci memory mappings in the controller devices. >> >> On linux em0 gets mapped as follows: >> >> cd 0000\:00\:01.0/ >> # ls >> class device local_cpus subsystem_device >> config driver resource subsystem_vendor >> detach_state irq rom vendor >> # cat resource >> 0x0000000080000000 0x000000008001ffff 0x0000000000000200 >> 0x0000000080020000 0x000000008003ffff 0x0000000000000200 >> 0x00000000fe000000 0x00000000fe00003f 0x0000000000000101 >> 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000000000000 0x0000000000000000 0x0000000000000000 >> 0x0000000080040000 0x000000008005ffff 0x0000000000007200 >> # >> >> >> >> Where as on FreeBSD I am seeing this: >> em0: port >> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device 1.0 >> on pci0 >> >> Seems that I am missing the 0x800 off the front of the PCI memory mappings. >> >> > > Ok I'm a bit confused about this code, it's been too long since I haven't > read it :) > Could you try the attached patch ? > > Thanks ! > > If it doesn't help, you can print adapter->osdep.mem_bus_space_handle in > if_em.c to make sure it is the same as in linux. > > Hi Olivier, I have tried the patch and here are the boot results: 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 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: 0xc00faad0 FSR=00000406, FAR=Invalid, spsr=200000d3 r0 =c00d0400, r1 =cd5bf000, r2 =00000010, r3 =0000000a r4 =c317e008, r5 =cd5bf000, r6 =c00d0400, r7 =c130212c r8 =c317e008, r9 =c0071180, r10=c317e000, r11=c00fab40 r12=c00fab44, ssp=c00fab1c, slr=c106a96c, pc =c106a968 [thread pid 0 tid 100000 ] Stopped at e1000_init_script_state_82541+0x24c: blx r7 db> As you can see I added some debug to if_em.c as such: Index: sys/dev/e1000/if_em.c =================================================================== --- sys/dev/e1000/if_em.c (revision 197472) +++ sys/dev/e1000/if_em.c (working copy) @@ -2770,6 +2770,9 @@ rman_get_bustag(adapter->memory); adapter->osdep.mem_bus_space_handle = rman_get_bushandle(adapter->memory); + device_printf(dev,"Start: 0x%08lX\n", rman_get_start(adapter->memory)); + device_printf(dev,"End: 0x%08lX\n", rman_get_end(adapter->memory)); + device_printf(dev,"Size: 0x%08lX\n", rman_get_size(adapter->memory)); adapter->hw.hw_addr = (u8 *)&adapter->osdep.mem_bus_space_handle; /* Only older adapters use IO mapping */ But the memory mapping seems to be missing the most significant 0x8. Thanks Tom