Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Nov 2014 01:14:16 +0100
From:      "Ronald Klop" <ronald-lists@klop.ws>
To:        "Konstantin Belousov" <kostikbel@gmail.com>, "Ian Lepore" <ian@freebsd.org>
Cc:        freebsd-fs@freebsd.org, freebsd-arm@freebsd.org
Subject:   Re: panic in nfs on arm
Message-ID:  <op.xpnex2umkndu52@82-171-231-144.ip.telfort.nl>
In-Reply-To: <1414335557.12052.672.camel@revolution.hippie.lan>
References:  <op.xn95m7ajeclrs1@82-171-231-144.ip.telfort.nl> <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> <20141026075720.GO1877@kib.kiev.ua> <1414335557.12052.672.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
------------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 <ian@freebsd.org> 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--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.xpnex2umkndu52>