Date: Wed, 23 Dec 2015 11:45:26 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Bartosz Szczepanek <bsz@semihalf.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Marcin Wojtas <mw@semihalf.com> Subject: Re: Translation Fault (L1) while using pmap-v6-new Message-ID: <CAFHCsPVrAhbNmfLMEG5bg9MZpdCXV689VU6hw8rCGRgGdJej5Q@mail.gmail.com> In-Reply-To: <CABLO=%2BkGzcnOLJ=_X8EfNw-YcBL%2BOFhf9G8YQb5RRasNLH9C_Q@mail.gmail.com> References: <CABLO=%2BkGzcnOLJ=_X8EfNw-YcBL%2BOFhf9G8YQb5RRasNLH9C_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 22, 2015 at 4:23 PM, Bartosz Szczepanek <bsz@semihalf.com> wrote: > Hello, > > currently I'm working on support for Armada38x on FreeBSD-CURRENT > (patchset was submitted to Phabricator - > https://reviews.freebsd.org/D4210). After switching to ARM_NEW_PMAP > problems related with PCIe subsystem emerged, even though that worked > fine on FreeBSD-10.2. > > My setup consists of Marvell Armada38x GP development board equipped > with Cortex-A9, PCIe controller serviced by arm/mv/mv_pci.c driver and > RealTek GE PCI card (re driver). Enabling ARM_NEW_PMAP leads to > 'Translation Fault (L1)' on write: > >> Starting Network: lo0 re0. >> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> >> re0: flags=8802<FataBROADCAST,SIMPLEl keX,MULTICAST> metrnelric 0 mtu 1500 >> mod options=8209b<Re daXCSUM,TXCSUM,VLAta > aN_MTU,VLAN_HWTAGbortGING,VLAN_HWCSUM: 'T,WOL_MAGIC,LINKSransTATE> >> on F ether 64lati:70:02:10:f7:20 >> ault (L1)' on write >> trapframe: 0xefe78b40 >> FSR=00000805, FAR=80000060, spsr=60000013 >> r0 =c0e796c0, r1 =80000000, r2 =00000004, r3 =00010000 >> r4 =c57f1000, r5 =c57f1000, r6 =00000000, r7 =00000001 >> r8 =c0e47e8c, r9 =c5be3780, r10=c57efb00, r11=efe78be0 >> r12=efe78d43, ssp=efe78bd0, slr=c0971ef4, pc =c0971f64 >> [ thread pid 241 tid 100068 ] >> Stopped at re_gmii_readreg+0x50: str r3, [r1, #0x060] >> db> > > (re_gmii_readreg is function in re driver, I made it non-static so it > is visible in debugger) > Address it crashes on lies in the PCI devices' memory range, and it > was accessed successfully several times during boot proccess before > crash (I put printfs in the exact function where fault occurs). So it > seems just like the memory mapping has disappeared at some point. I > put kdb_enter in re attach function (long before translation fault), > from that point I see that 0x80000000 mapping exists: > >> pcib0: <Marvell Integrated PCI/PCI-E Controller> mem 0xf1080000-0xf1081fff irq 1 on ofwbus0 >> [ thread pid 0 tid 100000 ] >> Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! >> db> show pmap >> pmap: 0xC0EAC544 >> PT2MAP: 0xBFC00000 >> pt2tab: 0xC0F04000 >> 0x80000000: Section 0x8001041A, s:1 g:1 >> 0x80100000: Section 0x8011041A, s:1 g:1 >> 0x80200000: Section 0x8021041A, s:1 g:1 >> 0x80300000: Section 0x8031041A, s:1 g:1 >> ... According to the show pmap output, there is a global mapping (g:1) on many addresses which are not from KVA (as Michal has already written). KVA starts at 0xC0000000 and global mapping outside of KVA space is not allowed. Thus,probably some malicious driver is doing bad mapping. Maybe it's just coincidence, but 0x80000060 looks like physical address of re(4) memory resource? > > Doing 'show pmap' after crash gives me long, long log without > 0x80000000 occuring. On the other hand, adding vtophys(0x80000060) > line before affected write operation translates address correctly. It > is visible in log attached. > > I've also tried to track various functions removing mapping in > pmap-v6-new, but with no luck. However, problem seems to lie there, as > system boots fine without ARM_NEW_PMAP option. I would be grateful for > you advice - what else can I do to investigate the issue? > > Best regards, > Bartosz Szczepanek
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPVrAhbNmfLMEG5bg9MZpdCXV689VU6hw8rCGRgGdJej5Q>