From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 10 11:23:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 662D1463 for ; Sun, 10 Mar 2013 11:23:38 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id CB62586C for ; Sun, 10 Mar 2013 11:23:37 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r2ABNKuI081425 for ; Sun, 10 Mar 2013 12:23:20 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r2ABNKQu081422 for ; Sun, 10 Mar 2013 12:23:20 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 10 Mar 2013 12:23:20 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: recent FreeBSD 9 kernel breaks fusefs-kmod Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 10 Mar 2013 12:23:21 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 11:23:38 -0000 Before about 3 months ago or so, fusefs-kmod worked fine under FreeBSD 9. Now, with newest 9 it doesn't on amd64. It works fine on i386. on amd64 i can do ntfsmount but the mountpoint is not a directory and all i can do is to unmount. tried exactly the same version of fusefs-kmod, as well as recent. Any idea? From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 11 01:08:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59673B67 for ; Mon, 11 Mar 2013 01:08:16 +0000 (UTC) (envelope-from ilya.kaliman@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id CF2B1A91 for ; Mon, 11 Mar 2013 01:08:15 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so3287101lab.5 for ; Sun, 10 Mar 2013 18:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=DBpREcCNEoB4ddEMfKH9cbDURFQBNsQfBJ91TKHDNlg=; b=Ux96hEfcqweC72zit0RYE0QzHH60OlnP8KMc32JmxzpRJlzObNGfpbjGnVOft3Shgt Rimlg+EKwFoeil4RJgSOArRW737nLh63DRYiqLHPMhj32qWS0j4YkuuLEwX0Z2BwEkSE SAdCY6V51ARblVChPJVviEv/rUwwt6I4I4usK2gnaKB2RHuOfZpgVTYy+COVAtwmzUiQ Ah4jX8iAoTRdplvVfwPlI1KwlegQRNc+zYT7qepTRECuQsk8ys+YXOmSvJZYQjh37mnb 7ZGFlLAGRRIlNrg81tF4YIEsO+ZH/xvqhs/gKoLEAL4sRRS8dAKTAkGE0iMPgw+VNV/w rLvw== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr8595586lab.28.1362963602496; Sun, 10 Mar 2013 18:00:02 -0700 (PDT) Received: by 10.114.19.105 with HTTP; Sun, 10 Mar 2013 18:00:02 -0700 (PDT) Date: Sun, 10 Mar 2013 21:00:02 -0400 Message-ID: Subject: Linking produces unusable executable From: Ilya Kaliman To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 01:08:16 -0000 Hello, hackers! I have a strange problem with a big executable. I have a piece of scientific software and some C++ module in it with a LOT of template code. When compiled this module produces 450 MB archive file (w/o debugging symbols). Now, when I compile the program without this module everything works perfect. With this module turned on the linker produces an executable (around 180 MB in size) without any errors or warnings. But when I try to start the final program zsh just says: abort. ldd on this exe says: ./a.out: signal 6. I watched the memory consumption during linking and it doesn't seem to exhaust all available memory (the linker seem to stop allocating on around 2 GB). I've also tried to enable --no-keep-memory for ld with no luck - linking still produces no errors but the resulting executable is unusable. I've tried it on 9.1 and 10-CURRENT with both gcc/g++/ld from the base system and from ports (gcc 4.7.3, binutils 2.23.1) and with clang. I've tried to build some of the bigger ports like chromium (just in case): all works fine. Everything works on linux though (with the same gcc/ld). With debugging symbols the exe is around 1GB, without them its around 200MB. Works fine in every case with different optimization levels. Any ideas how to solve this? Thanks, Ilya. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 11 05:58:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 122CEA66 for ; Mon, 11 Mar 2013 05:58:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAE97AA for ; Mon, 11 Mar 2013 05:58:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2B5wMrB049097; Mon, 11 Mar 2013 07:58:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2B5wMrB049097 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2B5wMW4049096; Mon, 11 Mar 2013 07:58:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Mar 2013 07:58:22 +0200 From: Konstantin Belousov To: Ilya Kaliman Subject: Re: Linking produces unusable executable Message-ID: <20130311055822.GK3794@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lKueCj4EYK2W7OYQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 05:58:27 -0000 --lKueCj4EYK2W7OYQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 10, 2013 at 09:00:02PM -0400, Ilya Kaliman wrote: > Hello, hackers! >=20 > I have a strange problem with a big executable. I have a piece of scienti= fic > software and some C++ module in it with a LOT of template code. When comp= iled > this module produces 450 MB archive file (w/o debugging symbols). Now, wh= en I > compile the program without this module everything works perfect. With th= is > module turned on the linker produces an executable (around 180 MB in size) > without any errors or warnings. But when I try to start the final program= zsh > just says: abort. ldd on this exe says: ./a.out: signal 6. >=20 > I watched the memory consumption during linking and it doesn't seem to ex= haust > all available memory (the linker seem to stop allocating on around 2 GB).= I've > also tried to enable --no-keep-memory for ld with no luck - linking still > produces no errors but the resulting executable is unusable. >=20 > I've tried it on 9.1 and 10-CURRENT with both gcc/g++/ld from the base sy= stem > and from ports (gcc 4.7.3, binutils 2.23.1) and with clang. >=20 > I've tried to build some of the bigger ports like chromium (just in case): > all works fine. >=20 > Everything works on linux though (with the same gcc/ld). With debugging s= ymbols > the exe is around 1GB, without them its around 200MB. Works fine in every= case > with different optimization levels. >=20 > Any ideas how to solve this? For start, it would be nice to provide some useful information together or even instead of the long story. What is the architecture ? Show at least the output of the size(1) on the final binary. Show exact shell message on the attempt of the binary run. Show the ktrace/kdump of the start attempt. As a guess, look at the sysctl kern.maxtsiz and compare it to the text size reported by the size(1). The same for the initialized data segment and kern.maxdsiz. --lKueCj4EYK2W7OYQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRPXJ9AAoJEJDCuSvBvK1BqbYP/2g3sQxERXQQ21Sxuvey6lpF 2Cp1KERyXmHyUoPmC9DPXykarsGffS8+z8138/0go2gYr84w1d++WVgdwsT8soAk eXbbxKv76/TlVD5P27GLX0v7m4H1KLQYOrr1bVKS2F7Qt5pfj0k9xLch557nHGnk 5a2w9PN/61WP4Lvjx+8m/hU7Tp/vwzy0Ol91hPgHHVrw/VCGO1sTW3GWaHDcg1Q9 uNs6wiBY97Oes/y563feK5MG+BlKCBsuTNZTb0nGxKlBEYxU3sRDJYfxVAYyyUUC 4svtbLt3iyvvlxC4uWbxuzR/YZWX0mYnwWJVpqRH46d3d0Q8SODV1N0Wcnzq0YJV 7FYywUGTUGFnlFYXnZ7JgJb659VdIoKHkSZ3fc00gLPCSzL9hU5FNKSvCdYrV37j wpm1x5hmg12yTnEEDh4/g1CXTRQsqCEKSSd2CsnttMnInym9WbXNN4h56y5R1sY7 o3LRCY2egB35yWY/TSHsDh3eOEMIRjB9Rc/2AIiAfcOdAJNRgOxwFF0NATC7/QKg /Si5/HyUawKqiRl9SbQyXTlS4AJr8YCp388H+XWZLYR0xfG6aQ5X1CnWLEKZoing v8FstUkXjfWhCtF7qixrA1TTXfizc3kOozDbcOa1ZnT52zQwzNzRVxT3i6GyCIGV JLML4A17D2vID2yxRkPK =Sxze -----END PGP SIGNATURE----- --lKueCj4EYK2W7OYQ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 11 16:12:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76BBB6B7 for ; Mon, 11 Mar 2013 16:12:42 +0000 (UTC) (envelope-from ilya.kaliman@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 06455D22 for ; Mon, 11 Mar 2013 16:12:41 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so4068265lab.4 for ; Mon, 11 Mar 2013 09:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nmRmrHG6DHmt8JS38kDGdy4p8aZfRAusATNGKCRIUGw=; b=HK2Fa5wOEmKU+TOoRolLEmQSGytkkC8qnF6nldgzq+FSM6DKWrFZsgvySdsSu3bDW5 JY73+z7u5e7srMu4Evc0MvUg0TtLoMR7QOL/pAsZZjjATookC1DQ+AnymwuGx9IUOHDO 41J7NkvEilOv9wKohcIl9WiTp1RSaLPTOTvO/DJmA/i4hDLzzrD7nfJYlh6xFoDkY8dw CtTDpB1qZburLKvTse0Ce2N0O5GAGPWpaBqpy1JG6Osdw7VpCwn8nWsS3FcXIIUuh1PB 5o/bwQGx5QQcpQ/BDJkTB4HdPjcAN1YlZ7dYM56lB1Brf/TXGTn0i4Pdz7b112MVpZY4 nFyw== MIME-Version: 1.0 X-Received: by 10.152.109.208 with SMTP id hu16mr10796035lab.45.1363018360759; Mon, 11 Mar 2013 09:12:40 -0700 (PDT) Received: by 10.114.19.105 with HTTP; Mon, 11 Mar 2013 09:12:40 -0700 (PDT) In-Reply-To: <20130311055822.GK3794@kib.kiev.ua> References: <20130311055822.GK3794@kib.kiev.ua> Date: Mon, 11 Mar 2013 12:12:40 -0400 Message-ID: Subject: Re: Linking produces unusable executable From: Ilya Kaliman To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 16:12:42 -0000 Thanks a lot for the help! Increasing kern.maxtsiz solved the problem. Best, Ilya. On Mon, Mar 11, 2013 at 1:58 AM, Konstantin Belousov wrote: > On Sun, Mar 10, 2013 at 09:00:02PM -0400, Ilya Kaliman wrote: >> Hello, hackers! >> >> I have a strange problem with a big executable. I have a piece of scientific >> software and some C++ module in it with a LOT of template code. When compiled >> this module produces 450 MB archive file (w/o debugging symbols). Now, when I >> compile the program without this module everything works perfect. With this >> module turned on the linker produces an executable (around 180 MB in size) >> without any errors or warnings. But when I try to start the final program zsh >> just says: abort. ldd on this exe says: ./a.out: signal 6. >> >> I watched the memory consumption during linking and it doesn't seem to exhaust >> all available memory (the linker seem to stop allocating on around 2 GB). I've >> also tried to enable --no-keep-memory for ld with no luck - linking still >> produces no errors but the resulting executable is unusable. >> >> I've tried it on 9.1 and 10-CURRENT with both gcc/g++/ld from the base system >> and from ports (gcc 4.7.3, binutils 2.23.1) and with clang. >> >> I've tried to build some of the bigger ports like chromium (just in case): >> all works fine. >> >> Everything works on linux though (with the same gcc/ld). With debugging symbols >> the exe is around 1GB, without them its around 200MB. Works fine in every case >> with different optimization levels. >> >> Any ideas how to solve this? > > For start, it would be nice to provide some useful information together > or even instead of the long story. > > What is the architecture ? Show at least the output of the size(1) on > the final binary. Show exact shell message on the attempt of the binary > run. Show the ktrace/kdump of the start attempt. > > As a guess, look at the sysctl kern.maxtsiz and compare it to the text > size reported by the size(1). The same for the initialized data segment > and kern.maxdsiz. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 12 03:17:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1F626F4; Tue, 12 Mar 2013 03:17:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3FE327; Tue, 12 Mar 2013 03:17:09 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l13so1468505wie.8 for ; Mon, 11 Mar 2013 20:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=E3s/U9vOwscCZU2LPAZqm/01ydGxLYfJw5yPfEWZKz8=; b=MjT2g0NLgS+Muqj1tbBly1ayB5inreSx5Qx1uTVe0MX2KYstGG0BzaiEcBYJPbPp36 1sv9hSfh5RSeZ9s7Q8RssuREUQwQmO/yAOBiptY2PqbeI8cIXlGtcbeKzsNY25MaQAL5 0IOQdvNmtgYR1sqAnD8tuFgahE1w/Jgib9Y9cf1V2QSBn+OiqM6TxViA56NV8Vq2mM2S 52JTCS0OggZVLxgUMd7mXLD16CUlO1/LWrhqIMJk+sKqivQPkUZtn33cMi4Ln1qiPFCy 8VZV1im+Jm+GXvWF/YOGVfbARpk0BA4FUObRKZ9a7FVM6I2793awsHL4tlWujkBmG8wi Wk/g== MIME-Version: 1.0 X-Received: by 10.180.94.135 with SMTP id dc7mr16637127wib.11.1363058228902; Mon, 11 Mar 2013 20:17:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.111.201 with HTTP; Mon, 11 Mar 2013 20:17:08 -0700 (PDT) Date: Mon, 11 Mar 2013 20:17:08 -0700 X-Google-Sender-Auth: 0sz8j-v-WWrN-p7XD8qvcXe8xws Message-ID: Subject: clang - odd macro / conditional expansion behaviour? From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 03:17:10 -0000 I've hit this rather amusing clang behaviour: In file included from /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21: /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300template_generic.h:107:3: error: implicit conversion from 'int' to 'u_int8_t' (aka 'unsigned char') changes value from -477 to 35 [-Werror,-Wconstant-conversion] FREQ2FBIN(2412, 1), ^~~~~~~~~~~~~~~~~~ /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300eep.h:136:65: note: expanded from macro 'FREQ2FBIN' (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) ~~~~~~~~~~~~~^~~ .. now, HAL_FREQ_BAND_2GHZ is defined here as: typedef enum { HAL_FREQ_BAND_5GHZ = 0, HAL_FREQ_BAND_2GHZ = 1, } HAL_FREQ_BAND; And: #define FREQ2FBIN(x,y) \ (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) And all of those macros here have '1' in the second field, yet when they're expanded they evaluate as if it were false. So, what's going on? :-) gcc is fine with this. :) Thanks! Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 12 07:52:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65E4FE7D; Tue, 12 Mar 2013 07:52:12 +0000 (UTC) (envelope-from dim@freebsd.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 218B8EB7; Tue, 12 Mar 2013 07:52:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::5090:4bd6:bcf8:9b4f] (unknown [IPv6:2001:7b8:3a7:0:5090:4bd6:bcf8:9b4f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5CE305C44; Tue, 12 Mar 2013 08:52:10 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: clang - odd macro / conditional expansion behaviour? From: Dimitry Andric In-Reply-To: Date: Tue, 12 Mar 2013 08:52:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1499) Cc: freebsd-hackers@freebsd.org, Joerg Sonnenberger X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 07:52:12 -0000 On Mar 12, 2013, at 04:17 , Adrian Chadd wrote: > In file included from > = /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/s= ys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21: > = /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/s= ys/dev/ath/ath_hal/ar9300/ar9300template_generic.h:107:3: > error: implicit conversion from 'int' to > 'u_int8_t' (aka 'unsigned char') changes value from -477 to 35 > [-Werror,-Wconstant-conversion] > FREQ2FBIN(2412, 1), > ^~~~~~~~~~~~~~~~~~ > = /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib/s= ys/dev/ath/ath_hal/ar9300/ar9300eep.h:136:65: > note: expanded from macro 'FREQ2FBIN' > (((y) =3D=3D HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / = 5)) > ~~~~~~~~~~~~~^~~ I cannot find the exact code you are referencing here, but I assume it = is some sort of global initialization? If so, this is most likely = , which has been = languishing in LLVM's Bugzilla for a way too long time. :-( From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 12 07:55:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C906BE5 for ; Tue, 12 Mar 2013 07:55:28 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.rzone.de (mo6-p00-ob.rzone.de [IPv6:2a01:238:20a:202:5300::1]) by mx1.freebsd.org (Postfix) with ESMTP id 67270ED7 for ; Tue, 12 Mar 2013 07:55:28 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/avkuryxskj2CPCCaJAbM X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (c214067.ppp.asahi-net.or.jp [210.155.214.67]) by smtp.strato.de (joses mo12) (RZmta 31.19 AUTH) with (AES128-SHA encrypted) ESMTPA id N023f9p2C7M6bl for ; Tue, 12 Mar 2013 08:55:20 +0100 (CET) Received: by britannica.bec.de (sSMTP sendmail emulation); Tue, 12 Mar 2013 16:55:16 +0900 Date: Tue, 12 Mar 2013 16:55:16 +0900 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: clang - odd macro / conditional expansion behaviour? Message-ID: <20130312075516.GC26683@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 07:55:28 -0000 On Mon, Mar 11, 2013 at 08:17:08PM -0700, Adrian Chadd wrote: > I've hit this rather amusing clang behaviour: I think you are hitting a variant of http://llvm.org/bugs/show_bug.cgi?id=10030. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 12 14:14:54 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ABFA0BCD; Tue, 12 Mar 2013 14:14:54 +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 B9DABBDF; Tue, 12 Mar 2013 14:14:53 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA18425; Tue, 12 Mar 2013 16:14:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <513F385B.9010106@FreeBSD.org> Date: Tue, 12 Mar 2013 16:14:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-hackers Subject: dtrace: operands have incompatible types: "dmu_buf_t **" = "dmu_buf_t **" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:14:54 -0000 For your amusement: ============= testcase.d ============= dmu_buf_t **buf; /* Remove the following line to defuse. */ bpobj_t *bpobj; fbt::dmu_bonus_hold:entry { buf = args[3]; /* the error is about this line */ } ======================================= I think I know what's going on, but I am still making sure that that's true. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 12 17:34:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C994DD21; Tue, 12 Mar 2013 17:34:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 444F45FE; Tue, 12 Mar 2013 17:34:20 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so104490wey.5 for ; Tue, 12 Mar 2013 10:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=r1XK8HymJvOCHuuBRNY91QWMR2xpq9Rqf7JkP6Xeh9Q=; b=lZa034s7oJ+LWXLwnIueHOW9YSGKP0yPoEmm2OPwNuR5IbXqxhOqZ3qCbIKYifLGoj 190h5KcW1BbAngM/5xs8iD+AhKm5KFEWwRYAgLal44nw6m9Z6Z/vGiotOD+ZX2VEhDUR K/tqnFBeLkeTKLlrPFEoinDX6l71N8nC2ArQaQVWci+YeC5Bbvn2MltQj6UdCyJodAM3 y0tvWK11XJn1K8vUndJhOwsk99y4HgNYQhjoT1NuohwnWt429I9czs+ljWGR/BUOqgP5 oqNf3ou/1V5rCA3SJmJ09EwkMEMFmmf+yHpY/tkoGcZ82P55osLcSKK1nADfkW4Ao0tC 9gKw== MIME-Version: 1.0 X-Received: by 10.180.87.129 with SMTP id ay1mr21591702wib.1.1363109659416; Tue, 12 Mar 2013 10:34:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.111.201 with HTTP; Tue, 12 Mar 2013 10:34:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 10:34:19 -0700 X-Google-Sender-Auth: lUJ9LZnpWBqG_47tHopYAfl2U7A Message-ID: Subject: Re: clang - odd macro / conditional expansion behaviour? From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Joerg Sonnenberger X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:34:20 -0000 On 12 March 2013 00:52, Dimitry Andric wrote: > On Mar 12, 2013, at 04:17 , Adrian Chadd wrote: >> In file included from >> /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib= /sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:21: >> /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib= /sys/dev/ath/ath_hal/ar9300/ar9300template_generic.h:107:3: >> error: implicit conversion from 'int' to >> 'u_int8_t' (aka 'unsigned char') changes value from -477 to 35 >> [-Werror,-Wconstant-conversion] >> FREQ2FBIN(2412, 1), >> ^~~~~~~~~~~~~~~~~~ >> /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ath/../../contrib= /sys/dev/ath/ath_hal/ar9300/ar9300eep.h:136:65: >> note: expanded from macro 'FREQ2FBIN' >> (((y) =3D=3D HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) >> ~~~~~~~~~~~~~^~~ > > I cannot find the exact code you are referencing here, but I assume it is= some sort of global initialization? If so, this is most likely , which has been languishing in LLVM's = Bugzilla for a way too long time. :-( > Yup it is, and yup it looks like this. adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 13 11:59:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 657F7EF0 for ; Wed, 13 Mar 2013 11:59:58 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id B834BB1E for ; Wed, 13 Mar 2013 11:59:57 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r2DBxfQY049656 for ; Wed, 13 Mar 2013 12:59:41 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r2DBxfEh049653 for ; Wed, 13 Mar 2013 12:59:41 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 13 Mar 2013 12:59:41 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: snd_geode - where it is Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 13 Mar 2013 12:59:41 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 11:59:58 -0000 i found it mentioned on older mailing list archives. Unfortunately all links to source are dead. There is no such driver now in FreeBSD-9. Is there any reason that it was removed, or it wasn't commited at all? any place where i can get it? From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 13 13:56:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AC9A5D4 for ; Wed, 13 Mar 2013 13:56:58 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 65F54764 for ; Wed, 13 Mar 2013 13:56:58 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id DEA5633C41 for ; Wed, 13 Mar 2013 09:56:46 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id D5FDB3985E; Wed, 13 Mar 2013 09:56:44 -0400 (EDT) From: Lowell Gilbert To: freebsd-hackers@freebsd.org Subject: Re: snd_geode - where it is References: Date: Wed, 13 Mar 2013 09:56:44 -0400 In-Reply-To: (Wojciech Puchar's message of "Wed, 13 Mar 2013 12:59:41 +0100 (CET)") Message-ID: <44620v8ktf.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:56:58 -0000 Wojciech Puchar writes: > i found it mentioned on older mailing list archives. Unfortunately all > links to source are dead. > > There is no such driver now in FreeBSD-9. > > Is there any reason that it was removed, or it wasn't commited at all? > > any place where i can get it? I'm pretty sure it was part of the base system at one time, but that was a long time ago. It's not like it would drop into a modern GIANT-free FreeBSD anyway. Try OSS from ports, would be my first guess. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 13 22:22:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDD6C738 for ; Wed, 13 Mar 2013 22:22:15 +0000 (UTC) (envelope-from joel@freebsd.org) Received: from mail.vnode.se (mail.vnode.se [212.247.52.13]) by mx1.freebsd.org (Postfix) with ESMTP id 935A027D for ; Wed, 13 Mar 2013 22:22:15 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 704F0E3F07A; Wed, 13 Mar 2013 23:22:14 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMGFrVRKwS3C; Wed, 13 Mar 2013 23:22:12 +0100 (CET) Received: from devbox.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 388CFE3F079; Wed, 13 Mar 2013 23:22:12 +0100 (CET) Date: Wed, 13 Mar 2013 23:22:10 +0100 From: Joel Dahl To: Wojciech Puchar Subject: Re: snd_geode - where it is Message-ID: <20130313222210.GB1089@devbox.vnode.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 22:22:15 -0000 On Wed, Mar 13, 2013 at 12:59:41PM +0100, Wojciech Puchar wrote: > i found it mentioned on older mailing list archives. Unfortunately all > links to source are dead. > > There is no such driver now in FreeBSD-9. It was never part of base. -- Joel From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 13 23:11:05 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68251C50 for ; Wed, 13 Mar 2013 23:11:05 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 56E6BA56 for ; Wed, 13 Mar 2013 23:11:05 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r2DN33Kf091699 for ; Wed, 13 Mar 2013 16:03:03 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <514105A6.40800@rawbw.com> Date: Wed, 13 Mar 2013 16:03:02 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130226 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Hackers Subject: top(1) doesn't report the correct CPU time for a multithreaded process Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:11:05 -0000 I have a process that is CPU bound with 1 thread in its first 5 seconds, then it creates 200 threads that are all reading/writing from the network, and becomes network bound for the other 6.5min. When I look at this process in top(1), right after 200 threads are created, I see WCPU and CPU values around 3400% and then it goes down to the values below 1% for the rest of the run: 50619 yuri 206 20 0 621M 555M uwait 7 0:31 0.68% myapp In the end, after all threads have quit, process measures its resources with getrusage(RUSAGE_SELF, &u); and it shows that CPU time consumed was like this: user=104609ms sys=8758ms wall=395938ms So "real" CPU percentage wasn't ~0.68%, but was more like 25%. Or maybe it is 6% if to consider 400% the max (there are 4 cores). I am inclined to trust getrusage(2). It was this PR, that is now marked as closed with patch checked in: http://www.freebsd.org/cgi/query-pr.cgi?pr=127331 But it doesn't seem like this code from the patch is even in usr.bin/top/machine.c now (9.1-STABLE). My original PR, considered a duplicate, is also closed: http://www.freebsd.org/cgi/query-pr.cgi?pr=135823 Why top(1) doesn't show the correct CPU time, aggregate for all threads? Is this a regression of the patch in the above PR#127331? Also, why do I ever see 3400% CPU time? This doesn't seem right in any case. Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 14 10:29:55 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2973A407; Thu, 14 Mar 2013 10:29:55 +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 EB89D113; Thu, 14 Mar 2013 10:29:53 +0000 (UTC) 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 MAA12823; Thu, 14 Mar 2013 12:29:45 +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 1UG5Pt-000Jeh-0Z; Thu, 14 Mar 2013 12:29:45 +0200 Message-ID: <5141A695.8060905@FreeBSD.org> Date: Thu, 14 Mar 2013 12:29:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-hackers Subject: Re: dtrace: operands have incompatible types: "dmu_buf_t **" = "dmu_buf_t **" References: <513F385B.9010106@FreeBSD.org> In-Reply-To: <513F385B.9010106@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:29:55 -0000 First, this link http://docs.oracle.com/cd/E37670_01/E38608/html/dt_typcondef_dlang.html has a rather good description in section 2.13.4 of how types are managed in DTrace and of the special "C" and "D" namespaces/modules. on 12/03/2013 16:14 Andriy Gapon said the following: > > For your amusement: > > ============= testcase.d ============= > dmu_buf_t **buf; CTF data in my kernel contains these types: <1964> STRUCT dmu_buf (32 bytes) <1965> TYPEDEF dmu_buf_t refers to 1964 <1966> POINTER __anon__ refers to 1965 [2501] POINTER __anon__ refers to 1966 Type 2501 is "dmu_buf_t **" and DTrace uses this type for 'buf'. > /* Remove the following line to defuse. */ > bpobj_t *bpobj; Now, there are the following types related to bpobj_t [*footnote]: <8775> STRUCT bpobj (80 bytes) <8776> TYPEDEF bpobj_t refers to 8775 but there is no type for POINTER that refers to 8776. So, as described in the referenced document, dtrace creates bpobj_t* type in the D module. For that it also has to copy bpobj_t and struct bpobj types and also types for each member in struct bpobj and so on. As a result, copies of struct dmu_buf and typedef dmu_buf_t are also created in D namespace. These copied types have different type IDs, but all other of their properties are supposed to be such that the CTF handling code should be able to determine that the copies and the originals are equivalent types. > fbt::dmu_bonus_hold:entry > { > buf = args[3]; /* the error is about this line */ > } When DTrace resolves types for arguments of 'dmu_bonus_hold' it first looks in C and D namespaces and only then it looks in the kernel CTF data. So, now "dmu_buf_t **" is resolved to a copy of the original type. Unfortunately, there is a quirk that may lead to an error like incompatible types "dmu_buf_t **" and "dmu_buf_t **". The CTF code assumes that the types like a pointer to another type or a qualifier plus another type are always anonymous. And in fact they are in C language (note that I am talking about "raw" things like char* or const int, and not about typedefs). Also, the DWARF specification mandates that anonymous types either should not have a name attribute at all or its value should be an empty string (a single zero byte). For the above reasons, when the CTF code creates a copy of a type such as a pointer to another type, it simply sets a name of the copy to an empty string. And here is the quirk: in a violation of the DWARF specification our libdwarf sets names of all anonymous types to "__anon__". This name surely looks special to a human, but unfortunately there is nothing special about it to the code. In the end, the original type with "__anon__" name and the copied type with empty name are no longer considered to be equivalent. The following patch seems to resolve the problem: --- a/lib/libdwarf/dwarf_die.c +++ b/lib/libdwarf/dwarf_die.c @@ -29,8 +29,6 @@ #include #include "_libdwarf.h" -static const char *anon_name = "__anon__"; - int dwarf_die_add(Dwarf_CU cu, int level, uint64_t offset, uint64_t abnum, Dwarf_Abbrev a, Dwarf_Die *diep, Dwarf_Error *err) { @@ -57,7 +55,7 @@ dwarf_die_add(Dwarf_CU cu, int level, uint64_t offset, uint64_t abnum, Dwarf_Abb die->die_abnum = abnum; die->die_a = a; die->die_cu = cu; - die->die_name = anon_name; + die->die_name = ""; /* Initialise the list of attribute values. */ STAILQ_INIT(&die->die_attrval); [*footnote] In fact I see that for some, unknown to me, reason there are more than one entries for struct bpobj and typedef bpobj_t in the ctf data. For one of those entries there is a related bpobj_t pointer entry. But as far as I can tell from the code, it's always the last entry with a given name that is actually used as a type definition for that name. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 14 18:46:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 396124FC for ; Thu, 14 Mar 2013 18:46:13 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id F21302C2 for ; Thu, 14 Mar 2013 18:46:12 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 13so3493594iea.28 for ; Thu, 14 Mar 2013 11:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OJoSroqWJslPBm+L9F34uWaqJ0mco2uEZuUPOOOso/I=; b=npb6mJZGKOoSTQcxjtAOgJY5bulPNqDFrNBHMu0A2hda4NaDczz0+FqkV41sCUpD0I REa2VTjO+F2qsY2nallCge+td1Qcqzc6Jvo/betW0K5xFVDMs1+F2/0fZS9FfUaPT+kC aIlZySExwzpMfEKr4kYyFFSjMA7W3gOeX5X7bsw1It3geqI/yKpgMorG88VbXetfGg3n 8FjRUaqZISgzi53cBmxy6O84MmXBjcco/f/mT94UKJCtz97z9Db+GIYvZ9keasrVc0tA Yr9pne3J5KXKNyW0I5DsGPQTYFCxCOyhOSlFM4NbWBye5ZWdpVcNJ75ScQiEPwqzvQbb vmUQ== X-Received: by 10.50.42.165 with SMTP id p5mr21719873igl.75.1363286772750; Thu, 14 Mar 2013 11:46:12 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.63.12 with HTTP; Thu, 14 Mar 2013 11:45:42 -0700 (PDT) In-Reply-To: <44620v8ktf.fsf@lowell-desk.lan> References: <44620v8ktf.fsf@lowell-desk.lan> From: Chris Rees Date: Thu, 14 Mar 2013 18:45:42 +0000 X-Google-Sender-Auth: 7zzabjMk-PDjwRVMIs5hV2cL3Fc Message-ID: Subject: Re: snd_geode - where it is To: Lowell Gilbert Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:46:13 -0000 On 13 March 2013 13:56, Lowell Gilbert wrote: > Wojciech Puchar writes: > >> i found it mentioned on older mailing list archives. Unfortunately all >> links to source are dead. >> >> There is no such driver now in FreeBSD-9. >> >> Is there any reason that it was removed, or it wasn't commited at all? >> >> any place where i can get it? > > I'm pretty sure it was part of the base system at one time, but that was > a long time ago. It's not like it would drop into a modern GIANT-free > FreeBSD anyway. Try OSS from ports, would be my first guess. Remember that if you install audio/oss, you will have to compile a kernel without sound drivers built in. Chris From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 15 07:33:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 191681A0; Fri, 15 Mar 2013 07:33:10 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 82E867C4; Fri, 15 Mar 2013 07:33:09 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ib11so1011944vcb.21 for ; Fri, 15 Mar 2013 00:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=3tT7O3YN/aOhZZNsL2FRqo1UFho6WPy+hHf57wA2mko=; b=aqRVPufMqMaIQEpPXa2I1rMcG2IJj6bcgF6yb+t0Bm5GYdiqvK9Fg0EctO7G8R/mS+ HTlNotTAX9avHsE/RNwgz1N7aVbR3Bzmh+DqGMfNH1PyYPaQztDGiH9/DD6sz05tWZYe vNav2qbMdf1NQOWJoNH/S1qof/+IiCMwRLC1DVWGOIg1pNA2Z0JFKqe5aRAhQftCB6Kd xGuBnzkTLPDGCpNgq+aNI70r9iTMqXyon2LlqE+apmFNSOfdlJ5uRb0uEdAZawL3jkAz nO0jGZM19kzsBmijn5IKvXULIttx43vtPZLO372s8pBEFJSBcB99tdjmes4N8WndQir5 /w6Q== MIME-Version: 1.0 X-Received: by 10.52.92.225 with SMTP id cp1mr4854739vdb.41.1363332783658; Fri, 15 Mar 2013 00:33:03 -0700 (PDT) Received: by 10.220.232.6 with HTTP; Fri, 15 Mar 2013 00:33:03 -0700 (PDT) Date: Fri, 15 Mar 2013 03:33:03 -0400 Message-ID: Subject: vlan on em0 cannot set MAC address. From: Zaphod Beeblebrox To: FreeBSD Net , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 07:33:10 -0000 I have a FreeBSD-8.3 machine with an em0 interface in it. em0: port 0xd400-0xd43f mem 0xcffa0000-0xcffbffff,0xcff80000-0xcff9ffff irq 12 at device 17.0 on pci0 em0: [FILTER] em0: Ethernet address: 00:0e:0c:bc:6f:87 For various reasons, I have more than one DSL interface, and for some time I have run two PPPoE connections (using mpd4) and I run those PPPoE connections over VLANs on the em0 interface. There are two switches on the path and both switches are sufficiently competent to understand that two different VLANs include the same MAC address. I'm convinced that I used to be connected to two separate DSLAM devices and that after some line trouble, I was reassigned to two ports on a single device. This is because using the SAME MAC address on both VLANs stopped working. To fix this, I tried setting the MAC address on one of the VLANs. This does not work. em0 no longer transmits the packet. Expected behavior? Are there drivers that support different MAC addresses for different VLAN sub-devices? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 15 16:54:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77B65BA2 for ; Fri, 15 Mar 2013 16:54:43 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 3833BD5A for ; Fri, 15 Mar 2013 16:54:42 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 1F80C652CFD; Fri, 15 Mar 2013 17:46:28 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.96.64] (eb0024.eb.z [192.168.96.64]) by mail.embedded-brains.de (Postfix) with ESMTP id 06F1A6524D9 for ; Fri, 15 Mar 2013 17:46:28 +0100 (CET) Message-ID: <51435063.7050907@embedded-brains.de> Date: Fri, 15 Mar 2013 17:46:27 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Purpose of kqueue_task? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:54:43 -0000 Hello, I want to port the FreeBSD kqueue implementation to another operating system (RTEMS in this case) to improve the Erlang support. I have difficulties to understand the purpose of the kqueue_task. This function runs asynchronously. It obtains some locks and wakes up the normal kqueue channel if (kq->kq_state & KQ_TASKDRAIN) == KQ_TASKDRAIN. This state is only set in kqueue_close(). So most of the time the kqueue_task only obtains some locks, clears a flag (KQ_TASKSCHED) and releases the locks? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 15 17:17:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A133215D for ; Fri, 15 Mar 2013 17:17:31 +0000 (UTC) (envelope-from loic.blot@unix-experience.fr) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACACE91 for ; Fri, 15 Mar 2013 17:17:30 +0000 (UTC) Received: from [10.42.69.150] ([82.124.160.236]) by mwinf5d28 with ME id BtHU1l00M56KMG203tHUce; Fri, 15 Mar 2013 18:17:29 +0100 Message-ID: <1363368112.22589.3.camel@Nerz-PC.home> Subject: Custom kernel under RPI From: =?ISO-8859-1?Q?Lo=EFc?= BLOT To: FreeBSD Hackers Date: Fri, 15 Mar 2013 18:21:52 +0100 Organization: UNIX Experience Fr Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-YoshIRNYUw0/x5OU34U9" X-Mailer: Evolution 3.6.4 Mime-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: loic.blot@unix-experience.fr List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:17:31 -0000 --=-YoshIRNYUw0/x5OU34U9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I don't know if it's the good list, but hackers for RPI, i think it's a good thing :D I have a little problem with custom kernel with RPI. I have modified RPI-B config file to include run/runfw driver, compiled the kernel and install it (make buildkernel KERNCONF=3DRPI-B && make installkernel KERNCONF=3DRPI-B, from the RPI). The problem is at reboot. I can't boot on the RPI, because the kernel is frozen after those lines: Kernel entry at 0x100100 .. Kernel args: (null) Nothing after. Can someone tell me if i do something wrong ? Thanks for advance --=20 Best regards, Lo=C3=AFc BLOT,=20 UNIX systems, security and network expert http://www.unix-experience.fr --=-YoshIRNYUw0/x5OU34U9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EABEIAAYFAlFDWLYACgkQh290DZyz8uaWtwEAuXOndNaWkGapaucjv1Jfq3TE HXx5gsNXekjIn3zLQZ0A/1LLAb56JpoPqU5XDAOB2ui/4qQ/WGPlAGwRCsdluy5a =MxzG -----END PGP SIGNATURE----- --=-YoshIRNYUw0/x5OU34U9-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 15 17:19:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89C222FD for ; Fri, 15 Mar 2013 17:19:20 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 57E3CEC5 for ; Fri, 15 Mar 2013 17:19:20 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id ef5so3520289obb.11 for ; Fri, 15 Mar 2013 10:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lK0UgRVdGi37kItSCzFul2d9b5jxgmyU2QenhEo0Y2c=; b=eNTrN8Bz9KujqKpVeO3Ia7Zjnk9aN684HayUSMpMxyBXmNSPd2iKgouh24UdYyaLlG 4Tbshy0DgFN+5VrIvTNSwLktLJaIXHyEfVf/CABajrVTcLeyS7RnoMVS/pMEt+ZYu84Z 6IDssKzURLCiTAOYWSnuAOV3VUtwMaxG0hiMJPS8g6Y8ALNT4K1YJaM/0GfzyGxmBX5z W3djx46IVf/RW5VZhEIU27iaKEJoIPf91D2Lluuko14xHkmATObPBhJajZ9vjVl09pd5 e2RG84zLEacAruI/vdF73yNed9FDvgTBUuZP6NPU8xfuwiB09WDTh+yc+KEdNRrA6AfJ AVGw== MIME-Version: 1.0 X-Received: by 10.60.172.237 with SMTP id bf13mr3389030oec.83.1363367959940; Fri, 15 Mar 2013 10:19:19 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Fri, 15 Mar 2013 10:19:19 -0700 (PDT) In-Reply-To: <51435063.7050907@embedded-brains.de> References: <51435063.7050907@embedded-brains.de> Date: Fri, 15 Mar 2013 13:19:19 -0400 Message-ID: Subject: Re: Purpose of kqueue_task? From: Ryan Stone To: Sebastian Huber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:19:20 -0000 On Fri, Mar 15, 2013 at 12:46 PM, Sebastian Huber < sebastian.huber@embedded-brains.de> wrote: > Hello, > > I want to port the FreeBSD kqueue implementation to another operating > system (RTEMS in this case) to improve the Erlang support. > > I have difficulties to understand the purpose of the kqueue_task. This > function runs asynchronously. It obtains some locks and wakes up the > normal kqueue channel if (kq->kq_state & KQ_TASKDRAIN) == KQ_TASKDRAIN. > This state is only set in kqueue_close(). So most of the time the > kqueue_task only obtains some locks, clears a flag (KQ_TASKSCHED) and > releases the locks? > You missed the most important thing that it does: it calls KNOTE_LOCKED to wake up any waiters sleeping on this event. I suspect that it had to be done in a separate task due to lock ordering problems with the kq_global lock. The call to wakeup() is used to synchronize with kqueue_close to ensure that kqueue_close will not free the kqueue while the task is pending. Otherwise the task could run after kq was freed and crash the system. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 15 17:37:43 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D5C969C; Fri, 15 Mar 2013 17:37:43 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 175D6FD5; Fri, 15 Mar 2013 17:37:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UGYZU-000997-53; Fri, 15 Mar 2013 17:37:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2FHbYOE015334; Fri, 15 Mar 2013 11:37:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/+/e3PyFu4ms+Jkx7I6wXg Subject: Re: Custom kernel under RPI From: Ian Lepore To: loic.blot@unix-experience.fr In-Reply-To: <1363368112.22589.3.camel@Nerz-PC.home> References: <1363368112.22589.3.camel@Nerz-PC.home> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 15 Mar 2013 11:37:34 -0600 Message-ID: <1363369054.1157.46.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r2FHbYOE015334 Cc: FreeBSD Hackers , freebsd-arm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:37:43 -0000 On Fri, 2013-03-15 at 18:21 +0100, Lo=EFc BLOT wrote: > Hi all, > I don't know if it's the good list, but hackers for RPI, i think it's a > good thing :D >=20 > I have a little problem with custom kernel with RPI. I have modified > RPI-B config file to include run/runfw driver, compiled the kernel and > install it (make buildkernel KERNCONF=3DRPI-B && make installkernel > KERNCONF=3DRPI-B, from the RPI). The problem is at reboot. I can't boot= on > the RPI, because the kernel is frozen after those lines: >=20 > Kernel entry at 0x100100 .. > Kernel args: (null) >=20 > Nothing after. > Can someone tell me if i do something wrong ? > Thanks for advance For arm-specific questions, the freebsd-arm list might be better (I've added it to the CC). The problem may be that it has no device-tree info. You can add "fdt addr 0x100" to the /boot/loader.rc file to fix that. You can also enter it by hand at the loader prompt first to see if that helps... just hit a character (other than return) while it's loading the kernel, enter that command, then enter 'boot'. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 16 18:09:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 774418E5; Sat, 16 Mar 2013 18:09:28 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 44964D09; Sat, 16 Mar 2013 18:09:26 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c13so2099425eek.0 for ; Sat, 16 Mar 2013 11:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=PwujDD0zKOkwj7uc0UKzbM3AeesBDRlfSmVViVZ4Ohc=; b=W/GNl8q69IFJqncDFOIHh8CJ1N6Cb1TxxQCZRdyYTvLXjFnZr00zKsFksmza0YBy9u +2v+Jb1N472oIwTyUkT9ttK7OGyIX9+Ce4CUKqUefEgXieWHaI3mo68L+k3avQonIxg5 kRVykPOYfve9igWtfl1zIwxDlWuF1zM+fktwdzyREPeQaDVeXJSbRMPctP38OJWsy/L4 I/e8A67oDcYd9k+lxlSiiricUZwejdKgIxdaN5G+Klle1+5j/8mnddq+FvgiqRjAXZ2+ 78S5+I1IQHZeBVJfAJojbRDNIKK2bG6TGPxyONwItYV72pbdyx2veCHYgz9ekakSHrQa a9nw== X-Received: by 10.14.211.65 with SMTP id v41mr30699041eeo.33.1363457359798; Sat, 16 Mar 2013 11:09:19 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id ca4sm17159109eeb.15.2013.03.16.11.09.17 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 16 Mar 2013 11:09:18 -0700 (PDT) Sender: Mikolaj Golub Date: Sat, 16 Mar 2013 20:09:16 +0200 From: Mikolaj Golub To: John Baldwin Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130316180915.GA91146@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130220195801.GA8679@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Kostik Belousov , "Robert N. M. Watson" , Attilio Rao , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 18:09:28 -0000 On Wed, Feb 20, 2013 at 09:58:02PM +0200, Mikolaj Golub wrote: > On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote: > > > The process should be stopped by the time we dump a core, so running it > > multiple times should be ok in that the sizes should not change. I would > > say that you should try to implement a "determine sizes" pass that doesn't > > allocate anything, but others should comment on that. > > I had a little talk with kib about this recently. Kib's main concern > looked to be that a process with many threads/open files might require > considerable amount of kernel memory if the procstat notes are > prepared in memory before writing. So currently I am working on > another approach, when on the first pass the sizes are found, and on > the second pass procstat notes are written to coredump without > preliminarily storing all notes in memory buffer. Hope, the code won't > look very ugly... Here is an updated patch: http://people.freebsd.org/~trociny/procstat_core.2.patch - The coredump routines are modified to be able to write notes directly to a core file, via sbuf interface, without preliminary preparing them all in a memory buffer. - To write NT_PROCSTAT_* notes, the corresponding sysctl routines are changed to provide kern_proc_filedesc_out(), kern_proc_kstack_out(), kern_proc_out(), and kern_proc_vmmap_out() functions. - libprocstat(3) is extended to extract procstat notes from a process core file. Also new functions (procstat_getvmmap, procstat_kstack) are added. - procstat(1) is changed to use libprocstat(3) where it is possible and to treat non-numeric command line arguments as core files. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 16 22:35:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D024389F; Sat, 16 Mar 2013 22:35:26 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3AE6AE; Sat, 16 Mar 2013 22:35:25 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so1991783eae.30 for ; Sat, 16 Mar 2013 15:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=KksQC9biQ8w33sDheBv5Tu0s8ZIPkH8KbzGKvHH1gzI=; b=PwRPQQAEJ2H5no9JscVcF/lmrQ2kjxpHZmFsrBb1hHbS1Dt4n7MSkTlUacu91nsi+b 3ejiC68p0iIfyfbkF/7FIDPQ5R9PZBawMTBxQJ/numDkAN55jsQeMPkVeomMNWTAbaNV /9mWow5kk/8jU4PxWQm4zfi83ticmpDflvm7lf4BoIJgTON9OhYyKgxCwhSkuwZjihit SnRgxh6D/GjW/JlYTPjKOjxTbYEEsgQj5VVnSRIpLHkmC+wQ4YDBzyGxPPMGRZj/1Ify h/GYKSZJG+bWDfra0YT3dUK3rH5C2j8jqAOcyZm8d88mgUNDQO8gkpfeNPcSJYTJ/Qnh 0FiQ== X-Received: by 10.14.207.200 with SMTP id n48mr32940943eeo.4.1363473324359; Sat, 16 Mar 2013 15:35:24 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id t4sm18365855eel.0.2013.03.16.15.35.22 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 16 Mar 2013 15:35:23 -0700 (PDT) Sender: Mikolaj Golub Date: Sun, 17 Mar 2013 00:35:20 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130316223339.GA3534@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130316191605.GJ3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 22:35:26 -0000 On Sat, Mar 16, 2013 at 09:16:05PM +0200, Konstantin Belousov wrote: > IMO sbuf_pad() should be moved to subr_sbuf.c. I find the KPI of > the sbuf_pad() wrong. You have two separate number, the amount to > pad to, and the current amount. Natural interface would take the > two numbers separate instead of the difference. Also, could the > sbuf_pad() deduce the current amount on its own, this would be the > best ? Hm, I am not sure about this. So are you proposing instead of something like this sbuf_pad(sb, roundup(x, y) - x, 0); to have sbuf_pad(sb, x, roundup(x, y), 0)? Although it is a little easier to write, it looks less intuitive for me. E.g. I have troubles how to document this and explain. I can't reffer x as a current position in sbuf, because it might not be. It is just a some position, roundup(x,y) is another one, and only their difference makes sence for sbuf_pad, so why not just to provide this difference? So sbuf_pad(sb, from, to, c); looks for me less intutive than sbuf_pad(sb, len, c); A KPI that would be natural for my case: /* start a section that is going to be aligned to sizeof(Elf_Size), using byte '0' for padding */ sbuf_padded_start(sb, sizeof(Elf_Size), 0); /* write something to sbuf */ sbuf_bcat(sb, data, len); /* align the sbuf section */ sbuf_pad(sb); This might look a little awkward and would add some overhead for the normal case though... > In register_note(), put spaces around '|' for the malloc line. > > It seems that you did not moved the 'ABI hack' for ENOMEM situation for > sysctl_kern_proc_filedesc() into the rewritten function. > Ah, this is a thing I wanted to discuss but forgot! As I understand the idea of the 'ABI hack' is: if the output buffer is less than the size of data we have, truncate our data to the last successfully written kinfo_file structure and return without error. In my code I do reset ENOMEM to 0 (see sysctl_kern_proc_filedesc), but I don't see a way how using sbuf interface I can truncate req->oldidx to the last successfully written file: sbuf_bcat() (to internal buffer) may be successful and the error might appear only later, when draining. I suspect it will break things if I return with a partial kinfo_file, but haven't come with a solution yet... > Please commit the changes to use pget() in the sysctl handlers separately. > > Indents after the else clauses in kern_proc_out() are wrong. Do you mean indents after '#ifdef COMPAT_FREEBSD32' block? I did it that way so if COMPAT_FREEBSD32 sections were removed from the code the indentation would be correct. I saw this practice through the code and used it myself before. > Since you are moving the KERN_PROC_ZOMBMASK out of kern_proc.c, > a comment is needed to describe its usage. I would find it very > confusing if grep reveals no like of code that sets the flags. > > In the comment for sbuf_drain_core_output(), s/drainig/draining/, > s/sefely/safely/ and s/hold/call us with the process lock held/. > > I do not see much sense in the kstack note. The core is dumped when > the threads are moved into the safe state in the kernel, so you > cannot catch 'living' stack backtraces for the kernel side of > things. I was afraid of it after I had tried it on real dumps :-( Ok, will remove the kstack note. > On the other hand, things like umask, resources and osrel might be > of the interest for post-morted analysis. This is in my TODO list. > I did not looked at the usermode changes. Thanks for your suggestions! Will do them. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 16 22:57:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5823E8EE; Sat, 16 Mar 2013 22:57:05 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id 339DF77B; Sat, 16 Mar 2013 22:57:03 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id t10so2142119eei.21 for ; Sat, 16 Mar 2013 15:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=byN/Nyf5tlXFatput1nbSeqaeKDBO5JHfoGf9ghMg/U=; b=yHtOOPbMZkipuHeDrLWYci0fx8x+WPTt439CPteDIurf3VSGCrC7bCyGfx+QHHeLDM F4KwDJcYKMzHgGAHQ33MVg3zCEQ8+N145pY7jjuffYuBeBYZwoyxzne4ljy5W9IC/Jiz 5smiCF8lMTLXCbxaTihV2PXEtzF0ysp//s9VkDE4rUApQLnkMo+pZAFVDilsrW63/c34 oi+wYaYvEb3qx9HRjNbzyDOD5Sg+kP08z6H1LmdAX9vWEur3b1IKaaZ5aw+5aifsqGKq G/uY0ljBIgSF4cvXpNrHfzPk+SOSFiAELJlglEakBdWgyzVKQJ/c+k6barH68AS2rKeK efKg== X-Received: by 10.14.3.70 with SMTP id 46mr33081372eeg.2.1363474616964; Sat, 16 Mar 2013 15:56:56 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id 44sm18425816eek.5.2013.03.16.15.56.55 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 16 Mar 2013 15:56:56 -0700 (PDT) Sender: Mikolaj Golub Date: Sun, 17 Mar 2013 00:56:52 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130316225651.GB3534@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130316223339.GA3534@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 22:57:05 -0000 On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote: > Ah, this is a thing I wanted to discuss but forgot! As I understand > the idea of the 'ABI hack' is: if the output buffer is less than the > size of data we have, truncate our data to the last successfully > written kinfo_file structure and return without error. > > In my code I do reset ENOMEM to 0 (see sysctl_kern_proc_filedesc), but > I don't see a way how using sbuf interface I can truncate req->oldidx > to the last successfully written file: sbuf_bcat() (to internal > buffer) may be successful and the error might appear only later, when > draining. I suspect it will break things if I return with a partial > kinfo_file, but haven't come with a solution yet... A solution I am going to try is to provide maxlen argument to kern_proc_filedesc_out(), and if it is not 0, output files that do not exceed the limit, so sysctl_kern_proc_filedesc would call: kern_proc_filedesc_out(p, &sb, req->oldlen); -- Mikolaj Golub