From owner-freebsd-arm@FreeBSD.ORG Wed Jun 11 16:45:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B58B646; Wed, 11 Jun 2014 16:45:59 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA67A2B6B; Wed, 11 Jun 2014 16:45:58 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s5BGfYRb007954; Wed, 11 Jun 2014 11:45:50 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1megfvr7ke-1; Wed, 11 Jun 2014 11:45:49 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 6704E500158; Wed, 11 Jun 2014 11:45:49 -0500 (CDT) Message-ID: <539887BD.2090408@rice.edu> Date: Wed, 11 Jun 2014 11:45:49 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: alc@freebsd.org, "freebsd-arm@freebsd.org" , ian@FreeBSD.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa 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> In-Reply-To: <20140611074159.GL31367@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------090707050109010501090800" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406110209 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:45:59 -0000 This is a multi-part message in MIME format. --------------090707050109010501090800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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... > --------------090707050109010501090800 Content-Type: text/plain; charset=ISO-8859-15; name="arm_pmap_remove_all.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap_remove_all.patch" 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. --------------090707050109010501090800--