From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 00:14:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76E233C3; Fri, 21 Nov 2014 00:14:25 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA0C31C; Fri, 21 Nov 2014 00:14:24 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xrbrd-0005mq-5K; Fri, 21 Nov 2014 01:14:22 +0100 Content-Type: multipart/mixed; boundary=----------JxeXu0Csk7rvM8RhMGHkI1 To: "Konstantin Belousov" , "Ian Lepore" Subject: Re: panic in nfs on arm References: <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> <20141026075720.GO1877@kib.kiev.ua> <1414335557.12052.672.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 01:14:16 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <1414335557.12052.672.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: e919acc199487664c4b881d73fbb3695 Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:14:25 -0000 ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sun, 26 Oct 2014 15:59:17 +0100, Ian Lepore wrote: > On Sun, 2014-10-26 at 09:57 +0200, Konstantin Belousov wrote: >> On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: >> > Ronald Klop wrote: >> > > Hi, >> > > >> > > I got a panic on my arm computer while building a port with >> > > /usr/ports >> > > mounted from my FreeBSD-10-STABLE/amd64 machine. >> > > >> > > This is the machine which paniced: >> > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 >> > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG >> > > arm >> > > >> > > >> > > Tracing pid 90295 tid 100119 td 0xc5f8c960 >> > > db_trace_self() at db_trace_self >> > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) >> > > sp = 0xdf29e5d0 fp = 0xc3e07120 >> > > db_trace_thread() at db_trace_thread+0x50 >> > > pc = 0xc0bb1354 lr = 0xc0936314 (db_command_init+0x5a4) >> > > sp = 0xdf29e630 fp = 0xc3e07120 >> > > db_command_init() at db_command_init+0x5a4 >> > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) >> > > sp = 0xdf29e648 fp = 0xc3e07120 >> > > r4 = 0xc0c8d350 r5 = 0x00000000 >> > > db_skip_to_eol() at db_skip_to_eol+0x484 >> > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) >> > > sp = 0xdf29e6e8 fp = 0xc3e07120 >> > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c >> > > r6 = 0x3cd90e75 r7 = 0x00000000 >> > > r8 = 0x00000001 r10 = 0x600000d3 >> > > db_command_loop() at db_command_loop+0x5c >> > > pc = 0xc0935c38 lr = 0xc0937f80 (X_db_sym_numargs+0xec) >> > > sp = 0xdf29e6f0 fp = 0xc3e07120 >> > > X_db_sym_numargs() at X_db_sym_numargs+0xec >> > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) >> > > sp = 0xdf29e808 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 >> > > kdb_trap() at kdb_trap+0x94 >> > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) >> > > sp = 0xdf29e828 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 r5 = 0x00000001 >> > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 >> > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 >> > > badaddr_read() at badaddr_read+0x274 >> > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) >> > > sp = 0xdf29e840 fp = 0xc3e07120 >> > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 >> > > r6 = 0x3cd90e05 >> > > badaddr_read() at badaddr_read+0x3ac >> > > pc = 0xc0bc1e98 lr = 0xc0bc2278 >> (data_abort_handler+0x10c) >> > > sp = 0xdf29e858 fp = 0xc3e07120 >> > > r4 = 0xc0cd8af8 r5 = 0xffff1004 >> > > data_abort_handler() at data_abort_handler+0x10c >> > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) >> > > sp = 0xdf29e8f8 fp = 0xc3e07120 >> > > r4 = 0xffffffff r5 = 0xffff1004 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d >> > > exception_exit() at exception_exit >> > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) >> > > sp = 0xdf29e948 fp = 0xc3e07120 >> > > r0 = 0xba9b9127 r1 = 0x8b3de5fb >> > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 >> > > r4 = 0x00000000 r5 = 0xc61c1fc8 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d r12 = 0x00000000 >> > > uma_reclaim() at uma_reclaim+0x24c >> > This looks to me like a crash in uma_reclaim() and I find UMA >> > way too obscure to understand. >> > >> > I have no idea if it might be related, but alc@ put a fix for low >> > memory situations in r272071 (or maybe it's r272221?). >> > >> > Might be worth trying a slightly newer kernel to see if the >> > problem still occurs. >> > >> > And hopefully someone more conversant with UMA (or this stack >> > trace) can help more. >> > >> > rick >> > >> > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) >> > > sp = 0xdf29e978 fp = 0xdf29ec10 >> > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 >> > > r6 = 0xc3e07120 r7 = 0x00000000 >> > > r8 = 0x00000102 r9 = 0xdf29ecf8 >> > > r10 = 0xc61c0760 >> > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 >> uma_reclaim() is not called from uma_zalloc(). >> I think there is some issue with ddb on arm, which means that >> the backtrace is not useful. See below for one more. >> > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) >> > > sp = 0xdf29e990 fp = 0xdf29ec10 >> > > r4 = 0x9bb9fa43 r5 = 0x00000000 >> > > r6 = 0xc550dce8 r7 = 0xc3edaa00 >> > > r8 = 0xc3ebbac0 >> > > nfscl_nget() at nfscl_nget+0x308 >> > > pc = 0xc09e1df0 lr = 0xc09da69c (ncl_readlinkrpc+0xf60) >> > > sp = 0xdf29e9d8 fp = 0xdf29ea10 >> > > r4 = 0xc550dce8 r5 = 0x00000000 >> > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 >> > > r8 = 0xdf29ec6c r9 = 0x00000000 >> > > r10 = 0xdf29ed28 >> > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 >> > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) >> > > sp = 0xdf29ec40 fp = 0xbffff620 >> > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c >> > > r6 = 0x00000001 r7 = 0x00020284 >> > > r8 = 0xffffff9c r9 = 0x00200800 >> > > r10 = 0xc5f8c960 >> > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 >> I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), >> esp. without intervening frame. >> > > Notice that the address is actually ncl_readlinkrpc+0xf60, 0xf60 is a > pretty big offset into a function, it's probably in some static function > that follows ncl_readlinkrpc in the source file but the symbol info has > been stripped. Using addr2line on the pc and lr values will give > reliable source line numbers (but I can't do that without Ronald's > kernel config). > > -- Ian Sorry for the late reply and I don't know if it is very interesting (or high prio) still. Attached my kernel config and the diff of my source tree. Ronald. > > > >> > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) >> > > sp = 0xdf29ec50 fp = 0xbffff620 >> > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 >> > > r6 = 0x00000000 >> > > kern_mkdirat() at kern_mkdirat+0x18c >> > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) >> > > sp = 0xdf29ede0 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0xc5f8c960 >> > > r6 = 0x00000000 r7 = 0xc5f7f000 >> > > r8 = 0x00000000 r10 = 0x00013640 >> > > kern_mkdir() at kern_mkdir+0x24 >> > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) >> > > sp = 0xdf29edf0 fp = 0xbffff620 >> > > sys_mkdir() at sys_mkdir+0x1c >> > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) >> > > sp = 0xdf29edf8 fp = 0xbffff620 >> > > swi_handler() at swi_handler+0x254 >> > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0x2085e8e0 >> > > r6 = 0x00020284 r7 = 0x00000088 >> > > r8 = 0x00000001 >> > > swi_exit() at swi_exit >> > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > Unable to unwind further >> > > >> > > >> > > Unfortunately dumping the kernel core also paniced. >> > > db> dump >> > > Physical memory: 507 MB >> > > Dumping 74 MB: 71 67 63 >> > > vm_fault(0xc4147000, 0, 1, 0) -> 0 >> > > Fatal kernel mode data abort: 'Translation Fault (P)' >> > > trapframe: 0xdf29e0b8 >> > > FSR=00000017, FAR=00000014, spsr=a00000d3 >> > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 >> > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c >> > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a >> > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 >> > > >> > > panic: Fatal abort >> > > Uptime: 3d18h30m32s >> > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Disposition: attachment; filename=SHEEVAPLUG Content-Type: application/octet-stream; name=SHEEVAPLUG Content-Transfer-Encoding: Base64 IwojIEN1c3RvbSBrZXJuZWwgZm9yIE1hcnZlbGwgU2hlZXZhUGx1ZyBkZXZpY2Vz LgojCiMgJEZyZWVCU0Q6IGhlYWQvc3lzL2FybS9jb25mL1NIRUVWQVBMVUcgMjYz MzAxIDIwMTQtMDMtMTggMTQ6NDE6MThaIGltcCAkCiMKCmlkZW50CQlTSEVFVkFQ TFVHCmluY2x1ZGUJCSIuLi9tdi9raXJrd29vZC9zdGQuZGI4OGY2eHh4IgoKb3B0 aW9ucyAJU09DX01WX0tJUktXT09ECm1ha2VvcHRpb25zCU1PRFVMRVNfT1ZFUlJJ REU9IiIKCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRo IGdkYigxKSBkZWJ1ZyBzeW1ib2xzCiNvcHRpb25zCQlJTlZBUklBTlRTCiNvcHRp b25zCQlJTlZBUklBTlRfU1VQUE9SVAojb3B0aW9ucwkJV0lUTkVTUwojb3B0aW9u cwkJREVCVUdfTE9DS1MKI29wdGlvbnMJCURFQlVHX1ZGU19MT0NLUwojb3B0aW9u cwkJRElBR05PU1RJQwptYWtlb3B0aW9ucwlXRVJST1I9Ii1XZXJyb3IiCm9wdGlv biBLU1RBQ0tfUEFHRVM9NQpvcHRpb24gQVJNX0RFVklDRV9NVUxUSVBBU1MKCm9w dGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXIKb3B0aW9ucyAJSU5F VAkJCSMgSW50ZXJORVR3b3JraW5nCiNvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBj b21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAJR0VPTV9QQVJUX0JTRAkJ IyBCU0QgcGFydGl0aW9uIHNjaGVtZQpvcHRpb25zIAlHRU9NX1BBUlRfTUJSCQkj IE1CUiBwYXJ0aXRpb24gc2NoZW1lCm9wdGlvbnMgCVRNUEZTCQkJIyBFZmZpY2ll bnQgbWVtb3J5IGZpbGVzeXN0ZW0Kb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBG YXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTkFOREZTCQkJIyBOQU5EIEZpbGVzeXN0 ZW0Kb3B0aW9ucyAJTkZTQ0wJCQkjIE5ldyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xp ZW50Cm9wdGlvbnMgCU5GU0xPQ0tECQkjIE5ldHdvcmsgTG9jayBNYW5hZ2VyCiNv cHRpb25zIAlORlNfUk9PVAkJIyBORlMgdXNhYmxlIGFzIC8sIHJlcXVpcmVzIE5G U0NMCiNvcHRpb25zIAlCT09UUAojb3B0aW9ucyAJQk9PVFBfTkZTUk9PVAojb3B0 aW9ucyAJQk9PVFBfTkZTVjMKI29wdGlvbnMgCUJPT1RQX1dJUkVEX1RPPW1nZTAK IyBBZGRlZCBieSBSb25hbGQKb3B0aW9ucyAJU09GVFVQREFURVMKb3B0aW9ucyAJ TVNET1NGUwpvcHRpb25zIAlJUEZJUkVXQUxMCm9wdGlvbnMgCUlQRklSRVdBTExf REVGQVVMVF9UT19BQ0NFUFQKCiMgUm9vdCBmcyBvbiBVU0IgZGV2aWNlCm9wdGlv bnMgCVJPT1RERVZOQU1FPVwidWZzOi9kZXYvZGEwczFhXCIKI29wdGlvbnMgCVJP T1RERVZOQU1FPVwidWZzOi9kZXYvZGEwczJkXCIKI29wdGlvbnMgCVJPT1RERVZO QU1FPVwibmFuZGZzOi9kZXYvZGEwczJkXCIKI29wdGlvbnMgCVJPT1RERVZOQU1F PVwibmFuZGZzOi9kZXYvZ25hbmQwcy5yb290XCIKCm9wdGlvbnMgCVNZU1ZTSE0J CQkjIFNZU1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJ IyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9wdGlvbnMgCVNZU1ZTRU0JCQkj IFNZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlfS1BPU0lYX1BSSU9SSVRZ X1NDSEVEVUxJTkcgIyBQb3NpeCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9u cwpvcHRpb25zIAlNVVRFWF9OT0lOTElORQpvcHRpb25zIAlSV0xPQ0tfTk9JTkxJ TkUKb3B0aW9ucyAJTk9fRkZTX1NOQVBTSE9UCm9wdGlvbnMgCU5PX1NXQVBQSU5H CgojIERlYnVnZ2luZwpvcHRpb25zIAlBTFRfQlJFQUtfVE9fREVCVUdHRVIKb3B0 aW9ucyAJRERCCm9wdGlvbnMgCUtEQgoKIyBQc2V1ZG8gZGV2aWNlcwpkZXZpY2UJ CXJhbmRvbQpkZXZpY2UJCWxvb3AKZGV2aWNlCQltZAoKIyBTZXJpYWwgcG9ydHMK ZGV2aWNlCQl1YXJ0CgojIE5ldHdvcmtpbmcKZGV2aWNlCQlldGhlcgpkZXZpY2UJ CW1nZQkJCSMgTWFydmVsbCBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xsZXIKZGV2 aWNlCQltaWkKZGV2aWNlCQllMTAwMHBoeQpkZXZpY2UJCWJwZgpvcHRpb25zIAlI Wj0xMDAwCm9wdGlvbnMgCURFVklDRV9QT0xMSU5HCmRldmljZQkJdmxhbgoKZGV2 aWNlCQljZXNhCQkJIyBNYXJ2ZWxsIHNlY3VyaXR5IGVuZ2luZQpkZXZpY2UJCWNy eXB0bwpkZXZpY2UJCWNyeXB0b2RldgoKIyBVU0IKb3B0aW9ucyAJVVNCX0RFQlVH CQkjIGVuYWJsZSBkZWJ1ZyBtc2dzCmRldmljZQkJdXNiCmRldmljZQkJZWhjaQpk ZXZpY2UJCXVtYXNzCmRldmljZQkJc2NidXMKZGV2aWNlCQlwYXNzCmRldmljZQkJ ZGEKCiMgTkFORApkZXZpY2UJCW5hbmQKCiNkZXZpY2UgCQltbWMKI2RldmljZSAJ CW1tY3NkCiNkZXZpY2UgCQlzZGhjaQoKIyBGbGF0dGVuZWQgRGV2aWNlIFRyZWUK b3B0aW9ucyAJRkRUCm9wdGlvbnMgCUZEVF9EVEJfU1RBVElDCm1ha2VvcHRpb25z CUZEVF9EVFNfRklMRT1zaGVldmFwbHVnLmR0cwo= ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Disposition: attachment; filename=svn.diff.txt Content-Type: text/plain; name=svn.diff.txt Content-Transfer-Encoding: 7bit Index: sys/arm/conf/SHEEVAPLUG =================================================================== --- sys/arm/conf/SHEEVAPLUG (revision 273634) +++ sys/arm/conf/SHEEVAPLUG (working copy) @@ -10,12 +10,20 @@ options SOC_MV_KIRKWOOD makeoptions MODULES_OVERRIDE="" -#makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols +makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols +#options INVARIANTS +#options INVARIANT_SUPPORT +#options WITNESS +#options DEBUG_LOCKS +#options DEBUG_VFS_LOCKS +#options DIAGNOSTIC makeoptions WERROR="-Werror" +option KSTACK_PAGES=5 +option ARM_DEVICE_MULTIPASS options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking -options INET6 # IPv6 communications protocols +#options INET6 # IPv6 communications protocols options GEOM_PART_BSD # BSD partition scheme options GEOM_PART_MBR # MBR partition scheme options TMPFS # Efficient memory filesystem @@ -23,14 +31,22 @@ options NANDFS # NAND Filesystem options NFSCL # New Network Filesystem Client options NFSLOCKD # Network Lock Manager -options NFS_ROOT # NFS usable as /, requires NFSCL -options BOOTP -options BOOTP_NFSROOT -options BOOTP_NFSV3 -options BOOTP_WIRED_TO=mge0 +#options NFS_ROOT # NFS usable as /, requires NFSCL +#options BOOTP +#options BOOTP_NFSROOT +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=mge0 +# Added by Ronald +options SOFTUPDATES +options MSDOSFS +options IPFIREWALL +options IPFIREWALL_DEFAULT_TO_ACCEPT # Root fs on USB device -#options ROOTDEVNAME=\"ufs:/dev/da0a\" +options ROOTDEVNAME=\"ufs:/dev/da0s1a\" +#options ROOTDEVNAME=\"ufs:/dev/da0s2d\" +#options ROOTDEVNAME=\"nandfs:/dev/da0s2d\" +#options ROOTDEVNAME=\"nandfs:/dev/gnand0s.root\" options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues @@ -49,6 +65,7 @@ # Pseudo devices device random device loop +device md # Serial ports device uart @@ -79,6 +96,10 @@ # NAND device nand +#device mmc +#device mmcsd +#device sdhci + # Flattened Device Tree options FDT options FDT_DTB_STATIC Index: sys/boot/fdt/dts/arm/sheevaplug.dts =================================================================== --- sys/boot/fdt/dts/arm/sheevaplug.dts (revision 273634) +++ sys/boot/fdt/dts/arm/sheevaplug.dts (working copy) @@ -95,7 +95,12 @@ }; slice@200000 { - reg = <0x200000 0x1fe00000>; + reg = <0x200000 0x600000>; + label = "fbsd-boot"; + }; + + slice@800000 { + reg = <0x800000 0x1f800000>; label = "root"; }; }; ------------JxeXu0Csk7rvM8RhMGHkI1--