From owner-freebsd-hackers@freebsd.org Sat Dec 19 21:02:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99FCBA4DE29 for ; Sat, 19 Dec 2015 21:02:20 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86C4211CB; Sat, 19 Dec 2015 21:02:20 +0000 (UTC) (envelope-from rpaulo@me.com) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from akita.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0NZM00GTWIFPIS00@mr11p00im-asmtp004.me.com>; Sat, 19 Dec 2015 21:02:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-19_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1512190388 Message-id: <1450558933.2348.11.camel@me.com> Subject: Re: boot1.efi and ConsoleControl on HP 840G1/G2 From: Rui Paulo To: John Baldwin , freebsd-hackers@freebsd.org Cc: Emmanuel Vadot , 'Ed Maste' , Rui Paulo Date: Sat, 19 Dec 2015 13:02:13 -0800 In-reply-to: <2690526.ic7VAp0tDr@ralph.baldwin.cx> References: <20151119120945.71d0cb068006398d3a556559@bidouilliste.com> <20151119141026.c1c859703fc5fcc09d18d9b5@bidouilliste.com> <2690526.ic7VAp0tDr@ralph.baldwin.cx> X-Mailer: Evolution 3.18.2-1 X-Mailman-Approved-At: Sun, 20 Dec 2015 02:47:32 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 21:02:20 -0000 On Fri, 2015-12-18 at 14:44 -0800, John Baldwin wrote: > On Thursday, November 19, 2015 02:10:26 PM Emmanuel Vadot wrote: > > On Thu, 19 Nov 2015 12:09:45 +0100 > > Emmanuel Vadot wrote: > > > > > > > >  Hello Hackers, > > > > > >  After hours I've found why I couldn't use properly FreeBSD on my > > > HP 840G1/G2 laptop. > > > > > >  What is happening right now with -current is that the kernel > > > framebuffer is garbage (https://www.bidouilliste.com/images/efi/I > > > MG_2650.JPG). > > >  The problem is that boot1.efi calls ConsoleControl which, from > > > my findings, is not in the UEFI specs but was only in the EDK > > > implementation. > > >  This should not be a problem as LocateProtocol should return != > > > EFI_SUCCESS but on my laptops (and probably others) this is not > > > the case. > > > > > >  After removing the ConsoleControl related lines and recompiling > > > boot1.efi I can now boot FreeBSD. > > > > > >  I'm pretty sure that this would not be a problem on other > > > machine (with the patch I can still boot correctly FreeBSD on my > > > Samsung 870Z laptop) but I would prefer that other people test > > > it. > > > > > >  I've opened a bug on bugzilla (https://bugs.freebsd.org/bugzilla > > > /show_bug.cgi?id=204674) if some people want to try the patch. > > > > > >  Cheers, > > > > > > >  Replying to myself cause I've found other stuff. > > > >  I looked at GRUB sources and it do what boot1.efi do (use > > ConsoleControl to set the Console to text mode, > > grub_efi_set_text_mode in grub-core/kern/efi/efi.c). > >  The only difference that I can see between how GRUB handle the EFI > > console and boot1 is that grub never Reset the Console nor change > > the current text mode (grub-core/term/efi/console.c). > >  So I patched again boot1.efi leaving the ConsoleControl stuff on > > but commented the Reset and the SetMode stuff, and this worked. > > > >  This is the screen when the console is Reset : https://www.bidouil > > liste.com/images/efi/IMG_2649.JPG > >  This is the screen when the console is not reseted : https://www.b > > idouilliste.com/images/efi/IMG_2651.JPG > > > >  From loader(8) with the current boot1.efi, if I type gop list I > > got 4 modes but all of them are 1920x1280. > >  If I gop set X and gop set 0 (1920x1280) (Or via loader.rc), when > > the kernel start the framebuffer data is correct. > > > >  From loader(8) with the patched boot1.efi, if I type gop list I > > got the 4 correct modes. > > Hmm, Rui added the console reset in r281059.  It sounds like you need > to > revert the changes made there?  Does it work if you leave the reset > and disable > the SetMode() bits? At least we need to find a way to reset certain consoles.  My changes were intended to reset the console and use the best available mode which worked on my laptop and got rid of the Lenovo logo that was stuck during boot1+loader. -- Rui Paulo From owner-freebsd-hackers@freebsd.org Mon Dec 21 05:45:21 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCDF8A4E4C7 for ; Mon, 21 Dec 2015 05:45:21 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBCC1638 for ; Mon, 21 Dec 2015 05:45:21 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id tBL5jFqO067198 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 20 Dec 2015 21:45:15 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com To: Freebsd hackers list From: Yuri Subject: Should DEBUG_VFS_LOCKS messages be reported as bugs? Message-ID: <567791E9.50207@rawbw.com> Date: Sun, 20 Dec 2015 21:45:13 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 05:45:21 -0000 With these debugging options in kernel: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_VFS_LOCKS options DEBUG_MEMGUARD it prints some messages that look like errors, see below. Are these generally worth reporting as bugs? 10.2-STABLE r292527 Yuri ----begin messages---- Dec 20 21:15:00 yuri kernel: lock order reversal: Dec 20 21:15:00 yuri kernel: 1st 0xfffffe0da86d5920 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3130 Dec 20 21:15:00 yuri kernel: 2nd 0xfffff801706a1a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:280 Dec 20 21:15:00 yuri kernel: KDB: stack backtrace: Dec 20 21:15:00 yuri kernel: #0 0xffffffff8097c330 at kdb_backtrace+0x60 Dec 20 21:15:00 yuri kernel: #1 0xffffffff80996ed4 at witness_checkorder+0xe24 Dec 20 21:15:00 yuri kernel: #2 0xffffffff809490d5 at _sx_xlock+0x75 Dec 20 21:15:00 yuri kernel: #3 0xffffffff80bac9da at ufsdirhash_add+0x4a Dec 20 21:15:00 yuri kernel: #4 0xffffffff80baf8f0 at ufs_direnter+0x6a0 Dec 20 21:15:00 yuri kernel: #5 0xffffffff80bb8945 at ufs_makeinode+0x575 Dec 20 21:15:00 yuri kernel: #6 0xffffffff80bb47dd at ufs_create+0x2d Dec 20 21:15:00 yuri kernel: #7 0xffffffff80e7744f at VOP_CREATE_APV+0x10f Dec 20 21:15:00 yuri kernel: #8 0xffffffff809faea3 at vn_open_cred+0x2c3 Dec 20 21:15:00 yuri kernel: #9 0xffffffff809f456f at kern_openat+0x26f Dec 20 21:15:00 yuri kernel: #10 0xffffffff80d4fb04 at amd64_syscall+0x2c4 Dec 20 21:15:00 yuri kernel: #11 0xffffffff80d3354b at Xfast_syscall+0xfb Dec 20 21:18:39 yuri kernel: insmntque: non-locked vp: 0xfffff80170fe0588 is not exclusive locked but should be Dec 20 21:18:39 yuri kernel: KDB: stack backtrace: Dec 20 21:18:39 yuri kernel: #0 0xffffffff8097c330 at kdb_backtrace+0x60 Dec 20 21:18:39 yuri kernel: #1 0xffffffff809ea99e at assert_vop_elocked+0x6e Dec 20 21:18:39 yuri kernel: #2 0xffffffff809ea1d1 at insmntque1+0x41 Dec 20 21:18:39 yuri kernel: #3 0xffffffff82e272a1 at unionfs_nodeget+0x281 Dec 20 21:18:39 yuri kernel: #4 0xffffffff82e2ab06 at unionfs_lookup+0x726 Dec 20 21:18:39 yuri kernel: #5 0xffffffff80e7728f at VOP_CACHEDLOOKUP_APV+0x10f Dec 20 21:18:39 yuri kernel: #6 0xffffffff809d8dd6 at vfs_cache_lookup+0xd6 Dec 20 21:18:39 yuri kernel: #7 0xffffffff80e770cf at VOP_LOOKUP_APV+0x10f Dec 20 21:18:39 yuri kernel: #8 0xffffffff809e13b2 at lookup+0x5c2 Dec 20 21:18:39 yuri kernel: #9 0xffffffff809e0ad4 at namei+0x4e4 Dec 20 21:18:39 yuri kernel: #10 0xffffffff809f635e at kern_statat_vnhook+0xae Dec 20 21:18:39 yuri kernel: #11 0xffffffff809f64f0 at sys_lstat+0x30 Dec 20 21:18:39 yuri kernel: #12 0xffffffff80d4fb04 at amd64_syscall+0x2c4 Dec 20 21:18:39 yuri kernel: #13 0xffffffff80d3354b at Xfast_syscall+0xfb Dec 20 21:34:39 yuri kernel: insmntque: non-locked vp: 0xfffff805c74793b0 is not exclusive locked but should be Dec 20 21:34:39 yuri kernel: KDB: stack backtrace: Dec 20 21:34:39 yuri kernel: #13 0xffffffff80d3354b at Xfast_syscall+0xfb Dec 20 21:34:39 yuri kernel: insmntque: non-locked vp: 0xfffff805c75221d8 is not exclusive locked but should be Dec 20 21:34:39 yuri kernel: KDB: stack backtrace: Dec 20 21:34:39 yuri kernel: #1 0xffffffff809ea99e at assert_vop_elocked+0x6e Dec 20 21:34:39 yuri kernel: #1 0xffffffff809ea99e at assert_vop_elocked+0x6e Dec 20 21:34:39 yuri kernel: #0 0xffffffff8097c330 at kdb_backtrace+0x60 Dec 20 21:34:39 yuri kernel: #0 0xffffffff8097c330 at kdb_backtrace+0x60 Dec 20 21:34:39 yuri kernel: #2 0xffffffff809ea1d1 at insmntque1+0x41 Dec 20 21:34:39 yuri kernel: #2 0xffffffff809ea1d1 at insmntque1+0x41 Dec 20 21:34:39 yuri kernel: #1 0xffffffff809ea99e at assert_vop_elocked+0x6e Dec 20 21:34:39 yuri kernel: #1 0xffffffff809ea99e at assert_vop_elocked+0x6e Dec 20 21:34:39 yuri kernel: #3 0xffffffff82e272a1 at unionfs_nodeget+0x281 Dec 20 21:34:39 yuri kernel: #3 0xffffffff82e272a1 at unionfs_nodeget+0x281 Dec 20 21:34:39 yuri kernel: #2 0xffffffff809ea1d1 at insmntque1+0x41 Dec 20 21:34:39 yuri kernel: #4 0xffffffff82e2ab06 at unionfs_lookup+0x726 Dec 20 21:34:39 yuri kernel: #2 0xffffffff809ea1d1 at insmntque1+0x41 Dec 20 21:34:39 yuri kernel: #4 0xffffffff82e2ab06 at unionfs_lookup+0x726 Dec 20 21:34:39 yuri kernel: #3 0xffffffff82e272a1 at unionfs_nodeget+0x281 Dec 20 21:34:39 yuri kernel: #3 0xffffffff82e272a1 at unionfs_nodeget+0x281 Dec 20 21:34:39 yuri kernel: #5 0xffffffff80e7728f at VOP_CACHEDLOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #5 0xffffffff80e7728f at VOP_CACHEDLOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #4 0xffffffff82e2ab06 at unionfs_lookup+0x726 Dec 20 21:34:39 yuri kernel: #4 0xffffffff82e2ab06 at unionfs_lookup+0x726 Dec 20 21:34:39 yuri kernel: #6 0xffffffff809d8dd6 at vfs_cache_lookup+0xd6 Dec 20 21:34:39 yuri kernel: #6 0xffffffff809d8dd6 at vfs_cache_lookup+0xd6 Dec 20 21:34:39 yuri kernel: #5 0xffffffff80e7728f at VOP_CACHEDLOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #5 0xffffffff80e7728f at VOP_CACHEDLOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #7 0xffffffff80e770cf at VOP_LOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #7 0xffffffff80e770cf at VOP_LOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #6 0xffffffff809d8dd6 at vfs_cache_lookup+0xd6 Dec 20 21:34:39 yuri kernel: #6 0xffffffff809d8dd6 at vfs_cache_lookup+0xd6 Dec 20 21:34:39 yuri kernel: #8 0xffffffff809e13b2 at lookup+0x5c2 Dec 20 21:34:39 yuri kernel: #8 0xffffffff809e13b2 at lookup+0x5c2 Dec 20 21:34:39 yuri kernel: #7 0xffffffff80e770cf at VOP_LOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #7 0xffffffff80e770cf at VOP_LOOKUP_APV+0x10f Dec 20 21:34:39 yuri kernel: #9 0xffffffff809e0ad4 at namei+0x4e4 Dec 20 21:34:39 yuri kernel: #9 0xffffffff809e0ad4 at namei+0x4e4 Dec 20 21:34:39 yuri kernel: #8 0xffffffff809e13b2 at lookup+0x5c2 Dec 20 21:34:39 yuri kernel: #8 0xffffffff809e13b2 at lookup+0x5c2 ----end messages---- From owner-freebsd-hackers@freebsd.org Mon Dec 21 05:59:31 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF50A4EB32 for ; Mon, 21 Dec 2015 05:59:31 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE7C41C66 for ; Mon, 21 Dec 2015 05:59:31 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id tBL5xVau067783 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 20 Dec 2015 21:59:31 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? To: Freebsd hackers list References: <567791E9.50207@rawbw.com> From: Yuri Message-ID: <56779542.8020205@rawbw.com> Date: Sun, 20 Dec 2015 21:59:30 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <567791E9.50207@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 05:59:31 -0000 On 12/20/2015 21:45, Yuri wrote: > > it prints some messages that look like errors, see below. I have recently began mounting /usr/ports as nullfs and unionfs on top of it, and I believe this causes the system crashes during the intense file activity on the unionfs-ed /usr/ports. /usr/ports.patches on /usr/ports (nullfs, local, read-only) :/usr/ports.subversion on /usr/ports (unionfs, local, noatime) The messages I reported are related to this. Yuri From owner-freebsd-hackers@freebsd.org Mon Dec 21 14:09:01 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB2CFA4EC2A for ; Mon, 21 Dec 2015 14:09:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0771435 for ; Mon, 21 Dec 2015 14:09:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:XY32IRZ+i1QcOXjLlrvH2jX/LSx+4OfEezUN459isYplN5qZpcm8bnLW6fgltlLVR4KTs6sC0LqI9fi4EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35rxj7j60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYCgJ45jaqAPCBV+e+2Eden8fjRBXRQPC6UepcI32t37At+F+kAyTNs7yQLV8DS6n5qxoTBLtoDoAOCM09HnXzMd52vEI6Cm9rgByltaHKLqeM+BzK+aEJYsX X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBABRB3hW/61jaINdhAxzjEyzEYYNAoFiEAEBAQEBAQEBgQmCLYIIAQUjKyALBQsCAQgYAgINHTEmAgQIKASIDqwqhlQBAQkCDAIBAYtmBIEBhVWEfoQkFwEBhQMFji6IUoU7iWyHbYVziXyDcgI5K4QiIIQeOoEIAQEB X-IronPort-AV: E=Sophos;i="5.20,459,1444708800"; d="scan'208";a="259142556" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 21 Dec 2015 09:06:45 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E3EF515F56D; Mon, 21 Dec 2015 09:06:45 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RusPQ9MY7ud7; Mon, 21 Dec 2015 09:06:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 8997115F565; Mon, 21 Dec 2015 09:06:45 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V2j205jbeLqP; Mon, 21 Dec 2015 09:06:45 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 7101615F55D; Mon, 21 Dec 2015 09:06:45 -0500 (EST) Date: Mon, 21 Dec 2015 09:06:45 -0500 (EST) From: Rick Macklem To: Yuri Cc: Freebsd hackers list Message-ID: <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <56779542.8020205@rawbw.com> References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: Should DEBUG_VFS_LOCKS messages be reported as bugs? Thread-Index: 32BZrIGI9+9y/vRNnOF3RG9lXyApSg== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 14:09:01 -0000 Yuri wrote: > On 12/20/2015 21:45, Yuri wrote: > > > > it prints some messages that look like errors, see below. > > I have recently began mounting /usr/ports as nullfs and unionfs on top > of it, and I believe this causes the system crashes during the intense > file activity on the unionfs-ed /usr/ports. > /usr/ports.patches on /usr/ports (nullfs, local, read-only) > :/usr/ports.subversion on /usr/ports (unionfs, local, noatime) > Unionfs is broken. See the BUGS section of "man mount_unionfs". Here a snippet from it: THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. As such, reports for problems that you encounter when not using unionfs are far more useful, imho. rick > The messages I reported are related to this. > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Dec 21 19:49:30 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83E76A4F493 for ; Mon, 21 Dec 2015 19:49:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 662F71347; Mon, 21 Dec 2015 19:49:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2EDCFB979; Mon, 21 Dec 2015 14:49:29 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Bertram Scharpf , emaste@freebsd.org Subject: Re: lldb crashes hello.c Date: Mon, 21 Dec 2015 11:11:06 -0800 Message-ID: <1822063.F241qPFAvS@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20151218190616.GA2284@becker.bs.l> References: <20151218190616.GA2284@becker.bs.l> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 21 Dec 2015 14:49:29 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 19:49:30 -0000 On Friday, December 18, 2015 08:06:16 PM Bertram Scharpf wrote: > Hi, > > I started to play around with LLDB, but it crashes right on the start. > > > user@host ~/sandbox % rake hello > cc -I/usr/local/include -g -O0 -o hello.o -c hello.c > cc -Wl,-L/usr/local/lib -o hello hello.o > user@host ~/sandbox % lldb > (lldb) target create hello > Current executable set to 'hello' (i386). > (lldb) source list > 8 { > 9 printf( "Hello, world!\n"); > 10 return 0; > 11 } > 12 > (lldb) breakpoint set -f hello.c -l 9 > Breakpoint 1: where = hello`main + 31 at hello.c:9, address = 0x080485af > (lldb) process launch > Process 2409 launching > Process 2409 stopped > (lldb) Process 2409 launched: '/usr/home/user/sandbox/hello' (i386) > Process 2409 stopped > * thread #1: tid = 100224, 0x0818188f, stop reason = hardware error > frame #0: 0x0818188f > -> 0x818188f: addb %al, (%eax) > 0x8181891: addb %al, (%eax) > 0x8181893: addb %al, (%eax) > 0x8181895: addb %al, (%eax) > (lldb) lldb doesn't (yet) support running FreeBSD/i386 binaries I believe. -- John Baldwin From owner-freebsd-hackers@freebsd.org Mon Dec 21 22:59:23 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58F76A4F3D9 for ; Mon, 21 Dec 2015 22:59:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3196814DE; Mon, 21 Dec 2015 22:59:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ig0-x230.google.com with SMTP id m11so39780748igk.1; Mon, 21 Dec 2015 14:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=O743WbbT5tszixGpvJmj4z4ntkI+lXamabkWgcOmpLE=; b=p6jFFS0BppC7pJkCG4PE7eBJJm9eiuimHcqiCg8kqIzFLr2c6GSW/BbW+1slke6aV7 gUpK5dPBhsHcsWu25qdHW7MX89FK9LDrZhnH3o/YtZTuOiGIEPgbcgxmSk+PZ9+Rzndb 4Vf9FTJLYjkaWvdJhj/lzX/zosLxAJniqotbthFGG2PdhyS2ZziDAi19T7wP3XinmJjZ DqgXgZLt4i79PpMR5dFrsOLiAWXsZbC2qpxaLJXgE31uO+b3v+hy4PgTsh78nhnNj/eH RSuttIqqCoU90vKOdWOKA00fIfFlaxoZwudX1h1KqyG0mA4C65cOgOa3uF4Lox4z6TFO Pzog== X-Received: by 10.50.57.38 with SMTP id f6mr19052901igq.97.1450738762570; Mon, 21 Dec 2015 14:59:22 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.163.66 with HTTP; Mon, 21 Dec 2015 14:59:03 -0800 (PST) In-Reply-To: <1822063.F241qPFAvS@ralph.baldwin.cx> References: <20151218190616.GA2284@becker.bs.l> <1822063.F241qPFAvS@ralph.baldwin.cx> From: Ed Maste Date: Mon, 21 Dec 2015 17:59:03 -0500 X-Google-Sender-Auth: iM6D9OOs4c6PqOjtpvWTtf_UuAA Message-ID: Subject: Re: lldb crashes hello.c To: John Baldwin Cc: "freebsd-hackers@freebsd.org" , Bertram Scharpf Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 22:59:23 -0000 On 21 December 2015 at 14:11, John Baldwin wrote: > On Friday, December 18, 2015 08:06:16 PM Bertram Scharpf wrote: >> Hi, >> >> I started to play around with LLDB, but it crashes right on the start. > > lldb doesn't (yet) support running FreeBSD/i386 binaries I believe. That is correct. Broadly speaking arch support looks like: * Live and core debugging works: amd64 * Live and core debugging should work or has been known to work, but may have regressed and may not have been recently tested: arm, powerpc, powerpc64 * Core debugging works: arm64 * Core debugging should work: mips64 * Target code exists but is not functional: i386 * Target code does not exist: mips, riscv64, sparc64 From owner-freebsd-hackers@freebsd.org Mon Dec 21 23:26:50 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B2EAA4FB87 for ; Mon, 21 Dec 2015 23:26:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABA6115F; Mon, 21 Dec 2015 23:26:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 24D90B979; Mon, 21 Dec 2015 18:26:48 -0500 (EST) From: John Baldwin To: Ed Maste Cc: "freebsd-hackers@freebsd.org" , Bertram Scharpf Subject: Re: lldb crashes hello.c Date: Mon, 21 Dec 2015 15:24:35 -0800 Message-ID: <10631378.9HXCB454Uo@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <20151218190616.GA2284@becker.bs.l> <1822063.F241qPFAvS@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 21 Dec 2015 18:26:48 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 23:26:50 -0000 On Monday, December 21, 2015 05:59:03 PM Ed Maste wrote: > On 21 December 2015 at 14:11, John Baldwin wrote: > > On Friday, December 18, 2015 08:06:16 PM Bertram Scharpf wrote: > >> Hi, > >> > >> I started to play around with LLDB, but it crashes right on the start. > > > > lldb doesn't (yet) support running FreeBSD/i386 binaries I believe. > > That is correct. Broadly speaking arch support looks like: > > * Live and core debugging works: > amd64 What about a FreeBSD/i386 binary on an amd64 host? -- John Baldwin From owner-freebsd-hackers@freebsd.org Tue Dec 22 06:49:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A46AA4CA6C for ; Tue, 22 Dec 2015 06:49:12 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A58B81DFA for ; Tue, 22 Dec 2015 06:49:11 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.13.141]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0MEn74-1ZwNJe3Vv8-00FzhZ for ; Tue, 22 Dec 2015 07:49:08 +0100 Received: from bsch by becker.bs.l with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aBGkt-000AP4-Tf for freebsd-hackers@freebsd.org; Tue, 22 Dec 2015 07:49:07 +0100 Date: Tue, 22 Dec 2015 07:49:07 +0100 From: Bertram Scharpf To: freebsd-hackers@freebsd.org Subject: Re: lldb crashes hello.c Message-ID: <20151222064907.GA39830@becker.bs.l> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20151218190616.GA2284@becker.bs.l> <1822063.F241qPFAvS@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1822063.F241qPFAvS@ralph.baldwin.cx> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: Bertram Scharpf X-Provags-ID: V03:K0:7Y6HHtpGvHRk3n6zBgN8DWDbdJUTZnG1s8gaEsrKaREiUQYUy3e KGERxVsSYoX3TwMEdgpzUvBdqvJhNmthkaKsK35xfw6s5wRx7XPugqnZwnoXpjI2YO2HMzu kfz/R8WV/vHJgma2pC7vbAtIfwda/Xpj54V6odRueHw26D3L+KpCK6CEYZm/O6sqDioDNJp /wnqb8XzxRdk0i1B+dZDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:eNEUkgKD5Ks=:9G/+mIfuFDT3BKP2/f/fo7 ANS0qp04EIaBhpRF224uzOB3WapbW152k/K5i3wGyEfVYy59C8zz4qS+ukCeJcuuRUF/TuxIa Ggfq+NUWQUOo08W4j/hIPDTXw6tgiCZEqm7TWf1Ey4m2Ii6hbL29X7fihQMGv3jOZgoGeq4+x EwwJrcgCnfvp2NJAFUr1QgnQtmh8zMIWmhU26RaLKRKkVzOF7DnFXtVTDa6BKO+hB9EUjFXjd kujJfUSdveyJEXyECnXj8rn8Nm6FfIDcU9o6NS1qP0KPewwHTGJyj4TUCjwRPZm46xjvbnV69 Q/EHb0VuUMDe5Ie39hFkkzPg0ZWRJuxALgj/SFWM4b0Bkf2x+ixnxvbUOuOx/AinE3AvyJpT7 dE6eU0McnnzEgfib9Hzcn4bGDadDauICMNJxwn8mujtGDh3U0mYymnbt4RJRyD+LzPD3KToLF s0UH9pfOIFM49h0K17zP25ZvxxzJCURrJ/bTkvxrWiBqsg8qkL1q0cVuzLIdjh92naNL5ys8A lhynJIMca56NFuPByKSuGiOLBaUqm8RFdk3dBYyuFiR4/8tqNwq1fEtl7F+Jmvg181ayZwoz3 M19btjSWzeA5E3U2WvshWtdkZNPpyU7YIaygcwA8ue1YcA9i6kNkeOo8MzGoW7twLcdhUUiLp KoFCLQ+hLRYa9PQaPEDUyWKuom2SoHebJusDa76mabIoUP2HDzvNg+PBpefutMX3e9EY= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 06:49:12 -0000 Hi, On Monday, 21. Dec 2015, 11:11:06 -0800, John Baldwin wrote: > On Friday, December 18, 2015 08:06:16 PM Bertram Scharpf wrote: > > I started to play around with LLDB, but it crashes right on the start. > > lldb doesn't (yet) support running FreeBSD/i386 binaries I believe. What is it I'm in here? The time when I learned C, debugging was the soul of programming. Is this a mixture of the Truman Show and Bad Grampa II? Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Tue Dec 22 09:35:00 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3ED7CA4FC33 for ; Tue, 22 Dec 2015 09:35:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 EF4711A84 for ; Tue, 22 Dec 2015 09:34:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aBJL9-000JgJ-W6; Tue, 22 Dec 2015 11:34:44 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? From: Daniel Braniss In-Reply-To: <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> Date: Tue, 22 Dec 2015 11:34:43 +0200 Cc: Yuri , Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 09:35:00 -0000 > On 21 Dec 2015, at 16:06, Rick Macklem wrote: >=20 > Yuri wrote: >> On 12/20/2015 21:45, Yuri wrote: >>>=20 >>> it prints some messages that look like errors, see below. >>=20 >> I have recently began mounting /usr/ports as nullfs and unionfs on = top >> of it, and I believe this causes the system crashes during the = intense >> file activity on the unionfs-ed /usr/ports. >> /usr/ports.patches on /usr/ports (nullfs, local, read-only) >> :/usr/ports.subversion on /usr/ports (unionfs, local, noatime) >>=20 > Unionfs is broken. See the BUGS section of "man mount_unionfs". > Here a snippet from it: > THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T = WORK) > AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT = YOUR OWN > RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. >=20 > As such, reports for problems that you encounter when not using = unionfs are > far more useful, imho. >=20 I have been using unionfs for a very long time, mounting /etc (nfs read = only) and md whiteout any problems. I=E2=80=99m not sure if i tested it on 11, but i = will soon. yes, it can be problematic for other crazy things, but in my case, where = many of=20 my hosts are dataless so the unionfs is a great simplifier :-) just my 2 cents. > rick >=20 >> The messages I reported are related to this. >>=20 >> Yuri >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Dec 21 17:49:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 398A2A4D948; Mon, 21 Dec 2015 17:49:14 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECA3A112A; Mon, 21 Dec 2015 17:49:13 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x244.google.com with SMTP id a188so9239535vkc.1; Mon, 21 Dec 2015 09:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Kyx2Ws9mlCmruFb15KUb7Gm9fYdCgMiT2OYWatzMal8=; b=PdgJa56eAKMowR001maeRebIz6lw7ABuYZ18HUjzgQctnfpFHqBQYaBRKyP9sbHwTH KQlFZaTF+lEjzC84WHVVV2QIj7Q1Io69kXLGMB3oGq3mKYK1i+FK/JjouCktOlLQPtd2 SuuxozlEqwcy1km7GXzOGKsXeypGOjqGBMl4ZUbV7MLbzXBoZ1AeK4rvsce08mazhngI aOxVsWEzxlDFR+T5UHRMoe14r0K+woTuH1jpubYQI9D/txWD/4iv8yh4UNx8LJdNGzn9 jALrrdQHBBzbZ3aI8FI6dG6STzXM+4S3bfaXd93gEXpVJWVWrXNoztoAAH/myASeXyiR nsJA== MIME-Version: 1.0 X-Received: by 10.31.132.140 with SMTP id g134mr13033520vkd.94.1450720153039; Mon, 21 Dec 2015 09:49:13 -0800 (PST) Received: by 10.103.9.195 with HTTP; Mon, 21 Dec 2015 09:49:12 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Dec 2015 12:49:12 -0500 Message-ID: Subject: Re: Pardon the interruption. From: Joe Nosay To: NGie Cooper , NGie Cooper , Dru Lavigne , dru@freebsd.org, team@powerpc-notebook.org, Debian powerpc Mailinglist , FreeBSD PowerPC ML , FreeBSD Hackers , Nathan Whitehorn , Tomasz CEDRO , freebsd-current X-Mailman-Approved-At: Tue, 22 Dec 2015 21:41:25 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 17:49:14 -0000 Okay. Somebody needs to get a board and start building the actual laptop. www.nxp.com Since this is a crowd funding effort, it should be easy to have support. On Mon, Dec 21, 2015 at 12:30 PM, Joe Nosay wrote: > Let's find out exactly what the laptop project needs and work from there. > I have some ideas on using it for accessibility and creativity. There needs > to be a working prototype - a few actually - for developers to build the > systems. > Have someone put together a model and we can work from there. > From owner-freebsd-hackers@freebsd.org Mon Dec 21 17:30:58 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDCA1A4EC95; Mon, 21 Dec 2015 17:30:58 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F01E182D; Mon, 21 Dec 2015 17:30:58 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x244.google.com with SMTP id a185so5817766vkb.3; Mon, 21 Dec 2015 09:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=79QS0nvNWkx/1hvauOOYRkzEMpfKdHyXk2vDS9eZpwc=; b=0Aeo7HSWh3jL/9AvU4W54QldTdxcrRecAJ4aX7svkMZ41tt4ubU0O4AG2DIz9y4XEU sqE3EzXz3C8rPpHemV+9VL4u++Prk2bF7UekcSIoyzyfyptaClRk1srK6Mm/up+pm3rf veFVajTD6kdlZADYEVJRCTk46QVCsA/vfq5g/Q2tBCkw03gyssDTLB4qbgCq6K6y4YOF ZXMRA736KHCQJ7rTonLtKHEVeUvQ6rLqa9dU3Rst36VFvJomYlBd5zUO7WRkRrW7nbfC ptUZ5UFRBxEp+UWZ7bn6S96b6PUNMutm9QpompGxYUtQnosemxNriCrCYNtcSwD+UVah XNIw== MIME-Version: 1.0 X-Received: by 10.31.132.140 with SMTP id g134mr12980449vkd.94.1450719057500; Mon, 21 Dec 2015 09:30:57 -0800 (PST) Received: by 10.103.9.195 with HTTP; Mon, 21 Dec 2015 09:30:57 -0800 (PST) Date: Mon, 21 Dec 2015 12:30:57 -0500 Message-ID: Subject: Pardon the interruption. From: Joe Nosay To: NGie Cooper , NGie Cooper , Dru Lavigne , dru@freebsd.org, team@powerpc-notebook.org, Debian powerpc Mailinglist , FreeBSD PowerPC ML , FreeBSD Hackers , Nathan Whitehorn , Tomasz CEDRO , freebsd-current X-Mailman-Approved-At: Tue, 22 Dec 2015 21:41:25 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 17:30:58 -0000 Let's find out exactly what the laptop project needs and work from there. I have some ideas on using it for accessibility and creativity. There needs to be a working prototype - a few actually - for developers to build the systems. Have someone put together a model and we can work from there. From owner-freebsd-hackers@freebsd.org Tue Dec 22 22:36:37 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71EE9A5089A for ; Tue, 22 Dec 2015 22:36:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44B91153A; Tue, 22 Dec 2015 22:36:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ig0-x234.google.com with SMTP id to18so67061768igc.0; Tue, 22 Dec 2015 14:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CKQCR25mS1SRiBHVmoBNGS/d5SUciix1ESZBL3BNrqc=; b=B486xbpUXBilCCmjPBjEN0Hac1M2wqZsKzNUzR2GX9jBXEEUP4FzZq9yyMps+bLQ5k GF0cm/37TeOBToSDrFDuAzfffD6ojLRSnO0RZ+wenwJh54RcreWJW6LoDkniBrfcnAPd uEkJNI1WxXHC5+k1OOAMMLZSpyOyb/b00o1FsYRcPYWRzdY5eAVrhLlpnfRaFU6N2WFN CK+EedNMrWhtmvSKbyBFCdaIOAMtuRyp+6CbdVq7vNFWP3k1wDaLOBtvBII1wkA9TFa2 1ZhlST2X4H8XryClj0LtXcQ0twVNDo0ciwlUDGMy3VL4cTswUj6SxU74U38KQo0bgKYy P3CA== X-Received: by 10.50.6.104 with SMTP id z8mr27823826igz.58.1450823796735; Tue, 22 Dec 2015 14:36:36 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.163.66 with HTTP; Tue, 22 Dec 2015 14:36:17 -0800 (PST) In-Reply-To: <10631378.9HXCB454Uo@ralph.baldwin.cx> References: <20151218190616.GA2284@becker.bs.l> <1822063.F241qPFAvS@ralph.baldwin.cx> <10631378.9HXCB454Uo@ralph.baldwin.cx> From: Ed Maste Date: Tue, 22 Dec 2015 17:36:17 -0500 X-Google-Sender-Auth: agIGdRRnDDJE312LCiJzZVUyydk Message-ID: Subject: Re: lldb crashes hello.c To: John Baldwin Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 22:36:37 -0000 On 21 December 2015 at 18:24, John Baldwin wrote: > > What about a FreeBSD/i386 binary on an amd64 host? Right now, no: (lldb) run Process 96045 launching failed to fetch ps_strings: Bad address From owner-freebsd-hackers@freebsd.org Tue Dec 22 22:58:42 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 705BAA50F97 for ; Tue, 22 Dec 2015 22:58:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 523691171; Tue, 22 Dec 2015 22:58:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A44D3B94C; Tue, 22 Dec 2015 17:58:40 -0500 (EST) From: John Baldwin To: Ed Maste Cc: "freebsd-hackers@freebsd.org" Subject: Re: lldb crashes hello.c Date: Tue, 22 Dec 2015 14:58:37 -0800 Message-ID: <6983779.y0Y8FR9jyN@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <20151218190616.GA2284@becker.bs.l> <10631378.9HXCB454Uo@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Dec 2015 17:58:40 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 22:58:42 -0000 On Tuesday, December 22, 2015 05:36:17 PM Ed Maste wrote: > On 21 December 2015 at 18:24, John Baldwin wrote: > > > > What about a FreeBSD/i386 binary on an amd64 host? > > Right now, no: > (lldb) run > Process 96045 launching > failed to fetch ps_strings: Bad address gdb7 can't run an i386 on amd64 either. It can attach to a running binary ok, but it gets confused because the embedded RTLD interpreter points to the amd64 RTLD. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Dec 23 00:02:56 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDA38A50588 for ; Wed, 23 Dec 2015 00:02:56 +0000 (UTC) (envelope-from arlie@worldash.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E174E1766 for ; Wed, 23 Dec 2015 00:02:56 +0000 (UTC) (envelope-from arlie@worldash.org) Received: by mailman.ysv.freebsd.org (Postfix) id DDC0DA50587; Wed, 23 Dec 2015 00:02:56 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD503A50586 for ; Wed, 23 Dec 2015 00:02:56 +0000 (UTC) (envelope-from arlie@worldash.org) Received: from ansuz.worldash.org (ansuz.worldash.org [198.144.201.100]) by mx1.freebsd.org (Postfix) with ESMTP id C63511765 for ; Wed, 23 Dec 2015 00:02:53 +0000 (UTC) (envelope-from arlie@worldash.org) Received: by ansuz.worldash.org (Postfix, from userid 1000) id 00CA7E1923; Tue, 22 Dec 2015 15:59:20 -0800 (PST) Date: Tue, 22 Dec 2015 15:59:20 -0800 From: Arlie Stephens To: hackers@FreeBSD.ORG Subject: Examining Page Tables in Kernel Crash Dumps (amd64) Message-ID: <20151222235920.GA21736@worldash.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 00:02:57 -0000 I'm chasing a bug in an elderly, customized freebsd kernel that appears to result in corrupted page tables. kgdb is not cooperating when I attempt to look at addresses of kernel page tables. I've replicated that part on an elderly stock freebsd system, running freebsd 8.4. , and it looks to me like it's probably getting that limitation from libkvm. Obviously I don't expect community help with an ancient freebsd issue... particularly one probably caused by our own customizations. But given the tool chain changes upstream, I don't expect testing with whatever kgdb has turned into there to be very relevant ;-( So far, the only way I know to get a look at kernel page table contents in FreeBSD is on live systems with ddb. I would like to know whether there are any tools I haven't noticed for dealing with page tables in crash dumps - or, for that matter, whether kgdb is supposed to be able to display the kernel's recursive page tables. Failing that, I may just have to write one ;-) (Or figure out how to chase my problem on live systems.) -- Arlie (Arlie Stephens arlie@worldash.org) From owner-freebsd-hackers@freebsd.org Wed Dec 23 10:43:38 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2B0AA50125 for ; Wed, 23 Dec 2015 10:43:38 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 884B81ECB for ; Wed, 23 Dec 2015 10:43:38 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 84DCBA50124; Wed, 23 Dec 2015 10:43:38 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84677A50123 for ; Wed, 23 Dec 2015 10:43:38 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 491FD1ECA for ; Wed, 23 Dec 2015 10:43:38 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: by mail-qg0-x231.google.com with SMTP id 74so82523561qgh.1 for ; Wed, 23 Dec 2015 02:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WKDUSoslDQKMiYjc4VwMLdeFpmcvVWHR5H5ybWDOOT0=; b=ZBB2NDyniIL7N7uAhdEuSKzJjIX20BvFEfWgxf5t0vJ54/16BesXQiY11FKZLQtTLj nunFuQPH+EqWMbuVKiZw8SQu4ZVOteNz52DGnyIHdulrao1m+RoRBCJVhPBFsc4dAeaQ mEqqY8Qc30fHKw/B7vHSpbD1cFhDddUpAY3UnLMui9fofMXPYskEeyzaI9Rp78enEAMU 2z6a7Axm1JGj8QVg3psytDsQtgzP50T0zp86Oe9dk7G3vh0mvLigqacAT+M6Xx7Azml2 CqezeyA+UVOI9aJFm1YNzqjr+HU3kZARmQGoK6mW+zXaAOazJPrrwSYFIBRqxrRuh6S1 uquw== MIME-Version: 1.0 X-Received: by 10.140.93.117 with SMTP id c108mr38495067qge.101.1450867417306; Wed, 23 Dec 2015 02:43:37 -0800 (PST) Received: by 10.140.35.177 with HTTP; Wed, 23 Dec 2015 02:43:37 -0800 (PST) Date: Wed, 23 Dec 2015 21:43:37 +1100 Message-ID: Subject: The minimum amount of memory needed to use ZFS. From: Stephen Hocking To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 10:43:38 -0000 Hi all, Inspired by this article: http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/ I am wondering about changing my offsite back strategy, which currently is made up of a Raspberry Pi with an external 3TB drive sitting at my brother's house, with periodic manual rsyncs. I'd like to change that to doing zfs replications. I want to use some of my ARM based hardware as the target for the ZFS replication, owing to its low power usage. I have a few Cubiboxes floating around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd have a UFS root on the SD card, and ZFS on the external drive. Any ideas? From owner-freebsd-hackers@freebsd.org Wed Dec 23 11:41:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD74AA4F41E for ; Wed, 23 Dec 2015 11:41:14 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C467E106D for ; Wed, 23 Dec 2015 11:41:14 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C3B4BA4F41D; Wed, 23 Dec 2015 11:41:14 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C33FAA4F41B for ; Wed, 23 Dec 2015 11:41:14 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85A6D106C for ; Wed, 23 Dec 2015 11:41:14 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: by mail-qg0-x22f.google.com with SMTP id o11so74703814qge.2 for ; Wed, 23 Dec 2015 03:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cw8pe5BGITRcY+3tVgqtA6bwBFGowfquXpLQvZAVW+Q=; b=FK8ybgFiPZRlWzOzAMdPxf7SPNrE5tVil98k5Lmyh38V14ZTP3WYyWOeP89W8gk11e 6njOjCOGqm6SXNb8ApjTJpNBlk6qtnRZIz7yt/9QiD+/p/ZMid9sLPNtJKdwWDrnBo55 1pqHlkGpbLVLYvdk6UyoKQuJ6nBMA+xMl9EO3EGoXP+Nslt0/aM4O7Ur2rnLJLc+iqam l2k+AdQxt1iKM8WUIb8/xyY2m6SmkkBYxua0yeXL52Kwz8eratxHKArc/4TWHidY9o9s FhSmSrs68qJXhSkQywEyK4dfQZAgMOc1BD0+AEWjtNCD8AtunBUZiNLQmlfYZGXJ5940 Gpew== MIME-Version: 1.0 X-Received: by 10.140.220.136 with SMTP id q130mr41766546qhb.24.1450870873144; Wed, 23 Dec 2015 03:41:13 -0800 (PST) Received: by 10.140.35.177 with HTTP; Wed, 23 Dec 2015 03:41:13 -0800 (PST) In-Reply-To: <20151223113216.GA4535@zxy.spb.ru> References: <20151223113216.GA4535@zxy.spb.ru> Date: Wed, 23 Dec 2015 22:41:13 +1100 Message-ID: Subject: Re: The minimum amount of memory needed to use ZFS. From: Stephen Hocking To: Slawa Olhovchenkov Cc: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 11:41:15 -0000 In my case, I want to use ZFS. I'm currently running FreeBSD on a number of systems, ranging from 16G (box with multiple ZFS pools and filesystems) to 256M (Early RPI), so I know it runs OK in relatively small amounts of memory (aeons ago I was running it one a box with 8MB). I was curious to know what people think it needs to run ZFS without problems. On Wed, Dec 23, 2015 at 10:32 PM, Slawa Olhovchenkov wrote: > On Wed, Dec 23, 2015 at 09:43:37PM +1100, Stephen Hocking wrote: > > > Hi all, > > > > Inspired by this article: > > > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/ > > > > I am wondering about changing my offsite back strategy, which currently > is > > made up of a Raspberry Pi with an external 3TB drive sitting at my > > brother's house, with periodic manual rsyncs. I'd like to change that to > > doing zfs replications. > > > > I want to use some of my ARM based hardware as the target for the ZFS > > replication, owing to its low power usage. I have a few Cubiboxes > floating > > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd > have > > a UFS root on the SD card, and ZFS on the external drive. > > > > Any ideas? > > I am do install FreeBSD i386 10 on the VirtualBox VM with 384M RAM and > successful pass `make buildworld`. > > In the real world all depends on workload and minimal depends from FS > (UFS or ZFS). > From owner-freebsd-hackers@freebsd.org Wed Dec 23 11:55:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86119A4FA89 for ; Wed, 23 Dec 2015 11:55:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 737EB1CE6 for ; Wed, 23 Dec 2015 11:55:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 7103EA4FA88; Wed, 23 Dec 2015 11:55:27 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70A17A4FA87 for ; Wed, 23 Dec 2015 11:55:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE52E1CE4 for ; Wed, 23 Dec 2015 11:55:26 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aBi0m-000HuF-Ov; Wed, 23 Dec 2015 14:55:20 +0300 Date: Wed, 23 Dec 2015 14:55:20 +0300 From: Slawa Olhovchenkov To: Stephen Hocking Cc: hackers@freebsd.org Subject: Re: The minimum amount of memory needed to use ZFS. Message-ID: <20151223115520.GB4535@zxy.spb.ru> References: <20151223113216.GA4535@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 11:55:27 -0000 On Wed, Dec 23, 2015 at 10:41:13PM +1100, Stephen Hocking wrote: > In my case, I want to use ZFS. I'm currently running FreeBSD on a number of > systems, ranging from 16G (box with multiple ZFS pools and filesystems) to > 256M (Early RPI), so I know it runs OK in relatively small amounts of > memory (aeons ago I was running it one a box with 8MB). I was curious to > know what people think it needs to run ZFS without problems. This depends on average ZFS block size on pool, number of files in working set, number of simultaneously open files, pattern of access to files and etc. Using large block size (1M and more) can significantly reduce memory consumption for ZFS overhead, but you can't cache independence files as much as for 128K. Common rule: if UFS working good in you memory and memory > 512M -- ZFS also will be working good. > On Wed, Dec 23, 2015 at 10:32 PM, Slawa Olhovchenkov wrote: > > > On Wed, Dec 23, 2015 at 09:43:37PM +1100, Stephen Hocking wrote: > > > > > Hi all, > > > > > > Inspired by this article: > > > > > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/ > > > > > > I am wondering about changing my offsite back strategy, which currently > > is > > > made up of a Raspberry Pi with an external 3TB drive sitting at my > > > brother's house, with periodic manual rsyncs. I'd like to change that to > > > doing zfs replications. > > > > > > I want to use some of my ARM based hardware as the target for the ZFS > > > replication, owing to its low power usage. I have a few Cubiboxes > > floating > > > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd > > have > > > a UFS root on the SD card, and ZFS on the external drive. > > > > > > Any ideas? > > > > I am do install FreeBSD i386 10 on the VirtualBox VM with 384M RAM and > > successful pass `make buildworld`. > > > > In the real world all depends on workload and minimal depends from FS > > (UFS or ZFS). > > From owner-freebsd-hackers@freebsd.org Wed Dec 23 12:13:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0933A507AD for ; Wed, 23 Dec 2015 12:13:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CEE761877 for ; Wed, 23 Dec 2015 12:13:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id CEA1EA507AC; Wed, 23 Dec 2015 12:13:20 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE327A507AB for ; Wed, 23 Dec 2015 12:13:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A7BC1876 for ; Wed, 23 Dec 2015 12:13:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aBheS-000HE7-EA; Wed, 23 Dec 2015 14:32:16 +0300 Date: Wed, 23 Dec 2015 14:32:16 +0300 From: Slawa Olhovchenkov To: Stephen Hocking Cc: hackers@freebsd.org Subject: Re: The minimum amount of memory needed to use ZFS. Message-ID: <20151223113216.GA4535@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 12:13:21 -0000 On Wed, Dec 23, 2015 at 09:43:37PM +1100, Stephen Hocking wrote: > Hi all, > > Inspired by this article: > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/ > > I am wondering about changing my offsite back strategy, which currently is > made up of a Raspberry Pi with an external 3TB drive sitting at my > brother's house, with periodic manual rsyncs. I'd like to change that to > doing zfs replications. > > I want to use some of my ARM based hardware as the target for the ZFS > replication, owing to its low power usage. I have a few Cubiboxes floating > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd have > a UFS root on the SD card, and ZFS on the external drive. > > Any ideas? I am do install FreeBSD i386 10 on the VirtualBox VM with 384M RAM and successful pass `make buildworld`. In the real world all depends on workload and minimal depends from FS (UFS or ZFS). From owner-freebsd-hackers@freebsd.org Wed Dec 23 12:14:54 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDBC4A50888 for ; Wed, 23 Dec 2015 12:14:54 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B6BB61A03 for ; Wed, 23 Dec 2015 12:14:54 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: by mailman.ysv.freebsd.org (Postfix) id B66E7A50887; Wed, 23 Dec 2015 12:14:54 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B604BA50886 for ; Wed, 23 Dec 2015 12:14:54 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: from homiemail-a56.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1.freebsd.org (Postfix) with ESMTP id A14F51A02 for ; Wed, 23 Dec 2015 12:14:54 +0000 (UTC) (envelope-from mail@ozzmosis.com) Received: from homiemail-a56.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTP id 8D96AFE05B; Wed, 23 Dec 2015 04:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ozzmosis.com; h=date:from :to:cc:subject:message-id:references:mime-version:content-type: in-reply-to; s=ozzmosis.com; bh=BzxusWIT+28w06DziFSIhggfQ/M=; b= StLEfvGlhEpE8TVTHL4wu/vcLrCtb3apf0RGJ5mmKqPG1TADVHUr60v1Qxj8UM5x l6BOmlfvcKfvffFX9n+syZ+C+Gbaw2TdR5mSCz1vcB+GOiTuWkEbfLlrzk3ST1AQ AqiCzd4GxioyBYRbYrFZ8ME7T663V0v3IxNCBJ4egdg= Received: from blizzard.ozzmosis.com (124-170-34-224.dyn.iinet.net.au [124.170.34.224]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: relay@ozzmosis.com) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 56569FE059; Wed, 23 Dec 2015 04:14:48 -0800 (PST) Received: by blizzard.ozzmosis.com (Postfix, from userid 1001) id C9BE9922; Wed, 23 Dec 2015 23:14:45 +1100 (AEDT) Date: Wed, 23 Dec 2015 23:14:45 +1100 From: andrew clarke To: Stephen Hocking Cc: hackers@freebsd.org Subject: Re: The minimum amount of memory needed to use ZFS. Message-ID: <20151223121445.GA85016@ozzmosis.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 12:14:54 -0000 On Wed 2015-12-23 21:43:37 UTC+1100, Stephen Hocking (stephen.hocking@gmail.com) wrote: > Inspired by this article: > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replication-to-the-cloud-is-finally-here-and-its-fast/ > > I am wondering about changing my offsite back strategy, which currently is > made up of a Raspberry Pi with an external 3TB drive sitting at my > brother's house, with periodic manual rsyncs. I'd like to change that to > doing zfs replications. > > I want to use some of my ARM based hardware as the target for the ZFS > replication, owing to its low power usage. I have a few Cubiboxes floating > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd have > a UFS root on the SD card, and ZFS on the external drive. > > Any ideas? I'm curious about this too. Currently I run a root-on-ZFS FreeBSD 10.2 amd64 system with 2 GB RAM that I use for offline backups. The ZFS pool consists of 2 x 1 TB drives in a mirror setup. I've never had FreeBSD run out of memory on that machine. I suggest you avoid using the deduplication feature of ZFS which from what I understands likes to chew through memory. I don't use ZFS snapshots on that machine, so can't speak about their memory usage. Perhaps it's fairly insignificant, though. An alternative might be to use something like rsnapshot, still on ZFS. You might get a bigger audience if you ask on the freebsd-questions list. Regards Andrew From owner-freebsd-hackers@freebsd.org Wed Dec 23 16:58:26 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0263DA4F1E6 for ; Wed, 23 Dec 2015 16:58:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E51C91F29 for ; Wed, 23 Dec 2015 16:58:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E3DB3A4F1E4; Wed, 23 Dec 2015 16:58:25 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3710A4F1E1 for ; Wed, 23 Dec 2015 16:58:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C86B71F28 for ; Wed, 23 Dec 2015 16:58:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 23 Dec 2015 16:57:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBNGwHms003813; Wed, 23 Dec 2015 09:58:17 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450889897.25138.190.camel@freebsd.org> Subject: Re: The minimum amount of memory needed to use ZFS. From: Ian Lepore To: Stephen Hocking , hackers@freebsd.org Date: Wed, 23 Dec 2015 09:58:17 -0700 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 16:58:26 -0000 On Wed, 2015-12-23 at 21:43 +1100, Stephen Hocking wrote: > Hi all, > > Inspired by this article: > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-r > eplication-to-the-cloud-is-finally-here-and-its-fast/ > > I am wondering about changing my offsite back strategy, which > currently is > made up of a Raspberry Pi with an external 3TB drive sitting at my > brother's house, with periodic manual rsyncs. I'd like to change that > to > doing zfs replications. > > I want to use some of my ARM based hardware as the target for the ZFS > replication, owing to its low power usage. I have a few Cubiboxes > floating > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd > have > a UFS root on the SD card, and ZFS on the external drive. > > Any ideas? People have reported running arm systems using zfs in as little as 512MB (on a beaglebone), but it's a long way from "it boots" to "it's useful" and I have no idea if they were using the systems for anything other than proof of concept. I wouldn't consider using an rpi for even a moment. They're just too slow and the chipset too crippled to be useful as anything other than a toy, IMO. A Cubox (4 cores @1.2GHz, 2GB ram) should work fine. Right now your only storage option is a USB drive, (it has an eSata port but we don't have the ahci driver working on that platform yet). The freebsd-arm mailing list might get you replies from people who've been down this road themselves. -- Ian From owner-freebsd-hackers@freebsd.org Wed Dec 23 17:07:57 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8340CA4F7A9 for ; Wed, 23 Dec 2015 17:07:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6A62414A7 for ; Wed, 23 Dec 2015 17:07:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 690B8A4F7A6; Wed, 23 Dec 2015 17:07:57 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68A16A4F7A5 for ; Wed, 23 Dec 2015 17:07:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38C2714A6 for ; Wed, 23 Dec 2015 17:07:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-ob0-x232.google.com with SMTP id ba1so77245278obb.3 for ; Wed, 23 Dec 2015 09:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fHYOTJGP1lzvojfPPgcDGCsIUVjkZFhpwjZLkL0oNQE=; b=YJklQizbZlkYQ1sMdS1F8JzODX/WajHxW3fa+HRMmR0fPMGwH7gQU3hiXQo3JIGgyi mf4yymqk6UhlYCWr4Qx4UWm9iUyUqQtbm1I0f85FwA9uEIeHL56hcnbxUWigOwV0ZbZY KAg8qY7aCLISah41nXdbsWnVmL2aeOxCr6HURYC9EMDRsYaJ/HACyr86RJpKRqxKFe8l PkOojQRtWhY3oTnqjg4gxAOvED7kIcapbDmMvTecocO/Nh3P7RYhSm5Ug06h4BjnwP9w xeNR7bn/RHlIuwm9wAFKZIBrMzrUl8An3p5Et5U+YjulZvUspDSQuP3FH1gkyr8cRfBv wwpA== MIME-Version: 1.0 X-Received: by 10.182.24.9 with SMTP id q9mr15220245obf.73.1450890476599; Wed, 23 Dec 2015 09:07:56 -0800 (PST) Received: by 10.76.172.195 with HTTP; Wed, 23 Dec 2015 09:07:56 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 09:07:56 -0800 Message-ID: Subject: Re: The minimum amount of memory needed to use ZFS. From: Freddie Cash To: Stephen Hocking Cc: "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 17:07:57 -0000 On Wed, Dec 23, 2015 at 2:43 AM, Stephen Hocking wrote: > Inspired by this article: > > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-repli= cation-to-the-cloud-is-finally-here-and-its-fast/ > > I am wondering about changing my offsite back strategy, which currently i= s > made up of a Raspberry Pi with an external 3TB drive sitting at my > brother's house, with periodic manual rsyncs. I'd like to change that to > doing zfs replications. > > I want to use some of my ARM based hardware as the target for the ZFS > replication, owing to its low power usage. I have a few Cubiboxes floatin= g > around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd hav= e > a UFS root on the SD card, and ZFS on the external drive. > > Any ideas? > =E2=80=8BMy lowest powered / lowest performing ZFS-based system was an Inte= l Pentium4 3.0 GHz single-core setup with 2 GB of RAM, running 32-bit FreeBSD. Used a 2 GB USB stick for the / filesystem (including /usr), and 4x 120 GB IDE drives in a raidz1. Back in the late FreeBSD 7 / early FreeBSD 8 days. It took a lot of tinkering with =E2=80=8B =E2=80=8Bthe kernel config, loader.conf, and sysctl.conf to make it stable.= But it eventually worked quite nicely. Used it for several years. Even migrated it over to 4x=E2=80=8B 160 GB SATA1 drives in raidz1, then to 500 GB SATA2 = drives in two mirror vdevs, then to ZFS-on-root. The last migration changed the motherboard for one that supports an AMD Phenom-II quad-core at 2.something GHz with 8 GB of RAM. And the to 4x 1 TB drives. Over the holidays, I'll be adding another mirror vdev (total of 3, using 6 drives) and another 8 GB of RAM. ZFS runs better with more RAM; and it requires less manual tuning with more RAM. But it's definitely possible to run it with less RAM. You just need to be willing to spend time tuning, tweaking, and testing. I wouldn't want to run it on an RPi, though. The CPU is just too weak to compute the checksums (unless you go for a weak/fast algorithm) and to do any compression. I've heard good things from people using Intel Atom CPUs, though. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@freebsd.org Wed Dec 23 17:58:03 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0010A508E9 for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B00C110EC for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id AC5D4A508E7; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABF30A508E6 for ; Wed, 23 Dec 2015 17:58:03 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 42D2010EA for ; Wed, 23 Dec 2015 17:58:02 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.24] ([194.32.164.24]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id tBNHrdJi061248; Wed, 23 Dec 2015 17:53:39 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: The minimum amount of memory needed to use ZFS. From: Bob Bishop In-Reply-To: <20151223121445.GA85016@ozzmosis.com> Date: Wed, 23 Dec 2015 17:53:41 +0000 Cc: Stephen Hocking , hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> References: <20151223121445.GA85016@ozzmosis.com> To: andrew clarke X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 17:58:03 -0000 Hi, > On 23 Dec 2015, at 12:14, andrew clarke wrote: >=20 > On Wed 2015-12-23 21:43:37 UTC+1100, Stephen Hocking = (stephen.hocking@gmail.com) wrote: >=20 >> Inspired by this article: >> = http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-replic= ation-to-the-cloud-is-finally-here-and-its-fast/ >>=20 >> I am wondering about changing my offsite back strategy, which = currently is >> made up of a Raspberry Pi with an external 3TB drive sitting at my >> brother's house, with periodic manual rsyncs. I'd like to change that = to >> doing zfs replications. >>=20 >> I want to use some of my ARM based hardware as the target for the ZFS >> replication, owing to its low power usage. I have a few Cubiboxes = floating >> around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd = have >> a UFS root on the SD card, and ZFS on the external drive. >>=20 >> Any ideas? >=20 > I'm curious about this too. >=20 > Currently I run a root-on-ZFS FreeBSD 10.2 amd64 system with 2 GB RAM > that I use for offline backups. The ZFS pool consists of 2 x 1 TB > drives in a mirror setup. I've never had FreeBSD run out of memory on > that machine. >=20 > I suggest you avoid using the deduplication feature of ZFS which from > what I understands likes to chew through memory. >=20 > I don't use ZFS snapshots on that machine, so can't speak about their > memory usage. Perhaps it's fairly insignificant, though. >=20 > An alternative might be to use something like rsnapshot, still on ZFS. >=20 > You might get a bigger audience if you ask on the freebsd-questions > list. >=20 > Regards > Andrew FWIW we have a backup box currently running 9.2 amd64 with 4GB RAM and a = ZFS mirror. We use rsync to transfer the data daily, and ZFS snapshots = to maintain a Time Machine-like structure (currently something over 150 = snapshots in play). We did have some instances of apparent memory = exhaustion until we limited vfs.zfs.arc_max to 2GB; that doesn=E2=80=99t = seem to have affected performance. Deduplication seems like a very bad idea unless you have both a lot of = duplicated data and a serious shortage of disk. It needs a lot of RAM, = increasing over time. Depending on the hardware and the use case, = compression (which effectively only costs CPU) might be a better option. -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Wed Dec 23 18:42:08 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0DDBA4F7DA for ; Wed, 23 Dec 2015 18:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C69E61B67 for ; Wed, 23 Dec 2015 18:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C4D3FA4F7D9; Wed, 23 Dec 2015 18:42:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A988DA4F7D8 for ; Wed, 23 Dec 2015 18:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33FE91B65 for ; Wed, 23 Dec 2015 18:42:07 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id l126so156564604wml.1 for ; Wed, 23 Dec 2015 10:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UPEmF3pToxdEAt0ULlojHqgbLKA+AzMEpjUV/fEfqmU=; b=Mr7BchPXLbPEDBnxI5tdmx8dPe8GCVtYKTCUU0ZfaBrvSymvPFhARWJom9yKNMdLHx GyXyAKHWI79U3R9YAIEoHIQCUVn8Uc17FdAH5l/Vfxcm7C2z6aPa06U+rWlipw/DNEG4 AW92sQAgTpwLUGAZncRXifo3rvM7BRSWAxllqAOjfYs/ozEAP8Od3VIKbNmDmux2EzwU INInPNNxFLIq0vXj0lCFlc0B239yGTra60h0zMU8UnVrpWSFZKOYoV/6PaIwYH6J05RI J762CBqOuzvUbTcfWr+ZTQQMDqr7EXST+lO25awE0dRGs2xRKIhT6i/vLWhRFlls1Nha n/JA== MIME-Version: 1.0 X-Received: by 10.194.117.5 with SMTP id ka5mr16979299wjb.20.1450896125405; Wed, 23 Dec 2015 10:42:05 -0800 (PST) Received: by 10.28.55.85 with HTTP; Wed, 23 Dec 2015 10:42:05 -0800 (PST) Received: by 10.28.55.85 with HTTP; Wed, 23 Dec 2015 10:42:05 -0800 (PST) In-Reply-To: <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> References: <20151223121445.GA85016@ozzmosis.com> <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> Date: Wed, 23 Dec 2015 18:42:05 +0000 Message-ID: Subject: Re: The minimum amount of memory needed to use ZFS. From: krad To: Bob Bishop Cc: andrew clarke , Stephen Hocking , hackers@freebsd.org X-Mailman-Approved-At: Wed, 23 Dec 2015 20:05:16 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 18:42:08 -0000 If you want something small and cheap you could look at a Celeron based Intel nuc or similar. I think I built mine for about =C2=A3150, it has an = ssd and 4gb or ram and runs zfs on root fine. It's basically a beefy router with inbuilt transparent web caching. It works well and is relatively low power for what I need. The pi and aurdino would be in a different league though in both senses of power On 23 Dec 2015 17:58, "Bob Bishop" wrote: > Hi, > > > On 23 Dec 2015, at 12:14, andrew clarke wrote: > > > > On Wed 2015-12-23 21:43:37 UTC+1100, Stephen Hocking ( > stephen.hocking@gmail.com) wrote: > > > >> Inspired by this article: > >> > http://arstechnica.com/information-technology/2015/12/rsync-net-zfs-repli= cation-to-the-cloud-is-finally-here-and-its-fast/ > >> > >> I am wondering about changing my offsite back strategy, which currentl= y > is > >> made up of a Raspberry Pi with an external 3TB drive sitting at my > >> brother's house, with periodic manual rsyncs. I'd like to change that = to > >> doing zfs replications. > >> > >> I want to use some of my ARM based hardware as the target for the ZFS > >> replication, owing to its low power usage. I have a few Cubiboxes > floating > >> around with around 2G of RAM, and a RPI2 or a Banana Pi with 1G. It'd > have > >> a UFS root on the SD card, and ZFS on the external drive. > >> > >> Any ideas? > > > > I'm curious about this too. > > > > Currently I run a root-on-ZFS FreeBSD 10.2 amd64 system with 2 GB RAM > > that I use for offline backups. The ZFS pool consists of 2 x 1 TB > > drives in a mirror setup. I've never had FreeBSD run out of memory on > > that machine. > > > > I suggest you avoid using the deduplication feature of ZFS which from > > what I understands likes to chew through memory. > > > > I don't use ZFS snapshots on that machine, so can't speak about their > > memory usage. Perhaps it's fairly insignificant, though. > > > > An alternative might be to use something like rsnapshot, still on ZFS. > > > > You might get a bigger audience if you ask on the freebsd-questions > > list. > > > > Regards > > Andrew > > FWIW we have a backup box currently running 9.2 amd64 with 4GB RAM and a > ZFS mirror. We use rsync to transfer the data daily, and ZFS snapshots to > maintain a Time Machine-like structure (currently something over 150 > snapshots in play). We did have some instances of apparent memory > exhaustion until we limited vfs.zfs.arc_max to 2GB; that doesn=E2=80=99t = seem to > have affected performance. > > Deduplication seems like a very bad idea unless you have both a lot of > duplicated data and a serious shortage of disk. It needs a lot of RAM, > increasing over time. Depending on the hardware and the use case, > compression (which effectively only costs CPU) might be a better option. > > -- > Bob Bishop > rb@gid.co.uk > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@freebsd.org Wed Dec 23 21:33:56 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 570C7A50E37; Wed, 23 Dec 2015 21:33:56 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA4A412A8; Wed, 23 Dec 2015 21:33:54 +0000 (UTC) (envelope-from lists@bertram-scharpf.de) Received: from becker.bs.l ([85.180.12.203]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0MOELI-1a8Xf20bpc-005ak9; Wed, 23 Dec 2015 22:33:52 +0100 Received: from bsch by becker.bs.l with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aBr2d-0000Lu-Ez; Wed, 23 Dec 2015 22:33:51 +0100 Date: Wed, 23 Dec 2015 22:33:51 +0100 From: Bertram Scharpf To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PATH variable in lpd's process Message-ID: <20151223213351.GA1304@becker.bs.l> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <20151221164338.GB33124@becker.bs.l> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151221164338.GB33124@becker.bs.l> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: Bertram Scharpf X-Provags-ID: V03:K0:6ncJMxeLZEjE5h2IyPBfhVp//3cg/zTJTkth4MOYWdq6+R6GvUH BuuTyoigpmGCwrIruPgcBzsAXLeREm66jz+5f+qtbYvTH7V7P7NC1QLZaYiO1PDFGXJNGsp h4m9gn+ue8so3KT/D5MZYzWqoEGa91ej0MFcVAcyRhXV+Ddv4LzPZbYg6vb28UyrOUok5OK IxcZtI7FqjyjtyqYJD6dQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:DpYQ8ZDhlGE=:bMXEYgKSBwll5pWsMvQPN6 1QxhBhY8F1rYeF9IGnmLBmGP3Ll10ifeWVwGyZsHeQcX2sOidnQZ0xXGTt5O/GTmtYONudD+6 YMKJ4f+WAuaaudXdBK32BBYjXGpjDFWSX2xdYj2oNm00UO3LU9xsDprsDdeafMHYSDsgVsH+B K0zI5mkzQ1SOOk/N/om38oW+vsKyuuXhPkQAV+iFAh4IFMLLOWzFs+c4ZJ6DZJAiYrjQbshfq rmMubn/e7/8lGv20hR9N5jvqrFqvkohnnwG/1ChU3/CbuVtrzFktOOHrLUvrBD5B8u2b7d2bI q9nlT8kaZ2577BhYOxcOUSOvaKhOrcYXBggKjV4XT3dBFm+LQke8VQhU97j094wMDx0QRumYC zZiU8kN8KQ5FU1SiGMBbY+1SvopkNDu0eP0QUl/D93mDOLc2zUdRN5QANv/FfBaliKNvxBzL4 LLQK+43A0YcXsbBaWd0/svxJwCKNiHeDfojIaJI45IbRTtMpMvhOKgeJgEGQLPYyuTPPx+Gn8 7n4GeLivx7e5GuQLn/vPvAILTlTL1M6tdCbuPTVBR8YzhGBD64mGImNyzQ59hcgnB1q8UE7GQ MnFT4Lkis0Th5dc1AK3A9xtX1bY1UCLoGMGK/JwUzlEPq+C307akLvBxfh6R0XbBjqh5YKhLn tUVSBEkEFLSuAIK331nY3f02htE+WDg4Wp4kOrnLrRJpvEne26dRBWoA3lwE0LPXYbl0= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 21:33:56 -0000 Hi, On Monday, 21. Dec 2015, 17:43:38 +0100, Bertram Scharpf wrote: > in my "/etc/printcap", the "if" field points to an input > filter I wrote in Ruby. There, the first line is a shebang > saying > > #!/usr/bin/env ruby > > Further there is > > # procstat -e `pgrep lpd` > PID COMM ENVIRONMENT > 940 lpd PATH=/sbin:/bin:/usr/sbin:/usr/bin PWD=/ HOME=/ RC_PID=20 > > As you can easily see, I will receive a mail saying the > print job failed because of > > env: ruby: No such file or directory > > When I restart "lpd" from the command line, the new process > receives the environment variables from the shell process > and everything ist fine. > > [...] > > "/etc/crontab" allows to reset the PATH variable but I do > not see a way to do the same in "/etc/printcap". I decided unhesitatingly to extend the lpd printcap mechanism and I added a filter-path variable that will be put into the filter processes before calling exec there. I think this should be part of the official FreeBSD release. Where is the right place to propose it? Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From owner-freebsd-hackers@freebsd.org Wed Dec 23 21:57:02 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89B18A5087E for ; Wed, 23 Dec 2015 21:57:02 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7390E152A for ; Wed, 23 Dec 2015 21:57:02 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: by mailman.ysv.freebsd.org (Postfix) id 707ECA5087D; Wed, 23 Dec 2015 21:57:02 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 700E1A5087C for ; Wed, 23 Dec 2015 21:57:02 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oitsec.umn.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C67A1529 for ; Wed, 23 Dec 2015 21:57:02 +0000 (UTC) (envelope-from amesbury@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id E82D65C80C for ; Wed, 23 Dec 2015 15:56:53 -0600 (CST) X-Virus-Scanned: amavisd-new at oitsec.umn.edu Received: from mail.oitsec.umn.edu ([127.0.0.1]) by mail.oitsec.umn.edu (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCul24txdyOO for ; Wed, 23 Dec 2015 15:56:52 -0600 (CST) Received: from optimator.oitsec.umn.edu (optimator.oitsec.umn.edu [134.84.23.1]) (Authenticated sender: amesbury) by mail.oitsec.umn.edu (Postfix) with ESMTPSA id B0F2D5C80A for ; Wed, 23 Dec 2015 15:56:52 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: The minimum amount of memory needed to use ZFS. From: Alan Amesbury In-Reply-To: <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> Date: Wed, 23 Dec 2015 15:56:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <411CC5EB-012B-43FC-B7E0-5D09D3CA3E55@oitsec.umn.edu> References: <20151223121445.GA85016@ozzmosis.com> <26557C02-C591-4232-BBD0-988B0EB89575@gid.co.uk> To: hackers@freebsd.org X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 21:57:02 -0000 On Dec 23, 2015, at 11:53 , Bob Bishop wrote: [snip] > Deduplication seems like a very bad idea unless you have both a lot of = duplicated data and a serious shortage of disk. It needs a lot of RAM, = increasing over time. Depending on the hardware and the use case, = compression (which effectively only costs CPU) might be a better option. Agreed: Deduplication isn't something you want to enable until you're = sure you have a workload that's suitable for it. Memory usage increases = on Freebsd to an estimated 2-5GB per terabyte of zpool[1]. Oracle has = published[2] some information on deduplication in ZFS, too, which = parallels information in the FreeBSD wiki, namely the use of 'zdb' to = analyze your data to determine if deduplication is even worthwhile. = Note this can take a while to run and, at least for me, had issues = running on at least one of my hosts. Output is pretty straightforward. For example: # zdb -S pool Simulated DDT histogram: bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 4.94M 578G 577G 579G 4.94M 578G 577G 579G 2 416K 50.5G 50.5G 50.5G 922K 112G 112G 112G 4 39.6K 4.89G 4.89G 4.89G 175K 21.6G 21.6G 21.6G 8 3.06K 382M 381M 382M 31.6K 3.85G 3.84G 3.85G 16 306 34.4M 33.3M 33.4M 5.81K 665M 639M 641M 32 62 6.13M 4.99M 5.04M 2.77K 281M 230M 232M 64 41 4.88M 4.88M 4.88M 3.56K 432M 432M 433M 128 25 3.12M 3.12M 3.12M 4.37K 560M 560M 560M 256 71 8.88M 8.88M 8.88M 20.4K 2.56G 2.56G 2.56G 512 2 256K 256K 256K 1.27K 163M 163M 163M 2K 2 256K 256K 256K 4.19K 536M 536M 536M 128K 1 128K 128K 128K 148K 18.4G 18.4G 18.4G Total 5.39M 634G 633G 634G 6.23M 739G 739G 740G dedup =3D 1.17, compress =3D 1.00, copies =3D 1.00, dedup * compress / = copies =3D 1.17 For this host there's some evidence that deduplication might buy me a = small amount of additional space, but I'd rather allocate RAM to the ARC = for performance instead of using it for what looks like a small = reduction in space usage. For my workloads, I tend to get a much bigger = boost from using compression, as modern CPUs can typically compress = pretty close to the speed of rotational media. (SSDs would be a = different story.) Example 'zdb -S' output from a host using = compression: # zdb -S pool Simulated DDT histogram: bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 8.25M 1008G 80.6G 80.6G 8.25M 1008G 80.6G 80.6G 2 697 76.4M 21.3M 21.3M 1.46K 160M 44.8M 44.8M 4 1.05K 10.2M 3.34M 3.34M 5.15K 48.6M 15.9M 15.9M 8 65 1.09M 318K 318K 649 10.8M 3.06M 3.06M 16 23 904K 300K 300K 558 20.1M 6.55M 6.55M 32 18 1.78M 681K 681K 770 74.2M 27.7M 27.7M 64 29 3.27M 1.23M 1.23M 2.61K 305M 115M 115M 128 15 1.41M 536K 536K 2.38K 209M 77.3M 77.3M Total 8.25M 1008G 80.6G 80.6G 8.26M 1009G 80.9G 80.9G dedup =3D 1.00, compress =3D 12.47, copies =3D 1.00, dedup * compress / = copies =3D 12.51 The data, primarily textual log files of some kind, compresses pretty = well. --=20 Alan Amesbury University Information Security http://umn.edu/lookup/amesbury [1] - https://wiki.freebsd.org/ZFSTuningGuide#Deduplication [2] - = http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-s= ize-zfs-dedup-1354231.html= From owner-freebsd-hackers@freebsd.org Wed Dec 23 21:35:29 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66680A50F7B; Wed, 23 Dec 2015 21:35:29 +0000 (UTC) (envelope-from vsasjason@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 066A81510; Wed, 23 Dec 2015 21:35:29 +0000 (UTC) (envelope-from vsasjason@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id p187so160961372wmp.1; Wed, 23 Dec 2015 13:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0F2IHeRQ64w18PCpVPEB53eoRa0dGT+Q71C17iBbv9o=; b=KA976zFCzf6zc1JAKmjYWv8JXl23clMvR5GETp4weMipOkLB1/RMUOqddb4nrdT8pr juh8Ve4TS3403duYN98OKnof/Mr+2UR/chXlBMK2CNtT/t9pGMX/aewQGJcEj//+8ll2 gMCw25vWtuPsf3pbfxB0wkPyuwB43Yc7A0c32eHWzqXHJsEXyih950m/oUB1hKOoeyHT HAbRTcdf36jHKJ7gHk1RL/zi8SrNI1/hvVT1fBt7VexoIZN/KhQTIzf91LHMdOTBkrzQ oJYeloQoQzkKuFTXSseM76fKzzzXC1voOXVrNXSeE7ud6UqHGEuaU1B/wNb1o9ZJF+Yq 3cog== MIME-Version: 1.0 X-Received: by 10.28.141.140 with SMTP id p134mr36500239wmd.6.1450906527390; Wed, 23 Dec 2015 13:35:27 -0800 (PST) Received: by 10.194.76.207 with HTTP; Wed, 23 Dec 2015 13:35:26 -0800 (PST) Received: by 10.194.76.207 with HTTP; Wed, 23 Dec 2015 13:35:26 -0800 (PST) In-Reply-To: <20151223213351.GA1304@becker.bs.l> References: <20151221164338.GB33124@becker.bs.l> <20151223213351.GA1304@becker.bs.l> Date: Thu, 24 Dec 2015 00:35:26 +0300 Message-ID: Subject: Re: PATH variable in lpd's process From: Anton Sayetsky To: FreeBSD Questions , freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 23 Dec 2015 22:19:01 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 21:35:29 -0000 23 =D0=B4=D0=B5=D0=BA. 2015 =D0=B3. 23:34 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0= =BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Bertram Scharpf" < lists@bertram-scharpf.de> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > Hi, > > On Monday, 21. Dec 2015, 17:43:38 +0100, Bertram Scharpf wrote: > > in my "/etc/printcap", the "if" field points to an input > > filter I wrote in Ruby. There, the first line is a shebang > > saying > > > > #!/usr/bin/env ruby > > > > Further there is > > > > # procstat -e `pgrep lpd` > > PID COMM ENVIRONMENT > > 940 lpd PATH=3D/sbin:/bin:/usr/sbin:/usr/bin PWD=3D/ HOME=3D/ RC_PID=3D20 > > > > As you can easily see, I will receive a mail saying the > > print job failed because of > > > > env: ruby: No such file or directory > > > > When I restart "lpd" from the command line, the new process > > receives the environment variables from the shell process > > and everything ist fine. > > > > [...] > > > > "/etc/crontab" allows to reset the PATH variable but I do > > not see a way to do the same in "/etc/printcap". > > I decided unhesitatingly to extend the lpd printcap > mechanism and I added a filter-path variable that will be > put into the filter processes before calling exec there. > > I think this should be part of the official FreeBSD release. > Where is the right place to propose it? http://bugs.FreeBSD.org From owner-freebsd-hackers@freebsd.org Thu Dec 24 01:45:09 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43A06A4E326 for ; Thu, 24 Dec 2015 01:45:09 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1C01B52 for ; Thu, 24 Dec 2015 01:45:08 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id tBO1igUL068293 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Dec 2015 17:44:42 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? To: Daniel Braniss , Rick Macklem References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> Cc: Freebsd hackers list From: Yuri Message-ID: <567B4E08.1000204@rawbw.com> Date: Wed, 23 Dec 2015 17:44:40 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 01:45:09 -0000 On 12/22/2015 01:34, Daniel Braniss wrote: > I have been using unionfs for a very long time, mounting /etc (nfs read only) and md > whiteout any problems. I’m not sure if i tested it on 11, but i will soon. > yes, it can be problematic for other crazy things, but in my case, where many of > my hosts are dataless so the unionfs is a great simplifier:-) > > just my 2 cents. > I tried to replace nullfs+unionfs with unionfs+unionfs, and got the same messages using the kernel with the same debug options. So it is dangerous. Yuri From owner-freebsd-hackers@freebsd.org Thu Dec 24 04:16:17 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0787CA50614 for ; Thu, 24 Dec 2015 04:16:17 +0000 (UTC) (envelope-from joe@via.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E72A31B19 for ; Thu, 24 Dec 2015 04:16:16 +0000 (UTC) (envelope-from joe@via.net) Received: by mailman.ysv.freebsd.org (Postfix) id E5241A50611; Thu, 24 Dec 2015 04:16:16 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3DD0A5060F for ; Thu, 24 Dec 2015 04:16:16 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp2.via.net (smtp2.via.net [209.81.9.14]) (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 CECE31B18 for ; Thu, 24 Dec 2015 04:16:16 +0000 (UTC) (envelope-from joe@via.net) Received: from mail.via.net (mail.via.net [209.81.9.12]) by smtp2.via.net (8.14.1/8.14.1-VIANET) with ESMTP id tBO4B3hb028871 for ; Wed, 23 Dec 2015 20:11:03 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at smtp2.via.net Received: from 91-2.via.net (91-2.via.net [209.81.2.91] (may be forged)) (authenticated bits=0) by mail.via.net (8.14.1/8.14.1-VIANET) with ESMTP id tBO4B2BO009575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Dec 2015 20:11:02 -0800 (PST) From: joe mcguckin Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: ZFS questions, ZFS hang Message-Id: Date: Wed, 23 Dec 2015 20:09:36 -0800 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (smtp2.via.net [209.81.9.14]); Wed, 23 Dec 2015 20:11:03 -0800 (PST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 04:16:17 -0000 I have a dual xeon w 16G of ram and 16 drives that I=E2=80=99m using to = play around with zfs. I was running the 32 bit kernel and everything seemed to work ok. I = upgraded to the amd 64 bit kernel and I=E2=80=99m seeing the box hang under load. No error messages = - it just goes catatonic. I=E2=80=99m running the GENERIC kernel. Are there any recommended kernel = settings I should be using? Thanks, Joe From owner-freebsd-hackers@freebsd.org Thu Dec 24 07:10:18 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C77EA50983 for ; Thu, 24 Dec 2015 07:10:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 58B451989 for ; Thu, 24 Dec 2015 07:10:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aC02L-0006vk-DR; Thu, 24 Dec 2015 09:10:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? From: Daniel Braniss In-Reply-To: <567B4E08.1000204@rawbw.com> Date: Thu, 24 Dec 2015 09:10:09 +0200 Cc: Rick Macklem , Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <2B571D55-0B24-4E75-AA5B-4CCF9D3B8CD5@cs.huji.ac.il> References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> <567B4E08.1000204@rawbw.com> To: Yuri X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 07:10:18 -0000 > On 24 Dec 2015, at 03:44, Yuri wrote: >=20 > On 12/22/2015 01:34, Daniel Braniss wrote: >> I have been using unionfs for a very long time, mounting /etc (nfs = read only) and md >> whiteout any problems. I=E2=80=99m not sure if i tested it on 11, but = i will soon. >> yes, it can be problematic for other crazy things, but in my case, = where many of >> my hosts are dataless so the unionfs is a great simplifier:-) >>=20 >> just my 2 cents. >>=20 >=20 > I tried to replace nullfs+unionfs with unionfs+unionfs, and got the = same messages using the kernel with the same debug options. > So it is dangerous. >=20 I just turned off WITNESS/INVARIANTS :-) the only complain I get is when I do a mountd restart, but it=E2=80=99s = harmless. danny > Yuri >=20 From owner-freebsd-hackers@freebsd.org Thu Dec 24 07:41:09 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B880AA50173 for ; Thu, 24 Dec 2015 07:41:09 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id A51BC1367 for ; Thu, 24 Dec 2015 07:41:09 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id tBO7ewLX097012 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Dec 2015 23:40:59 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? To: Daniel Braniss References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> <567B4E08.1000204@rawbw.com> <2B571D55-0B24-4E75-AA5B-4CCF9D3B8CD5@cs.huji.ac.il> Cc: Freebsd hackers list , Rick Macklem From: Yuri Message-ID: <567BA189.8080405@rawbw.com> Date: Wed, 23 Dec 2015 23:40:57 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2B571D55-0B24-4E75-AA5B-4CCF9D3B8CD5@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 07:41:09 -0000 On 12/23/2015 23:10, Daniel Braniss wrote: > I just turned off WITNESS/INVARIANTS:-) > the only complain I get is when I do a mountd restart, but it’s harmless. Which OS version? I get the messages on 10.2-STABLE with options from my OP. Endless messages like this: Dec 23 17:59:36 yuri kernel: KDB: stack backtrace: Dec 23 17:59:36 yuri kernel: #0 0xffffffff8097c810 at kdb_backtrace+0x60 Dec 23 17:59:36 yuri kernel: #1 0xffffffff809eae7e at assert_vop_elocked+0x6e Dec 23 17:59:36 yuri kernel: #2 0xffffffff809ea6b1 at insmntque1+0x41 Dec 23 17:59:36 yuri kernel: #3 0xffffffff82e202a1 at unionfs_nodeget+0x281 Dec 23 17:59:36 yuri kernel: #4 0xffffffff82e23b06 at unionfs_lookup+0x726 Dec 23 17:59:36 yuri kernel: #5 0xffffffff80e7776f at VOP_CACHEDLOOKUP_APV+0x10f Dec 23 17:59:36 yuri kernel: #6 0xffffffff809d92b6 at vfs_cache_lookup+0xd6 Dec 23 17:59:36 yuri kernel: #7 0xffffffff80e775af at VOP_LOOKUP_APV+0x10f Dec 23 17:59:36 yuri kernel: #8 0xffffffff809e1892 at lookup+0x5c2 Dec 23 17:59:36 yuri kernel: #9 0xffffffff809e0fb4 at namei+0x4e4 Dec 23 17:59:36 yuri kernel: #10 0xffffffff809f683e at kern_statat_vnhook+0xae Dec 23 17:59:36 yuri kernel: #11 0xffffffff809f66cd at sys_stat+0x2d Dec 23 17:59:36 yuri kernel: #12 0xffffffff80d4fff4 at amd64_syscall+0x2c4 Dec 23 17:59:36 yuri kernel: #13 0xffffffff80d339db at Xfast_syscall+0xfb Dec 23 17:59:36 yuri kernel: insmntque: non-locked vp: 0xfffff80046d233b0 is not exclusive locked but should be Yuri From owner-freebsd-hackers@freebsd.org Thu Dec 24 07:50:47 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68C76A5050F for ; Thu, 24 Dec 2015 07:50:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 58E951886 for ; Thu, 24 Dec 2015 07:50:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 555F9A5050E; Thu, 24 Dec 2015 07:50:47 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54FB4A5050D for ; Thu, 24 Dec 2015 07:50:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1846A1882 for ; Thu, 24 Dec 2015 07:50:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aC0fZ-000ISL-OF; Thu, 24 Dec 2015 10:50:41 +0300 Date: Thu, 24 Dec 2015 10:50:41 +0300 From: Slawa Olhovchenkov To: joe mcguckin Cc: hackers@freebsd.org Subject: Re: ZFS questions, ZFS hang Message-ID: <20151224075041.GD4535@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 07:50:47 -0000 On Wed, Dec 23, 2015 at 08:09:36PM -0800, joe mcguckin wrote: > I have a dual xeon w 16G of ram and 16 drives that I’m using to play around with zfs. > > I was running the 32 bit kernel and everything seemed to work ok. I upgraded to the amd 64 bit > kernel and I’m seeing the box hang under load. No error messages - it just goes catatonic. > > I’m running the GENERIC kernel. Are there any recommended kernel settings I should be using? Update to STABLE, some related bug found and fixed. From owner-freebsd-hackers@freebsd.org Thu Dec 24 08:56:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3605A51ADE for ; Thu, 24 Dec 2015 08:56:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 8F28C1887 for ; Thu, 24 Dec 2015 08:56:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aC1gv-0008MC-Kp; Thu, 24 Dec 2015 10:56:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? From: Daniel Braniss In-Reply-To: <567BA189.8080405@rawbw.com> Date: Thu, 24 Dec 2015 10:56:09 +0200 Cc: Freebsd hackers list , Rick Macklem Content-Transfer-Encoding: quoted-printable Message-Id: References: <567791E9.50207@rawbw.com> <56779542.8020205@rawbw.com> <1331010544.139156804.1450706805234.JavaMail.zimbra@uoguelph.ca> <567B4E08.1000204@rawbw.com> <2B571D55-0B24-4E75-AA5B-4CCF9D3B8CD5@cs.huji.ac.il> <567BA189.8080405@rawbw.com> To: Yuri X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 08:56:20 -0000 > On 24 Dec 2015, at 09:40, Yuri wrote: >=20 > On 12/23/2015 23:10, Daniel Braniss wrote: >> I just turned off WITNESS/INVARIANTS:-) >> the only complain I get is when I do a mountd restart, but it=E2=80=99s= harmless. >=20 > Which OS version? I get the messages on 10.2-STABLE with options from = my OP. >=20 > Endless messages like this: > Dec 23 17:59:36 yuri kernel: KDB: stack backtrace: > Dec 23 17:59:36 yuri kernel: #0 0xffffffff8097c810 at = kdb_backtrace+0x60 > Dec 23 17:59:36 yuri kernel: #1 0xffffffff809eae7e at = assert_vop_elocked+0x6e > Dec 23 17:59:36 yuri kernel: #2 0xffffffff809ea6b1 at insmntque1+0x41 > Dec 23 17:59:36 yuri kernel: #3 0xffffffff82e202a1 at = unionfs_nodeget+0x281 > Dec 23 17:59:36 yuri kernel: #4 0xffffffff82e23b06 at = unionfs_lookup+0x726 > Dec 23 17:59:36 yuri kernel: #5 0xffffffff80e7776f at = VOP_CACHEDLOOKUP_APV+0x10f > Dec 23 17:59:36 yuri kernel: #6 0xffffffff809d92b6 at = vfs_cache_lookup+0xd6 > Dec 23 17:59:36 yuri kernel: #7 0xffffffff80e775af at = VOP_LOOKUP_APV+0x10f > Dec 23 17:59:36 yuri kernel: #8 0xffffffff809e1892 at lookup+0x5c2 > Dec 23 17:59:36 yuri kernel: #9 0xffffffff809e0fb4 at namei+0x4e4 > Dec 23 17:59:36 yuri kernel: #10 0xffffffff809f683e at = kern_statat_vnhook+0xae > Dec 23 17:59:36 yuri kernel: #11 0xffffffff809f66cd at sys_stat+0x2d > Dec 23 17:59:36 yuri kernel: #12 0xffffffff80d4fff4 at = amd64_syscall+0x2c4 > Dec 23 17:59:36 yuri kernel: #13 0xffffffff80d339db at = Xfast_syscall+0xfb > Dec 23 17:59:36 yuri kernel: insmntque: non-locked vp: = 0xfffff80046d233b0 is not exclusive locked but should be >=20 > Yuri i have been using unionfs since it appeared, and on 10.2-stable, but i = don=E2=80=99t have WITNESS on. BTW, it=E2=80=99s very slow if you turn WITNESS on, and so should only = be used for debugging, and in some cases, the code actually works only if WITNESS is on :-( danny From owner-freebsd-hackers@freebsd.org Thu Dec 24 13:23:41 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8CE9A503D4; Thu, 24 Dec 2015 13:23:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73F8C10F8; Thu, 24 Dec 2015 13:23:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA11069; Thu, 24 Dec 2015 15:23:28 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aC5rb-000Cd9-PX; Thu, 24 Dec 2015 15:23:27 +0200 To: freebsd-gecko@FreeBSD.org From: Andriy Gapon Subject: firefox crashes during pkg upgrade X-Enigmail-Draft-Status: N1110 Cc: FreeBSD Hackers Message-ID: <567BF197.10908@FreeBSD.org> Date: Thu, 24 Dec 2015 15:22:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 13:23:41 -0000 Greetings! I've got a strange problem: sometime when I do pkg upgrade a firefox process crashes with SIGBUS. And that happens rather often. For example, the last upgrade did the following package upgrades: Installed packages to be UPGRADED: rubygem-bundler: 1.10.6 -> 1.11.2 [FreeBSD] pylint-py27: 1.4.3_1 -> 1.5.1 [FreeBSD] py27-logilab-common: 0.63.2 -> 1.1.0 [FreeBSD] py27-astroid: 1.3.6 -> 1.4.1 [FreeBSD] php5-libphutil: 20150626 -> 20151220 [FreeBSD] php5-arcanist: 20150626_2 -> 20151220 [FreeBSD] m17n-db: 1.6.5 -> 1.7.0 [FreeBSD] libvterm: git20150527 -> git20150828 [FreeBSD] fribidi: 0.19.2_3 -> 0.19.7 [FreeBSD] dmidecode: 2.12_2 -> 3.0 [FreeBSD] chromium: 47.0.2526.80 -> 47.0.2526.106 [FreeBSD] The process will require 2 MiB more space. 43 MiB to be downloaded. At the first glance none of those packages seem to be related to firefox. Also, I would guess that even if a shared library used by firefox would be upgraded, then either the old version would be unlinked first and firefox would keep using it, or there would be an error (ETXTBSY) if there would be an attempt to write to the shared library while it's being used. The core dump seems to be useless: Core was generated by `firefox'. Program terminated with signal SIGBUS, Bus error. #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 [Current thread is 60 (Thread 801a0d000 (LWP 101727))] (gdb) bt #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 #1 0x000000080ed6815e in ?? () from /usr/local/lib/libgio-2.0.so.0 #2 0x000000080ed68af8 in ?? () from /usr/local/lib/libgio-2.0.so.0 #3 0x000000080ddde7b5 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #4 0x000000080dddeacb in ?? () from /usr/local/lib/libglib-2.0.so.0 #5 0x000000080dddeb54 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #6 0x0000000803e134cc in ?? () from /usr/local/lib/firefox/libxul.so #7 0x0000000803de6c24 in ?? () from /usr/local/lib/firefox/libxul.so #8 0x0000000803de6cdd in ?? () from /usr/local/lib/firefox/libxul.so #9 0x000000080259945f in ?? () from /usr/local/lib/firefox/libxul.so #10 0x00000008025be1f3 in ?? () from /usr/local/lib/firefox/libxul.so #11 0x000000080282436e in ?? () from /usr/local/lib/firefox/libxul.so #12 0x0000000802808c68 in ?? () from /usr/local/lib/firefox/libxul.so #13 0x0000000803de694b in ?? () from /usr/local/lib/firefox/libxul.so #14 0x00000008045d47be in ?? () from /usr/local/lib/firefox/libxul.so #15 0x00000008046243be in ?? () from /usr/local/lib/firefox/libxul.so #16 0x0000000804624655 in ?? () from /usr/local/lib/firefox/libxul.so #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so #18 0x0000000000405abf in ?? () #19 0x00000000004054df in _start () Although, hmm: (gdb) disassemble 0x000000080ed69c70,+48 Dump of assembler code from 0x80ed69c70 to 0x80ed69ca0: 0x000000080ed69c70: add %al,(%rax) 0x000000080ed69c72: mov $0x18,%esi 0x000000080ed69c77: callq 0x80ec98ff4 0x000000080ed69c7c: mov %rax,%r13 0x000000080ed69c7f: xor %r15d,%r15d 0x000000080ed69c82: test %r13,%r13 0x000000080ed69c85: je 0x80ed69cf0 0x000000080ed69c87: mov %r13,%r15 0x000000080ed69c8a: mov %r14,%rbx 0x000000080ed69c8d: nopl (%rax) => 0x000000080ed69c90: mov 0x8(%rbx),%rax 0x000000080ed69c94: mov %rax,0x8(%r13) 0x000000080ed69c98: mov 0x10(%rbx),%eax 0x000000080ed69c9b: mov %eax,0x10(%r13) 0x000000080ed69c9f: cmpq $0x0,(%rbx) End of assembler dump. (gdb) i reg rax 0x81f542d60 34885348704 rbx 0x5a5a5a5a5a5a5a5a 6510615555426900570 rcx 0x20 32 rdx 0x0 0 rsi 0x0 0 rdi 0x81f542d80 34885348736 rbp 0x7fffffffd850 0x7fffffffd850 rsp 0x7fffffffd7e0 0x7fffffffd7e0 r8 0x20 32 r9 0xfffff80000000000 -8796093022208 r10 0x1 1 r11 0x81f542d60 34885348704 r12 0x81ccb0300 34842804992 r13 0x81f542d60 34885348704 r14 0x81f5540a0 34885419168 r15 0x81f542d40 34885348672 rip 0x80ed69c90 0x80ed69c90 eflags 0x10206 [ PF IF RF ] cs 0x43 67 ss 0x3b 59 ds es fs gs Seems like %rbx has a value characteristic of free-d memory. But I am not sure at all how this fact could be connected to pkg upgrade... Perhaps a change in the file system triggers a bug in libgio somewhere. Update. Surprisingly[?], the old base gdb produces a better[?] stack trace: (kgdb) bt #0 0x000000080ed69c90 in g_local_file_monitor_get_type () from /usr/local/lib/libgio-2.0.so.0 #1 0x000000080ed6815e in g_local_file_monitor_get_type () from /usr/local/lib/libgio-2.0.so.0 #2 0x000000080ed68af8 in g_local_file_monitor_get_type () from /usr/local/lib/libgio-2.0.so.0 #3 0x000000080ddde7b5 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #4 0x000000080dddeacb in g_main_context_pending () from /usr/local/lib/libglib-2.0.so.0 #5 0x000000080dddeb54 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #6 0x0000000803e134cc in std::__1::__tree, std::__1::allocator >::destroy () from /usr/local/lib/firefox/libxul.so #7 0x0000000803de6c24 in std::__1::__tree, std::__1::allocator >::destroy () from /usr/local/lib/firefox/libxul.so #8 0x0000000803de6cdd in std::__1::__tree, std::__1::allocator >::destroy () from /usr/local/lib/firefox/libxul.so #9 0x000000080259945f in XRE_AddJarManifestLocation () from /usr/local/lib/firefox/libxul.so #10 0x00000008025be1f3 in std::__1::vector >::__push_back_slow_path () from /usr/local/lib/firefox/libxul.so #11 0x000000080282436e in std::__1::vector, std::__1::allocator > >::__push_back_slow_path > () from /usr/local/lib/firefox/libxul.so #12 0x0000000802808c68 in std::__1::vector, std::__1::allocator >, std::__1::allocator, std::__1::allocator > > >::insert, std::__1::allocator >*> > () from /usr/local/lib/firefox/libxul.so #13 0x0000000803de694b in std::__1::__tree, std::__1::allocator >::destroy () from /usr/local/lib/firefox/libxul.so #14 0x00000008045d47be in XRE_StartupTimelineRecord () from /usr/local/lib/firefox/libxul.so #15 0x00000008046243be in XRE_InitCommandLine () from /usr/local/lib/firefox/libxul.so #16 0x0000000804624655 in XRE_GlibInit () from /usr/local/lib/firefox/libxul.so #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so #18 0x0000000000405abf in _start () #19 0x00000000004054df in _start () #20 0x0000000800640000 in ?? () #21 0x0000000000000000 in ?? () >From the disassembly, though, I can see that several different functions are reported as g_local_file_monitor_get_type(), e.g.: 0x000000080ed69c40 : push %rbp 0x000000080ed69c41 : mov %rsp,%rbp 0x000000080ed69c44 : push %r15 0x000000080ed69c46 : push %r14 0x000000080ed69c48 : push %r13 0x000000080ed69c4a : push %r12 0x000000080ed69c4c : push %rbx 0x000000080ed69c4d : sub $0x48,%rsp 0x000000080ed69c51 : mov %rcx,-0x50(%rbp) 0x000000080ed69c55 : mov %rdx,-0x48(%rbp) ... I've found a report that seems to be related: https://forums.freebsd.org/threads/gtk-programs-core-dump.54462/ -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Dec 24 17:25:45 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15AC1A511A5; Thu, 24 Dec 2015 17:25:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E982113D5; Thu, 24 Dec 2015 17:25:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C9FD2B989; Thu, 24 Dec 2015 12:25:43 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Arlie Stephens , hackers@freebsd.org Subject: Re: Examining Page Tables in Kernel Crash Dumps (amd64) Date: Thu, 24 Dec 2015 08:10:17 -0800 Message-ID: <2188443.PY7dC12t9i@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20151222235920.GA21736@worldash.org> References: <20151222235920.GA21736@worldash.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 24 Dec 2015 12:25:43 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 17:25:45 -0000 On Tuesday, December 22, 2015 03:59:20 PM Arlie Stephens wrote: > I'm chasing a bug in an elderly, customized freebsd kernel that appears to > result in corrupted page tables. > > kgdb is not cooperating when I attempt to look at addresses of kernel > page tables. I've replicated that part on an elderly stock freebsd > system, running freebsd 8.4. , and it looks to me like it's probably > getting that limitation from libkvm. > > Obviously I don't expect community help with an ancient freebsd > issue... particularly one probably caused by our own customizations. > > But given the tool chain changes upstream, I don't expect testing with > whatever kgdb has turned into there to be very relevant ;-( > > So far, the only way I know to get a look at kernel page table > contents in FreeBSD is on live systems with ddb. > > I would like to know whether there are any tools I haven't noticed for > dealing with page tables in crash dumps - or, for that matter, whether > kgdb is supposed to be able to display the kernel's recursive page > tables. > > Failing that, I may just have to write one ;-) (Or figure out how to > chase my problem on live systems.) kgdb depends on libkvm to handle translations of virtual addresses to offsets in the vmcore file (which is then used by kvm_read to read the relevant data). On amd64 you can cheat a bit by using direct map addresses (I use this in my gdb macros to walk the page tables by hand so I can look at raw PDEs, PTEs, etc.). (For the macros I use you can look at www.freebsd.org/~jhb/gdb/gdb6.amd64) Normally you download the files there and do 'source gdb6' which will pull in gdb6.amd64. The 'pmap_*' macros try to replicate the behavior of the equivalent functions in pmap.c. -- John Baldwin From owner-freebsd-hackers@freebsd.org Thu Dec 24 17:25:43 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F9CA5119B for ; Thu, 24 Dec 2015 17:25:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AA9D1339; Thu, 24 Dec 2015 17:25:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8BE9EB97A; Thu, 24 Dec 2015 12:25:42 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Daniel Braniss , Yuri , Rick Macklem , 'Konstantin Belousov' Subject: Re: Should DEBUG_VFS_LOCKS messages be reported as bugs? Date: Thu, 24 Dec 2015 09:19:34 -0800 Message-ID: <4247765.dyXyDaofWi@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <567791E9.50207@rawbw.com> <567BA189.8080405@rawbw.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 24 Dec 2015 12:25:42 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 17:25:43 -0000 On Thursday, December 24, 2015 10:56:09 AM Daniel Braniss wrote: >=20 > > On 24 Dec 2015, at 09:40, Yuri wrote: > >=20 > > On 12/23/2015 23:10, Daniel Braniss wrote: > >> I just turned off WITNESS/INVARIANTS:-) > >> the only complain I get is when I do a mountd restart, but it=E2=80= =99s harmless. > >=20 > > Which OS version? I get the messages on 10.2-STABLE with options fr= om my OP. > >=20 > > Endless messages like this: > > Dec 23 17:59:36 yuri kernel: KDB: stack backtrace: > > Dec 23 17:59:36 yuri kernel: #0 0xffffffff8097c810 at kdb_backtrace= +0x60 > > Dec 23 17:59:36 yuri kernel: #1 0xffffffff809eae7e at assert_vop_el= ocked+0x6e > > Dec 23 17:59:36 yuri kernel: #2 0xffffffff809ea6b1 at insmntque1+0x= 41 > > Dec 23 17:59:36 yuri kernel: #3 0xffffffff82e202a1 at unionfs_nodeg= et+0x281 > > Dec 23 17:59:36 yuri kernel: #4 0xffffffff82e23b06 at unionfs_looku= p+0x726 > > Dec 23 17:59:36 yuri kernel: #5 0xffffffff80e7776f at VOP_CACHEDLOO= KUP_APV+0x10f > > Dec 23 17:59:36 yuri kernel: #6 0xffffffff809d92b6 at vfs_cache_loo= kup+0xd6 > > Dec 23 17:59:36 yuri kernel: #7 0xffffffff80e775af at VOP_LOOKUP_AP= V+0x10f > > Dec 23 17:59:36 yuri kernel: #8 0xffffffff809e1892 at lookup+0x5c2 > > Dec 23 17:59:36 yuri kernel: #9 0xffffffff809e0fb4 at namei+0x4e4 > > Dec 23 17:59:36 yuri kernel: #10 0xffffffff809f683e at kern_statat_= vnhook+0xae > > Dec 23 17:59:36 yuri kernel: #11 0xffffffff809f66cd at sys_stat+0x2= d > > Dec 23 17:59:36 yuri kernel: #12 0xffffffff80d4fff4 at amd64_syscal= l+0x2c4 > > Dec 23 17:59:36 yuri kernel: #13 0xffffffff80d339db at Xfast_syscal= l+0xfb > > Dec 23 17:59:36 yuri kernel: insmntque: non-locked vp: 0xfffff80046= d233b0 is not exclusive locked but should be > >=20 > > Yuri >=20 > i have been using unionfs since it appeared, and on 10.2-stable, but = i don=E2=80=99t have WITNESS on. > BTW, it=E2=80=99s very slow if you turn WITNESS on, and so should onl= y be used for debugging, and in some > cases, the code actually works only if WITNESS is on :-( This isn't witness, this is DEBUG_VFS_LOCKS. DEBUG_VFS_LOCKS turns on assertions for vnode locks that are normally under INVARIANTS for other= locks. In this case unionfs is doing the insmntque() too early. It pr= obably needs to lock the lockmgr lock sooner (though it has to wait until it s= ets v_vnlock) and only insmtque() after the vnode lock is held. Here's a rough attempt at fixing this. I have not tested it though and= it might be very wrong. Index: union_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- union_subr.c=09(revision 292560) +++ union_subr.c=09(working copy) @@ -105,7 +105,7 @@ unionfs_get_hashhead(struct vnode *dvp, char *path */ static struct vnode * unionfs_get_cached_vnode(struct vnode *uvp, struct vnode *lvp, -=09=09=09struct vnode *dvp, char *path) + struct vnode *dvp, char *path, int flags, struct thread *td) { =09struct unionfs_node_hashhead *hd; =09struct unionfs_node *unp; @@ -123,12 +123,9 @@ unionfs_get_cached_vnode(struct vnode *uvp, struct= =09=09=09vp =3D UNIONFSTOV(unp); =09=09=09VI_LOCK_FLAGS(vp, MTX_DUPOK); =09=09=09VI_UNLOCK(dvp); -=09=09=09vp->v_iflag &=3D ~VI_OWEINACT; -=09=09=09if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) !=3D 0) { -=09=09=09=09VI_UNLOCK(vp); -=09=09=09=09vp =3D NULLVP; -=09=09=09} else -=09=09=09=09VI_UNLOCK(vp); +=09=09=09error =3D vget(vp, flags | LK_INTERLOCK, td); +=09=09=09if (error) +=09=09=09=09return (NULLVP); =09=09=09return (vp); =09=09} =09} @@ -142,7 +139,7 @@ unionfs_get_cached_vnode(struct vnode *uvp, struct */ static struct vnode * unionfs_ins_cached_vnode(struct unionfs_node *uncp, -=09=09=09struct vnode *dvp, char *path) + struct vnode *dvp, char *path, int flags, struct thread *td) { =09struct unionfs_node_hashhead *hd; =09struct unionfs_node *unp; @@ -153,6 +150,7 @@ unionfs_ins_cached_vnode(struct unionfs_node *uncp =09KASSERT((uncp->un_lowervp=3D=3DNULLVP || uncp->un_lowervp->v_type=3D= =3DVDIR), =09 ("unionfs_ins_cached_vnode: v_type !=3D VDIR")); =20 +retry: =09VI_LOCK(dvp); =09hd =3D unionfs_get_hashhead(dvp, path); =09LIST_FOREACH(unp, hd, un_hash) { @@ -159,14 +157,10 @@ unionfs_ins_cached_vnode(struct unionfs_node *unc= p =09=09if (!strcmp(unp->un_path, path)) { =09=09=09vp =3D UNIONFSTOV(unp); =09=09=09VI_LOCK_FLAGS(vp, MTX_DUPOK); -=09=09=09vp->v_iflag &=3D ~VI_OWEINACT; -=09=09=09if ((vp->v_iflag & (VI_DOOMED | VI_DOINGINACT)) !=3D 0) { -=09=09=09=09LIST_INSERT_HEAD(hd, uncp, un_hash); -=09=09=09=09VI_UNLOCK(vp); -=09=09=09=09vp =3D NULLVP; -=09=09=09} else -=09=09=09=09VI_UNLOCK(vp); =09=09=09VI_UNLOCK(dvp); +=09=09=09error =3D vget(vp2, flags | LK_INTERLOCK, td); +=09=09=09if (error =3D=3D ENOENT && (flags & LK_NOWAIT) =3D=3D 0) +=09=09=09=09goto retry; =09=09=09return (vp); =09=09} =09} @@ -218,7 +212,7 @@ unionfs_nodeget(struct mount *mp, struct vnode *up =09char=09 *path; =20 =09ump =3D MOUNTTOUNIONFSMOUNT(mp); -=09lkflags =3D (cnp ? cnp->cn_lkflags : 0); +=09lkflags =3D (cnp ? cnp->cn_lkflags : LK_EXCLUSIVE); =09path =3D (cnp ? cnp->cn_nameptr : NULL); =09*vpp =3D NULLVP; =20 @@ -233,19 +227,30 @@ unionfs_nodeget(struct mount *mp, struct vnode *u= p =20 =09/* check the cache */ =09if (path !=3D NULL && dvp !=3D NULLVP && vt =3D=3D VDIR) { -=09=09vp =3D unionfs_get_cached_vnode(uppervp, lowervp, dvp, path); +=09=09vp =3D unionfs_get_cached_vnode(uppervp, lowervp, dvp, path, +=09=09 lkflags, td); =09=09if (vp !=3D NULLVP) { -=09=09=09vref(vp); =09=09=09*vpp =3D vp; -=09=09=09goto unionfs_nodeget_out; +=09=09=09return (0); =09=09} =09} =20 +=09/* +=09 * We must promote to an exclusive lock for vnode creation. This +=09 * can happen if lookup is passed LOCKSHARED. +=09 */ +=09if ((lkflags & LK_TYPE_MASK) =3D=3D LK_SHARED) { +=09=09lkflags &=3D ~LK_TYPE_MASK; +=09=09lkflags |=3D LK_EXCLUSIVE; +=09} + =09if ((uppervp =3D=3D NULLVP || ump->um_uppervp !=3D uppervp) || =09 (lowervp =3D=3D NULLVP || ump->um_lowervp !=3D lowervp)) { =09=09/* dvp will be NULLVP only in case of root vnode. */ -=09=09if (dvp =3D=3D NULLVP) +=09=09if (dvp =3D=3D NULLVP) { +=09=09=09*vpp =3D NULL; =09=09=09return (EINVAL); +=09=09} =09} =09unp =3D malloc(sizeof(struct unionfs_node), =09 M_UNIONFSNODE, M_WAITOK | M_ZERO); @@ -253,11 +258,19 @@ unionfs_nodeget(struct mount *mp, struct vnode *u= p =09error =3D getnewvnode("unionfs", mp, &unionfs_vnodeops, &vp); =09if (error !=3D 0) { =09=09free(unp, M_UNIONFSNODE); +=09=09*vpp =3D NULL; =09=09return (error); =09} +=09if (uppervp !=3D NULLVP) +=09=09vp->v_vnlock =3D uppervp->v_vnlock; +=09else +=09=09vp->v_vnlock =3D lowervp->v_vnlock; +=09lockmgr(vp->v_vnlock, LK_EXCLUSIVE, NULL); =09error =3D insmntque(vp, mp);=09/* XXX: Too early for mpsafe fs */ =09if (error !=3D 0) { +=09=09vput(vp); =09=09free(unp, M_UNIONFSNODE); +=09=09*vpp =3D NULL; =09=09return (error); =09} =09if (dvp !=3D NULLVP) @@ -275,10 +288,6 @@ unionfs_nodeget(struct mount *mp, struct vnode *up= =09unp->un_uppervp =3D uppervp; =09unp->un_lowervp =3D lowervp; =09unp->un_dvp =3D dvp; -=09if (uppervp !=3D NULLVP) -=09=09vp->v_vnlock =3D uppervp->v_vnlock; -=09else -=09=09vp->v_vnlock =3D lowervp->v_vnlock; =20 =09if (path !=3D NULL) { =09=09unp->un_path =3D (char *) @@ -293,29 +302,25 @@ unionfs_nodeget(struct mount *mp, struct vnode *u= p =09 (lowervp !=3D NULLVP && ump->um_lowervp =3D=3D lowervp)) =09=09vp->v_vflag |=3D VV_ROOT; =20 -=09if (path !=3D NULL && dvp !=3D NULLVP && vt =3D=3D VDIR) -=09=09*vpp =3D unionfs_ins_cached_vnode(unp, dvp, path); -=09if ((*vpp) !=3D NULLVP) { -=09=09if (dvp !=3D NULLVP) -=09=09=09vrele(dvp); -=09=09if (uppervp !=3D NULLVP) -=09=09=09vrele(uppervp); -=09=09if (lowervp !=3D NULLVP) -=09=09=09vrele(lowervp); +=09if (path !=3D NULL && dvp !=3D NULLVP && vt =3D=3D VDIR) { +=09=09*vpp =3D unionfs_ins_cached_vnode(unp, dvp, path, lkflags, td); +=09=09if ((*vpp) !=3D NULLVP) { +=09=09=09if (dvp !=3D NULLVP) +=09=09=09=09vrele(dvp); +=09=09=09if (uppervp !=3D NULLVP) +=09=09=09=09vrele(uppervp); +=09=09=09if (lowervp !=3D NULLVP) +=09=09=09=09vrele(lowervp); =20 -=09=09unp->un_uppervp =3D NULLVP; -=09=09unp->un_lowervp =3D NULLVP; -=09=09unp->un_dvp =3D NULLVP; -=09=09vrele(vp); -=09=09vp =3D *vpp; -=09=09vref(vp); -=09} else -=09=09*vpp =3D vp; +=09=09=09unp->un_uppervp =3D NULLVP; +=09=09=09unp->un_lowervp =3D NULLVP; +=09=09=09unp->un_dvp =3D NULLVP; +=09=09=09vput(vp); +=09=09=09return (0); +=09=09} +=09} +=09*vpp =3D vp; =20 -unionfs_nodeget_out: -=09if (lkflags & LK_TYPE_MASK) -=09=09vn_lock(vp, lkflags | LK_RETRY); - =09return (0); } =20 --=20 John Baldwin From owner-freebsd-hackers@freebsd.org Thu Dec 24 17:32:48 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D48AEA51493 for ; Thu, 24 Dec 2015 17:32:48 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C45751B3C for ; Thu, 24 Dec 2015 17:32:48 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: by mailman.ysv.freebsd.org (Postfix) id C1902A51492; Thu, 24 Dec 2015 17:32:48 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C129AA51491 for ; Thu, 24 Dec 2015 17:32:48 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 722C81B3B for ; Thu, 24 Dec 2015 17:32:48 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.24] ([194.32.164.24]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id tBOHWisc015333; Thu, 24 Dec 2015 17:32:44 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: ZFS questions, ZFS hang From: Bob Bishop In-Reply-To: <20151224075041.GD4535@zxy.spb.ru> Date: Thu, 24 Dec 2015 17:32:44 +0000 Cc: joe mcguckin , hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <751ED6BA-93D8-4E11-96B8-50B33DD6F43D@gid.co.uk> References: <20151224075041.GD4535@zxy.spb.ru> To: Slawa Olhovchenkov X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 17:32:48 -0000 Hi, > On 24 Dec 2015, at 07:50, Slawa Olhovchenkov wrote: >=20 > On Wed, Dec 23, 2015 at 08:09:36PM -0800, joe mcguckin wrote: >=20 >> I have a dual xeon w 16G of ram and 16 drives that I=E2=80=99m using = to play around with zfs. >>=20 >> I was running the 32 bit kernel and everything seemed to work ok. I = upgraded to the amd 64 bit >> kernel and I=E2=80=99m seeing the box hang under load. No error = messages - it just goes catatonic. >>=20 >> I=E2=80=99m running the GENERIC kernel. Are there any recommended = kernel settings I should be using? >=20 > Update to STABLE, some related bug found and fixed. Also, if you have carried over any ZFS-specific tuning from your 32-bit = setup, you almost certainly don=E2=80=99t need it. -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Thu Dec 24 18:37:24 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECA89A50B37 for ; Thu, 24 Dec 2015 18:37:24 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D184D110F for ; Thu, 24 Dec 2015 18:37:24 +0000 (UTC) (envelope-from jmaloney@pcbsd.org) X-ASG-Debug-ID: 1450982241-08ca042abc0bc60002-2efMSh Received: from [10.0.1.15] (ip72-209-175-134.ks.ks.cox.net [72.209.175.134]) by barracuda.ixsystems.com with ESMTP id 6nINXdVJe7tp5yP0 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Dec 2015 10:37:22 -0800 (PST) X-Barracuda-Envelope-From: jmaloney@pcbsd.org X-Barracuda-AUTH-User: jmaloney@pcbsd.org X-Barracuda-Apparent-Source-IP: 72.209.175.134 From: Joe Maloney To: Andriy Gapon , CC: FreeBSD Hackers Date: Thu, 24 Dec 2015 12:37:21 -0600 Message-ID: <151d547f2e8.2710.65a736056516fedbe0e39048eb84e883@pcbsd.org> In-Reply-To: <567BF197.10908@FreeBSD.org> References: <567BF197.10908@FreeBSD.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.4 (build: 24000007) Subject: Re: firefox crashes during pkg upgrade MIME-Version: 1.0 X-ASG-Orig-Subj: Re: firefox crashes during pkg upgrade Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ip72-209-175-134.ks.ks.cox.net[72.209.175.134] X-Barracuda-Start-Time: 1450982242 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.25542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 18:37:25 -0000 I can confirm this happens to me as well. I believe it is a long standing problem. Joe Maloney On December 24, 2015 7:23:47 AM Andriy Gapon wrote: > > Greetings! > > I've got a strange problem: sometime when I do pkg upgrade a firefox process > crashes with SIGBUS. And that happens rather often. > > For example, the last upgrade did the following package upgrades: > Installed packages to be UPGRADED: > rubygem-bundler: 1.10.6 -> 1.11.2 [FreeBSD] > pylint-py27: 1.4.3_1 -> 1.5.1 [FreeBSD] > py27-logilab-common: 0.63.2 -> 1.1.0 [FreeBSD] > py27-astroid: 1.3.6 -> 1.4.1 [FreeBSD] > php5-libphutil: 20150626 -> 20151220 [FreeBSD] > php5-arcanist: 20150626_2 -> 20151220 [FreeBSD] > m17n-db: 1.6.5 -> 1.7.0 [FreeBSD] > libvterm: git20150527 -> git20150828 [FreeBSD] > fribidi: 0.19.2_3 -> 0.19.7 [FreeBSD] > dmidecode: 2.12_2 -> 3.0 [FreeBSD] > chromium: 47.0.2526.80 -> 47.0.2526.106 [FreeBSD] > > The process will require 2 MiB more space. > 43 MiB to be downloaded. > > At the first glance none of those packages seem to be related to firefox. > > Also, I would guess that even if a shared library used by firefox would be > upgraded, then either the old version would be unlinked first and firefox would > keep using it, or there would be an error (ETXTBSY) if there would be an > attempt > to write to the shared library while it's being used. > > The core dump seems to be useless: > > Core was generated by `firefox'. > Program terminated with signal SIGBUS, Bus error. > #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 > [Current thread is 60 (Thread 801a0d000 (LWP 101727))] > (gdb) bt > #0 0x000000080ed69c90 in ?? () from /usr/local/lib/libgio-2.0.so.0 > #1 0x000000080ed6815e in ?? () from /usr/local/lib/libgio-2.0.so.0 > #2 0x000000080ed68af8 in ?? () from /usr/local/lib/libgio-2.0.so.0 > #3 0x000000080ddde7b5 in g_main_context_dispatch () from > /usr/local/lib/libglib-2.0.so.0 > #4 0x000000080dddeacb in ?? () from /usr/local/lib/libglib-2.0.so.0 > #5 0x000000080dddeb54 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.0 > #6 0x0000000803e134cc in ?? () from /usr/local/lib/firefox/libxul.so > #7 0x0000000803de6c24 in ?? () from /usr/local/lib/firefox/libxul.so > #8 0x0000000803de6cdd in ?? () from /usr/local/lib/firefox/libxul.so > #9 0x000000080259945f in ?? () from /usr/local/lib/firefox/libxul.so > #10 0x00000008025be1f3 in ?? () from /usr/local/lib/firefox/libxul.so > #11 0x000000080282436e in ?? () from /usr/local/lib/firefox/libxul.so > #12 0x0000000802808c68 in ?? () from /usr/local/lib/firefox/libxul.so > #13 0x0000000803de694b in ?? () from /usr/local/lib/firefox/libxul.so > #14 0x00000008045d47be in ?? () from /usr/local/lib/firefox/libxul.so > #15 0x00000008046243be in ?? () from /usr/local/lib/firefox/libxul.so > #16 0x0000000804624655 in ?? () from /usr/local/lib/firefox/libxul.so > #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so > #18 0x0000000000405abf in ?? () > #19 0x00000000004054df in _start () > > Although, hmm: > (gdb) disassemble 0x000000080ed69c70,+48 > Dump of assembler code from 0x80ed69c70 to 0x80ed69ca0: > 0x000000080ed69c70: add %al,(%rax) > 0x000000080ed69c72: mov $0x18,%esi > 0x000000080ed69c77: callq 0x80ec98ff4 > 0x000000080ed69c7c: mov %rax,%r13 > 0x000000080ed69c7f: xor %r15d,%r15d > 0x000000080ed69c82: test %r13,%r13 > 0x000000080ed69c85: je 0x80ed69cf0 > 0x000000080ed69c87: mov %r13,%r15 > 0x000000080ed69c8a: mov %r14,%rbx > 0x000000080ed69c8d: nopl (%rax) > => 0x000000080ed69c90: mov 0x8(%rbx),%rax > 0x000000080ed69c94: mov %rax,0x8(%r13) > 0x000000080ed69c98: mov 0x10(%rbx),%eax > 0x000000080ed69c9b: mov %eax,0x10(%r13) > 0x000000080ed69c9f: cmpq $0x0,(%rbx) > End of assembler dump. > (gdb) i reg > rax 0x81f542d60 34885348704 > rbx 0x5a5a5a5a5a5a5a5a 6510615555426900570 > rcx 0x20 32 > rdx 0x0 0 > rsi 0x0 0 > rdi 0x81f542d80 34885348736 > rbp 0x7fffffffd850 0x7fffffffd850 > rsp 0x7fffffffd7e0 0x7fffffffd7e0 > r8 0x20 32 > r9 0xfffff80000000000 -8796093022208 > r10 0x1 1 > r11 0x81f542d60 34885348704 > r12 0x81ccb0300 34842804992 > r13 0x81f542d60 34885348704 > r14 0x81f5540a0 34885419168 > r15 0x81f542d40 34885348672 > rip 0x80ed69c90 0x80ed69c90 > eflags 0x10206 [ PF IF RF ] > cs 0x43 67 > ss 0x3b 59 > ds > es > fs > gs > > Seems like %rbx has a value characteristic of free-d memory. > But I am not sure at all how this fact could be connected to pkg upgrade... > Perhaps a change in the file system triggers a bug in libgio somewhere. > > Update. > > Surprisingly[?], the old base gdb produces a better[?] stack trace: > > (kgdb) bt > #0 0x000000080ed69c90 in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #1 0x000000080ed6815e in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #2 0x000000080ed68af8 in g_local_file_monitor_get_type () from > /usr/local/lib/libgio-2.0.so.0 > #3 0x000000080ddde7b5 in g_main_context_dispatch () from > /usr/local/lib/libglib-2.0.so.0 > #4 0x000000080dddeacb in g_main_context_pending () from > /usr/local/lib/libglib-2.0.so.0 > #5 0x000000080dddeb54 in g_main_context_iteration () from > /usr/local/lib/libglib-2.0.so.0 > #6 0x0000000803e134cc in std::__1::__tree std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #7 0x0000000803de6c24 in std::__1::__tree std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #8 0x0000000803de6cdd in std::__1::__tree std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #9 0x000000080259945f in XRE_AddJarManifestLocation () from > /usr/local/lib/firefox/libxul.so > #10 0x00000008025be1f3 in std::__1::vector std::__1::allocator >::__push_back_slow_path () > from /usr/local/lib/firefox/libxul.so > #11 0x000000080282436e in std::__1::vector, > std::__1::allocator > >>::__push_back_slow_path > () from > /usr/local/lib/firefox/libxul.so > #12 0x0000000802808c68 in std::__1::vector std::__1::char_traits, std::__1::allocator >, > std::__1::allocator, > std::__1::allocator > > >>::insert std::__1::char_traits, std::__1::allocator >*> > () from > /usr/local/lib/firefox/libxul.so > #13 0x0000000803de694b in std::__1::__tree std::__1::less, std::__1::allocator >::destroy () > from /usr/local/lib/firefox/libxul.so > #14 0x00000008045d47be in XRE_StartupTimelineRecord () from > /usr/local/lib/firefox/libxul.so > #15 0x00000008046243be in XRE_InitCommandLine () from > /usr/local/lib/firefox/libxul.so > #16 0x0000000804624655 in XRE_GlibInit () from /usr/local/lib/firefox/libxul.so > #17 0x0000000804624a56 in XRE_main () from /usr/local/lib/firefox/libxul.so > #18 0x0000000000405abf in _start () > #19 0x00000000004054df in _start () > #20 0x0000000800640000 in ?? () > #21 0x0000000000000000 in ?? () > > From the disassembly, though, I can see that several different functions are > reported as g_local_file_monitor_get_type(), e.g.: > 0x000000080ed69c40 : push %rbp > 0x000000080ed69c41 : mov > %rsp,%rbp > 0x000000080ed69c44 : push %r15 > 0x000000080ed69c46 : push %r14 > 0x000000080ed69c48 : push %r13 > 0x000000080ed69c4a : push %r12 > 0x000000080ed69c4c : push %rbx > 0x000000080ed69c4d : sub > $0x48,%rsp > 0x000000080ed69c51 : mov > %rcx,-0x50(%rbp) > 0x000000080ed69c55 : mov > %rdx,-0x48(%rbp) > ... > > I've found a report that seems to be related: > https://forums.freebsd.org/threads/gtk-programs-core-dump.54462/ > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Dec 24 18:46:19 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF199A50F2F; Thu, 24 Dec 2015 18:46:19 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F0A218EF; Thu, 24 Dec 2015 18:46:19 +0000 (UTC) (envelope-from thomas.e.zander@googlemail.com) Received: by mail-lf0-x22d.google.com with SMTP id p203so168046020lfa.0; Thu, 24 Dec 2015 10:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=T4LYRAjF+C3fKNgPc/FoTmZZnCPbuujJYDvcomGB7pU=; b=OsLp3Tms1+FwZhrNw4jTm0+34SG9s0knjTrXvgIij0+Y2KI/YV7yZbQW56YOBYcTc/ rIUCxkRIYXz1TS4znwUQ0bldemuFuDqlgJGudbtb5fJtASVD8Puqg677qUGsxY43XOK1 yVw/l3LutFkb65Tek+OLgLA2cEglAys0J0EoTQLZL7seYK1dfQPfWdPBXg/3X7DmWXsD i7Go+laxdNGpxrRpWQ5F2/f2mbUelRaXesFhJur2hI1xpSLqV/E0PpgvRDycP0As04MB 3VK7K6rf8ZosrM4HW4QtTqF1R8WR8d8aFVw4T07n76ilkv/0jbaMP31WjCsl43B3cB8F kc1w== MIME-Version: 1.0 X-Received: by 10.25.17.138 with SMTP id 10mr3442043lfr.26.1450982776436; Thu, 24 Dec 2015 10:46:16 -0800 (PST) Sender: thomas.e.zander@googlemail.com Received: by 10.114.48.9 with HTTP; Thu, 24 Dec 2015 10:46:16 -0800 (PST) In-Reply-To: <567BF197.10908@FreeBSD.org> References: <567BF197.10908@FreeBSD.org> Date: Thu, 24 Dec 2015 19:46:16 +0100 X-Google-Sender-Auth: GGA9tu5ZDWOWacXGXnpbUpKV8GU Message-ID: Subject: Re: firefox crashes during pkg upgrade From: Thomas Zander To: FreeBSD Hackers , freebsd-gecko@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 18:46:19 -0000 On 24 December 2015 at 14:22, Andriy Gapon wrote: > I've got a strange problem: sometime when I do pkg upgrade a firefox process > crashes with SIGBUS. And that happens rather often. Yep, here too. Didn't bother me enough to look into it, though. My crystal-ball-guess is that FF does not handle it well when ldconfig is run during pkg upgrade. Riggs From owner-freebsd-hackers@freebsd.org Thu Dec 24 20:01:49 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8D61A5094C for ; Thu, 24 Dec 2015 20:01:49 +0000 (UTC) (envelope-from arlie@worldash.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B9CB31EE0 for ; Thu, 24 Dec 2015 20:01:49 +0000 (UTC) (envelope-from arlie@worldash.org) Received: by mailman.ysv.freebsd.org (Postfix) id BA133A50947; Thu, 24 Dec 2015 20:01:49 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7CBCA50946; Thu, 24 Dec 2015 20:01:49 +0000 (UTC) (envelope-from arlie@worldash.org) Received: from ansuz.worldash.org (ansuz.worldash.org [198.144.201.100]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6C11EDE; Thu, 24 Dec 2015 20:01:49 +0000 (UTC) (envelope-from arlie@worldash.org) Received: by ansuz.worldash.org (Postfix, from userid 1000) id 66A49E1923; Thu, 24 Dec 2015 12:04:09 -0800 (PST) Date: Thu, 24 Dec 2015 12:04:09 -0800 From: Arlie Stephens To: John Baldwin Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Examining Page Tables in Kernel Crash Dumps (amd64) Message-ID: <20151224200409.GA10873@worldash.org> References: <20151222235920.GA21736@worldash.org> <2188443.PY7dC12t9i@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2188443.PY7dC12t9i@ralph.baldwin.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 20:01:49 -0000 On Dec 24 2015, John Baldwin wrote: > > On Tuesday, December 22, 2015 03:59:20 PM Arlie Stephens wrote: [snip] > > So far, the only way I know to get a look at kernel page table > > contents in FreeBSD is on live systems with ddb. > > > > I would like to know whether there are any tools I haven't noticed for > > dealing with page tables in crash dumps - or, for that matter, whether > > kgdb is supposed to be able to display the kernel's recursive page > > tables. > > > > Failing that, I may just have to write one ;-) (Or figure out how to > > chase my problem on live systems.) > > kgdb depends on libkvm to handle translations of virtual addresses to > offsets in the vmcore file (which is then used by kvm_read to read the > relevant data). On amd64 you can cheat a bit by using direct map > addresses (I use this in my gdb macros to walk the page tables by > hand so I can look at raw PDEs, PTEs, etc.). > > (For the macros I use you can look at www.freebsd.org/~jhb/gdb/gdb6.amd64) > > Normally you download the files there and do 'source gdb6' which will pull > in gdb6.amd64. The 'pmap_*' macros try to replicate the behavior of the > equivalent functions in pmap.c. Many thanks! This looks like exactly what I was looking for. I'd missed the trick of using the direct map to get at the page tables themselves - I was trying to start with PDmap. (Following the kernel code really closely is what you do when you aren't sure you understand how it works :-( ) FWIW, I'd missed a few other tricks of the trade as well. You are doing things in your gdb scripts I didn't know were possible. Thanks for that too. -- Arlie (Arlie Stephens arlie@worldash.org) From owner-freebsd-hackers@freebsd.org Sat Dec 26 11:59:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BA06A52AAE for ; Sat, 26 Dec 2015 11:59:12 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC4B14AD for ; Sat, 26 Dec 2015 11:59:11 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id l126so221877046wml.0 for ; Sat, 26 Dec 2015 03:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=p/Eoc9eZd4Lix5tcSRkyx/w+jT+3xg5kL2Ch1yMyjUg=; b=J6ywhA6iDGWBV8GCIq6dfXckRTElckAGUY+smoq5LThoFdUlnAenEpCuTreM3BTMDh zi/Omh2cWMbP2QVOzXiO/U/999z2J4CsSHaI3N1KW+Z3lXVvHrUqMQuj0RlYLDUvEyjc lEC1MASd97XKNHlGuT4+d/8fQRDaRBh8yRLaAyY87+SdsZWZ10bSuptYiVWU6l2bKqM+ XB8kjuC6Eq+ZdcaBKDsJQbPikyLsyaHxtnnrxGg5obeQDs2hCsvWGA3YJ4iKo0zYqHeL XA06nMKZAnX9yc7xsXGifke0bY8n3/zqQOcpmIymAwo3OWkxH/X5zVh+EGy12PRPD0Dr AGHw== X-Received: by 10.28.94.1 with SMTP id s1mr47987507wmb.60.1451131150253; Sat, 26 Dec 2015 03:59:10 -0800 (PST) Received: from zmaj.softwarehood.com (178-221-115-29.dynamic.isp.telekom.rs. [178.221.115.29]) by smtp.googlemail.com with ESMTPSA id l184sm40411260wmf.6.2015.12.26.03.59.09 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Dec 2015 03:59:09 -0800 (PST) Message-ID: <567E810C.3040809@gmail.com> Date: Sat, 26 Dec 2015 12:59:08 +0100 From: Ivan Radovanovic User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130812 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Unexpected behavior of dynamic linker Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 11:59:12 -0000 Hello, While investigating possibility of building some module system on FreeBSD I stumbled upon unexpected (at least for me) behavior of dynamic linker. I have several (C++) modules organized like this: * main program (executable) * main library (shared object, loaded with RTLD_GLOBAL since it provides symbols for main program and other modules) * module 1 (shared object, loaded with RTLD_LOCAL) I put all private initializations for library and module in (static) global object constructors, but I gave to both classes same (original) name "PrivateClass" (so there is in fact PrivateClass in mainlib.so, and unrelated PrivateClass in module.so). What is happening is that when main program loads main library (via dlopen(3)) its _init calls correctly mainlib::PrivateClass constructor which performs initialization, but when main program later loads module (again via dlopen(3)) its _init doesn't call module::PrivateClass constructor, but rather mainlib::PrivateClass constructor. I understand this is happening because symbols with same name exist in both shared objects and dynamic linker is replacing reference to module::PrivateClass with reference to mainlib::PrivateClass, but I would expect symbol to be looked up outside of module only if it doesn't exist within it (ie, the inner-most definition to be used) - in this case PrivateClass exists within module? Further I am not sure what would be correct solution for this in my case - C++ has static modifier for objects and functions, but not for classes to make them unavailable from other modules and solution with same random namespace name doesn't sound elegant enough :-) Any thoughts regarding this (I can also supply source files to test this behavior)? Kind regards, Ivan From owner-freebsd-hackers@freebsd.org Sat Dec 26 12:28:24 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43CA3A51B97 for ; Sat, 26 Dec 2015 12:28:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D378B163D for ; Sat, 26 Dec 2015 12:28:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBQCSIhO036924 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 26 Dec 2015 14:28:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBQCSIhO036924 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBQCSIHN036923; Sat, 26 Dec 2015 14:28:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Dec 2015 14:28:18 +0200 From: Konstantin Belousov To: Ivan Radovanovic Cc: freebsd-hackers@freebsd.org Subject: Re: Unexpected behavior of dynamic linker Message-ID: <20151226122818.GI3625@kib.kiev.ua> References: <567E810C.3040809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <567E810C.3040809@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 12:28:24 -0000 On Sat, Dec 26, 2015 at 12:59:08PM +0100, Ivan Radovanovic wrote: > Hello, > > While investigating possibility of building some module system on > FreeBSD I stumbled upon unexpected (at least for me) behavior of dynamic > linker. > > I have several (C++) modules organized like this: > > * main program (executable) > * main library (shared object, loaded with RTLD_GLOBAL since it provides > symbols for main program and other modules) > * module 1 (shared object, loaded with RTLD_LOCAL) > > I put all private initializations for library and module in (static) > global object constructors, but I gave to both classes same (original) > name "PrivateClass" (so there is in fact PrivateClass in mainlib.so, and > unrelated PrivateClass in module.so). > > What is happening is that when main program loads main library (via > dlopen(3)) its _init calls correctly mainlib::PrivateClass constructor > which performs initialization, but when main program later loads module > (again via dlopen(3)) its _init doesn't call module::PrivateClass > constructor, but rather mainlib::PrivateClass constructor. I understand > this is happening because symbols with same name exist in both shared > objects and dynamic linker is replacing reference to > module::PrivateClass with reference to mainlib::PrivateClass, but I > would expect symbol to be looked up outside of module only if it doesn't > exist within it (ie, the inner-most definition to be used) - in this > case PrivateClass exists within module? > > Further I am not sure what would be correct solution for this in my case > - C++ has static modifier for objects and functions, but not for classes > to make them unavailable from other modules and solution with same > random namespace name doesn't sound elegant enough :-) > > Any thoughts regarding this (I can also supply source files to test this > behavior)? This is expected behaviour, it is mandated by the ELF standard. ELF tried to emulate the behaviour of the static libraries as much as possible. Think what would happen in your case if both modules where linked statically into the binary. To augment the behaviour, read about linker option -Bsymbolic, compiler option -fhidden, and GNU-specific attribute __visibility__("hidden"). From owner-freebsd-hackers@freebsd.org Sat Dec 26 12:52:49 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7590A523A5 for ; Sat, 26 Dec 2015 12:52:49 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5657C1FF2 for ; Sat, 26 Dec 2015 12:52:49 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id p187so220346802wmp.1 for ; Sat, 26 Dec 2015 04:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VKR1anGUxG/NGegyPLrFxOE5U8owICqsPDEos0rsKl8=; b=kNnrXB1phTdcLOgfl1tiC8LBhFWIN6m6Lh+pbwVcewHsKLCRxuOnAVeSWC4rrClYYV 0wDN+r1tqpK1wJ0BoJnru6jE6DFzByJjKGJ8N3z0QHdugRtkH4FerTPwJas7xEvBeXNt jDEdFnMtXBXEvf26ohpmMoRPrwlEgXUb74YY0ASZrFUWrZEISTHjSLobeofL+sSMOOhm +Zt9Vq7bmumH3xNyq7XA9oJtuSFFQlQYgiBjY8zDu5hnSIu3weLqR6eAICaif3kIMwkQ K1SmXfoCErgcNn5c6BZda0K/rRmiHThXKXsV9Q7UuKy3zqmXBvEFdhf1SnARdC1upfIC Ot6g== X-Received: by 10.28.188.70 with SMTP id m67mr39303586wmf.24.1451134367330; Sat, 26 Dec 2015 04:52:47 -0800 (PST) Received: from zmaj.softwarehood.com (178-221-115-29.dynamic.isp.telekom.rs. [178.221.115.29]) by smtp.googlemail.com with ESMTPSA id qm9sm48858889wjc.39.2015.12.26.04.52.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Dec 2015 04:52:46 -0800 (PST) Message-ID: <567E8D9D.6080808@gmail.com> Date: Sat, 26 Dec 2015 13:52:45 +0100 From: Ivan Radovanovic User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130812 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-hackers@freebsd.org Subject: Re: Unexpected behavior of dynamic linker References: <567E810C.3040809@gmail.com> <20151226122818.GI3625@kib.kiev.ua> In-Reply-To: <20151226122818.GI3625@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 12:52:49 -0000 On 12/26/15 13:28, Konstantin Belousov napisa: > > This is expected behaviour, it is mandated by the ELF standard. ELF > tried to emulate the behaviour of the static libraries as much as possible. > Think what would happen in your case if both modules where linked statically > into the binary. > > To augment the behaviour, read about linker option -Bsymbolic, compiler > option -fhidden, and GNU-specific attribute __visibility__("hidden"). > Thanks for pointer about attributes (it does work as expected if I add __attribute__((visibility("hidden"))) to private classes). This behavior still looks counter-intuitive to me - like linker is resolving already resolved reference, however problem is solved. Thanks!