svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa

[Alan Cox]

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 at 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...
>

-------------- next part --------------
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.