From owner-freebsd-hackers@freebsd.org Sun Nov 13 21:57:40 2016 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 2092CC3FFC4; Sun, 13 Nov 2016 21:57:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 43AD0198A; Sun, 13 Nov 2016 21:57:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA01399; Sun, 13 Nov 2016 23:57:31 +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 1c62mI-000Bew-Uf; Sun, 13 Nov 2016 23:57:30 +0200 Subject: Re: firewire panic To: FreeBSD Current , FreeBSD Hackers References: <91a1440d-14c7-2cc6-6cbb-2b62bfd2c27d@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Sun, 13 Nov 2016 23:56:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <91a1440d-14c7-2cc6-6cbb-2b62bfd2c27d@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:57:40 -0000 On 11/11/2016 14:25, Andriy Gapon wrote: > panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967 > cpuid = 2 > curthread: 0xfffff8000ada5000 > stack: 0xfffffe0504ded000 - 0xfffffe0504df1000 > stack pointer: 0xfffffe0504df0a00 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff80420bbb = db_trace_self_wrapper+0x2b/frame > 0xfffffe0504df0930 > kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame 0xfffffe0504df09e0 > vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20 > panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80 > __mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame 0xfffffe0504df0ac0 > sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame > 0xfffffe0504df0af0 > xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame > 0xfffffe0504df0b30 > xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame 0xfffffe0504df0b80 So, it's pretty obvious that the sbp mutex can not be held when sbp_cam_scan_lun() is called. After removing the assertion, just to move further, I do not get any panics and can access the disk. But I see many witness warnings. Some examples: bus_dma_tag_create with the following non-sleepable locks held: exclusive sleep mutex sbp (sbp) r = 0 (0xfffff8000ff04f48) locked @ /usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802 stack backtrace: #0 0xffffffff80ab20a0 at witness_debugger+0x70 #1 0xffffffff80ab3387 at witness_warn+0x3d7 #2 0xffffffff810174dd at bus_dma_tag_create+0x3d #3 0xffffffff83703402 at fwdma_malloc+0x82 #4 0xffffffff836ed759 at sbp_post_explore+0x849 #5 0xffffffff836f9e76 at fw_bus_probe_thread+0x906 #6 0xffffffff80a164c4 at fork_exit+0x84 #7 0xffffffff80ea970e at fork_trampoline+0xe bus_dmamem_alloc with the following non-sleepable locks held: exclusive sleep mutex sbp (sbp) r = 0 (0xfffff8000ff04f48) locked @ /usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802 stack backtrace: #0 0xffffffff80ab20a0 at witness_debugger+0x70 #1 0xffffffff80ab3387 at witness_warn+0x3d7 #2 0xffffffff810175c3 at bus_dmamem_alloc+0x33 #3 0xffffffff83703424 at fwdma_malloc+0xa4 #4 0xffffffff836ed759 at sbp_post_explore+0x849 #5 0xffffffff836f9e76 at fw_bus_probe_thread+0x906 #6 0xffffffff80a164c4 at fork_exit+0x84 #7 0xffffffff80ea970e at fork_trampoline+0xe bus_dmamap_create with the following non-sleepable locks held: exclusive sleep mutex sbp (sbp) r = 0 (0xfffff8000ff04f48) locked @ /usr/src/sys/modules/firewire/sbp/../../../dev/firewire/sbp.c:802 stack backtrace: #0 0xffffffff80ab20a0 at witness_debugger+0x70 #1 0xffffffff80ab3387 at witness_warn+0x3d7 #2 0xffffffff8101755f at bus_dmamap_create+0x2f #3 0xffffffff836ed7d2 at sbp_post_explore+0x8c2 #4 0xffffffff836f9e76 at fw_bus_probe_thread+0x906 #5 0xffffffff80a164c4 at fork_exit+0x84 #6 0xffffffff80ea970e at fork_trampoline+0xe lock order reversal: 1st 0xfffff8000ff04f48 sbp (sbp) @ /usr/src/sys/kern/kern_mutex.c:220 2nd 0xfffffe0001b94870 firewire (firewire) @ /usr/src/sys/modules/firewire/firewire/../../../dev/firewire/firewire.c:302 stack backtrace: #0 0xffffffff80ab20a0 at witness_debugger+0x70 #1 0xffffffff80ab1f94 at witness_checkorder+0xe54 #2 0xffffffff80a33854 at __mtx_lock_flags+0xa4 #3 0xffffffff836f6423 at fw_asyreq+0x2d3 #4 0xffffffff80a68f2c at softclock_call_cc+0x19c #5 0xffffffff80a69327 at softclock+0x47 #6 0xffffffff80a18d76 at intr_event_execute_handlers+0x96 #7 0xffffffff80a193f6 at ithread_loop+0xa6 #8 0xffffffff80a164c4 at fork_exit+0x84 #9 0xffffffff80ea970e at fork_trampoline+0xe lock order reversal: 1st 0xfffff8000ff04f48 sbp (sbp) @ /usr/src/sys/kern/kern_mutex.c:220 2nd 0xfffff8000a0b4460 CAM device lock (CAM device lock) @ /usr/src/sys/cam/scsi/scsi_xpt.c:2349 stack backtrace: #0 0xffffffff80ab20a0 at witness_debugger+0x70 #1 0xffffffff80ab1f94 at witness_checkorder+0xe54 #2 0xffffffff80a33854 at __mtx_lock_flags+0xa4 #3 0xffffffff8031af12 at scsi_scan_lun+0x122 #4 0xffffffff836eef40 at sbp_cam_scan_target+0x100 #5 0xffffffff80a68f2c at softclock_call_cc+0x19c #6 0xffffffff80a69327 at softclock+0x47 #7 0xffffffff80a18d76 at intr_event_execute_handlers+0x96 #8 0xffffffff80a193f6 at ithread_loop+0xa6 #9 0xffffffff80a164c4 at fork_exit+0x84 #10 0xffffffff80ea970e at fork_trampoline+0xe -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Nov 14 09:58:11 2016 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 D44E5C3DC0D; Mon, 14 Nov 2016 09:58:11 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 689BA7F4; Mon, 14 Nov 2016 09:58:11 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id m203so13713080wma.3; Mon, 14 Nov 2016 01:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=Anh1iHKgL5LhAQVaMituc9q/DaDazAE/YPLQQyFS/xc=; b=WjvswxAE5HFlCtW1U37ufER3lscea33Zj+f7t9HaQjobGvzb5Z1MjU+aj73V0x70+h rL1sKrliUe4kSYZidiJdgxqC3mMSqJpzBQYBVUTts9iXrAgImwQ6eNax8LUQJ73Kf+4m eWc3ASodYY6U0XfbHcBsgkWY6aAK7bLDNsC/c7hBF1xJbfjBn+Elu0NGK5IbUfPF4yGD RhpEwFeV+g76M5k5WX81/IaMkgjnn0shXuotuu69lviMK1dB+zdle3n1nkA7Jd5qrumd GogEU6PwkiOMbhVceYGRd5jyY/eZs938+0njYHavKqBty5vALVP8tUja9HGdqHu+qXtL Tv0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=Anh1iHKgL5LhAQVaMituc9q/DaDazAE/YPLQQyFS/xc=; b=XHTJqv6sZBaBq6A1YQLUaJ/nXrCrBIunBBuZ0Qf3FNH/oXnVmytobO3Mfo40gHUxKe bvUEblxWXXZlnIOP2troZ1k+GQGVZM7CoZ1bsCXtxM/mTbbnyjSIE3uwSuvxJABEWFI9 eXw4QIZJiA+twI9TGrb7DuzMojNhHN8Aq/vi/QmJTVjX5Rj4EUy+EZoD5rGZlxxQz1EB iZrODBxEbAParHePDM2bEOgmKLROIu8O9hEK6eTWIcV0HBPHUgIIlWp7grunvBffOLgM XO9rkB2T9L98zayoREpP0dHNcXcmShhb2Q1xnksshp4e26MAdS5N84/BTyRkqkJwUWvL xuzQ== X-Gm-Message-State: ABUngve7R1k6uh8CHpgoVVxIgc7n8cSHhSFX+4l2etClLKWD4FLfwP1xnpBGTuQJyTqNog== X-Received: by 10.28.216.9 with SMTP id p9mr8824267wmg.11.1479117489683; Mon, 14 Nov 2016 01:58:09 -0800 (PST) Received: from ernst.home (p578E1FD9.dip0.t-ipconnect.de. [87.142.31.217]) by smtp.gmail.com with ESMTPSA id k2sm27730285wjv.11.2016.11.14.01.58.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 Nov 2016 01:58:08 -0800 (PST) Date: Mon, 14 Nov 2016 10:58:07 +0100 From: Gary Jennejohn To: Andriy Gapon Cc: FreeBSD Current , FreeBSD Hackers Subject: Re: firewire panic Message-ID: <20161114105807.02dfbe66@ernst.home> In-Reply-To: References: <91a1440d-14c7-2cc6-6cbb-2b62bfd2c27d@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 09:58:11 -0000 On Sun, 13 Nov 2016 23:56:09 +0200 Andriy Gapon wrote: > On 11/11/2016 14:25, Andriy Gapon wrote: > > panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967 > > cpuid = 2 > > curthread: 0xfffff8000ada5000 > > stack: 0xfffffe0504ded000 - 0xfffffe0504df1000 > > stack pointer: 0xfffffe0504df0a00 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff80420bbb = db_trace_self_wrapper+0x2b/frame > > 0xfffffe0504df0930 > > kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame 0xfffffe0504df09e0 > > vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20 > > panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80 > > __mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame 0xfffffe0504df0ac0 > > sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame > > 0xfffffe0504df0af0 > > xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame > > 0xfffffe0504df0b30 > > xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame 0xfffffe0504df0b80 > > So, it's pretty obvious that the sbp mutex can not be held when > sbp_cam_scan_lun() is called. > The code seems to assume that the scan_callout callout is still holding the mutex when sbp_cam_scan_lun() is entered. Seems reasonable, since the man page claims that the callout routine keeps the mutex locked until the callout function, in this case that's sbp_cam_scan_target(), returns. Since sbp_cam_scan_target() invokes xpt_action() with sbp_cam_scan_lun() as its callback, it seems like the assumption should be true. Pehaps there's some asynchronous action happening with the firewire code which is releasing the mutex prematurely. Or maybe the sbp used in sbp_cam_scan_lun() is wrong? Dunno. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Mon Nov 14 11:27:55 2016 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 77730C410C9; Mon, 14 Nov 2016 11:27:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE491A56; Mon, 14 Nov 2016 11:27:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03392; Mon, 14 Nov 2016 13:27:52 +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 1c6FQV-000CNx-TH; Mon, 14 Nov 2016 13:27:51 +0200 Subject: Re: firewire panic To: gljennjohn@gmail.com References: <91a1440d-14c7-2cc6-6cbb-2b62bfd2c27d@FreeBSD.org> <20161114105807.02dfbe66@ernst.home> Cc: FreeBSD Current , FreeBSD Hackers From: Andriy Gapon Message-ID: <372e33d1-0304-51f9-8f8e-94d3ca36420c@FreeBSD.org> Date: Mon, 14 Nov 2016 13:26:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161114105807.02dfbe66@ernst.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 11:27:55 -0000 On 14/11/2016 11:58, Gary Jennejohn wrote: > On Sun, 13 Nov 2016 23:56:09 +0200 > Andriy Gapon wrote: > >> On 11/11/2016 14:25, Andriy Gapon wrote: >>> panic: mutex sbp not owned at /usr/src/sys/dev/firewire/sbp.c:967 >>> cpuid = 2 >>> curthread: 0xfffff8000ada5000 >>> stack: 0xfffffe0504ded000 - 0xfffffe0504df1000 >>> stack pointer: 0xfffffe0504df0a00 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at 0xffffffff80420bbb = db_trace_self_wrapper+0x2b/frame >>> 0xfffffe0504df0930 >>> kdb_backtrace() at 0xffffffff80670359 = kdb_backtrace+0x39/frame 0xfffffe0504df09e0 >>> vpanic() at 0xffffffff8063986c = vpanic+0x14c/frame 0xfffffe0504df0a20 >>> panic() at 0xffffffff806395b3 = panic+0x43/frame 0xfffffe0504df0a80 >>> __mtx_assert() at 0xffffffff8061c40d = __mtx_assert+0xed/frame 0xfffffe0504df0ac0 >>> sbp_cam_scan_lun() at 0xffffffff80474667 = sbp_cam_scan_lun+0x37/frame >>> 0xfffffe0504df0af0 >>> xpt_done_process() at 0xffffffff802aacfa = xpt_done_process+0x2da/frame >>> 0xfffffe0504df0b30 >>> xpt_done_td() at 0xffffffff802ac2e5 = xpt_done_td+0xd5/frame 0xfffffe0504df0b80 >> >> So, it's pretty obvious that the sbp mutex can not be held when >> sbp_cam_scan_lun() is called. >> > > The code seems to assume that the scan_callout callout is still > holding the mutex when sbp_cam_scan_lun() is entered. > > Seems reasonable, since the man page claims that the callout routine > keeps the mutex locked until the callout function, in this case that's > sbp_cam_scan_target(), returns. Since sbp_cam_scan_target() invokes > xpt_action() with sbp_cam_scan_lun() as its callback, it seems like > the assumption should be true. The wrong assumption in your reasoning is that the callback is executed in the same thread. > Pehaps there's some asynchronous action happening with the > firewire code which is releasing the mutex prematurely. > > Or maybe the sbp used in sbp_cam_scan_lun() is wrong? Dunno. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Nov 15 11:17:17 2016 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 0BFDAC43B19 for ; Tue, 15 Nov 2016 11:17:17 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4130A14 for ; Tue, 15 Nov 2016 11:17:16 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.2.3] (schroedinger.eikeo.com [192.168.2.3]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-6) with ESMTPSA id uAFBH2Kr023010 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 15 Nov 2016 12:17:03 +0100 To: "freebsd-hackers@freebsd.org" From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Subject: RTL 8111G Message-ID: <582AEEAE.2030702@systella.fr> Date: Tue, 15 Nov 2016 12:17:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 11:17:17 -0000 Hello, I have installed some months ago a diskless terminal running FreeBSD 10.x. This workstation contains a MSI H97I AC motherboard and sadly a "Realtek® 8111G Gigabit LAN controller". With re driver provided by official FreeBSD 10.x kernel, network adapter can stop and, as this system is diskless, kernel crashes. I want to upgrade this system to FreeBSD 11.x as I have to use wifi adapter (Intel Wireless 7260) that is not supported by 10.x. I have downloaded the last driver from Realtek (rtl_bsd_drv_v192) and I'm unable to build it. Compilation aborts with : root@pythagore:/usr/src/sys/modules/re # make Warning: Object directory not changed from original /usr/src/sys/modules/re cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MP -MF.depend.if_re.o -MTif_re.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/modules/re/../../dev/re/if_re.c -o if_re.o /usr/src/sys/modules/re/../../dev/re/if_re.c:723:50: error: use of undeclared identifier 'M_DONTWAIT' sc->re_desc.rx_buf[i] = m_getjcl(M_DONTWAIT, MT_DATA, M_... ^ /usr/src/sys/modules/re/../../dev/re/if_re.c:773:37: error: incomplete definition of type 'struct ifnet' sc->re_rx_desc_buf_sz = (ifp->if_mtu > ETHERMTU) ? ifp->if_mtu: ... ~~~^ /usr/src/sys/sys/mbuf.h:140:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ /usr/src/sys/modules/re/../../dev/re/if_re.c:773:63: error: incomplete definition of type 'struct ifnet' sc->re_rx_desc_buf_sz = (ifp->if_mtu > ETHERMTU) ? ifp->if_mtu: ... ~~~^ /usr/src/sys/sys/mbuf.h:140:9: note: forward declaration of 'struct ifnet' struct ifnet *rcvif; /* rcv interface */ ^ /usr/src/sys/modules/re/../../dev/re/if_re.c:3085:28: error: implicit declaration of function 'if_alloc' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ifp = sc->re_ifp = if_alloc(IFT_ETHER); ... Does anyone successfully use this RTL 8111G adapter with in-kernel driver ? I have seen that some modifications have been done between 10.X and 11 but I'm not sure that they fix bugs I have seen with 10.x. Best regards, JKB From owner-freebsd-hackers@freebsd.org Wed Nov 16 02:27:10 2016 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 1D5CBC44213 for ; Wed, 16 Nov 2016 02:27:10 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (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 E0966FD8 for ; Wed, 16 Nov 2016 02:27:09 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f41.google.com with SMTP id c20so186655545itb.0 for ; Tue, 15 Nov 2016 18:27:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=w5zeQzW8sc3nfE2YknGRRNFN8D5XIZ9CIOQ+bW+SK14=; b=K8GF15v6NanQMcgBwL98DdxF++TxLP4mmB6JA/g7yKNel9LDUpSQfanPeE88meEo8s Yl8dvVnoNel9APgUv9KWs8KLBLH1SAPz8XVENO00BUBGC2ZXpF4YTzbr+VFhelmQVfCJ Njzg9Ar+OJUuYuaF5jj08HcPupYKuGUw3O1zVZvduiskkmNYBXE8XTaQ22C+ngcdAvn7 dGoVAxCWKO2IPTV85Fx9kr3FisAyiJ9SjwtIyNE2uAsxzTp0NB4+t1H8Q4ZlJNGbB4s5 2Cl0mtDu1oD5O4sjtdcLz/sgmvtvKoJVoTc4LCjtqByHBPsP+CDeuiW+KF62frcFBCoa lF4g== X-Gm-Message-State: ABUngvcfQ/a3VVRMxUP6XB19vxXifGO/aYti9xPUdNYG02UIbBVVkui+b0BU3CaK5zKX2g== X-Received: by 10.36.61.207 with SMTP id n198mr6476014itn.60.1479262732657; Tue, 15 Nov 2016 18:18:52 -0800 (PST) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com. [209.85.214.53]) by smtp.gmail.com with ESMTPSA id 7sm2579705itk.0.2016.11.15.18.18.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 18:18:52 -0800 (PST) Received: by mail-it0-f53.google.com with SMTP id c20so30637800itb.0 for ; Tue, 15 Nov 2016 18:18:52 -0800 (PST) X-Received: by 10.36.99.68 with SMTP id j65mr5965742itc.119.1479262731868; Tue, 15 Nov 2016 18:18:51 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.220.199 with HTTP; Tue, 15 Nov 2016 18:18:51 -0800 (PST) In-Reply-To: References: <20161110012624.GA23701@lonesome.com> <20161110215549.GL91607@kduck.kaduk.org> From: Conrad Meyer Date: Tue, 15 Nov 2016 18:18:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: sbrk(0) replacement for memory resource tracking? To: Matthias Andree Cc: Benjamin Kaduk , "freebsd-hackers@FreeBSD.org" , Mark Linimon Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:27:10 -0000 On Thu, Nov 10, 2016 at 2:26 PM, Matthias Andree wrote: > OK. So the quick and dirty way to re-enable e2fsprogs on those > architectures whilst scrapping any memory statistics would be to #define > sbrk(a) (a) which would just invalidate stats, providing the application > handles bogus data. > > Other than that, it would seem that mallctl("epoch", ...) to synch up > stats, and mallctl("stats.active", ...) or perhaps or "stats.mapped" > gets me close to what comparing sbrk(0) over process lifetime would have > achieved, wouldn't it? This is assuming sbrk() had page granularity > anyhow and stats.active provides exactly that (gross memory allocated). > Possibly this also wants mallctlnametomib and mallctlbymib for > optimization if called often. Right? Yes, something exactly like that (jemalloc-specific) or perhaps libprocstat (FreeBSD-specific). Best, Conrad From owner-freebsd-hackers@freebsd.org Thu Nov 17 01:38:03 2016 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 8248FC45988 for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 55CFBC78 for ; Thu, 17 Nov 2016 01:38:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22d.google.com with SMTP id j191so9928007ita.1 for ; Wed, 16 Nov 2016 17:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=+aLWTSmeusXkO/h16fvvZMI3E2/PTcSxhwr2HZ0jKu4=; b=UA+KgnfC/3uSj34tUtPa/9CrSbQvGOsJTFZ4qB2c1esBgJXWOZAdzZA7QtCUxztQq6 ypMICjYHI/rEUHRjvDkpDHBUt+nsBD48rlOMwv1814LRgATBqHUmKG+q9raH47mgreXk 9ZkUQHu3ZobNrPL7Zsonc0FqIBpVNN+kKIGfh8OrQAmMt97o1dYqhmcp5wHI8gZCmL1X ZadtAjAes392flekdX6/B1CaCqkISHNMaTf/JmnfI2rKjRoAI6oTHNlv11If8n/Aixbd 4IURceDrFeoBGzMh56eaQMr1wMSH7mJmp4L/UTDkYz5yB+ICb/dO4R8w7EIRPAvG0cfA I6hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=+aLWTSmeusXkO/h16fvvZMI3E2/PTcSxhwr2HZ0jKu4=; b=ThJofbkUO3MR2GWXaGMgOxJTgFjKKUkSDkCxOmplmWmBS8DHYf+sOMiVQuBygzfk/z 6OhwdsnR2LN9/Sb2C/8/5p67+s4UoSvATxF1KNcG17Olxb1mtWIRL4iqb3ahp6YNRTD9 mNUeSQVwzkH6cVlL8oSk/kMCUwRd7dJBV1nnvJYSsu+3Ek/AaILuo+tByvpi+GW4W5td zwDcRsesIm1osslgbspM2V0YWumB6AoywQ/huTjIahOHIXVjuMZEzkzRAff43cX7LDjU Hw2qlntmpyVvoSqKCPL5yBfQx3043/DmN+oARR+9qVYgiTp4swzoiKGuX6XK9/HQFVLG n/Sg== X-Gm-Message-State: ABUngvf5Zvd71xH18xaO1nDgSV9iKLCQfxaNf1oACRMM3SEznVLL4TllbBZS4XryRA3qye5+QtC3jy2BEIrHbC90 X-Received: by 10.36.79.10 with SMTP id c10mr11010313itb.56.1479346682763; Wed, 16 Nov 2016 17:38:02 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.201.65 with HTTP; Wed, 16 Nov 2016 17:38:02 -0800 (PST) From: Maxim Sobolev Date: Wed, 16 Nov 2016 17:38:02 -0800 X-Google-Sender-Auth: q0nsRGutbS1VFQsdhtfRwoEzFg8 Message-ID: Subject: Adding variant of SO_TIMESTAMP: bumping so_options from short to int or some other way around? To: freebsd-hackers@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:38:03 -0000 Hi folks, we are working on some extra socket options, which is getting monotinic timestamps instead of realtime. That might be extremely useful in the Real World[tm] situations. Before looking at the code closely I've considered SO_TIMESTAMP_MT. But then and I've found that are are out of space already there are 16 options and all 16 seems to be actually referenced in the code. Would there be any objections to doubling that? The userland interfaces seems to be already "int", so we are talking about just some minor KABI breakage. Alternative approach would be to merge SO_TIMESTAMP and SO_BINTIME, which is FreeBSD-specific anyways into just SO_TIMESTAMP, so that one can do something like: int val = SO_TS_BINTIME; setsockopt(fd, SOL_SOCKET, SO_TIMESTAMP, &val, sizeof(val)); Then we can also have SO_TS_MONOTONIC, SO_TS_UPTIME etc. That second approach would be a bit heavy on third-party apps that might be using SO_BINTIME already, but some guards could be placed in to make such software to blow up in a meaningful fashion when trying to use SO_BINTIME. Third option would be to leave SO_BINTIME alone and just make SO_TIMESTAMP accept some magic value as SO_TS_MONOTONIC. That is probably the easiest, but also creates some documentation challenge to explain why mechanism for requesting "bintime" variant is different from "monotonic". My preference would be (2), since SO_BINTIME is historic relic and it should be just value for the SO_TIMESTAMP, not a separate option. Thanks! -Maxim P.S. On somewhat unrelated note I've also noticed that tcp_var uses u_short for its copy, is it my design or just some overlook? I don't see why would we want to use two different types for essentially the same thing. This is just calling for all sorts of weird bugs due to implied sign(edness) of resulting expressions. P.P.S. Please keep me on the CC, I am not subscribed to those two lists. From owner-freebsd-hackers@freebsd.org Thu Nov 17 19:42:13 2016 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 A64A4C47B34 for ; Thu, 17 Nov 2016 19:42:13 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 69B6E1FE3 for ; Thu, 17 Nov 2016 19:42:13 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id y23so73749633itc.0 for ; Thu, 17 Nov 2016 11:42:13 -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; bh=roqciExN4tsxiaXO0Z/d9ytQgxcqa0z7Opdl1Cw3U+0=; b=jIsJHUWrGq06Oehtl+KsjjBkHi/6F0VAi6EeHb6psgIC2w5nI2RLV5gW7333yGmlLo YRv7ih/F9VtOgVyrI+fenTvA4APdCWNU/iJH7PyaEm8i+ZAeCxgr2nucPvTvNfKW45QH LdJNhl7OmC2NdJGZ1ymBNbQyHwB+HRYPhCp06PVgeyHf69KqFhSdthwyFFAh9C8VfJI4 jH9te+I3/IBeKDYLPkxc4l8jnK2kJEunGOpOV9gICtW/gxp0lJB6s07BS9DPwxLqYKKQ sfiMljXdOPS9Sn3UgvoqdYBOUvVmWuSZrEmaHsuwjU8PTHzaFK4yPRAa5bMe16BX2ZDU cWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=roqciExN4tsxiaXO0Z/d9ytQgxcqa0z7Opdl1Cw3U+0=; b=k+zNUnP0gRERpdZ7h4M1zstZrd9xwC9HT5IJ7RJeUpXwwKYN8LsSPa6dGdca+E3yDv 8yAXtAqCi+rXvpOuYOJdVDAHsjSaJdUDd8PfO56JPUB1/piGcuVW8mU0KfZhR95q0Wx7 CW1dG0ljdoV54h072+wGvW3J+ytQ7c58LnHG1qQc9HtqUfWToslIG72ORig7DAn0gSd1 UXxKVjUmk1qNZh9X++X1kTOnOELB8v+Ix8cuYqSsJ/YgDO+jXQQw9Rr9scChx4+5hPcP ymG0NAmDsxalZTTZroIH4yL5CPik2Fl2bR86559MoYayaAiFnoqy8mj3R7a33w9OGTsc kNzg== X-Gm-Message-State: ABUngveEVmizehMlSzffk2PhlsTULkPiNUeW2TII7pCNj30Pzwl9SoekFCAdvQr5SZK3Uqea0cHU+e4/+arP+A== X-Received: by 10.107.162.204 with SMTP id l195mr4799724ioe.169.1479411732518; Thu, 17 Nov 2016 11:42:12 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.212 with HTTP; Thu, 17 Nov 2016 11:41:52 -0800 (PST) In-Reply-To: References: <20161110012624.GA23701@lonesome.com> <20161110215549.GL91607@kduck.kaduk.org> From: Ed Maste Date: Thu, 17 Nov 2016 14:41:52 -0500 X-Google-Sender-Auth: 6xQKyFOe7mTUcCZb2PkvbQDTKZw Message-ID: Subject: Re: sbrk(0) replacement for memory resource tracking? To: Matthias Andree Cc: Benjamin Kaduk , "freebsd-hackers@FreeBSD.org" , Mark Linimon Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 19:42:13 -0000 I seem to be missing the beginning of this thread, so pardon the lack of context in quotes below. >>> To me it looks like the sbrk() function is going away from our base >>> system underneath a stable 11-* branch. If that is true, I'll have to >>> object to that and request sbrk() be put back, we add a deprecation >>> notice now (if necessary via errata notice) and pull it only from FreeBSD12. Stable/11 never provided sbrk on arm64, and sbrk is not in the first FreeBSD release to support arm64, 11.0. Right now nothing changes for existing architectures, which continue to provide sbrk. >>> OTOH, e2fsprogs uses only sbrk(0) to track its overall memory use, and >>> only to track its resource usage. I'll be happy to help porting to >> Same for zephyr. >> >>> something else that serves the same purpose, aka "how much memory am I >>> using" - but what would that be? >> I think there isn't really a drop-in replacement. N.B. that the number >> from sbrk(0) has been meaningless for quite some time, since jemalloc >> uses mmap to get more space. > OK. So the quick and dirty way to re-enable e2fsprogs on those > architectures whilst scrapping any memory statistics would be to #define > sbrk(a) (a) which would just invalidate stats, providing the application > handles bogus data. Indeed, and that's no worse than today: applications calling sbrk(0) to measure memory use are already handling bogus data. > Other than that, it would seem that mallctl("epoch", ...) to synch up > stats, and mallctl("stats.active", ...) or perhaps or "stats.mapped" > gets me close to what comparing sbrk(0) over process lifetime would have > achieved, wouldn't it? This is assuming sbrk() had page granularity > anyhow and stats.active provides exactly that (gross memory allocated). > Possibly this also wants mallctlnametomib and mallctlbymib for > optimization if called often. Right? That seems broadly sensible to me, and I think it will be useful to have a few worked examples to demonstrate collection of memory stats with jemalloc. From owner-freebsd-hackers@freebsd.org Fri Nov 18 09:10:07 2016 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 AAAF5C4648E for ; Fri, 18 Nov 2016 09:10:07 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 096C2132B; Fri, 18 Nov 2016 09:10:06 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([78.48.229.43]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lu3J4-1cnpwf3REk-011VS0; Fri, 18 Nov 2016 10:09:52 +0100 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id E32C223CEBD; Fri, 18 Nov 2016 10:09:44 +0100 (CET) Subject: Re: sbrk(0) replacement for memory resource tracking? To: Ed Maste References: <20161110012624.GA23701@lonesome.com> <20161110215549.GL91607@kduck.kaduk.org> Cc: Benjamin Kaduk , "freebsd-hackers@FreeBSD.org" , "freebsd-hackers@freebsd.org" , Mark Linimon From: Matthias Andree Message-ID: <56d3f59d-29e7-f98d-af25-e39c51a85f11@gmx.de> Date: Fri, 18 Nov 2016 10:09:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:Y9Rt5wMcXpSkNiOGSBUhnCx5643mHguDLCACbBGU8Vp+j9zNUvS c4o3lRcNEJiyW/T+K5TniQg8JqBzrOWzjpkqFqi9zucaGVJ9MKT3L6Tct3WVzfd1LlIDD7J SIFCb4CDG3YHl6mk9KNKPn8As/t3mnQ2qtFx9RyNUaNEHDk1BzZTyD9Rmn9EF6DyNsFsIfL P1kxRZ/OxTFS7vGqlKwJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:j5jN3pFNjHU=:Id7Gcr6U6WJTT++1gkowVJ SHXZVAkrHlUEuN6nTsf43O6bymjK+TLSkgct6zqX6A0PYCnDbcbvQLvf3URXNncDB8tCjmY7g kokAmcMnqi/6gJhdIWC4P0LXP3oB4Xgr27l7fbEEhrxhU2cQ22CkaE5H08xtixI1vaPQoF7ZB FE+Z9aSF0doPaoMVmoxmA6FKJztKdWWWdubSPT//JObywejqAdvc+660xjZdsRVsW4Qj1a66s cOkjkxJBRPOwBJsn2jT8TVMMOdOxroPbnbPWUPe/YVKFa9j//5e93OMixtrHOZglUMGkAT6Mm SfNBcG6pIQ2Hbrq3ESsfp9Y85edhEnMwh3dUj7dhewXbZRCzATxfNC1uh08osK8myr8oWSUbw WkrCy+IwlJ5wMszQFZvF6aLNrgZtBWk04MIg1VR/0A/XiWxRUuNOH3XkKcjxkEg19YeTagPv/ r7YTLa+q0BKPnOXXKukkVMyyN9C019xkZFkzW051hU1NddEFxr6TtW9cCXieT0aS/P+nx6Bd7 nB3v0BxjKdUXw1fMgJrcVdsaTMDnD7/MISv6PGh29VZZKhx7NLHsdn+aLNg5/LbvFeOof7cFK J3EsE2MhB0hvM23wONuumYiPefPhB6paiRTwpmXISLHGZiCRjOmXSNF2snvm2fhjUfBXHynHQ 51ATNEA/WpaWM7Pn6gXcjNcmomcz1NtlVDBx0/8gg1LL7oUfEuPz0C7y9jlAoY11sZveaKxQj IDoUZW1LHkWqVr2GoXsZ8Umi2nZYzdcoHOlpudBuIogYqDH5k/cqZ665mBJeErgawgXBdDJnH EbjB1xV X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 09:10:07 -0000 Am 17.11.2016 um 20:41 schrieb Ed Maste: > That seems broadly sensible to me, and I think it will be useful to > have a few worked examples to demonstrate collection of memory stats > with jemalloc. Thanks. Before going the jemalloc-example way in e2fsprogs, I'd contact the upstream maintainer if that's sensible at all, because it's mostly a maintainer/developer feature for a tool set that originates in Linux, and given we don't have ext3/ext4 write support in the FreeBSD kernels currently, nor a FUSE module TTBOMK, I think e2fsprogs will remain in a niche. The upstream author was kind enough to invest a lot of time into sorting the FreeBSD portability out with me, which is more than we could have asked for. So, regarding jemalloc, what's the best way to detect it, probe features from an autoconf test, or look at the FreeBSD version macros? On a different note, we also figured that the default TMPDIR locations often do not provide sparse file support (and setting up a ram disk with UFS to obtain sparse file support requires privileges, which I try to avoid requiring from a port build), while on-disk locations (for instance, inside the port's $WRKSRC) with sparse file support slow down the self-test suite considerably if using spinning magnetic platter stacks... From owner-freebsd-hackers@freebsd.org Fri Nov 18 11:12:27 2016 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 006FCC48BF6 for ; Fri, 18 Nov 2016 11:12:27 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BF1A31DBC for ; Fri, 18 Nov 2016 11:12:26 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 685FEAA57; Fri, 18 Nov 2016 11:12:19 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id BC2184129; Fri, 18 Nov 2016 12:12:09 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthias Andree Cc: freebsd-hackers@FreeBSD.org, Mark Linimon Subject: Re: sbrk(0) replacement for memory resource tracking? References: <20161110012624.GA23701@lonesome.com> Date: Fri, 18 Nov 2016 12:12:09 +0100 In-Reply-To: (Matthias Andree's message of "Thu, 10 Nov 2016 22:21:18 +0100") Message-ID: <86oa1dujna.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 11:12:27 -0000 Matthias Andree writes: > OTOH, e2fsprogs uses only sbrk(0) to track its overall memory use, and > only to track its resource usage. I'll be happy to help porting to > something else that serves the same purpose, aka "how much memory am I > using" - but what would that be? Ideally, the realization that the numbers you get from sbrk() are completely meaningless, followed by removal of that code. And I don't just mean that they're meaningless because jemalloc() uses mmap() - they were meaningless before jemalloc(), because they only tell you how much address space the program has allocated, not how much of it is actually in use. And even if it did, it wouldn't tell you anything about memory pressure, how much of the program's memory is swapped out, etc. It's like asking how long a road is and then claiming to know where you are based on that answer. You don't - all you know is how far you could have gone without a break if you'd started at one end and kept going. And for all you know, there may be a section that's closed for repairs. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@freebsd.org Fri Nov 18 13:41:42 2016 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 44927C45C30 for ; Fri, 18 Nov 2016 13:41:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1035C1BC1 for ; Fri, 18 Nov 2016 13:41:41 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 8EE3CACF3; Fri, 18 Nov 2016 13:41:40 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id B5CF2413F; Fri, 18 Nov 2016 14:41:39 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Anthony Pankov via freebsd-hackers Cc: Anthony Pankov Subject: Re: nss_ldap seems to not work References: <1644757548.20161108110056@mail.ru> Date: Fri, 18 Nov 2016 14:41:39 +0100 In-Reply-To: <1644757548.20161108110056@mail.ru> (Anthony Pankov via freebsd-hackers's message of "Tue, 8 Nov 2016 11:00:56 +0300") Message-ID: <86k2c0ucq4.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 13:41:42 -0000 Anthony Pankov via freebsd-hackers writes: > nss_ldap seems to not work correctly at least at FreeBSD 10.3. 1) did you try contacting the maintainer? 2) https://bugs.freebsd.org/190055 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@freebsd.org Fri Nov 18 16:28:28 2016 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 63482C47621 for ; Fri, 18 Nov 2016 16:28:28 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (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 445EB1648 for ; Fri, 18 Nov 2016 16:28:27 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AAD2B16013D; Fri, 18 Nov 2016 08:21:06 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id M3xDkwrfKVPI; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9577F160148; Fri, 18 Nov 2016 08:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eQpfxs-v1rro; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Received: from [192.168.1.9] (unknown [47.153.178.162]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7730916013D; Fri, 18 Nov 2016 08:21:04 -0800 (PST) Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture To: Ashish SHUKLA References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> Cc: 24892@debbugs.gnu.org, freebsd-hackers@freebsd.org From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> Date: Fri, 18 Nov 2016 08:21:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8637ipm0nb.fsf@lostca.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Nov 2016 16:41:40 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 16:28:28 -0000 Ashish SHUKLA wrote: > One of the FreeBSD developer has > pointed me to this ongoing discussion[1] on freebsd-hackers@ list. > > References: > [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/= 050144.html OK, thanks, I'll CC: freebsd-hackers. FreeBSD hackers: this is following = up on=20 this serious Emacs bug report, which says that Emacs no longer works on F= reeBSD=20 11.x arm64: https://bugs.gnu.org/24892 The referenced FreeBSD discussion appears to be under the misapprehension= that=20 sbrk is useful only to estimate how much memory is in use, and since this= use=20 has long been wrong sbrk should be unceremoniously removed. Unfortunately= , this=20 assumption is incorrect for Emacs, as (bleeding-edge) Emacs uses its own=20 allocator during its build process, and reverts to malloc only during use= r=20 operation. (The build-time Emacs makes a copy of itself in a new executab= le, and=20 relies on sbrk during the build.) Obviously this is dicey and we are plan= ning to=20 change Emacs to make it more portable; however, this will require nontriv= ial=20 reengineering on our part. In the meantime we respectfully request that sbrk functionality be kept i= n=20 FreeBSD 11.x arm64 for a while. It is fine to mark it as deprecated or ob= solete,=20 or even rename it, but please do not remove the functionality entirely. From owner-freebsd-hackers@freebsd.org Fri Nov 18 19:46:08 2016 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 19B61C48093 for ; Fri, 18 Nov 2016 19:46:08 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (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 DD6878D3 for ; Fri, 18 Nov 2016 19:46:07 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f52.google.com with SMTP id c20so41739471itb.0 for ; Fri, 18 Nov 2016 11:46:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Xb9Lfx7uk1jTTZZBJWITcbyT7JVCY49mRAipo7eAvGg=; b=bh2R059p1Ck8pSmba/vWFOA3Gx1jFwnm8WbKP7KJAclYIP3XIEJqvqRf9xn+20euuS SZtpYMXVBL1xfWY53CuSx54yP5BOIBqSkwV5mrdIEE85gfbtZ1/ymwxy9eA2UGkn4sr3 1wWRUpsulNNU2bOjTGo8vJEOBTDWrpWJb/hXhu4fkrgDyO05R4Ai2y/YYcJalPa+oPDm 6OtP5hT3s5QSeAtVmADc59gwnMVkFDtTp/Ov59WYTmwQvCgSR0wff0n5GXPyHI/jdDbC GSQqaX4eXrpT44ECBPHMy06mrCs+jSKOebQXcxKAG42ut1fIXQKn5PZAgm1isDEmUeTK gBiQ== X-Gm-Message-State: AKaTC02PKilIEmV4XtBxCZJi698vP83qB3BeRE00fdHjnowb48oRsYUUOAYoUr5POSv33A== X-Received: by 10.36.185.83 with SMTP id k19mr75162iti.59.1479498360583; Fri, 18 Nov 2016 11:46:00 -0800 (PST) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id j189sm3456785ioe.14.2016.11.18.11.45.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 11:46:00 -0800 (PST) Received: by mail-it0-f54.google.com with SMTP id y23so49903915itc.0 for ; Fri, 18 Nov 2016 11:45:59 -0800 (PST) X-Received: by 10.36.37.199 with SMTP id g190mr114779itg.66.1479498359774; Fri, 18 Nov 2016 11:45:59 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.36.220.199 with HTTP; Fri, 18 Nov 2016 11:45:59 -0800 (PST) In-Reply-To: <56d3f59d-29e7-f98d-af25-e39c51a85f11@gmx.de> References: <20161110012624.GA23701@lonesome.com> <20161110215549.GL91607@kduck.kaduk.org> <56d3f59d-29e7-f98d-af25-e39c51a85f11@gmx.de> From: Conrad Meyer Date: Fri, 18 Nov 2016 11:45:59 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: sbrk(0) replacement for memory resource tracking? To: Matthias Andree Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 19:46:08 -0000 On Fri, Nov 18, 2016 at 1:09 AM, Matthias Andree wrote: > Before going the jemalloc-example way in e2fsprogs, I'd contact the > upstream maintainer if that's sensible at all, because it's mostly a > maintainer/developer feature for a tool set that originates in Linux, > and given we don't have ext3/ext4 write support in the FreeBSD kernels > currently, nor a FUSE module TTBOMK, I think e2fsprogs will remain in a > niche. Hi Matthias, Actually, FreeBSD can R/W ext4 (and ext3/ext2) very happily with the sysutils/fusefs-lkl port :-). It can also read/write XFS and some kinds of BTRFS images. Best, Conrad From owner-freebsd-hackers@freebsd.org Fri Nov 18 20:20:47 2016 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 6FBBAC47AE5 for ; Fri, 18 Nov 2016 20:20:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 39584CE7 for ; Fri, 18 Nov 2016 20:20:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x241.google.com with SMTP id b123so6691783itb.2 for ; Fri, 18 Nov 2016 12:20:47 -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; bh=YMs5wF4JVnyCzAvZc7qnkZlNBZpXiNDhxwrHzvPBwko=; b=zOB+2VmFv5BUCZ3WjvErvkkYlBeOtnm82bC0Ob8JCY9jr1vxpFcVXMFvuHXJVA/wFD yRGxdnvRV4HLrsTF68W4TBrP7ZI7ukEZI8Qu/Ui/7VvOgx+q2jTCe2CcvKQEy7sYAcSG mjMV+iYNVxhVssipJ/AVaGE3KzrGB3GNaHD8KD0ZUQ06z4WfdAWSLcV6OAb+32o83t+f 3+IapKCmG6quK0QgsNOP6vLuDndpTdEB60AICgvN++fvlkIebPeV60/jyBGP1paX9oWM zyQ+DfAVWqC8b50MUrJHc9aeyNsYLp7Ojeikj5qBX0o172lxy5BeJ7JZ+LSL0nokyE/h Hfzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YMs5wF4JVnyCzAvZc7qnkZlNBZpXiNDhxwrHzvPBwko=; b=F8096sp4F4FxrMSzAADmfxVe5quj+txT5DUc19MFLGSyCScWnuHgOhYKdVO8mpjQCU ZCWLBSnQSlT3wih4/Z+S52vEgt6fbs/+1tDpK9XhbYPTF/73oHivGXPeNyHDGK1+YWd4 FhVDRwNtbDH10h0lWL3BvGOhGfKulWTslcEO6HjFqbvkP+jFo6zOM4acdUAZ0uQVEvuw JDoBuTMkO/07WfRNQflZ9ymJbupqoPf8JVi16eb2XXdj4Z0yrrE8XDf/pKCfwMD4+02Z PyKKmJtiXFEDVehD2Sc6v1fo4Mmf4YM87jdoAwRt8BDzOUYCslTwUdT7DutGLzS5rwuQ ELlQ== X-Gm-Message-State: AKaTC02VEAqVnAcimrEGdGPmf8pbHDz9n1R9ek8zc/wL63roHkatScBvT9rzqyioThiA8VjFu4IdUJjlKAR/YQ== X-Received: by 10.107.19.164 with SMTP id 36mr1603452iot.155.1479500446675; Fri, 18 Nov 2016 12:20:46 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.212 with HTTP; Fri, 18 Nov 2016 12:20:26 -0800 (PST) In-Reply-To: <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> From: Ed Maste Date: Fri, 18 Nov 2016 15:20:26 -0500 X-Google-Sender-Auth: xetLFq1nfpUkDCnuQsJf4XMJV5M Message-ID: Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture To: Paul Eggert Cc: Ashish SHUKLA , "freebsd-hackers@freebsd.org" , 24892@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 20:20:47 -0000 On 18 November 2016 at 11:21, Paul Eggert wrote: > > In the meantime we respectfully request that sbrk functionality be kept in > FreeBSD 11.x arm64 for a while. It is fine to mark it as deprecated or > obsolete, or even rename it, but please do not remove the functionality > entirely. Hi Paul, I want to clarify one point: arm64 support was first available in a release in FreeBSD 11.0, without sbrk, and sbrk never existed on the stable/11 branch. It's important for us that emacs works on FreeBSD (including FreeBSD/arm64) and there are folks willing to help make that happen. I had a quick look at emacs' source, and it seems there's an implementation that allocates memory out of a large array in .bss used for some platforms - could we make use of that here? From owner-freebsd-hackers@freebsd.org Fri Nov 18 20:31:23 2016 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 A0F97C48005 for ; Fri, 18 Nov 2016 20:31:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 7C38413C3 for ; Fri, 18 Nov 2016 20:31:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6C6135A9F14; Fri, 18 Nov 2016 20:23:28 +0000 (UTC) Date: Fri, 18 Nov 2016 20:23:28 +0000 From: Brooks Davis To: Paul Eggert Cc: Ashish SHUKLA , freebsd-hackers@freebsd.org, 24892@debbugs.gnu.org Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture Message-ID: <20161118202328.GA79070@spindle.one-eyed-alien.net> References: <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> User-Agent: Mutt/1.7.0 (2016-08-17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 20:31:23 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2016 at 08:21:04AM -0800, Paul Eggert wrote: > Ashish SHUKLA wrote: >=20 > > One of the FreeBSD developer has > > pointed me to this ongoing discussion[1] on freebsd-hackers@ list. > > > > References: > > [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/= 050144.html >=20 > OK, thanks, I'll CC: freebsd-hackers. FreeBSD hackers: this is following = up on=20 > this serious Emacs bug report, which says that Emacs no longer works on F= reeBSD=20 > 11.x arm64: >=20 > https://bugs.gnu.org/24892 >=20 > The referenced FreeBSD discussion appears to be under the misapprehension= that=20 > sbrk is useful only to estimate how much memory is in use, and since this= use=20 > has long been wrong sbrk should be unceremoniously removed. Unfortunately= , this=20 > assumption is incorrect for Emacs, as (bleeding-edge) Emacs uses its own= =20 > allocator during its build process, and reverts to malloc only during use= r=20 > operation. (The build-time Emacs makes a copy of itself in a new executab= le, and=20 > relies on sbrk during the build.) Obviously this is dicey and we are plan= ning to=20 > change Emacs to make it more portable; however, this will require nontriv= ial=20 > reengineering on our part. >=20 > In the meantime we respectfully request that sbrk functionality be kept i= n=20 > FreeBSD 11.x arm64 for a while. It is fine to mark it as deprecated or ob= solete,=20 > or even rename it, but please do not remove the functionality entirely. Under FreeBSD's stability rules if we shipped ANY release for a platforms (e.g. arm64, riscv) with a system call, we must support it for the life of the architecture (approximately FOREVER). As such, if any other solution is viable, we'd prefer that. What does emacs actually need from sbrk()? Could it get by with something with the same interface allocating from .bss or does it need its allocations to be at the end of .bss? I'm happy to put some time into a userspace workaround if one is viable. -- Brooks --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYL2M/AAoJEKzQXbSebgfAIWkH/1lRbnad9HgqjZzmWERuV9hn NqlZjygWmyALFvLnmTQPlEYK0MIWoVKlyRkozd7Okd4CEN5gvgOA/NilDLGktkuF 5Cttp5x9CxhXKOHJS0bABs1jEqXXgCz3B9GnWoDQ2u7JxLdv4UTretvFTBAlgY4G rljgv3B2NGa2+PrvON1cKmmMPJnn/lGkrNr2bOkOYmQFuMgI0XcqpszbxQYfeR2R /zCibyTIAYELxu2fBFJxf5WO5VE7yUkP+hzeTL0DVSGalQgQ4pkTTVUsJaV8uSr+ ++TjPzDqUONgQmr+WKxqwg89Yd/JUdL2OARbpnywqlZeahKxJTXy1w9RfnO1pxI= =IA5Z -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-hackers@freebsd.org Fri Nov 18 22:22:10 2016 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 36113C48755 for ; Fri, 18 Nov 2016 22:22:10 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (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 1463519C0; Fri, 18 Nov 2016 22:22:09 +0000 (UTC) (envelope-from eggert@cs.ucla.edu) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D3F5916006F; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4Uy_Ra3XdPtE; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 15A7F160070; Fri, 18 Nov 2016 14:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rz5yrrQtfNxQ; Fri, 18 Nov 2016 14:22:08 -0800 (PST) Received: from [192.168.1.9] (unknown [47.153.178.162]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E296B16006F; Fri, 18 Nov 2016 14:22:07 -0800 (PST) Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture To: Ed Maste References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> Cc: Ashish SHUKLA , freebsd-hackers@freebsd.org, 24892@debbugs.gnu.org, Brooks Davis From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu> Date: Fri, 18 Nov 2016 14:22:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Nov 2016 22:56:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 22:22:10 -0000 Ed Maste wrote: > arm64 support was first available in a release in FreeBSD 11.0, without= sbrk, and sbrk never existed on the stable/11 branch. Thanks, I didn't know that. So Emacs has never worked in this environment= . > it seems there's an implementation that allocates memory out of a large= array in .bss used for some platforms - could we make use of that here? Quite possibly. Unfortunately the code that uses that array (in gmalloc.c= ) also=20 uses sbrk to move the break past the end of the large array. The large ar= ray is=20 intended for use only during the build process; during ordinary execution= , sbrk=20 is used. Perhaps Emacs could work around the problem by supplying a user-space sbr= k=20 emulator, which uses mmap to support the old-fashioned model where the he= ap is=20 contiguous. Is that something that could be done easily? That is, is ther= e some=20 way to reserve the address space for a potentially-large Emacs heap right= after=20 .bss, such that library calls to malloc and mmap won't use this address s= pace?=20 That might do the trick. Brooks Davis wrote: > What does emacs actually need from sbrk()? Could it get by with someth= ing with the same interface allocating from .bss or does it need its allo= cations to be at the end of .bss? I think more the latter. The problem with a fixed-size .bss is that whate= ver=20 size we pick during the build is likely to be wrong for users. Also, Emac= s saves=20 the entire build-time .bss into an executable, so an enormous .bss will b= e=20 counterproductive. From owner-freebsd-hackers@freebsd.org Sat Nov 19 06:58:04 2016 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 4F4F4C49A0F for ; Sat, 19 Nov 2016 06:58:04 +0000 (UTC) (envelope-from eliz@gnu.org) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:4830:134:3::10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21A5FE10 for ; Sat, 19 Nov 2016 06:58:04 +0000 (UTC) (envelope-from eliz@gnu.org) Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7zb8-0002go-Cf for freebsd-hackers@freebsd.org; Sat, 19 Nov 2016 01:58:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7zam-0002bY-5x; Sat, 19 Nov 2016 01:57:40 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c7zal-0003x0-6z; Sat, 19 Nov 2016 01:57:39 -0500 Date: Sat, 19 Nov 2016 08:57:44 +0200 Message-Id: <83vavkardj.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert CC: emaste@freebsd.org, freebsd-hackers@freebsd.org, brooks@freebsd.org, 24892@debbugs.gnu.org, ashish.is@lostca.se In-reply-to: <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu> (message from Paul Eggert on Fri, 18 Nov 2016 14:22:07 -0800) Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture Reply-to: Eli Zaretskii References: <82a03552-8f33-2dbe-6bb5-54f649b29db7@cs.ucla.edu> <86vavxs2cn.fsf@members.fsf.org> <5adee8d9-8f08-9536-a95f-ae64719d6a0f@cs.ucla.edu> <40f8df50-b431-1ebd-221c-df2aa453aa81@cs.ucla.edu> <06ee71fd-1a64-d32b-862e-c725807aef4e@cs.ucla.edu> <876cf047-82fb-f08c-bbb3-024206f6fabd@cs.ucla.edu> <83twb6dnkm.fsf@gnu.org> <8637ipm0nb.fsf@lostca.se> <5ec481c4-41e1-c7dd-433d-f533653b132f@cs.ucla.edu> <1dc6fa8c-7378-6e4e-1d9e-86c962fc48bb@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Mailman-Approved-At: Sat, 19 Nov 2016 12:46:27 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 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 Nov 2016 06:58:04 -0000 > From: Paul Eggert > Date: Fri, 18 Nov 2016 14:22:07 -0800 > Cc: freebsd-hackers@freebsd.org, Brooks Davis , > 24892@debbugs.gnu.org, Ashish SHUKLA > > > it seems there's an implementation that allocates memory out of a large array in .bss used for some platforms - could we make use of that here? > > Quite possibly. Unfortunately the code that uses that array (in gmalloc.c) also > uses sbrk to move the break past the end of the large array. The large array is > intended for use only during the build process; during ordinary execution, sbrk > is used. > > Perhaps Emacs could work around the problem by supplying a user-space sbrk > emulator, which uses mmap to support the old-fashioned model where the heap is > contiguous. Is that something that could be done easily? That is, is there some > way to reserve the address space for a potentially-large Emacs heap right after > .bss, such that library calls to malloc and mmap won't use this address space? > That might do the trick. > > Brooks Davis wrote: > > What does emacs actually need from sbrk()? Could it get by with something with the same interface allocating from .bss or does it need its allocations to be at the end of .bss? > > I think more the latter. The problem with a fixed-size .bss is that whatever > size we pick during the build is likely to be wrong for users. Also, Emacs saves > the entire build-time .bss into an executable, so an enormous .bss will be > counterproductive. I agree with everything Paul wrote. There's one other factor you should be aware of: Emacs 25.2 will most probably start its pretest in a week or so. If this problem can be solved for FreeBSD on arm64 by providing a drop-in replacement for sbrk, we could include that in 25.2, which is a strictly bug-fix release that can only accept safe bug fixes. If not, the solution will have to wait for Emacs 26.1, currently being developed on the master branch, which is unlikely to be released before mid-2017 or even the end of 2017. Not a catastrophe, given that Emacs never worked on this host, but something to consider. (It is, of course, possible to provide a simple and safe solution for 25.2 and a more elaborate one for 26.1.) Thanks. From owner-freebsd-hackers@freebsd.org Sat Nov 19 18:14:02 2016 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 EC4D2C4BC94 for ; Sat, 19 Nov 2016 18:14:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 C08A81C6A for ; Sat, 19 Nov 2016 18:14:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22a.google.com with SMTP id j65so10060391iof.0 for ; Sat, 19 Nov 2016 10:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=d90ErHqCFaat5TiHBF9c86veiJzIQcn4gHOqhHHPJE8=; b=BgpdEo6fhQmF3JzD3VuNi+ylkr138JKyEXcOtZFf1hxn5re6UkdXs8t3og2uUsI9CU qxpBS4f11EmSQ7dOivS8RDfrsKPAD51CrSn3uBD41nUMcTyW2akJtOGwf3Jo89UoLK3O ObRKMTebe/vKMSh8hQf4c6BU53NxBCarBfqsd2OY7Tiiis1s6dPCNXUTVE27SEp8TfSu JhlMO1qH/YX1h5ahtFDoXGM92SVfX4bbM218CDWrM4JLYDoT8XydL8syLn6eXvdhcxra o6nM6YsCtPdGOhJP4JOtId63ovOncZfSaKGPv4HTvBNdAjdpa70VZCqxItdhPKEJZ+63 YKfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=d90ErHqCFaat5TiHBF9c86veiJzIQcn4gHOqhHHPJE8=; b=I/vjIto9SmQFxQNPPV8ifeu7h46QMzmRqxaabZSLRVRVqXFmWjkEoJjj5dBQcZjHXM Ex9k0X4suuitpHKNNojyf80U3XUm7KVyFtpDqoseihZ7XKDGOl+RipMXXmXUi3eYDhBZ NK8bWwcTYk2XVV7BX6FlNGhk7tRnE6dQPbS+ZlBVZBddr5f+wGJlImIUSW/TtW781OTr XRkN2le0yLwFsxQ50gXKYRpFY7804BO1C+FvprLrJzuzSinLx4AA7cajMZbY+/ZB89zf vacE8QHclyVagw/lGJFk1Ce+0j0AiiAbfGrOHAfEuF4snKuSdO9QVfakvIbPj11Y62av +WrQ== X-Gm-Message-State: AKaTC0122zd3gZheMBdR7GrUzcAhPmZNZg7PJmHS0lZRZfnPLrREIa1SWptgBgivws6qoFSEL6KjXfjYZ0o8h0AG X-Received: by 10.107.13.137 with SMTP id 131mr4629573ion.122.1479579241381; Sat, 19 Nov 2016 10:14:01 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.73.102 with HTTP; Sat, 19 Nov 2016 10:14:00 -0800 (PST) From: Maxim Sobolev Date: Sat, 19 Nov 2016 10:14:00 -0800 X-Google-Sender-Auth: 2M5FVZF3N3_QVMOd0ebnSE5ikDQ Message-ID: Subject: Re: Adding SO_CLOCK (replacing SO_BINTIME?). To: freebsd-hackers@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 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 Nov 2016 18:14:03 -0000 OK, after some more consideration, I'd probably go with scraping SO_BINTIME (FreeBSD private thing) and replacing it with SO_CLOCK which then would take type of clock as an argument, i.e.: int val = SO_CLOCK_MONOTONIC; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); or int val = SO_CLOCK_BINTIME; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); Default value being SO_CLOCK_REALTIME. Then SO_TIMESTAMP could be just the on/off trigger so that there is consistency. We can keep SO_BINTIME around for binary compatibility too at least on the binary level by moving it into a kernel private name space. Regardless of this, I think so_options needs to be bumped up to match what user interface can accommodate (int, not short), makes no sense to "save"* 2 bytes per socket in 2016. The diff is here, reviewers are welcome. https://reviews.freebsd.org/D8582 -Max *) yes, I know it's not really saved perhaps due to alignment and such, hence "". On Wed, Nov 16, 2016 at 5:38 PM, Maxim Sobolev wrote: > Hi folks, we are working on some extra socket options, which is getting > monotinic timestamps instead of realtime. That might be extremely useful in > the Real World[tm] situations. > > Before looking at the code closely I've considered SO_TIMESTAMP_MT. But > then and I've found that are are out of space already there are 16 options > and all 16 seems to be actually referenced in the code. Would there be any > objections to doubling that? The userland interfaces seems to be already > "int", so we are talking about just some minor KABI breakage. > > Alternative approach would be to merge SO_TIMESTAMP and SO_BINTIME, which > is FreeBSD-specific anyways into just SO_TIMESTAMP, so that one can do > something like: > > int val = SO_TS_BINTIME; > setsockopt(fd, SOL_SOCKET, SO_TIMESTAMP, &val, sizeof(val)); > > Then we can also have SO_TS_MONOTONIC, SO_TS_UPTIME etc. > > That second approach would be a bit heavy on third-party apps that might > be using SO_BINTIME already, but some guards could be placed in to make > such software to blow up in a meaningful fashion when trying to use > SO_BINTIME. > > Third option would be to leave SO_BINTIME alone and just make SO_TIMESTAMP > accept some magic value as SO_TS_MONOTONIC. That is probably the easiest, > but also creates some documentation challenge to explain why mechanism for > requesting "bintime" variant is different from "monotonic". > > My preference would be (2), since SO_BINTIME is historic relic and it > should be just value for the SO_TIMESTAMP, not a separate option. > > Thanks! > > -Maxim > P.S. On somewhat unrelated note I've also noticed that tcp_var > uses u_short for its copy, is it my design or just some overlook? I don't > see why would we want to use two different types for essentially the same > thing. This is just calling for all sorts of weird bugs due to implied > sign(edness) of resulting expressions. > P.P.S. Please keep me on the CC, I am not subscribed to those two lists. >