Date: Wed, 11 Jun 2014 11:45:49 -0500 From: Alan Cox <alc@rice.edu> To: alc@freebsd.org, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, ian@FreeBSD.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <539887BD.2090408@rice.edu> In-Reply-To: <20140611074159.GL31367@funkthat.com> References: <5395D312.5000302@rice.edu> <20140609163302.GS31367@funkthat.com> <5395E725.7020807@rice.edu> <20140609174431.GT31367@funkthat.com> <9100CDFA-0C40-4BC8-AA9C-1DE37EEA6208@rice.edu> <6DA17B5C-1824-49BF-8192-432135D42C6E@bsdimp.com> <20140609221742.GV31367@funkthat.com> <539730B1.2040900@rice.edu> <20140610170052.GF31367@funkthat.com> <5397F089.90403@rice.edu> <20140611074159.GL31367@funkthat.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 06/11/2014 02:41, John-Mark Gurney wrote:
> Alan Cox wrote this message on Wed, Jun 11, 2014 at 01:00 -0500:
>> On 06/10/2014 12:00, John-Mark Gurney wrote:
>>> Alan Cox wrote this message on Tue, Jun 10, 2014 at 11:22 -0500:
>>>> On 06/09/2014 17:17, John-Mark Gurney wrote:
>>>>> Warner Losh wrote this message on Mon, Jun 09, 2014 at 14:08 -0600:
>>>>>> On Jun 9, 2014, at 1:23 PM, Alan Cox <alc@rice.edu> wrote:
>>>>>>
>>>>>>> On Jun 9, 2014, at 12:44 PM, John-Mark Gurney wrote:
>>>>>>>
>>>>>>>> Alan Cox wrote this message on Mon, Jun 09, 2014 at 11:56 -0500:
>>>>>>>>> I made a mistake with the new KASSERT()s in vm_reserv_break(). Try this.
>>>>>>>> No worried, the new patch panics:
>>>>>>>> panic: vm_reserv_break: 2 saved_object=0xc06e6378 x=253 m_tmp->object=0xc06e6378 (1)
>>>>>>>>
>>>>>>> Is your arm processor running in big-endian or little-endian mode?
>>>>>> Big Endian.
>>>>> Specificly, TARGET_ARCH=armeb... So, ARMv4 in big-endian mode...
>>>>>
>>>> Please try the attached patch.
>>> This patch now boots to multiuser mode and I can log in!
>>>
>>> I can now more easily debug newsyslog segfaulting and stuff... I'll
>>> let you know if I have any more issues...
>>>
>>> Thanks again for tracking this down!
>>>
>> Here is a commit-able patch. Please tell me if it works.
> So, it worked for a while, but it looks like there are still lingering
> bugs... Not sure if this is the same, or different...
This is an entirely different problem. It's also a much simpler problem.
A simple workaround patch is attached. Go ahead and commit this patch
yourself if it helps.
> While doing portsnap extract, I got the following panic:
> panic: Lock vm object not exclusively locked @ /usr/src.avila/sys/arm/arm/pmap.c:4474
>
> w/ the bt:
> [lots of boiler plate panic backtrace deleted]
> kassert_panic() at kassert_panic
> pc = 0xc03ac2d4 lr = 0xc03a9980 (__rw_assert+0x168)
> sp = 0xcd157d78 fp = 0x00000000
> r0 = 0xc05e41f8 r1 = 0xc0617ab0
> r2 = 0xc061c818 r3 = 0x0000117a
> r4 = 0x00000000
> __rw_assert() at __rw_assert+0x168
> pc = 0xc03a9980 lr = 0xc05736a4 (pmap_remove_write+0x3c)
> sp = 0xcd157d88 fp = 0x00000000
> r4 = 0xc0845a50
> pmap_remove_write() at pmap_remove_write+0x3c
> pc = 0xc05736a4 lr = 0xc0574890 (pmap_remove_all+0x4c)
> sp = 0xcd157d90 fp = 0x00000000
> r4 = 0xc0845a50
> pmap_remove_all() at pmap_remove_all+0x4c
> pc = 0xc0574890 lr = 0xc055abf8 (vm_pageout_grow_cache+0x8b0)
> sp = 0xcd157dc0 fp = 0x00000000
> r4 = 0xc0845a50 r5 = 0xc184dd20
> r6 = 0xc14b8a9c r7 = 0x00000000
> r8 = 0xc06ea5d0 r9 = 0xc14b89e0
> r10 = 0xc184dd20
> vm_pageout_grow_cache() at vm_pageout_grow_cache+0x8b0
> pc = 0xc055abf8 lr = 0xc055af9c (vm_pageout_grow_cache+0xc54)
> sp = 0xcd157df0 fp = 0x00000000
> r4 = 0xc14b89e0 r5 = 0xc1853320
> r6 = 0xc0618cd8 r7 = 0xc184dd20
> r8 = 0xc14ea320 r9 = 0xc14b89e0
> r10 = 0xc14b89e0
> vm_pageout_grow_cache() at vm_pageout_grow_cache+0xc54
> pc = 0xc055af9c lr = 0xc037fa30 (fork_exit+0x94)
> sp = 0xcd157e48 fp = 0x00000000
> r4 = 0xc0f83960 r5 = 0xc0e58000
> r6 = 0xc055ac9c r7 = 0x00000000
> r8 = 0xcd157e60 r9 = 0x19999990
> r10 = 0x00000000
> fork_exit() at fork_exit+0x94
> pc = 0xc037fa30 lr = 0xc056c4e4 (swi_exit)
> sp = 0xcd157e60 fp = 0x00000000
> r4 = 0xc055ac9c r5 = 0x00000000
> r6 = 0x1284378c r7 = 0x00000104
> r8 = 0x00000104
> swi_exit() at swi_exit
> pc = 0xc056c4e4 lr = 0xc056c4e4 (swi_exit)
> sp = 0xcd157e60 fp = 0x00000000
> Unable to unwind further
>
> Let me know if there is any thing else you need to collect... I've
> rebooted the machine, and I'll be doing the same command to see if
> it's reproducable...
>
[-- Attachment #2 --]
Index: arm/arm/pmap.c
===================================================================
--- arm/arm/pmap.c (revision 267282)
+++ arm/arm/pmap.c (working copy)
@@ -3034,7 +3034,14 @@ pmap_remove_all(vm_page_t m)
if (TAILQ_EMPTY(&m->md.pv_list))
return;
rw_wlock(&pvh_global_lock);
- pmap_remove_write(m);
+
+ /*
+ * XXX This call shouldn't exist. Iterating over the PV list twice,
+ * once in pmap_clearbit() and again below, is both unnecessary and
+ * inefficient. The below code should itself write back the cache
+ * entry before it destroys the mapping.
+ */
+ pmap_clearbit(m, PVF_WRITE);
curpm = vmspace_pmap(curproc->p_vmspace);
while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) {
if (flush == FALSE && (pv->pv_pmap == curpm ||
@@ -3043,7 +3050,7 @@ pmap_remove_all(vm_page_t m)
PMAP_LOCK(pv->pv_pmap);
/*
- * Cached contents were written-back in pmap_remove_write(),
+ * Cached contents were written-back in pmap_clearbit(),
* but we still have to invalidate the cache entry to make
* sure stale data are not retrieved when another page will be
* mapped under this virtual address.
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539887BD.2090408>