From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 11:42:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF1B8D79 for ; Tue, 2 Sep 2014 11:42:18 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC491453 for ; Tue, 2 Sep 2014 11:42:18 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D5EF31FE027; Tue, 2 Sep 2014 13:42:15 +0200 (CEST) Message-ID: <5405AD1B.90208@selasky.org> Date: Tue, 02 Sep 2014 13:42:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Saad , Daniel Braniss Subject: Re: Mellanox 10gb driver? References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:42:19 -0000 On 08/29/14 15:23, Mark Saad wrote: > >> On Aug 29, 2014, at 2:37 AM, Daniel Braniss wrote: >> >> hi all, >> I managed to have the card recognised, now working is a different story :-) >> It sort of works, the console is full of: >> >> <6>mlx4_en: mlxen0: Link Up >> <6>mlx4_en: mlxen0: Link Up >> <6>mlx4_en: mlxen0: Link Up >> ... >> >> killing dhclient got rid of that. >> >> maybe the fact that my card is an ‘engineering sample’ have any thing to do? >> without dhclient, and not diskless it seems to be doing ok. >> also, I can’t get it working with a 15m Twinax >> > > I ran into an issue with intel 10gb cards where the twinax cables from Cisco would not work with the intel nics . You issue could be related , double check the twinax cables are supported . Truth be told it's the integrated sfp+ that is the issue . > > -- > Mark saad | mark.saad@longcount.org > FYI: Snapshot of coming MLXEN FreeBSD driver for those that want to try: > http://www.mellanox.com/page/products_dyn?product_family=193&mtag=freebsd_driver --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 12:50:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F8A2BC2 for ; Tue, 2 Sep 2014 12:50:55 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BA191FEE for ; Tue, 2 Sep 2014 12:50:54 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XOnXp-0001c5-CW; Tue, 02 Sep 2014 15:50:45 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <5405AD1B.90208@selasky.org> Date: Tue, 2 Sep 2014 15:50:43 +0300 Message-Id: <9452A1B7-CA45-45D3-A0B4-FF9158C7F42B@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> <5405AD1B.90208@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Mark Saad , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 12:50:55 -0000 On Sep 2, 2014, at 2:42 PM, Hans Petter Selasky wrote: >>=20 >> I ran into an issue with intel 10gb cards where the twinax cables = from Cisco would not work with the intel nics . You issue could be = related , double check the twinax cables are supported . Truth be told = it's the integrated sfp+ that is the issue . I got the 15m Twinax to work!, the problem was not in the cable/gibic = but with DHCP which seems to be troublesome. >>=20 >> -- >> Mark saad | mark.saad@longcount.org >>=20 >=20 > FYI: >=20 > Snapshot of coming MLXEN FreeBSD driver for those that want to try: >> = http://www.mellanox.com/page/products_dyn?product_family=3D193&mtag=3Dfree= bsd_driver >=20 and will be MFC=92ed to 9.3 =85? danny From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 14:32:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7C7AECE; Tue, 2 Sep 2014 14:32:04 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B02AD1EF1; Tue, 2 Sep 2014 14:32:04 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id at1so7520363iec.23 for ; Tue, 02 Sep 2014 07:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=nbIiVF9ounZ2ZLfyqywn+r+/grMmLbcEOwPRpPKxH5s=; b=ZAuQio9AoBOZExAbtKEsGihUh7gpIA6e1+2O1Li07hrOEvZjDWlZFspjfs3MOrCWHL y9HiCR5CAE/86NuhdDWQD+wB+YA2lkmnxqHXrIp/iC59F1kjDcGMZEhME1clluehFu49 VZBy7xl1GZoOJxLsJRIGFmib4Ktb4fnfxj/idDLIN6Ij3lPPqhVfj2eiHKQ7E+zUMWm1 bo0TmZPJqsgzDWQ4c7PmCvm2BG7M9VW2SesGXINc2PusN+LkoHx1r5gkuaBtJaxcFVRd M+Ul0N6npHCyeRlIU6hQVyUT6Pw9wKC3FY6StV9jfS5i1ALlH+vtm3WkkXk1Y8Agv6bT poJA== X-Received: by 10.50.28.75 with SMTP id z11mr28920736igg.11.1409668324070; Tue, 02 Sep 2014 07:32:04 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.1 with HTTP; Tue, 2 Sep 2014 07:31:44 -0700 (PDT) From: Ed Maste Date: Tue, 2 Sep 2014 10:31:44 -0400 X-Google-Sender-Auth: pmq9LR0kj8CA0Q5G2ZyCMEtny3E Message-ID: Subject: Call for FreeBSD 2014Q3 (July-September) Status Reports To: FreeBSD Current , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:32:05 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October 7, for work done in July through September. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2014Q3 reports! Thanks, Ed (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html [4] http://www.freebsd.org/news/status/report-2014-04-2014-06.html From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 20:12:04 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59423494 for ; Tue, 2 Sep 2014 20:12:04 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6E201D7A for ; Tue, 2 Sep 2014 20:12:03 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id q5so8581561wiv.0 for ; Tue, 02 Sep 2014 13:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=8xUlJVx/HgBh1/BlVjLejFRUogUWXRFD63vSqQ/ysis=; b=VYCrbRcBU7OXzRzvrj7qv++kwFQ6sRNaNplifLiY6c1issGm6bqJ+RYZBWlP0qf5Al QoaHU7i43Y1+lUFjEFGVo0ORg7SoudntG4mAZoJsc0FQJwy5iXczkwTvCGz+PLBbXUB5 2lh7jlbN1dtTiPnPQ/7yRRs0d2kjjdAo/iRdxH0/rYKhDFu7MomY6IjQzCnhl6BEK3wT SlC8HonOSrjUdCV21KKe0MzO0SUIYOTM1uXZ2xoCVSaFEZ0R+k+Im1P7Z1gz7SjhwO0Y gRE+ga4a3c6iq4t+gOY936FpY36YQaVL3mI21njf7V2HYuJu0uthqXwcEAq/S6J51SNp 852w== X-Received: by 10.180.89.100 with SMTP id bn4mr31100042wib.34.1409688722138; Tue, 02 Sep 2014 13:12:02 -0700 (PDT) Received: from [192.168.1.17] ([89.191.152.141]) by mx.google.com with ESMTPSA id r19sm37879176wik.0.2014.09.02.13.12.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Sep 2014 13:12:01 -0700 (PDT) Message-ID: <54062495.4080601@gmail.com> Date: Tue, 02 Sep 2014 22:12:05 +0200 From: Maciej Gabryszak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "hackers@freebsd.org" Subject: FreeBSD 10.0 + kernel crash Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:12:04 -0000 Hi All, I configurated freeBSD 10.0 at my servers. Two have configuration: CARP+PF. Sometimes one of them crash. Hardware: Supermicro servers Debug log: Unread portion of the kernel message buffer: <118>Stopping powerd. <118>Waiting for PIDS: 2913. <118>Stopping devd. <118>Waiting for PIDS: 2578. <118>Writing entropy file:. <118>. <118>Terminated <118>Aug 29 19:54:04 rack02 syslogd: exiting on signal 15 spin lock 0xffffffff814fa030 (smp rendezvous) held by 0xfffff8035506d000 (tid 100157) too long panic: spin lock held too long cpuid = 2 KDB: stack backtrace: #0 0xffffffff808e7dd0 at kdb_backtrace+0x60 #1 0xffffffff808af8b5 at panic+0x155 #2 0xffffffff8089cb71 at _mtx_lock_spin_cookie+0x241 #3 0xffffffff80c7ef54 at smp_targeted_tlb_shootdown+0xf4 #4 0xffffffff80c80922 at pmap_invalidate_all+0x232 #5 0xffffffff80c8736f at pmap_remove_pages+0x6af #6 0xffffffff80b104c0 at vmspace_exit+0xa0 #7 0xffffffff8087c6af at exit1+0x65f #8 0xffffffff808b2eef at sigexit+0xb7f #9 0xffffffff808b35a9 at postsig+0x349 #10 0xffffffff808f6e97 at ast+0x437 #11 0xffffffff80c765c9 at doreti_ast+0x1f Uptime: 1d2h40m52s (ada0:ahcich0:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: CCB request is in progress (ada0:ahcich0:0:0:0): Error 5, Retries exhausted (ada0:ahcich0:0:0:0): Spin-down disk failed (ada1:ahcich1:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 00 00 00 00 (ada1:ahcich1:0:0:0): CAM status: CCB request is in progress (ada1:ahcich1:0:0:0): Error 5, Retries exhausted (ada1:ahcich1:0:0:0): Spin-down disk failed Dumping 1590 out of 32706 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91% It looks like problem with standby and disks. I tried turn off it at disks by camcontrol cmd /dev/ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00" -v and same at second disk but it didn't change anything. Server crash after a few minuts/days. cat /etc/rc.conf zfs_enable="YES" hostname="rack02" keymap="pl_PL.ISO8859-2.kbd" sshd_enable="YES" ntpd_enable="YES" powerd_enable="YES" dumpdev="AUTO" cat /boot/loader.conf zfs_load="YES" ipmi_load="YES" vmm_load="YES" if_tap_load="YES" bridgestp_load="YES" if_bridge_load="YES" nmdm_load="YES" if_em_load="YES" pf_load="YES" pfsync_load="YES" pflog_load="YES" carp_load="YES" autoboot_delay="3" Can you suggest something how can i resolve issue ? Best Regards, Maciej From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 20:24:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB23E80B; Tue, 2 Sep 2014 20:24:50 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D49451E92; Tue, 2 Sep 2014 20:24:49 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id hz20so8573030lab.31 for ; Tue, 02 Sep 2014 13:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9Deun8zuZsqJYjWbjp7FEY6WEOGxPDoKk+niyPXo9p8=; b=Ymwyrj4xdb/uYVq2YYBirEbWwmgJ+Q8YtPFv+nLj8OpY0hLeCY63siY/wjNdO9hqrQ Q8UTbS4o8C3giJNiPeszIUbtQIE1BjMQ8IOxAayvGPlqELkimLGy0ieQYUl8/OeRVzwY Ve/uajW19OGBFdKxIR0BkXcsNCfVlWKPdBmTaKcy07f/mCco9zcsEkZqqWCSVGb3IqyY 71N4oUELH0nJY2ktq6jsXInAYai7dZgtUkCqLSH34TOdY9PUL02CDmdGPrXq/V7ZpT50 RWIN4kmZ1Y6y35IIjZ21CjWTCyYQ+jo5pltv3153NYWMaRx74BCH6kv6uKb7SOweSoAB 4aLA== MIME-Version: 1.0 X-Received: by 10.112.198.34 with SMTP id iz2mr4360069lbc.96.1409689487839; Tue, 02 Sep 2014 13:24:47 -0700 (PDT) Received: by 10.25.205.2 with HTTP; Tue, 2 Sep 2014 13:24:47 -0700 (PDT) Date: Tue, 2 Sep 2014 13:24:47 -0700 Message-ID: Subject: Usage of DTRACE_PROBE macro from sdt.h in kernel modules From: Shrikanth Kamath To: freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, markj@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:24:50 -0000 Adding a DTRACE_PROBE(name) in a kernel module does not create the SDT probe. I added the following to the module file before using DTRACE_PROBE. #include "opt_kdtrace.h" #include function_foo() { ... + DTRACE_PROBE(name); ... } I figured the sdt.h does declare SDT_PROVIDER_DECLARE(set); but that is not helping. Was expecting a sdt probe added under provider 'set'. The SDT probe creation returns from sdt_kld_load from here if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, &end, NULL)) return; I did a nm on the kernel module and did not find anything matching "sdt_providers_set" nm -a module.ko | grep sdt 00000000 r __set_sdt_probes_set_sym_sdt_sdt______func____LINE__.103790 U __start_set_sdt_probes_set U __stop_set_sdt_probes_set U sdt_probe_func U sdt_provider_sdt 000006c0 d sdt_sdt______func____LINE__.103789 Can't seem to figure how to get the SDT probe created by using DTRACE_PROBE macro in a kernel module. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 20:44:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15415E15; Tue, 2 Sep 2014 20:44:47 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5EAE110D; Tue, 2 Sep 2014 20:44:46 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id j7so6774921qaq.24 for ; Tue, 02 Sep 2014 13:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=48LRUFGHwpxhGMJz82XrVxpnjH/xLk2ePxORjYPbE3U=; b=hGcU6LGB5ca1yVNX2cBDVnNdlSuqYw0gnzBVG9055d16fZwPP2DGswztUsAn6T90vG 7D3wR88yuM3LprArkFcx0d3+d3yA9P48aGoBgtAgXtgRVzO8E9m3VzFEtx5LXRGXe93V /l501hg0X0NqwtlOaJM6AnekcR1GpKtdAxKaFQBSaQQzEeVDAl/YjvDfqiE/WOWY6C/g YOm39lcF7h8xqisSMDG/L6Hxro+NZX34pqYuYnIdo56eqCp4i43HVWB8VrQQnJbyZmhs Aw6qQCvZP7R31xir7CBh1WPvpSJo6D22C8Mc736nUa6zy5fIqhVQkBa/H0cf23p3WSLL 0M1Q== X-Received: by 10.224.44.14 with SMTP id y14mr58461359qae.34.1409690685696; Tue, 02 Sep 2014 13:44:45 -0700 (PDT) Received: from charmander.home ([64.229.13.35]) by mx.google.com with ESMTPSA id j3sm12616965qaa.32.2014.09.02.13.44.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Sep 2014 13:44:45 -0700 (PDT) Sender: Mark Johnston Date: Tue, 2 Sep 2014 16:44:13 -0400 From: Mark Johnston To: Shrikanth Kamath Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules Message-ID: <20140902204413.GC59246@charmander.home> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:44:47 -0000 On Tue, Sep 02, 2014 at 01:24:47PM -0700, Shrikanth Kamath wrote: > Adding a DTRACE_PROBE(name) in a kernel module does not create the SDT > probe. I added > the following to the module file before using DTRACE_PROBE. Somewhat confusingly, DTRACE_PROBE* shouldn't be used in the kernel. It's there for compatibility with the DTrace probes in ZFS, which use the SDT interfaces in illumos. The SDT_PROBE* macros should be used instead. If you grep the kernel sources, you'll find lots of examples of SDT providers and probes. > #include "opt_kdtrace.h" > #include > > function_foo() { > ... > + DTRACE_PROBE(name); > ... > } > > I figured the sdt.h does declare SDT_PROVIDER_DECLARE(set); but that > is not helping. Was expecting a sdt probe added under provider 'set'. SDT_PROVIDER_DEFINE() is used to define a provider. SDT_PROVIDER_DECLARE() just adds a declaration, so it won't result in anything being added to the SDT provider linker set in the corresponding kld. So SDT_PROVIDER_DEFINE() should be used once to define a new provider, and the provider can be made visible across multiple files using SDT_PROVIDER_DECLARE(). > > The SDT probe creation returns from sdt_kld_load from here > > if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, &end, NULL)) > return; > > I did a nm on the kernel module and did not find anything matching > "sdt_providers_set" > > nm -a module.ko | grep sdt > > 00000000 r __set_sdt_probes_set_sym_sdt_sdt______func____LINE__.103790 > > U __start_set_sdt_probes_set > > U __stop_set_sdt_probes_set > > U sdt_probe_func > > U sdt_provider_sdt > > 000006c0 d sdt_sdt______func____LINE__.103789 > > Can't seem to figure how to get the SDT probe created by using > DTRACE_PROBE macro in a kernel module. In addition to the comments above, I suggest taking a look at the SDT(9) man page, which has a few examples. Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 21:35:38 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA3B5CEC for ; Tue, 2 Sep 2014 21:35:38 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6180517F0 for ; Tue, 2 Sep 2014 21:35:38 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so7675774wes.37 for ; Tue, 02 Sep 2014 14:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XhJZc8DX8BCl/kXVrcKYQFJpYKEqsKOsfY0V/14kRnk=; b=XNf8tJ/DOTEyPiGmmpOKQgOJcHuFKQLNM7LkKf2lmpKzeAOrKZlAbZcwJRCQ/gyBg8 OXm9bCShYrS964DzYttzgWw0gTMrf8VcjATCUtpko+n32IVdGxTv6wvNEvpd+p43xaIm ErWkC9w9cpGiQzqostRNYvu1sIcGOWyt3Bu234vI4MBQI7F7NFmjEE3u1isQepQLYR47 Ll6fcEAvhXy74NF4gSJacwU3V042wL5dsnJ0NbEuggRo8zhUD/hdlHsg3OStgGjowYRq ab8dpqx0r+iEVZLmNW5WDK1khsLRRsXodYODm1eWHITZ0MHDbNshYLne5T7RjIk1FIy3 SD5w== X-Received: by 10.180.9.41 with SMTP id w9mr3205881wia.62.1409693736613; Tue, 02 Sep 2014 14:35:36 -0700 (PDT) Received: from [192.168.1.17] ([89.191.152.141]) by mx.google.com with ESMTPSA id hi4sm11937688wjb.46.2014.09.02.14.35.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Sep 2014 14:35:35 -0700 (PDT) Message-ID: <5406382B.9080107@gmail.com> Date: Tue, 02 Sep 2014 23:35:39 +0200 From: Maciej Gabryszak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "hackers@freebsd.org" Subject: Re: FreeBSD 10.0 + kernel crash References: <54062495.4080601@gmail.com> <1832F09D-9F02-4B90-AB0A-64D58D9C8B18@dataix.net> <540637E1.2010905@gmail.com> In-Reply-To: <540637E1.2010905@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 21:35:38 -0000 Hi Jason, I turned off powerd after your mail. Server has frozen after 30-40 minutes. Best regards, Maciej On 02.09.2014 22:16, Jason Hellenthal wrote: > Attach your crash dump ? (text only) > > Also disable powerd… for the meantime. > > On Sep 2, 2014, at 15:12, Maciej Gabryszak > wrote: > >> Hi All, >> >> I configurated freeBSD 10.0 at my servers. >> Two have configuration: CARP+PF. >> Sometimes one of them crash. >> Hardware: Supermicro servers >> >> Debug log: >> Unread portion of the kernel message buffer: >> <118>Stopping powerd. >> <118>Waiting for PIDS: 2913. >> <118>Stopping devd. >> <118>Waiting for PIDS: 2578. >> <118>Writing entropy file:. >> <118>. >> <118>Terminated >> <118>Aug 29 19:54:04 rack02 syslogd: exiting on signal 15 >> spin lock 0xffffffff814fa030 (smp rendezvous) held by >> 0xfffff8035506d000 (tid 100157) too long >> panic: spin lock held too long >> cpuid = 2 >> KDB: stack backtrace: >> #0 0xffffffff808e7dd0 at kdb_backtrace+0x60 >> #1 0xffffffff808af8b5 at panic+0x155 >> #2 0xffffffff8089cb71 at _mtx_lock_spin_cookie+0x241 >> #3 0xffffffff80c7ef54 at smp_targeted_tlb_shootdown+0xf4 >> #4 0xffffffff80c80922 at pmap_invalidate_all+0x232 >> #5 0xffffffff80c8736f at pmap_remove_pages+0x6af >> #6 0xffffffff80b104c0 at vmspace_exit+0xa0 >> #7 0xffffffff8087c6af at exit1+0x65f >> #8 0xffffffff808b2eef at sigexit+0xb7f >> #9 0xffffffff808b35a9 at postsig+0x349 >> #10 0xffffffff808f6e97 at ast+0x437 >> #11 0xffffffff80c765c9 at doreti_ast+0x1f >> Uptime: 1d2h40m52s >> (ada0:ahcich0:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 >> 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: CCB request is in progress >> (ada0:ahcich0:0:0:0): Error 5, Retries exhausted >> (ada0:ahcich0:0:0:0): Spin-down disk failed >> (ada1:ahcich1:0:0:0): STANDBY_IMMEDIATE. ACB: e0 00 00 00 00 40 00 00 >> 00 00 00 00 >> (ada1:ahcich1:0:0:0): CAM status: CCB request is in progress >> (ada1:ahcich1:0:0:0): Error 5, Retries exhausted >> (ada1:ahcich1:0:0:0): Spin-down disk failed >> Dumping 1590 out of 32706 >> MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91% >> >> >> It looks like problem with standby and disks. >> >> I tried turn off it at disks by camcontrol cmd /dev/ada0 -a "EF 85 00 >> 00 00 00 00 00 00 00 00 00" -v and same at second disk but it didn't >> change anything. >> Server crash after a few minuts/days. >> >> cat /etc/rc.conf >> >> zfs_enable="YES" >> hostname="rack02" >> keymap="pl_PL.ISO8859-2.kbd" >> sshd_enable="YES" >> ntpd_enable="YES" >> powerd_enable="YES" >> dumpdev="AUTO" >> >> >> cat /boot/loader.conf >> zfs_load="YES" >> ipmi_load="YES" >> vmm_load="YES" >> if_tap_load="YES" >> bridgestp_load="YES" >> if_bridge_load="YES" >> nmdm_load="YES" >> if_em_load="YES" >> pf_load="YES" >> pfsync_load="YES" >> pflog_load="YES" >> carp_load="YES" >> autoboot_delay="3" >> >> >> Can you suggest something how can i resolve issue ? >> >> >> Best Regards, >> Maciej >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 2 22:11:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FF172C5 for ; Tue, 2 Sep 2014 22:11:58 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2379E1BFF for ; Tue, 2 Sep 2014 22:11:58 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 1C88120E7088B; Tue, 2 Sep 2014 22:11:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 9961720E70886; Tue, 2 Sep 2014 22:11:54 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Maciej Gabryszak" , References: <54062495.4080601@gmail.com> <1832F09D-9F02-4B90-AB0A-64D58D9C8B18@dataix.net> <540637E1.2010905@gmail.com> <5406382B.9080107@gmail.com> Subject: Re: FreeBSD 10.0 + kernel crash Date: Tue, 2 Sep 2014 23:11:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:11:58 -0000 Bad hardware? My first guess would be disk. ----- Original Message ----- From: "Maciej Gabryszak" To: Sent: Tuesday, September 02, 2014 10:35 PM Subject: Re: FreeBSD 10.0 + kernel crash Hi Jason, I turned off powerd after your mail. Server has frozen after 30-40 minutes. From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 09:28:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5775718 for ; Wed, 3 Sep 2014 09:28:26 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ADFE19AD for ; Wed, 3 Sep 2014 09:28:26 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id n12so8181082wgh.7 for ; Wed, 03 Sep 2014 02:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o7vePEWFWU5u3Ys7ASBu/VU8qPV7Boxqb9ryB81wZx4=; b=NqXRLvvSoJui1KOb+aPIYIK1CMlAn36hUpW8rdkka3TSuL3+JB/ut9fhQY3eFGw4JA b2mFb6G31jw7VFT57WlLnUR/yOWvd2czw7zCdbPBqw9Uresrnbi+DDV0lKsjg/q8Ne7q WYhp0U5dZj6KoHAMt5mL5AbpUGJZnHL82QKtGD4aFnUYJN8FzCsLeKaWWgFca8tjiRMa KxRh58HlNbhxpEguY4knAoOgb6JXSFwZvX4sjwSMgqJak0tIf2+CIJwklVNaxiwwa4/I BjtjNzQeY59BRa7EoxUIYpp+Gf+AwPOOSiHmhyEm+ApIlTEbAZPEoenDVjPU5YKrCToW SKHQ== X-Received: by 10.180.84.66 with SMTP id w2mr33276840wiy.27.1409736504204; Wed, 03 Sep 2014 02:28:24 -0700 (PDT) Received: from [192.168.43.211] (user-94-254-129-159.play-internet.pl. [94.254.129.159]) by mx.google.com with ESMTPSA id y5sm14720283wje.32.2014.09.03.02.28.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 02:28:23 -0700 (PDT) Message-ID: <5406DF33.3070600@gmail.com> Date: Wed, 03 Sep 2014 11:28:19 +0200 From: Maciej Gabryszak User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steven Hartland , hackers@freebsd.org Subject: Re: FreeBSD 10.0 + kernel crash References: <54062495.4080601@gmail.com> <1832F09D-9F02-4B90-AB0A-64D58D9C8B18@dataix.net> <540637E1.2010905@gmail.com> <5406382B.9080107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 09:28:26 -0000 Disks no. Two servers have disks: 2x ST3000DM001-9YN166 CC4B + PF + CARP + sometimes bhyve to test + vlans + bridge interface + tap interfaces for bhyve Two another servers have (bigger servers): 4x INTEL SSDSC2BA100G3 5DV10265 7x ATA HGST HUS724040AL AA70 + without PF + CARP + bhyve + vlans + bridge interface + tap interfaces for bhyve From my site it looks likes bug in the kernel. I'm testing bhyve but servers without bhyve crash too. Best regards, Maciej On 03.09.2014 00:11, Steven Hartland wrote: > Bad hardware? My first guess would be disk. > > ----- Original Message ----- From: "Maciej Gabryszak" > > To: > Sent: Tuesday, September 02, 2014 10:35 PM > Subject: Re: FreeBSD 10.0 + kernel crash > > > > Hi Jason, > > I turned off powerd after your mail. > Server has frozen after 30-40 minutes. > From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 13:05:46 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9A36900; Wed, 3 Sep 2014 13:05:46 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF66144B; Wed, 3 Sep 2014 13:05:42 +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 QAA13450; Wed, 03 Sep 2014 16:05:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XPAFo-000GcX-PB; Wed, 03 Sep 2014 16:05:40 +0300 Message-ID: <540711ED.2050909@FreeBSD.org> Date: Wed, 03 Sep 2014 16:04:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark Johnston , Shrikanth Kamath Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules References: <20140902204413.GC59246@charmander.home> In-Reply-To: <20140902204413.GC59246@charmander.home> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-dtrace@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 13:05:46 -0000 on 02/09/2014 23:44 Mark Johnston said the following: > Somewhat confusingly, DTRACE_PROBE* shouldn't be used in the kernel. But it can be used. Shrikanth, please double check that KDTRACE_HOOKS is defined when you compile your module. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 15:55:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EB1A251; Wed, 3 Sep 2014 15:55:51 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id C306B1D73; Wed, 3 Sep 2014 15:55:50 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 2 Sep 2014 21:38:55 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 2 Sep 2014 18:38:55 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" , Ryan Stone , Brooks Davis Subject: Re: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPxxfSUBEgYXTq+ky03AEN5pUz3Q== Date: Wed, 3 Sep 2014 01:38:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.17.142.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D0E018AFADB1F4DA4EB71139D1C3B8A@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2014 01:38:55.0977 (UTC) FILETIME=[D345B590:01CFC717] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:55:51 -0000 -----Original Message----- From: , Ravi Pokala Date: Tuesday, August 26, 2014 at 11:35 PM To: "freebsd-hackers@freebsd.org" , Ryan Stone , Brooks Davis Subject: Re: Common storage of original MAC address > Doesn't this restore the original MAC on LAGG teardown? It looks like that code does indeed restore the working MAC when the lagg is torn down; see the example output below. > If someone can enumerate the places where we want to restore the >original LLADDR but currently don't, then I'll add that. I never did hear from anyone, but it appears to be moot - as mentioned above, the LAGG driver restores the original LLADDR. > If what I've done so far looks good, I'll continue to the next steps: >changing the places where we want to auto-restore the HW LLADDR (see my >question above), and updating `ifconfig' to report and restore the HW >LLADDR. No one pointed my at places where we want to auto-restore, but don't. Similarly, since we *do* auto-restore, there's no restore-related change needed for `ifconfig'. That just leaves reporting, which is included in the patch below. If there are no objections to this, could a willing committer contact me privately so we can work out the details of getting this submitted to -CURRENT? Thanks, Ravi ---------------------------- ghwlladdr.patch --------------------------- Index: sbin/ifconfig/af_link.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/ifconfig/af_link.c (revision 270916) +++ sbin/ifconfig/af_link.c (working copy) @@ -42,6 +42,7 @@ #include #include #include +#include =20 #include #include @@ -61,9 +62,30 @@ if ((sdl->sdl_type =3D=3D IFT_ETHER || sdl->sdl_type =3D=3D IFT_L2VLAN || sdl->sdl_type =3D=3D IFT_BRIDGE) && - sdl->sdl_alen =3D=3D ETHER_ADDR_LEN) + sdl->sdl_alen =3D=3D ETHER_ADDR_LEN) { + struct ifreq ifr; + int s_hw; printf("\tether %s\n", ether_ntoa((struct ether_addr *)LLADDR(sdl))); + strncpy(ifr.ifr_name, ifa->ifa_name, + sizeof(ifr.ifr_name)); + memcpy(&ifr.ifr_addr, ifa->ifa_addr, + sizeof(ifa->ifa_addr->sa_len)); + ifr.ifr_addr.sa_family =3D AF_LOCAL; + if ((s_hw =3D socket(AF_LOCAL, SOCK_DGRAM, 0)) < 0) { + warn("socket(AF_LOCAL,SOCK_DGRAM)"); + return; + } + if (ioctl(s_hw, SIOCGHWLLADDR, &ifr) < 0) { + warn("SIOCGHWLLADDR"); + close(s_hw); + return; + } + printf("\thwaddr %s\n", + ether_ntoa((const struct ether_addr *) + &ifr.ifr_addr.sa_data)); + close(s_hw); + } else { int n =3D sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0; =20 Index: sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if.c (revision 270916) +++ sys/net/if.c (working copy) @@ -2554,6 +2554,10 @@ EVENTHANDLER_INVOKE(iflladdr_event, ifp); break; =20 + case SIOCGHWLLADDR: + error =3D if_gethwlladdr(ifp, ifr); + break; + case SIOCAIFGROUP: { struct ifgroupreq *ifgr =3D (struct ifgroupreq *)ifr; @@ -3427,6 +3431,33 @@ } =20 /* + * Get the link layer address that was read from the hardware at probe. + * + * At this time we only support certain types of interfaces. + */ +int +if_gethwlladdr(struct ifnet *ifp, struct ifreq *ifr) +{ + switch (ifp->if_type) { + case IFT_ETHER: + case IFT_FDDI: + case IFT_XETHER: + case IFT_ISO88025: + case IFT_L2VLAN: + case IFT_BRIDGE: + case IFT_ARCNET: + case IFT_IEEE8023ADLAG: + case IFT_IEEE80211: + bcopy(&IFP2AC(ifp)->hw_lladdr, ifr->ifr_addr.sa_data, ETHER_ADDR_LEN); + ifr->ifr_addr.sa_len =3D ETHER_ADDR_LEN; + break; + default: + return (ENODEV); + } + return (0); +} + +/* * The name argument must be a pointer to storage which will last as * long as the interface does. For physical devices, the result of * device_get_name(dev) is a good choice and for pseudo-devices a Index: sys/net/if_arp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_arp.h (revision 270916) +++ sys/net/if_arp.h (working copy) @@ -102,9 +102,11 @@ * Structure shared between the ethernet driver modules and * the address resolution code. */ +#include struct arpcom { struct ifnet *ac_ifp; /* network-visible interface */ void *ac_netgraph; /* ng_ether(4) netgraph node info */ + struct ether_addr hw_lladdr; /* original lladdr from hardware */ }; #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) #define AC2IFP(ac) ((ac)->ac_ifp) Index: sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_ethersubr.c (revision 270916) +++ sys/net/if_ethersubr.c (working copy) @@ -841,6 +841,7 @@ sdl->sdl_type =3D IFT_ETHER; sdl->sdl_alen =3D ifp->if_addrlen; bcopy(lla, LLADDR(sdl), ifp->if_addrlen); + bcopy(lla, &IFP2AC(ifp)->hw_lladdr, ifp->if_addrlen); =20 bpfattach(ifp, DLT_EN10MB, ETHER_HDR_LEN); if (ng_ether_attach_p !=3D NULL) Index: sys/net/if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_var.h (revision 270916) +++ sys/net/if_var.h (working copy) @@ -501,6 +501,7 @@ void if_ref(struct ifnet *); void if_rele(struct ifnet *); int if_setlladdr(struct ifnet *, const u_char *, int); +int if_gethwlladdr(struct ifnet *, struct ifreq *); void if_up(struct ifnet *); int ifioctl(struct socket *, u_long, caddr_t, struct thread *); int ifpromisc(struct ifnet *, int); Index: sys/sys/sockio.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/sockio.h (revision 270916) +++ sys/sys/sockio.h (working copy) @@ -97,6 +97,7 @@ #define SIOCGIFSTATUS _IOWR('i', 59, struct ifstat) /* get IF status */ #define SIOCSIFLLADDR _IOW('i', 60, struct ifreq) /* set linklevel addr */ #define SIOCGI2C _IOWR('i', 61, struct ifstat) /* get I2C data */ +#define SIOCGHWLLADDR _IOWR('i', 62, struct ifreq) /* get hw lladdr */ =20 #define SIOCSIFPHYADDR _IOW('i', 70, struct ifaliasreq) /* set gif addres */ #define SIOCGIFPSRCADDR _IOWR('i', 71, struct ifreq) /* get gif psrc addr */ ---------------------------- example output ---------------------------- root@fbsd-X:~ # : Output from 'ifconfig'. Note the new 'hwaddr' line, and root@fbsd-X:~ # : that it has the same value as the 'ether' line, because no root@fbsd-X:~ # : MAC manipulation has been done yet: root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:d2:48:a3 hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 root@fbsd-X:~ # : Create a 'lagg0' from 'em1' and 'em2' root@fbsd-X:~ # ifconfig lagg0 create laggproto lacp laggport em1 laggport em2 root@fbsd-X:~ # : Output from 'ifconfig'. Note that 'em2's 'ether' value has root@fbsd-X:~ # : changed to match 'em1's 'ether' value, but 'em2's 'hwaddr' root@fbsd-X:~ # : value is unchanged. root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 lagg0: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 00:00:00:00:00:00 nd6 options=3D29 media: Ethernet autoselect status: no carrier laggproto lacp lagghash l2,l3,l4 laggport: em2 flags=3D0<> laggport: em1 flags=3D0<> root@fbsd-X:~ # : Destroy lagg0 root@fbsd-X:~ # ifconfig lagg0 destroy root@fbsd-X:~ # : Output from 'ifconfig'. Note that 'em2's 'ether' value has root@fbsd-X:~ # : returned to its original value, which once again matches root@fbsd-X:~ # : 'em2's 'hwaddr' value, which has remained unchanged. root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:d2:48:a3 hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 root@fbsd-X:~ #=09 From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 15:55:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0015253; Wed, 3 Sep 2014 15:55:51 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1141D74; Wed, 3 Sep 2014 15:55:51 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 2 Sep 2014 14:08:35 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 2 Sep 2014 11:08:34 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" , Ryan Stone , Brooks Davis Subject: Re: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPwcEUUBEgYXTq+ky03AEN5pUz3ZvuLlCA Date: Tue, 2 Sep 2014 18:08:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <26F5AC6C7ECD494CABED34F4BE79FCA4@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Sep 2014 18:08:35.0212 (UTC) FILETIME=[E9A42CC0:01CFC6D8] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 15:55:51 -0000 -----Original Message----- From: , Ravi Pokala Date: Tuesday, August 26, 2014 at 11:35 PM To: "freebsd-hackers@freebsd.org" , Ryan Stone , Brooks Davis Subject: Re: Common storage of original MAC address > Doesn't this restore the original MAC on LAGG teardown? It looks like that code does indeed restore the working MAC when the lagg is torn down; see the example output below. > If someone can enumerate the places where we want to restore the original > LLADDR but currently don't, then I'll add that. I never did hear from anyone, but it appears to be moot - as mentioned above, the LAGG driver restores the original LLADDR. > If what I've done so far looks good, I'll continue to the next steps: > changing the places where we want to auto-restore the HW LLADDR (see my > question above), and updating `ifconfig' to report and restore the HW > LLADDR. No one pointed my at places where we want to auto-restore, but don't. Similarly, since we *do* auto-restore, there's no restore-related change needed for `ifconfig'. That just leaves reporting, which is included in the patch below. If there are no objections to this, could a willing committer contact me privately so we can work out the details of getting this submitted to -CURRENT? Thanks, Ravi ---------------------------- ghwlladdr.patch --------------------------- Index: sbin/ifconfig/af_link.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/ifconfig/af_link.c (revision 270916) +++ sbin/ifconfig/af_link.c (working copy) @@ -42,6 +42,7 @@ #include #include #include +#include =20 #include #include @@ -61,9 +62,30 @@ if ((sdl->sdl_type =3D=3D IFT_ETHER || sdl->sdl_type =3D=3D IFT_L2VLAN || sdl->sdl_type =3D=3D IFT_BRIDGE) && - sdl->sdl_alen =3D=3D ETHER_ADDR_LEN) + sdl->sdl_alen =3D=3D ETHER_ADDR_LEN) { + struct ifreq ifr; + int s_hw; printf("\tether %s\n", ether_ntoa((struct ether_addr *)LLADDR(sdl))); + strncpy(ifr.ifr_name, ifa->ifa_name, + sizeof(ifr.ifr_name)); + memcpy(&ifr.ifr_addr, ifa->ifa_addr, + sizeof(ifa->ifa_addr->sa_len)); + ifr.ifr_addr.sa_family =3D AF_LOCAL; + if ((s_hw =3D socket(AF_LOCAL, SOCK_DGRAM, 0)) < 0) { + warn("socket(AF_LOCAL,SOCK_DGRAM)"); + return; + } + if (ioctl(s_hw, SIOCGHWLLADDR, &ifr) < 0) { + warn("SIOCGHWLLADDR"); + close(s_hw); + return; + } + printf("\thwaddr %s\n", + ether_ntoa((const struct ether_addr *) + &ifr.ifr_addr.sa_data)); + close(s_hw); + } else { int n =3D sdl->sdl_nlen > 0 ? sdl->sdl_nlen + 1 : 0; =20 Index: sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if.c (revision 270916) +++ sys/net/if.c (working copy) @@ -2554,6 +2554,10 @@ EVENTHANDLER_INVOKE(iflladdr_event, ifp); break; =20 + case SIOCGHWLLADDR: + error =3D if_gethwlladdr(ifp, ifr); + break; + case SIOCAIFGROUP: { struct ifgroupreq *ifgr =3D (struct ifgroupreq *)ifr; @@ -3427,6 +3431,33 @@ } =20 /* + * Get the link layer address that was read from the hardware at probe. + * + * At this time we only support certain types of interfaces. + */ +int +if_gethwlladdr(struct ifnet *ifp, struct ifreq *ifr) +{ + switch (ifp->if_type) { + case IFT_ETHER: + case IFT_FDDI: + case IFT_XETHER: + case IFT_ISO88025: + case IFT_L2VLAN: + case IFT_BRIDGE: + case IFT_ARCNET: + case IFT_IEEE8023ADLAG: + case IFT_IEEE80211: + bcopy(&IFP2AC(ifp)->hw_lladdr, ifr->ifr_addr.sa_data, ETHER_ADDR_LEN); + ifr->ifr_addr.sa_len =3D ETHER_ADDR_LEN; + break; + default: + return (ENODEV); + } + return (0); +} + +/* * The name argument must be a pointer to storage which will last as * long as the interface does. For physical devices, the result of * device_get_name(dev) is a good choice and for pseudo-devices a Index: sys/net/if_arp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_arp.h (revision 270916) +++ sys/net/if_arp.h (working copy) @@ -102,9 +102,11 @@ * Structure shared between the ethernet driver modules and * the address resolution code. */ +#include struct arpcom { struct ifnet *ac_ifp; /* network-visible interface */ void *ac_netgraph; /* ng_ether(4) netgraph node info */ + struct ether_addr hw_lladdr; /* original lladdr from hardware */ }; #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) #define AC2IFP(ac) ((ac)->ac_ifp) Index: sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_ethersubr.c (revision 270916) +++ sys/net/if_ethersubr.c (working copy) @@ -841,6 +841,7 @@ sdl->sdl_type =3D IFT_ETHER; sdl->sdl_alen =3D ifp->if_addrlen; bcopy(lla, LLADDR(sdl), ifp->if_addrlen); + bcopy(lla, &IFP2AC(ifp)->hw_lladdr, ifp->if_addrlen); =20 bpfattach(ifp, DLT_EN10MB, ETHER_HDR_LEN); if (ng_ether_attach_p !=3D NULL) Index: sys/net/if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_var.h (revision 270916) +++ sys/net/if_var.h (working copy) @@ -501,6 +501,7 @@ void if_ref(struct ifnet *); void if_rele(struct ifnet *); int if_setlladdr(struct ifnet *, const u_char *, int); +int if_gethwlladdr(struct ifnet *, struct ifreq *); void if_up(struct ifnet *); int ifioctl(struct socket *, u_long, caddr_t, struct thread *); int ifpromisc(struct ifnet *, int); Index: sys/sys/sockio.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/sockio.h (revision 270916) +++ sys/sys/sockio.h (working copy) @@ -97,6 +97,7 @@ #define SIOCGIFSTATUS _IOWR('i', 59, struct ifstat) /* get IF status */ #define SIOCSIFLLADDR _IOW('i', 60, struct ifreq) /* set linklevel addr */ #define SIOCGI2C _IOWR('i', 61, struct ifstat) /* get I2C data */ +#define SIOCGHWLLADDR _IOWR('i', 62, struct ifreq) /* get hw lladdr */ =20 #define SIOCSIFPHYADDR _IOW('i', 70, struct ifaliasreq) /* set gif addres */ #define SIOCGIFPSRCADDR _IOWR('i', 71, struct ifreq) /* get gif psrc addr */ ---------------------------- example output ---------------------------- root@fbsd-X:~ # : Output from 'ifconfig'. Note the new 'hwaddr' line, and root@fbsd-X:~ # : that it has the same value as the 'ether' line, because no root@fbsd-X:~ # : MAC manipulation has been done yet: root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:d2:48:a3 hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 root@fbsd-X:~ # : Create a 'lagg0' from 'em1' and 'em2' root@fbsd-X:~ # ifconfig lagg0 create laggproto lacp laggport em1 laggport em2 root@fbsd-X:~ # : Output from 'ifconfig'. Note that 'em2's 'ether' value has root@fbsd-X:~ # : changed to match 'em1's 'ether' value, but 'em2's 'hwaddr' root@fbsd-X:~ # : value is unchanged. root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 lagg0: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 00:00:00:00:00:00 nd6 options=3D29 media: Ethernet autoselect status: no carrier laggproto lacp lagghash l2,l3,l4 laggport: em2 flags=3D0<> laggport: em1 flags=3D0<> root@fbsd-X:~ # : Destroy lagg0 root@fbsd-X:~ # ifconfig lagg0 destroy root@fbsd-X:~ # : Output from 'ifconfig'. Note that 'em2's 'ether' value has root@fbsd-X:~ # : returned to its original value, which once again matches root@fbsd-X:~ # : 'em2's 'hwaddr' value, which has remained unchanged. root@fbsd-X:~ # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D9b ether 08:00:27:9d:28:32 hwaddr 08:00:27:9d:28:32 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a hwaddr 08:00:27:f0:8f:8a nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em2: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:d2:48:a3 hwaddr 08:00:27:d2:48:a3 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 root@fbsd-X:~ #=09 From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 16:12:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23BB9F9 for ; Wed, 3 Sep 2014 16:12:04 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6C81F79 for ; Wed, 3 Sep 2014 16:12:04 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 3 Sep 2014 12:12:03 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Wed, 3 Sep 2014 09:12:02 -0700 From: "Sinha, Prokash" To: "freebsd-hackers@freebsd.org" Subject: PXE boot Thread-Topic: PXE boot Thread-Index: AQHPx5HLJQqu7eyjHEWkqP8Kaivyig== Date: Wed, 3 Sep 2014 16:12:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.133.204] Content-Type: text/plain; charset="Windows-1252" Content-ID: <12A6B2A45BCBA94D9A2EFC1157171859@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2014 16:12:03.0749 (UTC) FILETIME=[CCD15550:01CFC791] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:12:04 -0000 Hi All, I'm trying to understand the invocation of the routines pxe_init(); pxe_ope= n() etc. in pxe.c By the structure, it looks like a driver with devsw_pxedisk =3D { entry poi= nts =85} Once this pxeldr is brought down from the net boot server, how does it get = invoked ( or rather who calls these routines ) ??? The loader ( strapped wi= th it don't seem to call). I assume that the the boot code in the NVRAM ( or wherever ) of the NIC tha= t supports calls these pxe_* () functions ??? Thanks -prokash From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 16:59:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D2F5668 for ; Wed, 3 Sep 2014 16:59:58 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEDDD15AA for ; Wed, 3 Sep 2014 16:59:57 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id jd19so6285303oac.30 for ; Wed, 03 Sep 2014 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZA44Nbdwu6zQQNtGZNkBs6PEsIFbsobwV23XNZxz3qQ=; b=tY/dMFuldI0KtwXglBLR3l918935OKVe3EIwLk+3Zdt3sVibWJHSL4X+n2Ogf6gV/6 KTzgtM2HwRSuDOOzXEfFGRocjK18/pBM0zF7fQMOMWKGSU9eVPYGASb55ajc1LEYWEFY qHxMRffbi1Uytsv97e5MblXyYfv3zlCxXBw1JiwyLold+sc/6BNs0ExHjZSHQ79f/Fzk n8bcBD7ju7BR7y971zThUyfyfD/yZpP2af4mJi6nnAyjpR8dOb3uCBU73iPMy0uOHAsH D+FVzTXZOt93SXdYPuR5z24b2QBDDuhpYr9S7NZz2qSRDoH0iSPKCrDGQ0opd6MA2qzg 2oWQ== MIME-Version: 1.0 X-Received: by 10.182.114.131 with SMTP id jg3mr40227263obb.9.1409763596897; Wed, 03 Sep 2014 09:59:56 -0700 (PDT) Received: by 10.182.250.234 with HTTP; Wed, 3 Sep 2014 09:59:56 -0700 (PDT) Date: Wed, 3 Sep 2014 09:59:56 -0700 Message-ID: Subject: IOAT driver for FreeBSD From: Vijay Singh To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 16:59:58 -0000 Hi All, I found some discussion in the past about this. Is there a version of such a driver that I can test, and hopefully help get committed? -vijay From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 20:06:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 402C7C5E; Wed, 3 Sep 2014 20:06:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAE621D8A; Wed, 3 Sep 2014 20:06:26 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C932BB968; Wed, 3 Sep 2014 16:06:25 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: stopped processes using cpu? Date: Wed, 03 Sep 2014 16:05:49 -0400 Message-ID: <1567020.dfiLmFunn8@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <201408201138.40228.jhb@freebsd.org> References: <1408540626.1150.1.camel@revolution.hippie.lan> <201408201138.40228.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Sep 2014 16:06:25 -0400 (EDT) Cc: Ian Lepore , Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:06:27 -0000 On Wednesday, August 20, 2014 11:38:40 AM John Baldwin wrote: > On Wednesday, August 20, 2014 9:17:06 am Ian Lepore wrote: > > On Tue, 2014-08-19 at 18:45 -0700, Tim Kientzle wrote: > > > On Aug 19, 2014, at 12:28 PM, Allan Jude = wrote: > > > > On 2014-08-19 15:21, Dieter BSD wrote: > > > >> 8.2 on amd64 > > > >> Top(1) with no arguments reports that some firefox processes a= re > > > >> using >=20 > cpu >=20 > > > >> dispite being stopped (via kill -stop pid) for at least severa= l > > > >> hours. > > > >> Adding -C doesn't change the numbers. Ps(1) reports the same.= > > > >> Interestingly, a firefox that isn't stopped is (correctly?) re= ported > > > >> as > > > >> using 0 cpu. The 100% idle should be correct, but who knows. > > > >>=20 > > > >> last pid: 51932; load averages: 0.07, 0.99, 1.42 up 14+19:02= :56 >=20 > 08:48:28 >=20 > > > >> 267 processes: 1 running, 138 sleeping, 128 stopped > > > >> CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 1= 00% > > > >> idle > > > >> Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf= , 815M >=20 > Free >=20 > > > >> Swap: 8965M Total, 560K Used, 8965M Free > > > >>=20 > > > >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU= > > > >> COMMAND > > > >>=20 > > > >> 44188 a 9 44 0 303M 187M STOP 113:19 13.43= % >=20 > firefox-bin >=20 > > > >> 92986 b 11 44 0 164M 62848K STOP 0:18 5.03= % >=20 > firefox-bin >=20 > > > >> 16507 c 11 44 0 189M 88976K STOP 0:13 0.24= % >=20 > firefox-bin >=20 > > > >> 2265 root 1 44 0 248M 193M select 625:38 0.00%= Xorg > > > >> 51271 d 10 44 0 233M 128M ucond 12:12 0.00= % >=20 > firefox-bin >=20 > > > >> _______________________________________________ > > > >> freebsd-hackers@freebsd.org mailing list > > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > >> To unsubscribe, send any mail to "freebsd-hackers- >=20 > unsubscribe@freebsd.org" >=20 > > > > I wonder if jhb@'s new top code solves this. He adjusted the wa= y CPU > > > > usage is tracked to be more responsive, and not based on averag= es > > >=20 > > > I wonder if jhb@=E2=80=99s new top code fixes the whacky WCPU val= ues we=E2=80=99ve been >=20 > seeing on FreeBSD/ARM. (1713% CPU is a little hard to believe on a s= ingle- > core board ;-). >=20 > > > Tim > >=20 > > *Fixes* it? I've been under the impression those changes caused it= . I > > certainly never saw 1000%+ numbers in top until very recently. >=20 > Yes, if it's a recent change then mine are to blame. In both cases t= he > numbers are imprecise. The older code still in stable@ (as in the OP= ), > takes a long time to ramp up and down. So in this case the processes= are > stopped (no, there's no rootkit), but the scheduler takes a long time= to > factor that into its decayed %CPU computation. >=20 > In the "new" code, the problem is that fetching the kinfo_proc and th= e > current timestamp for that kinfo_proc is not atomic. I have thought > about "fixing" that by embedding a new timeval in kinfo_proc that is > stamped with the time the individual kinfo_proc is generated. This w= ould > (I believe) alleviate the noise in the new code as the delta in wallt= ime > at the "bottom" of the ratio would then correspond to the delta in ru= ntime > on the "top". >=20 > However, trying to store a timeval in kinfo_proc is quite tricky as a= ll the > available fields are things like ints and longs. I could perhaps spl= it it > up into two longs which is kind of fugly. Another option would be to= just > generate a single long that holds raw nanoseconds uptime and store th= at > (wrapping would be ok since I would only care about deltas). So I tried this and the results aren't a lot better. I think the probl= em now=20 is that rufetch() doesn't force an update of the target thread's stats = to "now" (the way getrusage() does for curthread). Because the idle threa= d runs constantly when idle, it is especially prone to this imprecision. I'm = not=20 sure of a good way to fix this. Having a per-thread timestamp that was= =20 updated each time the runtime was updated would help for a currently-ru= nning thread perhaps. Another option would be to use an IPI (ewww) to force currently running threads to update their runtime when the sysctl runs.= That seems a bit expensive though. (I might at least try it to see if it do= es resolve it to verify my understanding of the issue.) --=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:04:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA0A2A5E for ; Wed, 3 Sep 2014 21:04:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AC6B1542 for ; Wed, 3 Sep 2014 21:04:51 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 629D5B94C; Wed, 3 Sep 2014 17:04:50 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: IOAT driver for FreeBSD Date: Wed, 03 Sep 2014 17:04:39 -0400 Message-ID: <1756348.ZCS2aAbzam@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Sep 2014 17:04:50 -0400 (EDT) Cc: Vijay Singh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:04:51 -0000 On Wednesday, September 03, 2014 09:59:56 AM Vijay Singh wrote: > Hi All, I found some discussion in the past about this. Is there a version > of such a driver that I can test, and hopefully help get committed? I am not aware of a driver. You can try talking to Jim Harris (jimharris@) at Intel. He might know of any driver that exists. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:04:52 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 359CDA5F for ; Wed, 3 Sep 2014 21:04:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E4951543 for ; Wed, 3 Sep 2014 21:04:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F1971B95E; Wed, 3 Sep 2014 17:04:50 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: PXE boot Date: Wed, 03 Sep 2014 17:03:44 -0400 Message-ID: <1641492.zXWdUoX4Sh@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Sep 2014 17:04:51 -0400 (EDT) Cc: "Sinha, Prokash" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:04:52 -0000 On Wednesday, September 03, 2014 04:12:01 PM Sinha, Prokash wrote: > Hi All, >=20 > I'm trying to understand the invocation of the routines pxe_init(); > pxe_open() etc. in pxe.c >=20 > By the structure, it looks like a driver with devsw_pxedisk =3D { ent= ry points > =E2=80=A6} >=20 > Once this pxeldr is brought down from the net boot server, how does i= t get > invoked ( or rather who calls these routines ) ??? The loader ( strap= ped > with it don't seem to call). >=20 > I assume that the the boot code in the NVRAM ( or wherever ) of the N= IC that > supports calls these pxe_* () functions ??? pxeboot is pxeldr + /boot/loader. The firmware (BIOS or EFI) downloads= the=20 pxeboot binary to a known fixed address and starts executing it. When = it=20 starts executing, pxeldr finds the /boot/loader binary "behind" it and=20= arranges for it to run. It passes a flag telling it that it was booted= via=20 PXE. The loader then uses the routines in pxe.c to talk to firmware on= the=20 NIC. The firmware provides both TFTP and UDP interfaces. The loader u= ses=20 those to provide either a TFTP "filesystem" or to mount an NFS filesyst= em over=20 UDP. --=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:04:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39FEFAEB; Wed, 3 Sep 2014 21:04:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11C661547; Wed, 3 Sep 2014 21:04:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 04AE7B964; Wed, 3 Sep 2014 17:04:53 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: On changing rand(3) to random(3) in awk(1) Date: Wed, 03 Sep 2014 16:50:35 -0400 Message-ID: <11596842.yV7kvIp5At@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> References: <54003C42.1070309@gmail.com> <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 03 Sep 2014 17:04:53 -0400 (EDT) Cc: Chenguang Li , delphij@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:04:54 -0000 On Friday, August 29, 2014 04:55:57 PM Chenguang Li wrote: > Vitaly Magerya wrote: > > On 2014-08-29 10:12, Chenguang Li wrote: > >> ... ... > >> > >> Yes, I've noticed there's a fairness problem, 0 comes out more often. > >> Since > >> the original code is buggy too, do we need to be compatible with it? > > > > I see no reason why we would. > > > > Interestingly enough, GNU awk has this bug as well (and I am entirely > > too lazy to report it). > > Yes, I came across that line a few days ago. OSX's awk also has this bug, > judging from their code[1]: > > u = (Awkfloat) (random() % RAND_MAX) / RAND_MAX; > > >> Thanks for pointing that out, I've modified the gist as your suggestion. > > > > Looks good to me. You might want to open a bug report with that patch, > > as it's not clear if any committer is reading this thread. Can you please open a bug report with the latest patch? Xin Li (delphij@) imported the most recent awk version. Ideally this patch would go upstream and not just be a local patch. Perhaps Xin can help with that? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:09:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5991AEC4; Wed, 3 Sep 2014 21:09:51 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 540F015BB; Wed, 3 Sep 2014 21:09:50 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id 10so1820458lbg.30 for ; Wed, 03 Sep 2014 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5TUAsTdFDAT1EMz29YOwXKMyE7bwfxVe+kANDoh1YwY=; b=wIfT2MPVe4THb5QTeTSSBjQSgqZD/XLM3e6bUJLX5bbq9ZoVrkvOua2tCRaLRwkhMp RxW+pJ0MXGlb8VYXPgrjaNB1Llih3ELQyKtP2E0G7Cb5YAllRafKJ9pcLXfAzlKPC0uG +4UV47ZRJu2hWDqswdVwfRY34LLp//rugpOWYSvnkb8xqYOn9xK8RC0WfmaLCoQCgzon lTSVxeZIgPpxxLN1gZShen/MOiAZzeZc7XxtSyadg4oN7yXxNu9W6Vor0D6QJMabO3i9 wde/aMxvQdPMCo14GgJH+9Ptz51df2iE/8ALns26GnvG7+yIE+q4iIexBoTS5N1NlFAD lQdw== MIME-Version: 1.0 X-Received: by 10.112.199.42 with SMTP id jh10mr174202lbc.49.1409778588091; Wed, 03 Sep 2014 14:09:48 -0700 (PDT) Received: by 10.25.205.2 with HTTP; Wed, 3 Sep 2014 14:09:48 -0700 (PDT) In-Reply-To: <540711ED.2050909@FreeBSD.org> References: <20140902204413.GC59246@charmander.home> <540711ED.2050909@FreeBSD.org> Date: Wed, 3 Sep 2014 14:09:48 -0700 Message-ID: Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules From: Shrikanth Kamath To: avg@freebsd.org, markj@freebsd.org, freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:09:51 -0000 Thanks Mark/Andriy for helping with this query. I checked the define KDTRACE_HOOKS define that is set. Rather I tried this, I defined a fake provider just to check if that prompts sdt_kld_load to create the SDT probes from my kernel module. + SDT_PROVIDER_DEFINE(fake); And it does help load the SDT probes I created, even though I am not using the fake provider I defined. I feel that sdt_kld_load is flawed when it is looking for sdt_providers_set in the module. It expects at least a provider define and cannot use one of the defined ones in kernel by just declaring it. if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, &end, NULL)) return; I intended to use DTRACE_PROBE() instead of the conventional SDT_PROBE_DEFINE/SDT_PROBE usage because I wanted to create probes which have probe names based on __LINE__ macro...disclaimer...this was just for experiment sakes... E.g func_foo() { .... if () return EINVAL; ... if () return EINVAL; ... if () return EINVAL; } which I replaced with func_foo() { ... if () RETSDT(func_foo, EINVAL); ... if () RETSDT(func_foo, EINVAL); ... if () RETSDT(func_foo, EINVAL); } where RETSDT macro and other macros are defined as #define PROBENAME1(func, __LINE__) func ## __LINE__ #define PROBENAME(func, line) PROBENAME1(func, line) #define RETSDT(func, error_code) \ do { \ DTRACE_PROBE(PROBENAME(func, __LINE__));\ return (error_code); \ } while (0) With the fake provider I defined I get to see and execute my SDT probes % dtrace -l | grep func_foo 56455 sdt netstack func_foo1592 Here netstack is my module, and I have a probe name based on __LINE__ which is 1592. Don't know if that is good way to do it but using SDT_PROBE_DEFINE looks like a problem because of the presence of __LINE__ in the probename. Thanks for reaching out... -- Shrikanth R K On Wed, Sep 3, 2014 at 6:04 AM, Andriy Gapon wrote: > on 02/09/2014 23:44 Mark Johnston said the following: >> Somewhat confusingly, DTRACE_PROBE* shouldn't be used in the kernel. > > But it can be used. > > Shrikanth, please double check that KDTRACE_HOOKS is defined when you compile > your module. > > -- > Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 21:35:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98692735 for ; Wed, 3 Sep 2014 21:35:13 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37AE319D6 for ; Wed, 3 Sep 2014 21:35:12 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-50-5407885ccbc3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 45.79.09603.C5887045; Wed, 3 Sep 2014 17:30:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s83LU3Bx016423; Wed, 3 Sep 2014 17:30:04 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s83LU1o0017311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Sep 2014 17:30:03 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s83LU1N2001229; Wed, 3 Sep 2014 17:30:01 -0400 (EDT) Date: Wed, 3 Sep 2014 17:30:01 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Steven Stewart-Gallus Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1o3pYA8xWLFE2WL75n+MFjM/z2N3 YPKY8Wk+i8fJf29ZApiiuGxSUnMyy1KL9O0SuDJ6VvxmLXjMU/F54x22BsZuri5GDg4JAROJ 1U/duxg5gUwxiQv31rN1MXJxCAnMZpLYdmYpI4SzgVGi5cN7qMxBJom1TbdZQFqEBOol9nfe YwOZxCKgJdE40RMkzCagJvF4bzMrxFRFic2nJjGD2CICNhL/2mawgdjMAvISFzYfYgSxhQXC JTbtXAU2klPAUOLm08nsIDavgKPE7AO9UEf0MEr8XtcMViQqoCOxev8UFogiQYmTM5+wQAzV klg+fRvLBEahWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSndxAgK YHYX1R2MEw4pHWIU4GBU4uFdEMAWIsSaWFZcmXuIUZKDSUmUd20de4gQX1J+SmVGYnFGfFFp TmrxIUYJDmYlEd6aWqAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mC V78dqFGwKDU9tSItM6cEIc3EwQkynAdoeFkbyPDigsTc4sx0iPwpRl2OdZ3f+pmEWPLy81Kl xHlTQIoEQIoySvPg5sASzytGcaC3hHnfg1TxAJMW3KRXQEuYgJa45bCCLClJREhJNTB6GHGd 6O99u1XK+nb94mVbc46v5jvgdXAjv9Q5wY/ZnYnTt7OYmuS4LQhd73CKSVv6zvXAk5/ezV4d 4aDWeeyb2K26XbP2W377mh23+Nj79alTjBO2v2G9EWbQsMzy0NnwJQ96vu25xyZ1fi3bDYkj x1LtU1fMvGGgETpzuf3yVQVVMUxLTaKTlViKMxINtZiLihMBNBXrRxcDAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:35:13 -0000 On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: > > svn blame says that the whole implementation dates from r1541. > > Looks like > > it was never implemented. Some googling indicates that it was a > > plannedroutine to set the stack size, which was never implemented, > > anywhere. > > > The locking comments were added in r79224, but the implementation is > > otherwise from r1541, i.e., it was never implemented. > > Alright, so sys/kern/syscalls.master can be patched somewhat like so > and I won't need to document them? > > -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ > - ovadvise_args int > +72 AUE_NULL OBSOL ovadvise > > -70 AUE_SSTK STD { int sstk(int incr); } > +70 AUE_SSTK OBSOL sstk I don't think so; I think that would be a regression. We do currently provide implementations for these syscalls, that just happen to always return failure. I think that the OBSOL annotation corresponds to a complete lack of implementation. Perhaps it would be acceptable at a major release boundary, but this is not my area of expertise. > Okay, Linux has similar reserved system calls such as tuxcall. Linux > deals with these by having an unimplemented.2 manpage which lists > obsolete or reserved system calls. So we can just add to the manpage > stuff like: afs3_syscall is a system call reserved for the use of the > OpenAFS people. I don't have any particular objection to such a thing existing, but I wonder whether the developer time to create it could be better used on other things. I guess it comes down to what value it is seen as providing. -Ben From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 3 23:50:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 883FFD94; Wed, 3 Sep 2014 23:50:24 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA541ABB; Wed, 3 Sep 2014 23:50:24 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id rl12so10739295iec.39 for ; Wed, 03 Sep 2014 16:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5/W3aV/+j9dPX++4t9TJqLifhz6pPxZ8Ow9CAQCH+Zc=; b=l/9kQUNIJ7ORssopzFgqv/uTUqTPbLYTxzcqEe3NCHSZm/AZxU5EsPfDTIDc6BAYl6 +V7Qan8ydd2T1FCe0mDjs17ibtN/p9ed5TyvHwsWM/N0BbKq9Wl4lJG9R8Cm/hW3d0zY r/wFdIzglPz+zOGaGaKYIOYewfJDN/JA2YezjLC9JD90TSr9k45IeFG56WlOF8EIShQv 5/CBS72hd4lrW9KneMDYdS6HYkh91xmbrvorEy6AW5+uHUy9Drh/+7Vru0NWaFqQpSQT Fjmw/sgeEBViq8O/PdER1ZastUhSBDYnPspNSDqnDPCz2B4Yc5OaSMYC3YAf3Tvj44UG As+g== X-Received: by 10.42.204.76 with SMTP id fl12mr721777icb.80.1409788223647; Wed, 03 Sep 2014 16:50:23 -0700 (PDT) Received: from charmander.home ([64.229.13.35]) by mx.google.com with ESMTPSA id cj8sm6831568igb.11.2014.09.03.16.50.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 16:50:22 -0700 (PDT) Sender: Mark Johnston Date: Wed, 3 Sep 2014 19:49:50 -0400 From: Mark Johnston To: Shrikanth Kamath Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules Message-ID: <20140903234950.GB38016@charmander.home> References: <20140902204413.GC59246@charmander.home> <540711ED.2050909@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 23:50:24 -0000 On Wed, Sep 03, 2014 at 02:09:48PM -0700, Shrikanth Kamath wrote: > Thanks Mark/Andriy for helping with this query. I checked the define > KDTRACE_HOOKS define that is set. Rather I tried this, I defined a > fake provider just to check if that prompts sdt_kld_load to create the > SDT probes from my kernel module. > > + SDT_PROVIDER_DEFINE(fake); > And it does help load the SDT probes I created, even though I am not > using the fake provider I defined. I feel that sdt_kld_load is flawed > when it is looking for sdt_providers_set in the module. It expects at > least a provider define and cannot use one of the defined ones in > kernel by just declaring it. > > if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, > &end, NULL)) > return; You're completely right; this issue was fixed in http://svnweb.freebsd.org/base?view=revision&revision=267706 > > I intended to use DTRACE_PROBE() instead of the conventional > SDT_PROBE_DEFINE/SDT_PROBE usage because I wanted to create probes > which have probe names based on __LINE__ macro...disclaimer...this was > just for experiment sakes... > > E.g > func_foo() > { > .... > if () > return EINVAL; > ... > if () > return EINVAL; > ... > if () > return EINVAL; > } > > which I replaced with > func_foo() > { > ... > if () > RETSDT(func_foo, EINVAL); > ... > if () > RETSDT(func_foo, EINVAL); > ... > if () > RETSDT(func_foo, EINVAL); > } > where RETSDT macro and other macros are defined as > > #define PROBENAME1(func, __LINE__) func ## __LINE__ > #define PROBENAME(func, line) PROBENAME1(func, line) > > #define RETSDT(func, error_code) \ > do { \ > DTRACE_PROBE(PROBENAME(func, __LINE__));\ > return (error_code); \ > } while (0) > > With the fake provider I defined I get to see and execute my SDT probes > % dtrace -l | grep func_foo > 56455 sdt netstack func_foo1592 > > Here netstack is my module, and I have a probe name based on __LINE__ > which is 1592. Why not just use a single probe and make the line number and function name arguments to the probe? That is, write something like #define RETSDT(error_code) do { \ DTRACE_PROBE2(error__return, __func__, __LINE__) return (error_code); } while (0) > Don't know if that is good way to do it but using SDT_PROBE_DEFINE > looks like a problem because of the presence of __LINE__ in the > probename. > > Thanks for reaching out... > -- > Shrikanth R K > > On Wed, Sep 3, 2014 at 6:04 AM, Andriy Gapon wrote: > > on 02/09/2014 23:44 Mark Johnston said the following: > >> Somewhat confusingly, DTRACE_PROBE* shouldn't be used in the kernel. > > > > But it can be used. > > > > Shrikanth, please double check that KDTRACE_HOOKS is defined when you compile > > your module. > > > > -- > > Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 01:45:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D363A42; Thu, 4 Sep 2014 01:45:49 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9E51733; Thu, 4 Sep 2014 01:45:49 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id r10so12409521pdi.36 for ; Wed, 03 Sep 2014 18:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yHLL1RTU7WsiqbtuTZpOPznQacFpqkHAetOP+DFQKP4=; b=Lq4zpwmtBImiKXLXqV8TFq+5SxVh0FJp4wrFfXAuQCMfdeJ7DaH7fQlBtC+LgDJ7KD r38lToR2he0exH2tHQGMTE008KHDUTokeloz7bOKkyqujUeAFNrTthTuOZ+qFKJ45S6k tjUsSxgWR4k00ME0RlMToh29kI1thN4opVUFBL2Kro+I0ygcymFksrc0HbZKTmPjavPi bF+uTxkkDCqNopsRhXYKDLo3GgS+y73qr3/8qbnhggBVDMIVEVNt6guNuNNBjvZfO1DH +p3rCnUN/zbiXEojGqmCzUPkLe0xL4svF2v18bhxzI5aECLiyxd+pEp5ogRc3LJe0c4u 8rXQ== X-Received: by 10.66.65.230 with SMTP id a6mr2651550pat.18.1409795148166; Wed, 03 Sep 2014 18:45:48 -0700 (PDT) Received: from [10.240.140.110] ([123.58.191.69]) by mx.google.com with ESMTPSA id n7sm164080pdm.35.2014.09.03.18.45.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 18:45:47 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <11596842.yV7kvIp5At@ralph.baldwin.cx> Date: Thu, 4 Sep 2014 09:45:25 +0800 Content-Transfer-Encoding: 8bit Message-Id: <480C9391-4E1F-4E54-888F-419B7B6A0E24@gmail.com> References: <54003C42.1070309@gmail.com> <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> <11596842.yV7kvIp5At@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, d@delphij.net, Vitaly Magerya , Erik Cederstrand X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 01:45:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 John Baldwin wrote: > [omitted] > > Can you please open a bug report with the latest patch? > > Xin Li (delphij@) imported the most recent awk version. Ideally this patch > would go upstream and not just be a local patch. Perhaps Xin can help with > that? Sorry for not keeping you guys updated, actually I did open a bug report[1] a few days ago. I also wrote Brian Kernighan an email with details and a link to this thread then, as Erik suggested. He replied: > I've read the thread on rand vs random; it's interesting. > It sounds like replacing rand with random would be a good > idea regardless, and probably it's good to replace the > RAND_MAX with an explicit 2^31+1. > > I don't think that it would hurt to also use RAND_MAX+1UL > with rand() as an interim measure. You're right that zero > does come up twice as often as any other value. Probably > doesn't make much difference in practice, but better to do > things right when possible. > > I'll add this to my list of things to try to fix up, which > is getting longer than it should, but I've been busy on > other things and keep pushing awk over the horizon. So I guess this would eventually be patched upstream. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193147 Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUB8REAAoJELG4cS+11lRhrPcQAK5nH6ZozdeMPzl9LfLn2PAM NHhq0G/yaAihNSYqmhQSW7W3ZbNtQ1HTTqsDSgh+rnk1WEgUkyHZARdhnywElnwF AXldYw0CJTJCL4aN6SeX9Wt34M4DJvaXAsvG+YaMUsicaho+cUEUW7m+b+YkAAUI G1JqaImvT0crYWTewS7nVvpqiyWw7bL7mS+v/B6zY7Fh8yCxWomc+7ZC5Q837vic cBUqCZG2bpZpOb0lvRnSIeDLhlHx8L4HOXuXMWUD/O7OGNehdYqBiaEIASAmT/ar sKa2kDb3DTrJ+AGZh9keDoLWHhcZA9EtFREdTqdDlm+V2QyyzpEDbwFZHnt9KoPI HzP4JuJuIG4+iSIarZ8WLje8jy5D+Us6JVz1e6oc/7ZetDR3w27Qzb6pcvGgloFI OuYksTi+TxlGYQqQlqL4JIuvCPC87gT0AKNpuJxAzAajCCaoMRDvwQyCI4wqsrQ9 e9IOlNRtqERRBifL/Vq/MJNgHPus6l2PEs4GZgEf+BA30Lbq+k2bvLHvtORO19s6 kCu/zebnmPX4JNKFB99zOHUOFTmQv5QkG0AstmcxWeR6IDpBmuGe/ejLzDtU8iWT cg6oPtk+/JytooNYjm1ADz6pxwab1Q71rVXCUQQFWG8cIR1LIrGeeEJguzXP9nAL 9GOF7XQnTwGTFj4wuga0 =sBDJ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 08:52:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC1F5409; Thu, 4 Sep 2014 08:52:31 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB2E31821; Thu, 4 Sep 2014 08:52:31 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id v63so6520490oia.1 for ; Thu, 04 Sep 2014 01:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9l7RxZx4K5I/i5BdXOtDOoigsEjsgBt8r++9MvWSBd8=; b=CtYRy2g7jkIvQWGZC9s09RtXyoUfwDHwaEmPtAj5rT+M2dWg/MGUIohcouh38ZOfhY OSO4UYpWIW33FcvYt/p14/DCwYML7Vd2ao8pm0MZZh3JVTkDSHMVhwmV3gOssyAedeFi ezuBwf4BA8XacfSE7RP+/IjdAWx3rFBTxD8XvfS5Fp11+Qyi+3jFHlGiLJEF3W44KdC0 8ED2W43Rq6l5NJBWkCCVauV236LwRQZ38HQ6lLzqhgC0xNb8j3uJYhb45qApSafzgA7h EIsxLr+aHn9RX40uzAj2Dp60BsfccUkYtRXs8DOXf/doD5L1P6KUgrGG9+jhC/Jn0IxQ 5gYw== MIME-Version: 1.0 X-Received: by 10.60.124.115 with SMTP id mh19mr3152628oeb.40.1409820751010; Thu, 04 Sep 2014 01:52:31 -0700 (PDT) Received: by 10.182.28.100 with HTTP; Thu, 4 Sep 2014 01:52:30 -0700 (PDT) In-Reply-To: <1756348.ZCS2aAbzam@ralph.baldwin.cx> References: <1756348.ZCS2aAbzam@ralph.baldwin.cx> Date: Thu, 4 Sep 2014 10:52:30 +0200 Message-ID: Subject: Re: IOAT driver for FreeBSD From: Oliver Pinter To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Vijay Singh X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 08:52:32 -0000 On 9/3/14, John Baldwin wrote: > On Wednesday, September 03, 2014 09:59:56 AM Vijay Singh wrote: >> Hi All, I found some discussion in the past about this. Is there a >> version >> of such a driver that I can test, and hopefully help get committed? > > I am not aware of a driver. You can try talking to Jim Harris (jimharris@) > at > Intel. He might know of any driver that exists. Or Jack Vogel from Intel too: https://lists.freebsd.org/pipermail/freebsd-hackers/2011-June/035579.html > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 09:03:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB89C6F2; Thu, 4 Sep 2014 09:03:24 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8BEF21923; Thu, 4 Sep 2014 09:03:23 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 3 Sep 2014 19:16:11 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Wed, 3 Sep 2014 16:16:07 -0700 From: "Sinha, Prokash" To: John Baldwin , "freebsd-hackers@freebsd.org" Subject: Re: PXE boot Thread-Topic: PXE boot Thread-Index: AQHPx7q2tjxfRdxxqUWbg0sIKzb+LpvwCpsA Date: Wed, 3 Sep 2014 23:16:05 +0000 Message-ID: References: <1641492.zXWdUoX4Sh@ralph.baldwin.cx> In-Reply-To: <1641492.zXWdUoX4Sh@ralph.baldwin.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.142.176] Content-Type: text/plain; charset="Windows-1252" Content-ID: <71D1D353A67F794D88557FD48FB18114@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2014 23:16:11.0201 (UTC) FILETIME=[0CAE5B10:01CFC7CD] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:03:25 -0000 Thanks much, John ! When it starts executing ? How ?. Who starts executing these. From the Makefile it's org is 0x7c00. So I would assume that it would be loaded at that absolute real-mode address !. I don't understand this part. But, if I put traces, I see pxe_open, and pxe_close are being called, but after all these pxe_calls are done, the loader's main is invoked at Rebooting =8A tim= e. We are using a net boot server, and I see mountd- authenticated =8A message storm on the boot server side. Wondering what could cause such a message storm, while pxe_open() -> net if_open( ) executes. -prokash=20 On 9/3/14 2:03 PM, "John Baldwin" wrote: >On Wednesday, September 03, 2014 04:12:01 PM Sinha, Prokash wrote: >> Hi All, >>=20 >> I'm trying to understand the invocation of the routines pxe_init(); >> pxe_open() etc. in pxe.c >>=20 >> By the structure, it looks like a driver with devsw_pxedisk =3D { entry >>points >> =8A} >>=20 >> Once this pxeldr is brought down from the net boot server, how does it >>get >> invoked ( or rather who calls these routines ) ??? The loader ( strapped >> with it don't seem to call). >>=20 >> I assume that the the boot code in the NVRAM ( or wherever ) of the NIC >>that >> supports calls these pxe_* () functions ??? > >pxeboot is pxeldr + /boot/loader. The firmware (BIOS or EFI) downloads >the=20 >pxeboot binary to a known fixed address and starts executing it. When it >starts executing, pxeldr finds the /boot/loader binary "behind" it and >arranges for it to run. It passes a flag telling it that it was booted >via=20 >PXE. The loader then uses the routines in pxe.c to talk to firmware on >the=20 >NIC. The firmware provides both TFTP and UDP interfaces. The loader >uses=20 >those to provide either a TFTP "filesystem" or to mount an NFS filesystem >over=20 >UDP. > >--=20 >John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 09:23:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C80F238A; Thu, 4 Sep 2014 09:23:29 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B97AB1B1B; Thu, 4 Sep 2014 09:23:28 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id mc6so11587275lab.29 for ; Thu, 04 Sep 2014 02:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W1QI0/USO/27FH/hPfCrA9bA734UIm30Z8PE4LvoZac=; b=mN7EGmAOLA3OeWqjwOltTY1x/DQYFv1KL0s2GYin40S/jl7jYbbdMIYUxoUg1xV+Ig xu/PgkTXjtYOB+v2K5jGSST5VxZ7bfJDc+uNwukmxTj7s2nD304XEt12jKd2kfgPONA9 BkVA0X1UrF9noE4nMdwL9J56VN9P61zu5cKn+SogeBnQdpDO+mrfIk+ojUiDPDzQOk3k Kt9qs+T9xQaLmj0TY/zZPFyogZxs2oqvBY5aQgEap7aIznBvTJlISB3n3HyRXNTvYM2H dEqP2zCnAWpkSUzgVREAItkzSVjUn9Bca1GX/T7SJK85GNddaufOKZtMZPQBYDy2FDng Tnxg== MIME-Version: 1.0 X-Received: by 10.112.209.36 with SMTP id mj4mr3224027lbc.26.1409822606498; Thu, 04 Sep 2014 02:23:26 -0700 (PDT) Received: by 10.25.205.2 with HTTP; Thu, 4 Sep 2014 02:23:26 -0700 (PDT) In-Reply-To: <20140903234950.GB38016@charmander.home> References: <20140902204413.GC59246@charmander.home> <540711ED.2050909@FreeBSD.org> <20140903234950.GB38016@charmander.home> Date: Thu, 4 Sep 2014 02:23:26 -0700 Message-ID: Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules From: Shrikanth Kamath To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:23:30 -0000 On Wed, Sep 3, 2014 at 4:49 PM, Mark Johnston wrote: > On Wed, Sep 03, 2014 at 02:09:48PM -0700, Shrikanth Kamath wrote: >> Thanks Mark/Andriy for helping with this query. I checked the define >> KDTRACE_HOOKS define that is set. Rather I tried this, I defined a >> fake provider just to check if that prompts sdt_kld_load to create the >> SDT probes from my kernel module. >> >> + SDT_PROVIDER_DEFINE(fake); >> And it does help load the SDT probes I created, even though I am not >> using the fake provider I defined. I feel that sdt_kld_load is flawed >> when it is looking for sdt_providers_set in the module. It expects at >> least a provider define and cannot use one of the defined ones in >> kernel by just declaring it. >> >> if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, >> &end, NULL)) >> return; > > You're completely right; this issue was fixed in > http://svnweb.freebsd.org/base?view=revision&revision=267706 > >> >> I intended to use DTRACE_PROBE() instead of the conventional >> SDT_PROBE_DEFINE/SDT_PROBE usage because I wanted to create probes >> which have probe names based on __LINE__ macro...disclaimer...this was >> just for experiment sakes... >> >> E.g >> func_foo() >> { >> .... >> if () >> return EINVAL; >> ... >> if () >> return EINVAL; >> ... >> if () >> return EINVAL; >> } >> >> which I replaced with >> func_foo() >> { >> ... >> if () >> RETSDT(func_foo, EINVAL); >> ... >> if () >> RETSDT(func_foo, EINVAL); >> ... >> if () >> RETSDT(func_foo, EINVAL); >> } >> where RETSDT macro and other macros are defined as >> >> #define PROBENAME1(func, __LINE__) func ## __LINE__ >> #define PROBENAME(func, line) PROBENAME1(func, line) >> >> #define RETSDT(func, error_code) \ >> do { \ >> DTRACE_PROBE(PROBENAME(func, __LINE__));\ >> return (error_code); \ >> } while (0) >> >> With the fake provider I defined I get to see and execute my SDT probes >> % dtrace -l | grep func_foo >> 56455 sdt netstack func_foo1592 >> >> Here netstack is my module, and I have a probe name based on __LINE__ >> which is 1592. > > Why not just use a single probe and make the line number and function > name arguments to the probe? That is, write something like > > #define RETSDT(error_code) do { \ > DTRACE_PROBE2(error__return, __func__, __LINE__) > return (error_code); > } while (0) > Mark, for some reason using a single probe does not seem to fire the probe. -- Shrikanth R K From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 14:56:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9956D4CC for ; Thu, 4 Sep 2014 14:56:12 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6254B1321 for ; Thu, 4 Sep 2014 14:56:12 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hn18so1223507igb.3 for ; Thu, 04 Sep 2014 07:56:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:mime-version:subject :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=M3WMtwEZqJRXfP7MzMirSIaZHn/+BwSG0mFIouSebkc=; b=N8Q/FnC0glk32YW+ib5+i/r9cfIhCmSkJ9p7qrdsaIRlH8ipWRGYC+yKG2gHCs8Ksc U4dG0SR5IEf8X1mqyETWJYn+860K9dF/9Ynp3ybS9KQFy00juByV2GDg0t9RUgJrqxhG 4+g4vIM+lj4G3fxRgClyl0AH2WWze2z9L7qP3LJXZurDv8hrlN0bd+8TphxTZTab1peD zv2fCVnFh1C8mzUSYFcSKar/VxNASmwxT4XmL0WxQ1XFSzVlEt1lbVf09O0HgoCFGB2f aw54Qwru5VgIXDFYV/dWrvQDgkdDZ83lb6NWDIxuJCQ5GGKkPWKrFiQwThZwm2QKD1y6 6l0w== X-Gm-Message-State: ALoCoQnofFr/Hjc2BmhyYsYi4yooKzaWXjR/raS8oPg8rHhaAZWV2BLia1P17cBvRYiLgNQwUkzY X-Received: by 10.42.26.74 with SMTP id e10mr6303328icc.25.1409842570845; Thu, 04 Sep 2014 07:56:10 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id e16sm1119596igz.8.2014.09.04.07.56.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 07:56:10 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: The use of C language is avoided in FreeBSD development? In-Reply-To: Date: Thu, 4 Sep 2014 08:56:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7538A48E-6DDA-4820-B11C-2AFDA9175DA7@gmail.com> References: To: =?windows-1252?Q?fran=E7ai_s?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 14:56:12 -0000 On Aug 12, 2014, at 12:07 PM, fran=E7ai s wrote: > The use of C language is avoided in FreeBSD development?=20 Hello? Yes, this is 1993 calling. Yes, I=92m comp.os.unix, I can hold=85. Ah, you=92re back. Thanks for taking my call. I=92m looking for one of = my trolls. He seems to have mysteriously vanished and I was wondering if you=92d seen him=85 He keeps posting flame bate about how out-dated C is and how other things are better=85 Been doing it for 10 years as far as I can tell. Can you help me? Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 15:01:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3590E4B; Thu, 4 Sep 2014 15:01:57 +0000 (UTC) Date: Thu, 4 Sep 2014 11:01:54 -0400 From: Glen Barber To: Warner Losh Subject: Re: The use of C language is avoided in FreeBSD development? Message-ID: <20140904150154.GM36287@hub.FreeBSD.org> References: <7538A48E-6DDA-4820-B11C-2AFDA9175DA7@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lRF4gxo9Z9M++D0O" Content-Disposition: inline In-Reply-To: <7538A48E-6DDA-4820-B11C-2AFDA9175DA7@gmail.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:01:58 -0000 --lRF4gxo9Z9M++D0O Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2014 at 08:56:09AM -0600, Warner Losh wrote: >=20 > On Aug 12, 2014, at 12:07 PM, fran=C3=A7ai s wrote: >=20 > > The use of C language is avoided in FreeBSD development?=20 >=20 > Hello? Yes, this is 1993 calling. Yes, I=E2=80=99m comp.os.unix, I can ho= ld=E2=80=A6. >=20 > Ah, you=E2=80=99re back. Thanks for taking my call. I=E2=80=99m looking = for one of my > trolls. He seems to have mysteriously vanished and I was wondering > if you=E2=80=99d seen him=E2=80=A6 He keeps posting flame bate about how= out-dated > C is and how other things are better=E2=80=A6 Been doing it for 10 years= as > far as I can tell. >=20 > Can you help me? >=20 We're sorry, all representatives are currently assisting other clients. Please hold, and your call will be answered in the order in which it was received. Glen --lRF4gxo9Z9M++D0O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUCH7iAAoJELls3eqvi17QwagP/jVKNf4K8Qd0iLcPwSWJW+UW 3GrqyP2kVPMOOmxDNjsRUdSimitInlJ4XksBmnqLBwtp+jm/J14fX5HEdrl3vqiG N2xb+ggdK4LSy8cdi7wbEKDO4KjgxUFuZx5g0lcm3U+q7qlEzvmP4RLmaFp8xhZ5 32B/0m89NK0kgMeNEEQh+RmMSPkV3lGIk/91m2pjZCeg28jvj6CAHxf3EaMAQmN3 xge00GaAp6UEfTabS8YhvPWuVTKfk6rLrhAGyCXtu+QvWLvyIlJuqOWAloVCZvpg qnHiSwTAtKdIlkLpUz4EXqxtNnQMCAaTCLSWEtlg0sSl1wSj5DG8FDg7r89sxudg 16SgQ3wFWGpGFu/mqrHDCJjpAeJVzKLSKMRd/eUIpCpNqOMNEysap8a9+kRhfMO5 npJzdlr6khAgqU4eKItsBvDMAK1hjCNs8UyrOhtDKQqw205oJYtV8jRytU8+ZuzU Xuqf8YZzgg6EgkYLR3fxdZWldTXnvYqMWM+iF/wqiA6/UwLomWomJH3fKKuwgowg AyX+7Rsk7Vb/GHjn2fbyjBH/i08jq8R2eK/gmB+D8b2vDkxheHT1/0+186j/Zba2 4yqHMx6IxlqRvAkCXNtkERi1Jq6xOCglbHRsJqP4FW1WhjwDqTUKeysHwKIqQA0Z DUYjhrEmYSxd+fK4JFs5 =soh7 -----END PGP SIGNATURE----- --lRF4gxo9Z9M++D0O-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 15:56:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63E1C2D7 for ; Thu, 4 Sep 2014 15:56:02 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C2B31CEB for ; Thu, 4 Sep 2014 15:56:02 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2F80DB95E; Thu, 4 Sep 2014 11:56:01 -0400 (EDT) From: John Baldwin To: "Sinha, Prokash" Subject: Re: PXE boot Date: Thu, 04 Sep 2014 10:57:56 -0400 Message-ID: <8193889.CqHK0JhjBu@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <1641492.zXWdUoX4Sh@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 11:56:01 -0400 (EDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:56:02 -0000 On Wednesday, September 03, 2014 11:16:05 PM Sinha, Prokash wrote: > Thanks much, John ! >=20 > When it starts executing ? How ?. Who starts executing these. From th= e > Makefile it's org is 0x7c00. So I would assume that it would be loade= d at > that absolute real-mode address !. I don't understand this part. But,= if I > put traces, I see pxe_open, and pxe_close are being called, but after= all > these pxe_calls are done, the loader's main is invoked at Rebooting =C5= =A0 time. >=20 > We are using a net boot server, and I see mountd- authenticated =C5=A0= message > storm on the boot server side. >=20 > Wondering what could cause such a message storm, while pxe_open() -> = net > if_open( ) executes. The PXE BIOS uses TFTP to fetch the pxeboot binary (and it will do its = own=20 DHCP, etc. as part of doing that). It writes the binary it downloads s= tarting=20 at address 0x7c00. Once the download is complete, it jumps to 0x7c00 s= imilar=20 to how booting from a disk loads the first sector at address 0x7c00 and= then=20 jumps to it. The PXE calls in libi386 should not be invoked until the loader main() = routine=20 runs: /* * Special handling for PXE and CD booting. */ if (kargs->bootinfo =3D=3D 0) { =09/* =09 * We only want the PXE disk to try to init itself in the below =09 * walk through devsw if we actually booted off of PXE. =09 */ =09if (kargs->bootflags & KARGS_FLAGS_PXE) =09 pxe_enable(kargs->pxeinfo ? PTOV(kargs->pxeinfo) : NULL); =09else if (kargs->bootflags & KARGS_FLAGS_CD) =09 bc_add(initial_bootdev); } That enables the PXE devsw driver so that it will do something later wh= en=20 main() calls all the devsw init routines: /* * March through the device switch probing for things. */ for (i =3D 0; devsw[i] !=3D NULL; i++) =09if (devsw[i]->dv_init !=3D NULL) =09 (devsw[i]->dv_init)(); printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024,=20= bios_extmem / 1024); --=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 15:56:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 998713D2; Thu, 4 Sep 2014 15:56:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7BD1CEF; Thu, 4 Sep 2014 15:56:08 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5FC20B995; Thu, 4 Sep 2014 11:56:07 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? Date: Thu, 04 Sep 2014 10:06:08 -0400 Message-ID: <2041449.H6lUHcsTDl@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 11:56:07 -0400 (EDT) Cc: Benjamin Kaduk , kib@freebsd.org, Steven Stewart-Gallus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:56:08 -0000 On Wednesday, September 03, 2014 05:30:01 PM Benjamin Kaduk wrote: > On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: > > > svn blame says that the whole implementation dates from r1541. > > > Looks like > > > it was never implemented. Some googling indicates that it was a > > > plannedroutine to set the stack size, which was never implemented, > > > anywhere. > > > > > > The locking comments were added in r79224, but the implementation is > > > otherwise from r1541, i.e., it was never implemented. > > > > Alright, so sys/kern/syscalls.master can be patched somewhat like so > > and I won't need to document them? > > > > -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ > > - ovadvise_args int > > +72 AUE_NULL OBSOL ovadvise > > > > -70 AUE_SSTK STD { int sstk(int incr); } > > +70 AUE_SSTK OBSOL sstk > > I don't think so; I think that would be a regression. > > We do currently provide implementations for these syscalls, that just > happen to always return failure. I think that the OBSOL annotation > corresponds to a complete lack of implementation. Perhaps it would be > acceptable at a major release boundary, but this is not my area of > expertise. For these two calls, I doubt anything is actually using them. They've been stubs since the Mach VM was imported into BSD in 1990. We don't ship a system call for creat() anymore either. In this particular case, I think it would be more of a feature if those symbols disappeared from libc and caused link errors. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 16:31:09 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF82FC1B for ; Thu, 4 Sep 2014 16:31:09 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [IPv6:2a02:6b8:0:1819::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 874F3118A for ; Thu, 4 Sep 2014 16:31:09 +0000 (UTC) Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 09B2E1441073; Thu, 4 Sep 2014 20:31:05 +0400 (MSK) Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 8B7BF1900054; Thu, 4 Sep 2014 20:31:05 +0400 (MSK) Received: from 84.201.166.247-vpn.dhcp.yndx.net (84.201.166.247-vpn.dhcp.yndx.net [84.201.166.247]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id SuSP2KBTHf-V54KWBUj; Thu, 4 Sep 2014 20:31:05 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 506efd1f-5aa3-4bc3-b145-bd82caa13e7f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1409848265; bh=vEMGenrSTqaMAKhxo8c3wI3ob992E1jAHzp2osBDxyU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=NrF6ZMo8sEphXjs0EFHXRbNSmiq8l4zsz+y5qiwYJ6N7ieRzj/LLvynRLpcgujYGk TrieflMDhotzfCKAh4EmtTCAhzAzdMvPhJHLEnmiUFxTuGjZAvhnU49VUyT2X4CFU9 2tg3W2a5qgzNb3DrlO5DWKNstzmCxcWQDG/IGbx4= Authentication-Results: smtp17.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5408938E.5020005@yandex.ru> Date: Thu, 04 Sep 2014 20:30:06 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vijay Singh , hackers@freebsd.org Subject: Re: IOAT driver for FreeBSD References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:31:09 -0000 On 03.09.2014 20:59, Vijay Singh wrote: > Hi All, I found some discussion in the past about this. Is there a version > of such a driver that I can test, and hopefully help get committed? There was some work in http://svnweb.freebsd.org/base/user/jimharris/ioat/sys/dev/ioat/ -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 16:33:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA9A7DD3; Thu, 4 Sep 2014 16:33:50 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 69724126E; Thu, 4 Sep 2014 16:33:50 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 4 Sep 2014 12:33:48 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Thu, 4 Sep 2014 09:33:47 -0700 From: "Sinha, Prokash" To: John Baldwin Subject: Re: PXE boot Thread-Topic: PXE boot Thread-Index: AQHPx7q2tjxfRdxxqUWbg0sIKzb+LpvwCpsAgAF8gAD//6TLgIAAAKKA Date: Thu, 4 Sep 2014 16:33:46 +0000 Message-ID: References: <1641492.zXWdUoX4Sh@ralph.baldwin.cx> <8193889.CqHK0JhjBu@ralph.baldwin.cx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.133.204] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <11204A09430C77439EB160232C140BD7@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Sep 2014 16:33:48.0460 (UTC) FILETIME=[00E62EC0:01CFC85E] Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 16:33:50 -0000 On 9/4/14 9:31 AM, "Sinha, Prokash" wrote: >Thanks once again... > >This is the part - that you spelled out is why I had a trace in the >pxe_enable(...) routine. As well as at pxe_init( ...) routine, just to be >sure >the pxe.c routines are working like ( as you said ) devsw invocation. But >did not see the trace messages, could be serial console is not acting ( >though I doubt it). > >Now gave me a base, off of what I could debug ... > >-prokash > >On 9/4/14 7:57 AM, "John Baldwin" wrote: > >>On Wednesday, September 03, 2014 11:16:05 PM Sinha, Prokash wrote: >>> Thanks much, John ! >>>=20 >>> When it starts executing ? How ?. Who starts executing these. From the >>> Makefile it's org is 0x7c00. So I would assume that it would be loaded >>>at >>> that absolute real-mode address !. I don't understand this part. But, >>>if I >>> put traces, I see pxe_open, and pxe_close are being called, but after >>>all >>> these pxe_calls are done, the loader's main is invoked at Rebooting =A9 >>>time. >>>=20 >>> We are using a net boot server, and I see mountd- authenticated =A9 >>>message >>> storm on the boot server side. >>>=20 >>> Wondering what could cause such a message storm, while pxe_open() -> >>>net >>> if_open( ) executes. >> >>The PXE BIOS uses TFTP to fetch the pxeboot binary (and it will do its >>own=20 >>DHCP, etc. as part of doing that). It writes the binary it downloads >>starting=20 >>at address 0x7c00. Once the download is complete, it jumps to 0x7c00 >>similar=20 >>to how booting from a disk loads the first sector at address 0x7c00 and >>then=20 >>jumps to it. >> >>The PXE calls in libi386 should not be invoked until the loader main() >>routine=20 >>runs: >> >> /* >> * Special handling for PXE and CD booting. >> */ >> if (kargs->bootinfo =3D=3D 0) { >> /* >> * We only want the PXE disk to try to init itself in the below >> * walk through devsw if we actually booted off of PXE. >> */ >> if (kargs->bootflags & KARGS_FLAGS_PXE) >> pxe_enable(kargs->pxeinfo ? PTOV(kargs->pxeinfo) : NULL); >> else if (kargs->bootflags & KARGS_FLAGS_CD) >> bc_add(initial_bootdev); >> } >> >>That enables the PXE devsw driver so that it will do something later when >>main() calls all the devsw init routines: >> >> /* >> * March through the device switch probing for things. >> */ >> for (i =3D 0; devsw[i] !=3D NULL; i++) >> if (devsw[i]->dv_init !=3D NULL) >> (devsw[i]->dv_init)(); >> printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024, >>bios_extmem / 1024); >> >>--=20 >>John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 17:48:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8C6CC36; Thu, 4 Sep 2014 17:48:12 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 91B251D18; Thu, 4 Sep 2014 17:48:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s84HmBK3000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Sep 2014 10:48:11 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s84HmBZV000534; Thu, 4 Sep 2014 10:48:11 -0700 (PDT) (envelope-from jmg) Date: Thu, 4 Sep 2014 10:48:11 -0700 From: John-Mark Gurney To: Shrikanth Kamath Subject: Re: Usage of DTRACE_PROBE macro from sdt.h in kernel modules Message-ID: <20140904174811.GK82175@funkthat.com> Mail-Followup-To: Shrikanth Kamath , Mark Johnston , freebsd-hackers@freebsd.org, freebsd-dtrace@freebsd.org, avg@freebsd.org References: <20140902204413.GC59246@charmander.home> <540711ED.2050909@FreeBSD.org> <20140903234950.GB38016@charmander.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 04 Sep 2014 10:48:11 -0700 (PDT) Cc: freebsd-hackers@freebsd.org, Mark Johnston , avg@freebsd.org, freebsd-dtrace@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 17:48:12 -0000 Shrikanth Kamath wrote this message on Thu, Sep 04, 2014 at 02:23 -0700: > On Wed, Sep 3, 2014 at 4:49 PM, Mark Johnston wrote: > > On Wed, Sep 03, 2014 at 02:09:48PM -0700, Shrikanth Kamath wrote: > >> Thanks Mark/Andriy for helping with this query. I checked the define > >> KDTRACE_HOOKS define that is set. Rather I tried this, I defined a > >> fake provider just to check if that prompts sdt_kld_load to create the > >> SDT probes from my kernel module. > >> > >> + SDT_PROVIDER_DEFINE(fake); > >> And it does help load the SDT probes I created, even though I am not > >> using the fake provider I defined. I feel that sdt_kld_load is flawed > >> when it is looking for sdt_providers_set in the module. It expects at > >> least a provider define and cannot use one of the defined ones in > >> kernel by just declaring it. > >> > >> if (linker_file_lookup_set(lf, "sdt_providers_set", &begin, > >> &end, NULL)) > >> return; > > > > You're completely right; this issue was fixed in > > http://svnweb.freebsd.org/base?view=revision&revision=267706 > > > >> > >> I intended to use DTRACE_PROBE() instead of the conventional > >> SDT_PROBE_DEFINE/SDT_PROBE usage because I wanted to create probes > >> which have probe names based on __LINE__ macro...disclaimer...this was > >> just for experiment sakes... > >> > >> E.g > >> func_foo() > >> { > >> .... > >> if () > >> return EINVAL; > >> ... > >> if () > >> return EINVAL; > >> ... > >> if () > >> return EINVAL; > >> } > >> > >> which I replaced with > >> func_foo() > >> { > >> ... > >> if () > >> RETSDT(func_foo, EINVAL); > >> ... > >> if () > >> RETSDT(func_foo, EINVAL); > >> ... > >> if () > >> RETSDT(func_foo, EINVAL); > >> } > >> where RETSDT macro and other macros are defined as > >> > >> #define PROBENAME1(func, __LINE__) func ## __LINE__ > >> #define PROBENAME(func, line) PROBENAME1(func, line) > >> > >> #define RETSDT(func, error_code) \ > >> do { \ > >> DTRACE_PROBE(PROBENAME(func, __LINE__));\ > >> return (error_code); \ > >> } while (0) > >> > >> With the fake provider I defined I get to see and execute my SDT probes > >> % dtrace -l | grep func_foo > >> 56455 sdt netstack func_foo1592 > >> > >> Here netstack is my module, and I have a probe name based on __LINE__ > >> which is 1592. > > > > Why not just use a single probe and make the line number and function > > name arguments to the probe? That is, write something like > > > > #define RETSDT(error_code) do { \ > > DTRACE_PROBE2(error__return, __func__, __LINE__) > > return (error_code); > > } while (0) > > > Mark, for some reason using a single probe does not seem to fire the probe. I'm doing something similar in my code: cryptodev.c:SDT_PROBE_DEFINE1(opencrypto, dev, ioctl, error, "int"/*line number*/); cryptodev.c: SDT_PROBE1(opencrypto, dev, ioctl, error, __LINE__); and it worked for me... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 19:11:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DF28BCE for ; Thu, 4 Sep 2014 19:11:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61DA91939 for ; Thu, 4 Sep 2014 19:11:42 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E9FDB97E; Thu, 4 Sep 2014 15:11:41 -0400 (EDT) From: John Baldwin To: "Sinha, Prokash" Subject: Re: PXE boot Date: Thu, 04 Sep 2014 13:53:13 -0400 Message-ID: <2303890.kxxKhV23z4@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 15:11:41 -0400 (EDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 19:11:42 -0000 On Thursday, September 04, 2014 04:33:46 PM Sinha, Prokash wrote: > On 9/4/14 9:31 AM, "Sinha, Prokash" wrote: > >Thanks once again... > > > >This is the part - that you spelled out is why I had a trace in the > >pxe_enable(...) routine. As well as at pxe_init( ...) routine, just = to be > >sure > >the pxe.c routines are working like ( as you said ) devsw invocation= . But > >did not see the trace messages, could be serial console is not actin= g ( > >though I doubt it). > > > >Now gave me a base, off of what I could debug ... Hmm, the console should be working (cons_probe() is called before=20 pxe_enable()). However, if you are using 'console=3Dcomconsole' in loa= der.conf=20 to set a serial console, you won't see early messages because loader.co= nf is=20 processed after main() calls interact() at the bottom of the function. = If you=20 want to see early loader messages on serial, you will need to build pxe= boot=20 with BOOT_PXELDR_ALWAYS_SERIAL defined as a make variable (so on the co= mmand=20 line, or in /etc/make.conf or /etc/src.conf). That will force a serial= =20 console for early loader messages. > > > >-prokash > > > >On 9/4/14 7:57 AM, "John Baldwin" wrote: > >>On Wednesday, September 03, 2014 11:16:05 PM Sinha, Prokash wrote: > >>> Thanks much, John ! > >>>=20 > >>> When it starts executing ? How ?. Who starts executing these. Fro= m the > >>> Makefile it's org is 0x7c00. So I would assume that it would be l= oaded > >>> > >>>at > >>> > >>> that absolute real-mode address !. I don't understand this part. = But, > >>> > >>>if I > >>> > >>> put traces, I see pxe_open, and pxe_close are being called, but a= fter > >>> > >>>all > >>> > >>> these pxe_calls are done, the loader's main is invoked at Rebooti= ng =C5=A0 > >>> > >>>time. > >>> > >>> We are using a net boot server, and I see mountd- authenticated =C5= =A0 > >>> > >>>message > >>> > >>> storm on the boot server side. > >>>=20 > >>> Wondering what could cause such a message storm, while pxe_open()= -> > >>> > >>>net > >>> > >>> if_open( ) executes. > >> > >>The PXE BIOS uses TFTP to fetch the pxeboot binary (and it will do = its > >>own > >>DHCP, etc. as part of doing that). It writes the binary it downloa= ds > >>starting > >>at address 0x7c00. Once the download is complete, it jumps to 0x7c= 00 > >>similar > >>to how booting from a disk loads the first sector at address 0x7c00= and > >>then > >>jumps to it. > >> > >>The PXE calls in libi386 should not be invoked until the loader mai= n() > >>routine > >> > >>runs: > >> /* > >> =20 > >> * Special handling for PXE and CD booting. > >> */ > >> =20 > >> if (kargs->bootinfo =3D=3D 0) { > >>=09 > >>=09/* > >>=09 > >>=09 * We only want the PXE disk to try to init itself in the below > >>=09 * walk through devsw if we actually booted off of PXE. > >>=09 */ > >>=09 > >>=09if (kargs->bootflags & KARGS_FLAGS_PXE) > >>=09 > >>=09 pxe_enable(kargs->pxeinfo ? PTOV(kargs->pxeinfo) : NULL); > >>=09 > >>=09else if (kargs->bootflags & KARGS_FLAGS_CD) > >>=09 > >>=09 bc_add(initial_bootdev); > >> =20 > >> } > >> > >>That enables the PXE devsw driver so that it will do something late= r when > >> > >>main() calls all the devsw init routines: > >> /* > >> =20 > >> * March through the device switch probing for things. > >> */ > >> =20 > >> for (i =3D 0; devsw[i] !=3D NULL; i++) > >>=09 > >>=09if (devsw[i]->dv_init !=3D NULL) > >>=09 > >>=09 (devsw[i]->dv_init)(); > >> =20 > >> printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024= , > >> > >>bios_extmem / 1024); --=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 19:53:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A5C5F95; Thu, 4 Sep 2014 19:53:51 +0000 (UTC) Received: from message.langara.bc.ca (message.mylangara.bc.ca [142.35.159.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0941D94; Thu, 4 Sep 2014 19:53:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from langara.bc.ca ([127.0.0.1]) by message.langara.bc.ca (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTP id <0NBE008XD79KJ3G0@message.langara.bc.ca>; Thu, 04 Sep 2014 12:53:44 -0700 (PDT) Received: from [38.108.87.20] by message.langara.bc.ca (mshttpd); Thu, 04 Sep 2014 19:53:44 +0000 (GMT) From: Steven Stewart-Gallus To: Benjamin Kaduk Message-id: Date: Thu, 04 Sep 2014 19:53:44 +0000 (GMT) X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-language: en Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? X-Accept-Language: en Priority: normal In-reply-to: References: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 19:53:51 -0000 > I don't have any particular objection to such a thing existing, but > I wonder whether the developer time to create it could be better > used on other things. I guess it comes down to what value it is > seen as providing. I'm not suggesting anybody else create this stuff. I plan to work on patches for some of this stuff myself. Eg) .\" Copyright (c) 2014 .\" The Regents of the University of California. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" @(#)unimplemented.2 8.2 (Berkeley) 1/09/14 .\" $FreeBSD$ .\" .Dd September 1, 2014 .Dt UNIMPLEMENTED 2 .Os .Sh NAME .Nm nnpfs_syscall, afs3_syscall .Nd unimplemented system calls .Sh SYNOPSIS Unimplemented system calls. .Sh DESCRIPTION These system calls are not implemented in the standard FreeBSD kernel and are reserved for the use of third parties. .Sh RETURN VALUES These calls return \-1 and set errno to ENOSYS. I've also already started work on an nlm_syscall man page but I'm starting to think that if symlinks are supported it should just symlink to rpc.lockd.8. Also if symlinks in the doc system are supported then I can just symlink nnpfs_syscall.2 and afs3_syscall to unimplemented.2. I'm not sure if I want to wait until I've documented umtx_syscall or just submit the patch ealier. Thank you, Steven Stewart-Gallus From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 21:23:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 381239F; Thu, 4 Sep 2014 21:23:23 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id D1E6C18B2; Thu, 4 Sep 2014 21:23:22 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 4 Sep 2014 17:23:20 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Thu, 4 Sep 2014 14:23:20 -0700 From: "Sinha, Prokash" To: John Baldwin Subject: Re: PXE boot Thread-Topic: PXE boot Thread-Index: AQHPx7q2tjxfRdxxqUWbg0sIKzb+LpvwCpsAgAF8gAD//6TLgIAAAKKAgACLjID//8T9AIAAAF0A Date: Thu, 4 Sep 2014 21:23:19 +0000 Message-ID: References: <2303890.kxxKhV23z4@ralph.baldwin.cx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.133.204] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2630458C4A10414690BA3729DB6F27C2@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Sep 2014 21:23:20.0804 (UTC) FILETIME=[739F8240:01CFC886] Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 21:23:23 -0000 On 9/4/14 2:22 PM, "Sinha, Prokash" wrote: >Yeah, something going on that I don't understand. I defined that macro, >and for quick verify - >make -v=20 >Warning: Object directory not changed from original >/.automount/nfs.paneast.panasas.com/root/home/psinha/psinha-bug-pa/src/fre >e >bsd-c/sys/boot/i386/pxeldr >cc -O2 -fno-strict-aliasing -pipe -ffreestanding >-mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >-mno-sse3 -m32 -march=3Di386 -DALWAYS_SERIAL -c pxeldr.S >cc -O2 -fno-strict-aliasing -pipe -ffreestanding >-mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >-mno-sse3 -m32 -march=3Di386 -DALWAYS_SERIAL -nostdlib -m elf_i386_fbsd = -N >-e start -Ttext 0x7c00 -Wl,-S,--oformat,binary -o pxeldr pxeldr.o >make: don't know how to make pxeboot.8. Stop > >=3D=3D> The variable is defined and the correct flag is included in the cc= ... > > >But I still don't get the messages from pxe_enable or pxe_init... > >Need to sit back and look further... > >John, much appreciated for the help... > >If anything else you can think of, please drop couple lines for me to >investigate... >-prokash > >On 9/4/14 10:53 AM, "John Baldwin" wrote: > >>On Thursday, September 04, 2014 04:33:46 PM Sinha, Prokash wrote: >>> On 9/4/14 9:31 AM, "Sinha, Prokash" wrote: >>> >Thanks once again... >>> > >>> >This is the part - that you spelled out is why I had a trace in the >>> >pxe_enable(...) routine. As well as at pxe_init( ...) routine, just to >>>be >>> >sure >>> >the pxe.c routines are working like ( as you said ) devsw invocation. >>>But >>> >did not see the trace messages, could be serial console is not acting >>>( >>> >though I doubt it). >>> > >>> >Now gave me a base, off of what I could debug ... >> >>Hmm, the console should be working (cons_probe() is called before >>pxe_enable()). However, if you are using 'console=3Dcomconsole' in >>loader.conf=20 >>to set a serial console, you won't see early messages because loader.conf >>is=20 >>processed after main() calls interact() at the bottom of the function. >>If you=20 >>want to see early loader messages on serial, you will need to build >>pxeboot=20 >>with BOOT_PXELDR_ALWAYS_SERIAL defined as a make variable (so on the >>command=20 >>line, or in /etc/make.conf or /etc/src.conf). That will force a serial >>console for early loader messages. >> >>> > >>> >-prokash >>> > >>> >On 9/4/14 7:57 AM, "John Baldwin" wrote: >>> >>On Wednesday, September 03, 2014 11:16:05 PM Sinha, Prokash wrote: >>> >>> Thanks much, John ! >>> >>>=20 >>> >>> When it starts executing ? How ?. Who starts executing these. From >>>the >>> >>> Makefile it's org is 0x7c00. So I would assume that it would be >>>loaded >>> >>> >>> >>>at >>> >>> >>> >>> that absolute real-mode address !. I don't understand this part. >>>But, >>> >>> >>> >>>if I >>> >>> >>> >>> put traces, I see pxe_open, and pxe_close are being called, but >>>after >>> >>> >>> >>>all >>> >>> >>> >>> these pxe_calls are done, the loader's main is invoked at Rebooting >>>=A9 >>> >>> >>> >>>time. >>> >>> >>> >>> We are using a net boot server, and I see mountd- authenticated =A9 >>> >>> >>> >>>message >>> >>> >>> >>> storm on the boot server side. >>> >>>=20 >>> >>> Wondering what could cause such a message storm, while pxe_open() >>>-> >>> >>> >>> >>>net >>> >>> >>> >>> if_open( ) executes. >>> >> >>> >>The PXE BIOS uses TFTP to fetch the pxeboot binary (and it will do >>>its >>> >>own >>> >>DHCP, etc. as part of doing that). It writes the binary it downloads >>> >>starting >>> >>at address 0x7c00. Once the download is complete, it jumps to 0x7c00 >>> >>similar >>> >>to how booting from a disk loads the first sector at address 0x7c00 >>>and >>> >>then >>> >>jumps to it. >>> >> >>> >>The PXE calls in libi386 should not be invoked until the loader >>>main() >>> >>routine >>> >> >>> >>runs: >>> >> /* >>> >> =20 >>> >> * Special handling for PXE and CD booting. >>> >> */ >>> >> =20 >>> >> if (kargs->bootinfo =3D=3D 0) { >>> >>=09 >>> >> /* >>> >>=09 >>> >> * We only want the PXE disk to try to init itself in the below >>> >> * walk through devsw if we actually booted off of PXE. >>> >> */ >>> >>=09 >>> >> if (kargs->bootflags & KARGS_FLAGS_PXE) >>> >>=09 >>> >> pxe_enable(kargs->pxeinfo ? PTOV(kargs->pxeinfo) : NULL); >>> >>=09 >>> >> else if (kargs->bootflags & KARGS_FLAGS_CD) >>> >>=09 >>> >> bc_add(initial_bootdev); >>> >> =20 >>> >> } >>> >> >>> >>That enables the PXE devsw driver so that it will do something later >>>when >>> >> >>> >>main() calls all the devsw init routines: >>> >> /* >>> >> =20 >>> >> * March through the device switch probing for things. >>> >> */ >>> >> =20 >>> >> for (i =3D 0; devsw[i] !=3D NULL; i++) >>> >>=09 >>> >> if (devsw[i]->dv_init !=3D NULL) >>> >>=09 >>> >> (devsw[i]->dv_init)(); >>> >> =20 >>> >> printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024, >>> >> >>> >>bios_extmem / 1024); >> >>--=20 >>John Baldwin > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 22:50:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F092FB2F for ; Thu, 4 Sep 2014 22:50:36 +0000 (UTC) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 919C31213 for ; Thu, 4 Sep 2014 22:50:36 +0000 (UTC) X-AuditID: 12074422-f79436d000000c21-7d-5408eb89ee9f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id D3.39.03105.98BE8045; Thu, 4 Sep 2014 18:45:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s84MjS8o027020; Thu, 4 Sep 2014 18:45:29 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s84MjQMe008877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Sep 2014 18:45:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s84MjQdt010307; Thu, 4 Sep 2014 18:45:26 -0400 (EDT) Date: Thu, 4 Sep 2014 18:45:26 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Steven Stewart-Gallus Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT0e18zRFicGiPoMX2zf8YLWZ+nsfu wOQx49N8Fo+T/96yBDBFcdmkpOZklqUW6dslcGWsWXqVueCzeMW7junMDYyThbsYOTkkBEwk Fl37wgJhi0lcuLeerYuRi0NIYDaTxN/bCxhBEkICGxgl7ncxQ9gHmSR+fPeCsOslTje3gsVZ BLQktn89zgpiswmoSTze28wKMVRRYvOpSWA1IgI2Ev/aZrCB2MwC8hIXNh8Cmy8sEC6xaecq sCM4BQwljh1bCFbDK+Ao8XPHDKgbMiW+rV3NBGKLCuhIrN4/hQWiRlDi5MwnLBAztSSWT9/G MoFRaBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfVyM0v0UlNKNzGCw9dFaQfj z4NKhxgFOBiVeHhPvGIPEWJNLCuuzD3EKMnBpCTKu/4FR4gQX1J+SmVGYnFGfFFpTmrxIUYJ DmYlEd4Pd4FyvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJXsdXQI2C RanpqRVpmTklCGkmDk6Q4TxAw6NAaniLCxJzizPTIfKnGHU51nV+62cSYsnLz0uVEued8xKo SACkKKM0D24OLO28YhQHekuYtxxkFA8wZcFNegW0hAloiVsOK8iSkkSElFQD44KAWZHR51Xf Zbzu+7P1uNaMzWu82ENziiKVK9Yvk9c8nxB3avHRcA5ld8Wq+IWv56uecyh/pPgip2bhBoGE +2f2L7yWavXk16rN7n8tTY6VVqmZmZr6vmY8kBl3ieXh24mrW99csrv9u2tRXPLl86uWrEt5 s6BH4QOPpd+rjD1Rwm9YuZ3+CimxFGckGmoxFxUnAgC8fPwLFgMAAA== Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:50:37 -0000 On Thu, 4 Sep 2014, Steven Stewart-Gallus wrote: > Eg) > > .\" Copyright (c) 2014 > .\" The Regents of the University of California. All rights reserved. I suggest that you retain the copyright on your own works and not assign it to the Regents :) > .\" Redistribution and use in source and binary forms, with or without > .\" modification, are permitted provided that the following conditions > .\" are met: > .\" 1. Redistributions of source code must retain the above copyright > .\" notice, this list of conditions and the following disclaimer. > .\" 2. Redistributions in binary form must reproduce the above copyright > .\" notice, this list of conditions and the following disclaimer in the > .\" documentation and/or other materials provided with the distribution. > .\" 4. Neither the name of the University nor the names of its contributors > .\" may be used to endorse or promote products derived from this software > .\" without specific prior written permission. Also, we are trying to move to the two-clause license as much as possible. > .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND > .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE > .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > .\" SUCH DAMAGE. > .\" > .\" @(#)unimplemented.2 8.2 (Berkeley) 1/09/14 > .\" $FreeBSD$ > .\" > .Dd September 1, 2014 > .Dt UNIMPLEMENTED 2 > .Os > .Sh NAME > .Nm nnpfs_syscall, afs3_syscall > .Nd unimplemented system calls > .Sh SYNOPSIS > Unimplemented system calls. > .Sh DESCRIPTION > These system calls are not implemented in the standard FreeBSD kernel > and are reserved for the use of third parties. I might say what organization requested them; I believe that that information is included in the commit logs when they were added. > .Sh RETURN VALUES > These calls return \-1 and set errno to ENOSYS. > > I've also already started work on an nlm_syscall man page but I'm > starting to think that if symlinks are supported it should just > symlink to rpc.lockd.8. Also if symlinks in the doc system are > supported then I can just symlink nnpfs_syscall.2 and afs3_syscall to > unimplemented.2. I'm not sure if I want to wait until I've documented > umtx_syscall or just submit the patch ealier. The MLINKS variable in the corresponding Makefile will do the linking (they are hardlinks actually, not symlinks). -Ben From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 00:38:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E42D146 for ; Fri, 5 Sep 2014 00:38:16 +0000 (UTC) Received: from out144-ams.mf.surf.net (out144-ams.mf.surf.net [145.0.1.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B07971C88 for ; Fri, 5 Sep 2014 00:38:15 +0000 (UTC) Received: from out43-ams.mf.surf.net (out43-ams.mf.surf.net [145.0.1.43]) by fbout1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s850US9o018047 for ; Fri, 5 Sep 2014 02:30:28 +0200 Received: from smtps.utwente.nl (smtp-o1.utsp.utwente.nl [130.89.2.9]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s850UJIN029187 for ; Fri, 5 Sep 2014 02:30:19 +0200 Received: from [130.89.165.91] (nox.student.utwente.nl [130.89.165.91]) by smtps.utwente.nl (8.13.8) with ESMTP id s850UJWb028900 for ; Fri, 5 Sep 2014 02:30:19 +0200 Message-ID: <540903FF.6010602@degoeje.nl> Date: Fri, 05 Sep 2014 02:29:51 +0200 From: Pieter de Goeje User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: mmap MAP_NOSYNC regression in 10.x Content-Type: multipart/mixed; boundary="------------000800040209070700030907" X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-Spam-Score: -0.50 () [Tag at 5.00] 2450(0),CC(NL:-0.5) X-CanIt-Geo: ip=130.89.2.9; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMLcuj0C - b95822e8545d - 20140905 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 00:38:16 -0000 This is a multi-part message in MIME format. --------------000800040209070700030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit After upgrading my month old 10-stable installation today (to r271093) , I've noticed a that the kernel no longer honors the MAP_NOSYNC flag. Attached is a demonstration program that highlights the issue (also available here: http://pastebin.com/y0kvdn0r ). The program creates and mmap()s a 200MiB file and repeatedly writes zeros to it. The expected behavior is that under normal circumstances (no memory pressure), the dirtied pages are not flushed to disk. Observed is however that every ~30 seconds the syncer kicks in and basically halts the program while it does its job. The program prints a line everytime the throughput drops below 500MBps, well below memory bandwidth. mmap() is called like this: void *p = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0); Sample output: write... zeroing: 209.6 MB ...write: 5.839s mmap... ...mmap: 0.000s 20.1s: memset #259: 34.7MBps - stalled 55.7s: memset #810: 34.7MBps - stalled 91.3s: memset #1359: 34.6MBps - stalled 100.0s: memset #1522: 3938.5MBps overall bandwidth: 3190.6MBps munmap... ...munmap: 5.796s done (this is a rather old system) If necessary I'm willing to find out the exact commit that caused the problem. - Pieter --------------000800040209070700030907 Content-Type: text/plain; charset=windows-1252; name="mmap_test.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mmap_test.c" #include #include #include #include #include #include #include #include #define CLEAREOL "\e[0K" #define CLOCK_START(a) double _clk_##a = now(); printf("%s... \n", #a) #define CLOCK_STOP(a) printf(" ...%s: %.3fs\n", #a, now() - _clk_##a) static double now() { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); return ts.tv_sec + ts.tv_nsec * 1E-9; } int main() { setvbuf(stdout, NULL, _IONBF, 0); int fd = open("backing-file", O_RDWR | O_CREAT | O_TRUNC, 0666); if(fd == -1) err(1, "open"); size_t len = 200 * 1024 * 1024; size_t blen = 128 * 1024; CLOCK_START(write); char *buf = calloc(1, blen); for(size_t i = 0; i < len; i += blen) { printf("\rzeroing: %.1f MB" CLEAREOL, i * 1E-6); if(write(fd, buf, blen) != blen) err(1, "write\n"); } free(buf); printf("\n"); CLOCK_STOP(write); CLOCK_START(mmap); void *p = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0); if(p == MAP_FAILED) err(1, "mmap"); CLOCK_STOP(mmap); if(close(fd) == -1) err(1, "close"); double start, stop, last; stop = start = now(); int n = 0; do { memset(p, 0, len); last = stop; stop = now(); double bw = 1E-6 * len / (stop - last); printf("\r%.1fs: memset #%d: %.1fMBps" CLEAREOL, stop - start, ++n, bw); if(bw < 500.0) printf(" - stalled\n"); } while(stop - start < 100.0); printf("\noverall bandwidth: %.1fMBps\n", n * (double)len / (stop - start) * 1E-6); CLOCK_START(munmap); if(munmap(p, len) == -1) err(1, "munmap"); CLOCK_STOP(munmap); printf("done\n"); return 0; } --------------000800040209070700030907-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 01:20:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6683EA2F; Fri, 5 Sep 2014 01:20:36 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0325B1FF6; Fri, 5 Sep 2014 01:20:35 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s851KXQA029331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Sep 2014 18:20:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54090FDB.6090801@freebsd.org> Date: Thu, 04 Sep 2014 18:20:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? References: <2041449.H6lUHcsTDl@ralph.baldwin.cx> In-Reply-To: <2041449.H6lUHcsTDl@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Benjamin Kaduk , kib@freebsd.org, Steven Stewart-Gallus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 01:20:36 -0000 On 9/4/14, 7:06 AM, John Baldwin wrote: > On Wednesday, September 03, 2014 05:30:01 PM Benjamin Kaduk wrote: >> On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: >>>> svn blame says that the whole implementation dates from r1541. >>>> Looks like >>>> it was never implemented. Some googling indicates that it was a >>>> plannedroutine to set the stack size, which was never implemented, >>>> anywhere. >>>> >>>> The locking comments were added in r79224, but the implementation is >>>> otherwise from r1541, i.e., it was never implemented. >>> Alright, so sys/kern/syscalls.master can be patched somewhat like so >>> and I won't need to document them? >>> >>> -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ >>> - ovadvise_args int >>> +72 AUE_NULL OBSOL ovadvise >>> >>> -70 AUE_SSTK STD { int sstk(int incr); } >>> +70 AUE_SSTK OBSOL sstk >> I don't think so; I think that would be a regression. >> >> We do currently provide implementations for these syscalls, that just >> happen to always return failure. I think that the OBSOL annotation >> corresponds to a complete lack of implementation. Perhaps it would be >> acceptable at a major release boundary, but this is not my area of >> expertise. > For these two calls, I doubt anything is actually using them. They've been > stubs since the Mach VM was imported into BSD in 1990. We don't ship a system > call for creat() anymore either. In this particular case, I think it would be > more of a feature if those symbols disappeared from libc and caused link > errors. have we ever shipped code for creat? if we lose teh ability to run FreeBSD 1.1 chroots I'll be most upset.. it's a great selling point when pointing out our commitment to ABI stability and backwards portability. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 07:02:52 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E1F0CEC for ; Fri, 5 Sep 2014 07:02:52 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CC7C1465 for ; Fri, 5 Sep 2014 07:02:52 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id rl12so12811058iec.25 for ; Fri, 05 Sep 2014 00:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UlHE8pbxzzoNi3bVt3VCf2wxZ1qpAzevT86lapvsVq0=; b=uP+q7LnjEV80sLMTNmVsP7UrKpG8T7skU0lPTh10AU0F2mtVQ48L5OihMT624GRTX6 PC4dqvCoG1MYVpn9YVbUjJh/y/3zUSGMBCQCCtDoFI4l6/5Al2GcB5b1Ol6JF+857EZ0 jEKX7/eVH9pmwrKRw74idbME1wN9FjseJYqeV1bBjCD7r/7rfIq1j2eIT4n2s60UJhQz TZsiagp3/GgB5C6ibFRccJhdDkxIzpjJ9/wH46C0lw+1zT3BqEuRTm51XVRRrOASvg/s bjWjh45BsKuJyemwSciHrooJdv4W/VGkRh1ODYCLkNx4KySpnnDyawKK0/3eKYFrMu4L Yv6A== MIME-Version: 1.0 X-Received: by 10.42.137.194 with SMTP id z2mr36971ict.85.1409900571625; Fri, 05 Sep 2014 00:02:51 -0700 (PDT) Received: by 10.43.178.200 with HTTP; Fri, 5 Sep 2014 00:02:51 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: <540903FF.6010602@degoeje.nl> References: <540903FF.6010602@degoeje.nl> Date: Fri, 5 Sep 2014 02:02:51 -0500 Message-ID: Subject: Re: mmap MAP_NOSYNC regression in 10.x From: Alan Cox To: Pieter de Goeje , Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 07:02:52 -0000 On Thu, Sep 4, 2014 at 7:29 PM, Pieter de Goeje wrote: > After upgrading my month old 10-stable installation today (to r271093) , > I've noticed a that the kernel no longer honors the MAP_NOSYNC flag. > Attached is a demonstration program that highlights the issue (also > available here: http://pastebin.com/y0kvdn0r ). > > The program creates and mmap()s a 200MiB file and repeatedly writes zeros > to it. The expected behavior is that under normal circumstances (no memory > pressure), the dirtied pages are not flushed to disk. Observed is however > that every ~30 seconds the syncer kicks in and basically halts the program > while it does its job. The program prints a line everytime the throughput > drops below 500MBps, well below memory bandwidth. > > mmap() is called like this: > > void *p = mmap(NULL, len, PROT_READ | PROT_WRITE, > MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0); > > Sample output: > > write... > zeroing: 209.6 MB > ...write: 5.839s > mmap... > ...mmap: 0.000s > 20.1s: memset #259: 34.7MBps - stalled > 55.7s: memset #810: 34.7MBps - stalled > 91.3s: memset #1359: 34.6MBps - stalled > 100.0s: memset #1522: 3938.5MBps > overall bandwidth: 3190.6MBps > munmap... > ...munmap: 5.796s > done > > (this is a rather old system) > > If necessary I'm willing to find out the exact commit that caused the > problem. > > That's not necessary. This is a bug in the page fault handler's new fast path. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 08:06:48 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC51CB19; Fri, 5 Sep 2014 08:06:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 658E81B48; Fri, 5 Sep 2014 08:06:48 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8586XgJ097346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 11:06:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8586XgJ097346 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8586X73097345; Fri, 5 Sep 2014 11:06:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Sep 2014 11:06:33 +0300 From: Konstantin Belousov To: Pieter de Goeje Subject: Re: mmap MAP_NOSYNC regression in 10.x Message-ID: <20140905080633.GM2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="izE3dcXa7Fnj97wq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: alc@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 08:06:49 -0000 --izE3dcXa7Fnj97wq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 05, 2014 at 02:02:51AM -0500, Alan Cox wrote: > On Thu, Sep 4, 2014 at 7:29 PM, Pieter de Goeje wrote: >=20 > > After upgrading my month old 10-stable installation today (to r271093) , > > I've noticed a that the kernel no longer honors the MAP_NOSYNC flag. > > Attached is a demonstration program that highlights the issue (also > > available here: http://pastebin.com/y0kvdn0r ). > > > > The program creates and mmap()s a 200MiB file and repeatedly writes zer= os > > to it. The expected behavior is that under normal circumstances (no mem= ory > > pressure), the dirtied pages are not flushed to disk. Observed is howev= er > > that every ~30 seconds the syncer kicks in and basically halts the prog= ram > > while it does its job. The program prints a line everytime the throughp= ut > > drops below 500MBps, well below memory bandwidth. > > > > mmap() is called like this: > > > > void *p =3D mmap(NULL, len, PROT_READ | PROT_WRITE, > > MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0); > > > > Sample output: > > > > write... > > zeroing: 209.6 MB > > ...write: 5.839s > > mmap... > > ...mmap: 0.000s > > 20.1s: memset #259: 34.7MBps - stalled > > 55.7s: memset #810: 34.7MBps - stalled > > 91.3s: memset #1359: 34.6MBps - stalled > > 100.0s: memset #1522: 3938.5MBps > > overall bandwidth: 3190.6MBps > > munmap... > > ...munmap: 5.796s > > done > > > > (this is a rather old system) > > > > If necessary I'm willing to find out the exact commit that caused the > > problem. > > > > >=20 > That's not necessary. This is a bug in the page fault handler's new fast > path. The following patch fixed the issue for me. diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 30b0456..803bf59 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -174,6 +174,49 @@ unlock_and_deallocate(struct faultstate *fs) } } =20 +static void +vm_fault_dirty(vm_map_entry_t entry, vm_page_t m, vm_prot_t prot, + vm_prot_t fault_type, int fault_flags, boolean_t set_wd) +{ + + if (((prot & VM_PROT_WRITE) !=3D 0 || + (fault_flags & VM_FAULT_DIRTY) !=3D 0) && + (m->oflags & VPO_UNMANAGED) =3D=3D 0) { + if (set_wd) + vm_object_set_writeable_dirty(m->object); + + /* + * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC + * if the page is already dirty to prevent data written with + * the expectation of being synced from not being synced. + * Likewise if this entry does not request NOSYNC then make + * sure the page isn't marked NOSYNC. Applications sharing + * data should use the same flags to avoid ping ponging. + */ + if (entry->eflags & MAP_ENTRY_NOSYNC) { + if (m->dirty =3D=3D 0) + m->oflags |=3D VPO_NOSYNC; + } else { + m->oflags &=3D ~VPO_NOSYNC; + } + + /* + * If the fault is a write, we know that this page is being + * written NOW so dirty it explicitly to save on=20 + * pmap_is_modified() calls later. + * + * Also tell the backing pager, if any, that it should remove + * any swap backing since the page is now dirty. + */ + if (((fault_type & VM_PROT_WRITE) !=3D 0 && + (fault_flags & VM_FAULT_CHANGE_WIRING) =3D=3D 0) || + (fault_flags & VM_FAULT_DIRTY) !=3D 0) { + vm_page_dirty(m); + vm_pager_page_unswapped(m); + } + } +} + /* * TRYPAGER - used by vm_fault to calculate whether the pager for the * current object *might* contain the page. @@ -321,11 +364,8 @@ RetryFault:; vm_page_hold(m); vm_page_unlock(m); } - if ((fault_type & VM_PROT_WRITE) !=3D 0 && - (m->oflags & VPO_UNMANAGED) =3D=3D 0) { - vm_page_dirty(m); - vm_pager_page_unswapped(m); - } + vm_fault_dirty(fs.entry, m, prot, fault_type, fault_flags, + FALSE); VM_OBJECT_RUNLOCK(fs.first_object); if (!wired) vm_fault_prefault(&fs, vaddr, 0, 0); @@ -898,42 +938,7 @@ vnode_locked: if (hardfault) fs.entry->next_read =3D fs.pindex + faultcount - reqpage; =20 - if (((prot & VM_PROT_WRITE) !=3D 0 || - (fault_flags & VM_FAULT_DIRTY) !=3D 0) && - (fs.m->oflags & VPO_UNMANAGED) =3D=3D 0) { - vm_object_set_writeable_dirty(fs.object); - - /* - * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC - * if the page is already dirty to prevent data written with - * the expectation of being synced from not being synced. - * Likewise if this entry does not request NOSYNC then make - * sure the page isn't marked NOSYNC. Applications sharing - * data should use the same flags to avoid ping ponging. - */ - if (fs.entry->eflags & MAP_ENTRY_NOSYNC) { - if (fs.m->dirty =3D=3D 0) - fs.m->oflags |=3D VPO_NOSYNC; - } else { - fs.m->oflags &=3D ~VPO_NOSYNC; - } - - /* - * If the fault is a write, we know that this page is being - * written NOW so dirty it explicitly to save on=20 - * pmap_is_modified() calls later. - * - * Also tell the backing pager, if any, that it should remove - * any swap backing since the page is now dirty. - */ - if (((fault_type & VM_PROT_WRITE) !=3D 0 && - (fault_flags & VM_FAULT_CHANGE_WIRING) =3D=3D 0) || - (fault_flags & VM_FAULT_DIRTY) !=3D 0) { - vm_page_dirty(fs.m); - vm_pager_page_unswapped(fs.m); - } - } - + vm_fault_dirty(fs.entry, fs.m, prot, fault_type, fault_flags, TRUE); vm_page_assert_xbusied(fs.m); =20 /* --izE3dcXa7Fnj97wq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCW8IAAoJEJDCuSvBvK1BrvQP/1Ih/f1BTIOdqJbVuRPXCjTh DyKJfbWtnPrcwY7PBIEO74ILYYt5wWIhaI7W5pw6aLvY/r2z5LMR/+IKC4nqEXEm heu/N2mUPAzBInrUoTm/tk4JYSBU0OwyGxnKgIAnjtKDRlDs9pYeMqnTXVO10QJv LrpJnhdQt8oLS7FHasuuKzSEop61z8bGXJFklwQ9dSGLimqNHqkTY4QUdVMeHbvY nvjzbptpXKzQ83j7ZCGddvw1AT3QW243zybrhjKZzt+T0j+7WM7WZoaC3kxO21q5 /BmSwIXICyVmmKdahLTLwFTKZ4+mThFFvIEK4g3ruWnQfzXao9RoX4Pmnhau097p d3iqQkfea691VioTmFiBChnzWkPIcftF6nuX4SxVIwi+ksdPzq7f+8d90nvwMgbP VnD9gnuX/f9k7zSJJsfQOCO7orJaT2IlKLtkFvuP4fn/KfxyO8Q4JjuukDpvQwoR F5e4m3r0ReaL2RzxO9H7hBe+1jIg7Wbny0zToxDLn6jP6Wrn8FgtQc9px5GMluhl /vZoX0WcGAX0tw5SCxmXLEVCbiN0i1EEfRuLikuC43DUqVfqIXFsysc2WPY0COT4 mNA5adnAY3rAQ9kyQs2LxTX9Ybg+0x31bldJznF2rJNuXTne+1NCFyGUfDAewc2+ 64WiqA1qaZ7kLkUactjO =oeR7 -----END PGP SIGNATURE----- --izE3dcXa7Fnj97wq-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 12:13:03 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 689F2F8; Fri, 5 Sep 2014 12:13:03 +0000 (UTC) Received: from out142-ams.mf.surf.net (out142-ams.mf.surf.net [145.0.1.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB751C8D; Fri, 5 Sep 2014 12:13:01 +0000 (UTC) Received: from out64-ams.mf.surf.net (out64-ams.mf.surf.net [145.0.1.64]) by fbout1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s85BuxFb028533; Fri, 5 Sep 2014 13:56:59 +0200 Received: from smtps.utwente.nl (smtp-o2.utsp.utwente.nl [130.89.2.10]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s85Bxxa5017491; Fri, 5 Sep 2014 13:59:59 +0200 Received: from [130.89.165.91] (nox.student.utwente.nl [130.89.165.91]) by smtps.utwente.nl (8.13.8) with ESMTP id s85BumbW022146; Fri, 5 Sep 2014 13:56:50 +0200 Message-ID: <5409A4F8.6020204@degoeje.nl> Date: Fri, 05 Sep 2014 13:56:40 +0200 From: Pieter de Goeje User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: mmap MAP_NOSYNC regression in 10.x References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> In-Reply-To: <20140905080633.GM2737@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-Spam-Score: -0.50 () [Tag at 5.00] 2450(0),CC(NL:-0.5) X-CanIt-Geo: ip=130.89.2.10; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMLnXX7A - f2747e0abf2a - 20140905 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: alc@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:13:03 -0000 Konstantin Belousov schreef op 5-9-2014 10:06: > On Fri, Sep 05, 2014 at 02:02:51AM -0500, Alan Cox wrote: >> On Thu, Sep 4, 2014 at 7:29 PM, Pieter de Goeje wrote: >> >>> After upgrading my month old 10-stable installation today (to r271093) , >>> I've noticed a that the kernel no longer honors the MAP_NOSYNC flag. >>> Attached is a demonstration program that highlights the issue (also >>> available here: http://pastebin.com/y0kvdn0r ). >>> >>> The program creates and mmap()s a 200MiB file and repeatedly writes zeros >>> to it. The expected behavior is that under normal circumstances (no memory >>> pressure), the dirtied pages are not flushed to disk. Observed is however >>> that every ~30 seconds the syncer kicks in and basically halts the program >>> while it does its job. The program prints a line everytime the throughput >>> drops below 500MBps, well below memory bandwidth. >>> >>> mmap() is called like this: >>> >>> void *p = mmap(NULL, len, PROT_READ | PROT_WRITE, >>> MAP_SHARED | MAP_NOSYNC | MAP_ALIGNED_SUPER, fd, 0); >>> >>> Sample output: >>> >>> write... >>> zeroing: 209.6 MB >>> ...write: 5.839s >>> mmap... >>> ...mmap: 0.000s >>> 20.1s: memset #259: 34.7MBps - stalled >>> 55.7s: memset #810: 34.7MBps - stalled >>> 91.3s: memset #1359: 34.6MBps - stalled >>> 100.0s: memset #1522: 3938.5MBps >>> overall bandwidth: 3190.6MBps >>> munmap... >>> ...munmap: 5.796s >>> done >>> >>> (this is a rather old system) >>> >>> If necessary I'm willing to find out the exact commit that caused the >>> problem. >>> >>> >> That's not necessary. This is a bug in the page fault handler's new fast >> path. > The following patch fixed the issue for me. Thanks, works for me! - Pieter From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 12:31:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DEC536C; Fri, 5 Sep 2014 12:31:27 +0000 (UTC) Received: from tinker.exit.com (unknown [IPv6:2001:470:f0fd:0:2e0:81ff:fe2b:acbc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C57F1E42; Fri, 5 Sep 2014 12:31:26 +0000 (UTC) Received: from jill.exit.com (jill.exit.com [IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by tinker.exit.com (8.14.7/8.14.7) with ESMTP id s85CUxiK025680; Fri, 5 Sep 2014 05:30:59 -0700 (PDT) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1409920259; bh=JNOcOsS4v/oTsXiu6VhFsw2KGDbKrhg7rKFhook6Uco=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Date; b=DtL1i5FgxmP8yFYLhfdtrXkcItDoiMc+iFkX20xIIzicEoludpAUbrH8HuWlQzzdk qK2Sh1809csxxSRoo096I1NTokWQYjZ08gKHv+7mzLLtqk6YeJ4PL/SznVeISzsJvm uJ1VVmX0PgcGAaW24fGPZ+dy0m4iPdGzAnabbySo= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.7/8.14.5) with ESMTP id s85CaEdC019449; Fri, 5 Sep 2014 05:36:14 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.7/8.14.5/Submit) id s85CaEFE019448; Fri, 5 Sep 2014 05:36:14 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f Subject: Re: The use of C language is avoided in FreeBSD development? From: Frank Mayhar Reply-To: frank@exit.com To: Glen Barber In-Reply-To: <20140904150154.GM36287@hub.FreeBSD.org> References: <7538A48E-6DDA-4820-B11C-2AFDA9175DA7@gmail.com> <20140904150154.GM36287@hub.FreeBSD.org> Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: Organization: Exit Consulting Date: Fri, 05 Sep 2014 05:36:13 -0700 Message-ID: <1409920573.16879.12.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:31:27 -0000 On Thu, 2014-09-04 at 11:01 -0400, Glen Barber wrote: > On Thu, Sep 04, 2014 at 08:56:09AM -0600, Warner Losh wrote: > > > > On Aug 12, 2014, at 12:07 PM, franai s wrote: > > > > > The use of C language is avoided in FreeBSD development? > > > > Hello? Yes, this is 1993 calling. Yes, I$B!G(Bm comp.os.unix, I can hold$B!D(B. > > > > Ah, you$B!G(Bre back. Thanks for taking my call. I$B!G(Bm looking for one of my > > trolls. He seems to have mysteriously vanished and I was wondering > > if you$B!G(Bd seen him$B!D(B He keeps posting flame bate about how out-dated > > C is and how other things are better$B!D(B Been doing it for 10 years as > > far as I can tell. > > > > Can you help me? > > > > We're sorry, all representatives are currently assisting other clients. > Please hold, and your call will be answered in the order in which it was > received. Sorry, Glen, but no. "We're sorry, all representatives are currently ignoring other clients. Please hold, and your call will be ignored in the order in which it was received." (On-hold muzak.) Ten minutes later... "We're sorry, all representatives are currently ignoring other clients. Please hold, and your call will be ignored in the order in which it was received." (On-hold muzak.) Ten minutes later... (You get the idea.) :-) -- Frank Mayhar frank@exit.com From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 12:38:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E885591; Fri, 5 Sep 2014 12:38:39 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 079D61E83; Fri, 5 Sep 2014 12:38:38 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s85CcQBN086373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 15:38:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s85CcQBN086373 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s85CcQ8C086372; Fri, 5 Sep 2014 15:38:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Sep 2014 15:38:26 +0300 From: Konstantin Belousov To: Pieter de Goeje Subject: Re: mmap MAP_NOSYNC regression in 10.x Message-ID: <20140905123826.GP2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> <5409A4F8.6020204@degoeje.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W2+iMEDMST8vYcDN" Content-Disposition: inline In-Reply-To: <5409A4F8.6020204@degoeje.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: alc@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 12:38:39 -0000 --W2+iMEDMST8vYcDN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 05, 2014 at 01:56:40PM +0200, Pieter de Goeje wrote: > Thanks, works for me! I realized that the patch contains yet another bug. The oflags page flags update is protected by the exclusive vm object lock, which is only held in shared mode on the fast path. Below is the fixed patch, where I take the page lock around setting VPO_NOSYNC (exclusive lock owners cannot race with fast path since we own shared lock, and two parallel fast path execution would be handled by the page lock). diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 30b0456..f327ab0 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -174,6 +174,54 @@ unlock_and_deallocate(struct faultstate *fs) } } =20 +static void +vm_fault_dirty(vm_map_entry_t entry, vm_page_t m, vm_prot_t prot, + vm_prot_t fault_type, int fault_flags, boolean_t set_wd) +{ + + if (((prot & VM_PROT_WRITE) !=3D 0 || + (fault_flags & VM_FAULT_DIRTY) !=3D 0) && + (m->oflags & VPO_UNMANAGED) =3D=3D 0) { + if (set_wd) + vm_object_set_writeable_dirty(m->object); + + /* + * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC + * if the page is already dirty to prevent data written with + * the expectation of being synced from not being synced. + * Likewise if this entry does not request NOSYNC then make + * sure the page isn't marked NOSYNC. Applications sharing + * data should use the same flags to avoid ping ponging. + */ + if (entry->eflags & MAP_ENTRY_NOSYNC) { + if (m->dirty =3D=3D 0) { + if (!set_wd) + vm_page_lock(m); + m->oflags |=3D VPO_NOSYNC; + if (!set_wd) + vm_page_unlock(m); + } + } else { + m->oflags &=3D ~VPO_NOSYNC; + } + + /* + * If the fault is a write, we know that this page is being + * written NOW so dirty it explicitly to save on + * pmap_is_modified() calls later. + * + * Also tell the backing pager, if any, that it should remove + * any swap backing since the page is now dirty. + */ + if (((fault_type & VM_PROT_WRITE) !=3D 0 && + (fault_flags & VM_FAULT_CHANGE_WIRING) =3D=3D 0) || + (fault_flags & VM_FAULT_DIRTY) !=3D 0) { + vm_page_dirty(m); + vm_pager_page_unswapped(m); + } + } +} + /* * TRYPAGER - used by vm_fault to calculate whether the pager for the * current object *might* contain the page. @@ -321,11 +369,8 @@ RetryFault:; vm_page_hold(m); vm_page_unlock(m); } - if ((fault_type & VM_PROT_WRITE) !=3D 0 && - (m->oflags & VPO_UNMANAGED) =3D=3D 0) { - vm_page_dirty(m); - vm_pager_page_unswapped(m); - } + vm_fault_dirty(fs.entry, m, prot, fault_type, fault_flags, + FALSE); VM_OBJECT_RUNLOCK(fs.first_object); if (!wired) vm_fault_prefault(&fs, vaddr, 0, 0); @@ -898,42 +943,7 @@ vnode_locked: if (hardfault) fs.entry->next_read =3D fs.pindex + faultcount - reqpage; =20 - if (((prot & VM_PROT_WRITE) !=3D 0 || - (fault_flags & VM_FAULT_DIRTY) !=3D 0) && - (fs.m->oflags & VPO_UNMANAGED) =3D=3D 0) { - vm_object_set_writeable_dirty(fs.object); - - /* - * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC - * if the page is already dirty to prevent data written with - * the expectation of being synced from not being synced. - * Likewise if this entry does not request NOSYNC then make - * sure the page isn't marked NOSYNC. Applications sharing - * data should use the same flags to avoid ping ponging. - */ - if (fs.entry->eflags & MAP_ENTRY_NOSYNC) { - if (fs.m->dirty =3D=3D 0) - fs.m->oflags |=3D VPO_NOSYNC; - } else { - fs.m->oflags &=3D ~VPO_NOSYNC; - } - - /* - * If the fault is a write, we know that this page is being - * written NOW so dirty it explicitly to save on=20 - * pmap_is_modified() calls later. - * - * Also tell the backing pager, if any, that it should remove - * any swap backing since the page is now dirty. - */ - if (((fault_type & VM_PROT_WRITE) !=3D 0 && - (fault_flags & VM_FAULT_CHANGE_WIRING) =3D=3D 0) || - (fault_flags & VM_FAULT_DIRTY) !=3D 0) { - vm_page_dirty(fs.m); - vm_pager_page_unswapped(fs.m); - } - } - + vm_fault_dirty(fs.entry, fs.m, prot, fault_type, fault_flags, TRUE); vm_page_assert_xbusied(fs.m); =20 /* diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index f12b76c..a45648d 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -147,7 +147,7 @@ struct vm_page { uint16_t hold_count; /* page hold count (P) */ uint16_t flags; /* page PG_* flags (P) */ uint8_t aflags; /* access is atomic */ - uint8_t oflags; /* page VPO_* flags (O) */ + uint8_t oflags; /* page VPO_* flags (OM) */ uint8_t queue; /* page queue index (P,Q) */ int8_t psind; /* pagesizes[] index (O) */ int8_t segind; @@ -163,8 +163,9 @@ struct vm_page { /* * Page flags stored in oflags: * - * Access to these page flags is synchronized by the lock on the object - * containing the page (O). + * Access to these page flags is synchronized by the exclusive lock on + * the object containing the page, or combination of shared object + * lock and the page lock (OM). * * Note: VPO_UNMANAGED (used by OBJT_DEVICE, OBJT_PHYS and OBJT_SG) * indicates that the page is not under PV management but --W2+iMEDMST8vYcDN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCa7CAAoJEJDCuSvBvK1Bka4P/iPGCr9I5LVmIkugcj4QzELB UwzBrQlK42bNiW5sAiU1qRbkMrLVfZyjPTBHPsFjsiVmVb8b5Xi+KbWFZesyFnxj SMynOb6msXm0NJItlZNuWXFF6Uf8LAFdR7LJypNbgQb1Rgu7ztmzpugNs/8I2A8n J8XG/W4+Jcb6QEZ9yfhCGDWy4YnHqEOh9WzjNYPyE//GN+ommNaDOOcbsFBKBw6G 5vYfiP0tIXHOVRPAzvUl6jrkXYT4S9CqFvVDGdLQoTeAfm7jj49D67bf1CMy4uUN jVINMhtTPmzqkcLSHFnzRQmy7AtAQI+VBgoJxg3OCk6pVuUs4w5WB1by9ecA7ZcF 8q49QLcsxGjIVNrNB551djl2eu2hGl1rp0IgYZb0wO1zHuDYMlJZc5X8KEh1XQUy ckmutFCdEt8piqCzIK7cShisbMyMY+rmFiBuwWM9X/7NYjjXU9M43tfByBqGeh65 XSpz9mHvckEG0BCouhu6UIs9JdipRLKRLu+8w233gDf31FCPRTf38T6zAvVHdG4l 9BINyz4vt9hJl0q7M5S5KxUGVtW+0nDvApA2a52h3RfL5QtYO/JHC6dVIdzOnHHJ eb9gazv0gS10LZQ23igTfFpZ6zTixk3q73orvqG3rJN62uSz/iFIjHqjCHeH6z36 FV0TpFkI495w4C7YlTS7 =Z8iA -----END PGP SIGNATURE----- --W2+iMEDMST8vYcDN-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 13:41:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5006A93A for ; Fri, 5 Sep 2014 13:41:15 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09FCA1556 for ; Fri, 5 Sep 2014 13:41:14 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id z107so11658230qgd.21 for ; Fri, 05 Sep 2014 06:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=Z6NrI6Lat8YdvTE53uC+Bu3GQQpWjshasBgecZPJ5kY=; b=PxjN/GYftcY1KR42Id5GJ8PibvfXU4FeT9eD1CokdjY2E8Lh96JlpCbAACO9dnRXtb JWBAT59btubV/X+GENRF14EH2yVB308PJd8PtPJfE5pYhpdbmgh1CSNU37lGXK/oNLF9 fJ93Wn9zNYzn+/5FG2pKsEvO1iW+ei7BXcelE= 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:content-type; bh=Z6NrI6Lat8YdvTE53uC+Bu3GQQpWjshasBgecZPJ5kY=; b=iquhNPaD9vZbSSRNwc7ilWU+leYoDNxDQzP+sP93fM0SVA8ut/7xYh6rIrDxq+3FW/ lS4ldm84hxx2PU7ZL0tZBz3ts5XKHKHR2WPM0k7zDOA2XHk8OZRsmjTn07Q9ODrTwd76 irR9WLdOgKuK3jHbsokSLkoD+8BnmTj1feCSNroE3upw4t9sriFTMGzpEU1ZNPgkfVm+ 3/bV5V13HhRkoGuIe3F3W2KchGy97IZGQWqdiNdZCiqkb194zZmfZnPhWw8YjUWHJQeH 6sLoaseXhRfTVNRkELF9gqZHPeYfkT7FzfdpqrC0+plAZh3/gzZWBPp01YZ2QGUyjvd0 9Reg== X-Gm-Message-State: ALoCoQlx4d/6c1kpfLz37Qt87VDxS9r0/jhnlTsl8qtQNRRTjQ26RK5lml1vUEuBfk3O4hLr9LFA X-Received: by 10.224.163.83 with SMTP id z19mr19032460qax.68.1409924473857; Fri, 05 Sep 2014 06:41:13 -0700 (PDT) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.96.28.168 with HTTP; Fri, 5 Sep 2014 06:40:43 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Fri, 5 Sep 2014 06:40:43 -0700 X-Google-Sender-Auth: UXEBFg4OoqUtnJ91bfLs9Imt5iQ Message-ID: Subject: Re: patchchecker for FreeBSD ? To: Kashyap Desai , David Chisnall , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 13:41:15 -0000 +theraven@ who might be able to give a better answer +hackers@ since this relates to a technical issue On 5 September 2014 03:53, Kashyap Desai wrote: > Hi Eitan Adler, > > I was searching for patchchecker tool on FreeBSD same as Linux and found > below link. > > https://wiki.freebsd.org/GoogleCodeIn/2012Tasks#Patch_style_checker > > Is there any tool available to check any coding standard issue in FreeBSD ? I don't think there is any standard tool we use, but there have been multiple projects to come up with one. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 14:14:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88AA635A; Fri, 5 Sep 2014 14:14:14 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F6031A89; Fri, 5 Sep 2014 14:14:05 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 664C91FE028; Fri, 5 Sep 2014 16:12:46 +0200 (CEST) Message-ID: <5409C4DD.9020703@selasky.org> Date: Fri, 05 Sep 2014 16:12:45 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Eitan Adler , Kashyap Desai , David Chisnall , FreeBSD Hackers Subject: Re: patchchecker for FreeBSD ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:14:14 -0000 On 09/05/14 15:40, Eitan Adler wrote: > +theraven@ who might be able to give a better answer > +hackers@ since this relates to a technical issue > > On 5 September 2014 03:53, Kashyap Desai wrote: >> Hi Eitan Adler, >> >> I was searching for patchchecker tool on FreeBSD same as Linux and found >> below link. >> >> https://wiki.freebsd.org/GoogleCodeIn/2012Tasks#Patch_style_checker >> >> Is there any tool available to check any coding standard issue in FreeBSD ? > > I don't think there is any standard tool we use, but there have been > multiple projects to come up with one. > > Hi, The attached script does the trick for me at least. Might be useful to others too :-) --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 14:17:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A742655B; Fri, 5 Sep 2014 14:17:46 +0000 (UTC) Date: Fri, 5 Sep 2014 10:17:41 -0400 From: Glen Barber To: Hans Petter Selasky Subject: Re: patchchecker for FreeBSD ? Message-ID: <20140905141741.GZ36287@hub.FreeBSD.org> References: <5409C4DD.9020703@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Tg5qL4DubmxJEzuM" Content-Disposition: inline In-Reply-To: <5409C4DD.9020703@selasky.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:17:47 -0000 --Tg5qL4DubmxJEzuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 05, 2014 at 04:12:45PM +0200, Hans Petter Selasky wrote: > The attached script does the trick for me at least. Might be useful to > others too :-) >=20 I think mailman ate it. Glen --Tg5qL4DubmxJEzuM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUCcYFAAoJELls3eqvi17Q2joP/0Aijbm4zlbG9ATiLktZQ7mp 797lH/Z2JnP0UkSI9rcJ9iIZkb8dTEss4Q7Vq2wm84ZDDPclUWTQL+OxbyM3bRq0 eCwNYtCyULx4IKrNT7Mk31llZ8Ly9emsR70b5dL1u8MxkndtHPgdqWaV57Bf1+lo FPy27CBwEsxggPGu8lA6gRjedxEwa9wghJgzfAPNLWZ01d9+GrNbk2KjxQmjnfZp pu2SemZRlyk72a5Pwsgvw0zXpTVa0kU6l9Vg99qHM5gusj3waWhLxVRVrL6YP1MK gR6+S7iuwGYbUpGWpZAOxPkefGGh8q+CtgHIaDBN2CIcZev1m8VYukNNvae0qfYD hUwet3PNNrHDDoKZRaoskzGjSLjlvNGSa5LBxKDSx0U1IOsvagvBIFS/5TgLMKQR EuS5iSvgycbNkOg/LOy1aSWdsPpWmsYW69JdZDRTyoVY03wp92fPBoCTHxnO7v6n gcdxi1heD48huapTX4lztOV0yMldWUOPjD7XAR24PRQPaj8ZZl0uJkeg8wGlVHkG Eh7Y/JIRZzBSTbQmWFuNdkcJWg1MIDdnF9gAxiYEgTJ8sFV3nU+Fh6yvGTFtciRf 0cOLbMiSSDgF0z4su75ZlaxYMCa0JO5wvbQmG7vVh9SRcjpH0NjXL+oK/4wKLr5d d9ns9Oj2fe0Ro0+Cp2fB =r5Ai -----END PGP SIGNATURE----- --Tg5qL4DubmxJEzuM-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 14:25:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE7F78C5 for ; Fri, 5 Sep 2014 14:25:18 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 815581BC6 for ; Fri, 5 Sep 2014 14:25:18 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz1so1220089pad.7 for ; Fri, 05 Sep 2014 07:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LmDsyYuolqk2RZah6bDxKIA7L+55H5khalAvJ2iAfMM=; b=Cxn5Fd2AJw+feWuHR8C6owqFqAzJCB4Yvfe462fdGVxb2ZNu5Zi/EIuuY/0ckFHq4o 7MIN/D6KTNWM26GFeVwtroZKbD9gJ7QZNveLSvbTrJyeko+vG1bnq3PrcgQL/O1RvcbX vbHGv5OkEtj+tjjTvsPUmYJyJVvdFJ0sRVYhT35jtOuUYHL94SlpmxFpzs2/ciymQtga Cqf0XawBTX/CoGdaXkjX0C9jBnVddlLYV/ICm5JpVte+l39Tz0ypZMn3g9Ulyhsbq4K4 KI8pWzxx25dFbPEV2UWM9onnCPmW2Cjq1FBRylfOeniJuTLL8Y77IIeyzGPOG5icpv/z aKGg== MIME-Version: 1.0 X-Received: by 10.66.242.47 with SMTP id wn15mr22488518pac.64.1409927113357; Fri, 05 Sep 2014 07:25:13 -0700 (PDT) Received: by 10.70.93.169 with HTTP; Fri, 5 Sep 2014 07:25:13 -0700 (PDT) Date: Fri, 5 Sep 2014 16:25:13 +0200 Message-ID: Subject: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Lionel Cons To: Freebsd hackers list Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:25:18 -0000 Is there any tool which can be used to access ZFS and NFSv4 alternate data streams on FreeBSD? Lionel From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 14:32:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A290D6B; Fri, 5 Sep 2014 14:32:21 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18DE41CB8; Fri, 5 Sep 2014 14:32:21 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id eu11so22265822pac.25 for ; Fri, 05 Sep 2014 07:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yBTWvP2e7yTK6dTHhYgoA1buWvHSN/ZSMpu1VV1cPr4=; b=OJIUjVnSEzrf0ULWLwccwfd/oRvt8iQNxH4DITtzd0hphjS1mJLi0V3KBbXQQgae+z bceqpGQNqzjxWlNPHwco2YH3Mey1wWCE2SxDA7tValJkLrAx0ONKrC1qTRalFfvhJ7Xr YR/gGGdz4s5zyHMUiqdzbWAJbbrWoMhX0nxM87mPNpDweUyPF66xItM7ChXFd8VVAPVm 9WL7XNvZOpJnJaTr3xDrIcG48xHzpI5FyMiLI+qTngjjdxKCbmEL6jxCAQzLdhae8T+r Kddqep3CzDOLDcP4t7IHoA2Y8aTzWig04h1/tizRicgfNwpoE2khfuqiR8tdhGHnOZoA 7lAA== MIME-Version: 1.0 X-Received: by 10.66.242.47 with SMTP id wn15mr22477728pac.64.1409927042863; Fri, 05 Sep 2014 07:24:02 -0700 (PDT) Received: by 10.70.93.169 with HTTP; Fri, 5 Sep 2014 07:24:02 -0700 (PDT) In-Reply-To: References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> Date: Fri, 5 Sep 2014 16:24:02 +0200 Message-ID: Subject: Re: O_XATTR support in FreeBSD? From: Lionel Cons To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:32:21 -0000 On 1 December 2013 23:05, Lionel Cons wrote: > On 27 November 2013 05:52, Tim Kientzle wrote: >> >> On Nov 26, 2013, at 1:51 AM, Cedric Blancher wrote: >> >>> 5. Support for tar and pax is already there. Its described in >>> Solaris's fsattr man page, they use a extended header with filename >>> /dev/null (to prevent older tar versions from tripping over the new >>> headers) and then have a named attribute header which describes the >>> attributes names and flags. >> >> There are quite a few alternative approaches for storing >> extended attributes in tar and pax files. > > But this discussion is *not* about extended attributes, this > discussion is about Alternate Data Streams. Unfortunately the O_XATTR > discussion somehow started to cover the Linux "extended attribute > system", which is utterly useless in the intended use cases (as said, > no access through normal POSIX read(), write(), mmap(), no unlimited > size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc). > > Lionel What is the status of O_XATTR (alias alternate data stream support) in FreeBSD? We run more and more into the trouble that these kind of streams are in use but cannot be accessed or processed on FreeBSD. Lionel From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 14:32:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3558E43; Fri, 5 Sep 2014 14:32:25 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F35A1CBE; Fri, 5 Sep 2014 14:32:25 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9B3E01FE027; Fri, 5 Sep 2014 16:32:23 +0200 (CEST) Message-ID: <5409C976.3030308@selasky.org> Date: Fri, 05 Sep 2014 16:32:22 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Glen Barber Subject: Re: patchchecker for FreeBSD ? References: <5409C4DD.9020703@selasky.org> <20140905141741.GZ36287@hub.FreeBSD.org> In-Reply-To: <20140905141741.GZ36287@hub.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:32:25 -0000 On 09/05/14 16:17, Glen Barber wrote: > On Fri, Sep 05, 2014 at 04:12:45PM +0200, Hans Petter Selasky wrote: >> The attached script does the trick for me at least. Might be useful to >> others too :-) >> > > I think mailman ate it. > > Glen > #!/bin/sh # # This script should be run on every USB C- and H- file before # commit to enforce correct style. # [ -z "$1" ] && (echo "Please specify a filename.") && exit # # The "-ta" option is an extension to indent. # Contact hselasky@freebsd.org to receive a # patch that adds support for this option to # indent ! # # # sed -E 's/&\(([^, \)]*)\)/\&\1/' | # for F in $* do echo "Now styling $F" (cat $F | indent -Toss_mixerinfo -TFILE -Tu_char -Tu_int -Tu_long \ -TTAILQ_HEAD -TLIST_HEAD -TTAILQ_ENTRY -TLIST_ENTRY \ -TSTAILQ_HEAD -TSTAILQ_ENTRY \ -Tu_short -Tfd_set -ta -st -bad -bap -nbbb -nbc -br -nbs \ -c41 -cd41 -cdb -ce -ci4 -cli0 -d0 -di8 -ndj -ei -nfc1 \ -nfcb -i8 -ip8 -l79 -lc77 -ldi0 -nlp -npcs -psl -sc \ -nsob -nv | sed -e "s/_HEAD [(]/_HEAD(/g" | sed -e "s/_ENTRY [(]/_ENTRY(/g" | sed -e "s/ __packed/ __packed/g" | sed -e "s/ __aligned/ __aligned/g" | sed -e "s/^#define /#define /g") > temp (diff temp $F > /dev/null) || (cp temp $F) done From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 15:36:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C01B2355 for ; Fri, 5 Sep 2014 15:36:08 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 830E215AC for ; Fri, 5 Sep 2014 15:36:08 +0000 (UTC) Received: from hexe.rlwinm.de (p50834F64.dip0.t-ipconnect.de [80.131.79.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 4CD843448 for ; Fri, 5 Sep 2014 17:35:57 +0200 (CEST) Message-ID: <5409D85C.6040803@rlwinm.de> Date: Fri, 05 Sep 2014 17:35:56 +0200 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:36:08 -0000 On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which can be used to access ZFS and NFSv4 alternate > data streams on FreeBSD? Are you looking for lsextattr(8) and getextattr(8)? From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 15:25:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D934C2F for ; Fri, 5 Sep 2014 15:25:18 +0000 (UTC) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C121B13BE for ; Fri, 5 Sep 2014 15:25:17 +0000 (UTC) Received: from mail-lb0-f169.google.com ([209.85.217.169]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKVAnV1/8owdg2sg6ZOXBzLkkNXzeKxMAI@postini.com; Fri, 05 Sep 2014 08:25:17 PDT Received: by mail-lb0-f169.google.com with SMTP id p9so2976484lbv.0 for ; Fri, 05 Sep 2014 08:25:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=2R8ZfNx37Wktgnhu2snydLk1I0KrO8KolrrONcrjMFw=; b=HFHBvQh9aNZBTHjweLv94DDYckyUQlhOyuS26+an4HjT1Z6Ma+u3gS9FlYa0LlAmz0 mdPEULGM8wVHkH8/4234vGRhOyJ2zucsqLFDlmv/pfIBtfi+p6bbNOJnsT0gLPc2dHq+ 2+QO08++oHA8YysL7dVPhLQWXi7Fbutd8ejnr4cs9epPWuCH1yYKmUyMyw5AXdbZGRde h9xAxSZ7Voa5pcmyrCaj0gGOmrkwsGUXOPhnE+jiAYomMI+C1nSznzXLso6GvO+qmMx7 AGI+zutHKcr7KePuNT7fLAspo3Cr4yp4OrdJ58dq+OUNDgbZnxEhsEz8IdOU6jZG2iut UxMw== X-Gm-Message-State: ALoCoQmeT0eW6sl0BLdw1uOYTT708kFjvNgiSll5CXx/kO2HH5MgqyF+UMY17UQnJXkiZXAOz0B82i04okSsTeURk5VQwegCu9k+/0izqfO2sk3tR64iJ9iVFbBEtRfID6lq689Ib06CfanXQV7liRugQdD+cE/F1w== X-Received: by 10.152.207.36 with SMTP id lt4mr12758079lac.72.1409930710295; Fri, 05 Sep 2014 08:25:10 -0700 (PDT) X-Received: by 10.152.207.36 with SMTP id lt4mr12758024lac.72.1409930709793; Fri, 05 Sep 2014 08:25:09 -0700 (PDT) From: Kashyap Desai References: <5409C4DD.9020703@selasky.org> In-Reply-To: <5409C4DD.9020703@selasky.org> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGTkRgaNdGX81KNDiftUltdrdo88gESo/pHAdQOOCmcU+MRYA== Date: Fri, 5 Sep 2014 20:55:08 +0530 Message-ID: <7cd2fba535531ae8d48d5267e44f5142@mail.gmail.com> Subject: RE: patchchecker for FreeBSD ? To: Hans Petter Selasky , Eitan Adler , David Chisnall , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 05 Sep 2014 15:41:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:25:18 -0000 > -----Original Message----- > From: Hans Petter Selasky [mailto:hps@selasky.org] > Sent: Friday, September 05, 2014 7:43 PM > To: Eitan Adler; Kashyap Desai; David Chisnall; FreeBSD Hackers > Subject: Re: patchchecker for FreeBSD ? > > On 09/05/14 15:40, Eitan Adler wrote: > > +theraven@ who might be able to give a better answer hackers@ since > > +this relates to a technical issue > > > > On 5 September 2014 03:53, Kashyap Desai > wrote: > >> Hi Eitan Adler, > >> > >> I was searching for patchchecker tool on FreeBSD same as Linux and > >> found below link. > >> > >> https://wiki.freebsd.org/GoogleCodeIn/2012Tasks#Patch_style_checker > >> > >> Is there any tool available to check any coding standard issue in FreeBSD ? > > > > I don't think there is any standard tool we use, but there have been > > multiple projects to come up with one. > > > > > > Hi, > > The attached script does the trick for me at least. Might be useful to others > too :-) Thanks a lot. I will also try this. Something is better than nothing :-) ~ Kashyap > > --HPS > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 15:53:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A4DAF51 for ; Fri, 5 Sep 2014 15:53:57 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6C801917 for ; Fri, 5 Sep 2014 15:53:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BDA51B9B1; Fri, 5 Sep 2014 11:53:55 -0400 (EDT) From: John Baldwin To: "Sinha, Prokash" Subject: Re: PXE boot Date: Fri, 5 Sep 2014 11:18:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Message-Id: <201409051118.50416.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 05 Sep 2014 11:53:55 -0400 (EDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:53:57 -0000 On Thursday, September 04, 2014 5:23:19 pm Sinha, Prokash wrote: > > On 9/4/14 2:22 PM, "Sinha, Prokash" wrote: > > >Yeah, something going on that I don't understand. I defined that macro, > >and for quick verify - > >make -v > >Warning: Object directory not changed from original > >/.automount/nfs.paneast.panasas.com/root/home/psinha/psinha-bug-pa/src/fre > >e > >bsd-c/sys/boot/i386/pxeldr > >cc -O2 -fno-strict-aliasing -pipe -ffreestanding > >-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > >-mno-sse3 -m32 -march=i386 -DALWAYS_SERIAL -c pxeldr.S > >cc -O2 -fno-strict-aliasing -pipe -ffreestanding > >-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > >-mno-sse3 -m32 -march=i386 -DALWAYS_SERIAL -nostdlib -m elf_i386_fbsd -N > >-e start -Ttext 0x7c00 -Wl,-S,--oformat,binary -o pxeldr pxeldr.o > >make: don't know how to make pxeboot.8. Stop > > > >==> The variable is defined and the correct flag is included in the cc ... > > > > > >But I still don't get the messages from pxe_enable or pxe_init... > > > >Need to sit back and look further... > > > >John, much appreciated for the help... Weird. Are you using COM1 at 9600? Aside from that, do you get logs of calls once interact() starts and loader.conf is parsed? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 15:53:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86A63F52; Fri, 5 Sep 2014 15:53:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8A31918; Fri, 5 Sep 2014 15:53:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C90AB9C3; Fri, 5 Sep 2014 11:53:57 -0400 (EDT) From: John Baldwin To: Julian Elischer Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? Date: Fri, 5 Sep 2014 11:43:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <2041449.H6lUHcsTDl@ralph.baldwin.cx> <54090FDB.6090801@freebsd.org> In-Reply-To: <54090FDB.6090801@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201409051143.33213.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 05 Sep 2014 11:53:57 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, kib@freebsd.org, Steven Stewart-Gallus , Benjamin Kaduk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:53:58 -0000 On Thursday, September 04, 2014 9:20:27 pm Julian Elischer wrote: > On 9/4/14, 7:06 AM, John Baldwin wrote: > > On Wednesday, September 03, 2014 05:30:01 PM Benjamin Kaduk wrote: > >> On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: > >>>> svn blame says that the whole implementation dates from r1541. > >>>> Looks like > >>>> it was never implemented. Some googling indicates that it was a > >>>> plannedroutine to set the stack size, which was never implemented, > >>>> anywhere. > >>>> > >>>> The locking comments were added in r79224, but the implementation is > >>>> otherwise from r1541, i.e., it was never implemented. > >>> Alright, so sys/kern/syscalls.master can be patched somewhat like so > >>> and I won't need to document them? > >>> > >>> -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ > >>> - ovadvise_args int > >>> +72 AUE_NULL OBSOL ovadvise > >>> > >>> -70 AUE_SSTK STD { int sstk(int incr); } > >>> +70 AUE_SSTK OBSOL sstk > >> I don't think so; I think that would be a regression. > >> > >> We do currently provide implementations for these syscalls, that just > >> happen to always return failure. I think that the OBSOL annotation > >> corresponds to a complete lack of implementation. Perhaps it would be > >> acceptable at a major release boundary, but this is not my area of > >> expertise. > > For these two calls, I doubt anything is actually using them. They've been > > stubs since the Mach VM was imported into BSD in 1990. We don't ship a system > > call for creat() anymore either. In this particular case, I think it would be > > more of a feature if those symbols disappeared from libc and caused link > > errors. > have we ever shipped code for creat? > > if we lose teh ability to run FreeBSD 1.1 chroots I'll be most upset.. > it's a great > selling point when pointing out our commitment to ABI stability and > backwards > portability. These system calls were NOPs in 4.4 BSD. vadvise was marked as obsolete ('ovadvise') in syscalls.master when it was first imported in 1989: http://svnweb.freebsd.org/csrg/sys/kern/syscalls.master?view=markup&pathrev=37325 I can't actually find the implementations of vadvise() and sstk() prior to the Mach VM import in the CSRG repository so I don't know how far back they were NOPs, but I doubt any FreeBSD binary uses these. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 16:00:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F81B3AE for ; Fri, 5 Sep 2014 16:00:29 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 8AA721A07 for ; Fri, 5 Sep 2014 16:00:29 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.80.1 #2 (Red Hat Linux)) id 1XPvw4-0004K4-Ox; Fri, 05 Sep 2014 16:00:28 +0000 Date: Fri, 5 Sep 2014 09:00:28 -0700 From: Christoph Hellwig To: Jan Bramkamp Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? Message-ID: <20140905160028.GA11152@infradead.org> References: <5409D85C.6040803@rlwinm.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5409D85C.6040803@rlwinm.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:00:29 -0000 On Fri, Sep 05, 2014 at 05:35:56PM +0200, Jan Bramkamp wrote: > On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which can be > used to access ZFS and NFSv4 alternate > > data streams on FreeBSD? > > Are you looking for lsextattr(8) and getextattr(8)? He wants Solaris-style subfiles. Due to Sun abusing the existing (x)attr naming for it there's a lot of confusing unfortunately. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 16:06:58 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23E175DF for ; Fri, 5 Sep 2014 16:06:58 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id EF62F1A55 for ; Fri, 5 Sep 2014 16:06:57 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 00CDF4483D for ; Fri, 5 Sep 2014 16:06:50 +0000 (UTC) Message-ID: <5409DFB4.4030205@freebsd.org> Date: Fri, 05 Sep 2014 12:07:16 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: patchchecker for FreeBSD ? References: <5409C4DD.9020703@selasky.org> <7cd2fba535531ae8d48d5267e44f5142@mail.gmail.com> In-Reply-To: <7cd2fba535531ae8d48d5267e44f5142@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DnVc93c6sCorFwE36kSAQGDEWPusvgFEA" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 16:06:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DnVc93c6sCorFwE36kSAQGDEWPusvgFEA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-09-05 11:25, Kashyap Desai wrote: >> -----Original Message----- >> From: Hans Petter Selasky [mailto:hps@selasky.org] >> Sent: Friday, September 05, 2014 7:43 PM >> To: Eitan Adler; Kashyap Desai; David Chisnall; FreeBSD Hackers >> Subject: Re: patchchecker for FreeBSD ? >> >> On 09/05/14 15:40, Eitan Adler wrote: >>> +theraven@ who might be able to give a better answer hackers@ since >>> +this relates to a technical issue >>> >>> On 5 September 2014 03:53, Kashyap Desai >> wrote: >>>> Hi Eitan Adler, >>>> >>>> I was searching for patchchecker tool on FreeBSD same as Linux and >>>> found below link. >>>> >>>> https://wiki.freebsd.org/GoogleCodeIn/2012Tasks#Patch_style_checker >>>> >>>> Is there any tool available to check any coding standard issue in > FreeBSD ? >>> >>> I don't think there is any standard tool we use, but there have been >>> multiple projects to come up with one. >>> >>> >> >> Hi, >> >> The attached script does the trick for me at least. Might be useful to= > others >> too :-) >=20 > Thanks a lot. I will also try this. Something is better than nothing :-= ) >=20 > ~ Kashyap >=20 >> >> --HPS >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 If this works well, should we add it as a 'lint' check for phabricator/ar= c ? --=20 Allan Jude --DnVc93c6sCorFwE36kSAQGDEWPusvgFEA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUCd+2AAoJEJrBFpNRJZKfDhUP/0VBXuM7o590O4vqJKAVaoaJ 11qgSuXRbppBEsXuvrlZN5bxNc9/KumFJEQQPfdfYCaoPHrcbGbtBackdVOallrN IaEgiu/DSvt4My1vQkeH/0xyIecN+LFJOuxtNhI+yiSThcce6SwRZhOgdLz0vKkI nxyL+dOm37ZFDr9FLoHzrC7h0W+DcIe5q4aAQOtliudw8LVMTFJDOZLMQLwAPPMH 9vbmwRQaUwfyR/0l5kijHuHGeHNfugmWC+ZA5gs8rXqChv330OvpEmSZeV3ejBLN NHRQsn9Q4V0JyjJFjlPQqFOhxe9JV8W2ebsaaURWSuyuBb60su6jpECcqx2tJbTK CVfCXt4XCvaU3FXeqkbh1vd7E0ewKchQVrQ1F6tTgIFP2YdSFr/l14w4/NnEC1jp 4i3DaRHew0OHyVVm87Fzs+EUMLFJC+YrOPmI8PFWgX05NOCLAJu1wRi7rtWkqbhQ a64TOG/ZzuwYKOK1RD+8Wl8FJwyrVSjsZbmZFcEIwhYTp7P1q53anpgax/2rjr4x vjUHVheYQMxabHDG92ObQ4MYf91Kr4GCiynTt3WlSHywz6ME0tXPMaEZg/SYz8AY f+zw5dz20wty3NXaQT1gM4kmG89W2dSC+yC0ZnAFmiELmjn6gqatuJpv3TChs5IC bQSPckVArVDO972is1DA =t163 -----END PGP SIGNATURE----- --DnVc93c6sCorFwE36kSAQGDEWPusvgFEA-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 17:26:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32808D50 for ; Fri, 5 Sep 2014 17:26:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 0CA4413B5 for ; Fri, 5 Sep 2014 17:26:30 +0000 (UTC) Received: from [IPv6:2001:470:1f07:93::2] (unknown [IPv6:2001:470:1f07:93::2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 83306340042; Fri, 5 Sep 2014 17:26:28 +0000 (UTC) Message-ID: <5409F23B.2070806@gentoo.org> Date: Fri, 05 Sep 2014 13:26:19 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jan Bramkamp , freebsd-hackers@freebsd.org Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? References: <5409D85C.6040803@rlwinm.de> In-Reply-To: <5409D85C.6040803@rlwinm.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6x9U2bVK3Ck0J0ubshPdo6NdpOdDFP3ql" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 17:26:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6x9U2bVK3Ck0J0ubshPdo6NdpOdDFP3ql Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/05/2014 11:35 AM, Jan Bramkamp wrote: > On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which can be= > used to access ZFS and NFSv4 alternate >> data streams on FreeBSD? >=20 > Are you looking for lsextattr(8) and getextattr(8)? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 Do you mean Solaris extended attributes? Those tend to be called resource forks on other platforms. Unifying extended attributes and resource forks was clever. --6x9U2bVK3Ck0J0ubshPdo6NdpOdDFP3ql Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUCfJDAAoJECDuEZm+6Exk560QAJcOgb5CHXIvzm+a3vefWgYe X/4VJG9A+TLRHKbGAvsDVyoivdn6cDRtLrV09qHsYGKNp5HsUCImpad4ucqqZ1XA UjIvBNnHIgABHEvBRwb768xucZsxRLtX6zFavl0H28Js6ukGUUbPIToWMzsYzb4I CABROCrU1EANd3ulXdUR0DIfDJRKpxKVubvhQFUPf2PZtJrTzGwkk1Az3yTxMwgW TvWO/KqyHsC8RfcjMK27sQnbfqoBczeeeh7Kvk3CFb17QgvS0geS6ZDSGAy75pK2 MicBu+xdG8Dg9L8kHmIuyLnndbJudb7Fl1NaM5wJkLynQ1AcPBnJTaOparWkog55 nXg5GDOCXXhuESEJr+5HlV0ezhxdQHN8JWtKwKO7kizxs1KbeTTwkpsxOgtxuBis Lx2IgEvqAK1H96hKwoNH15zNLLi2oOc3U+z7bqgnVfE3VlI8HWC3urHymIXDxapp AOat32Zii7GD3oEm3gv/mXZ6PJn9gaFgfX9pjnzF4R5wIAXWLo93+D/Sb3UBRnI4 +3VQqPml1YP5M9XK3HAgyTrfAA0ldz1OpgZxDleKjvWMLW00yOqIjzMmhuLPx0tk iIzxJJJNJ5oNadhnvhWBMyEj+o4tnMrHoGd4H5dw6LXsoJjz/R8Ji+n51ujH2BHW wIpYXRXtEkfObkLrjUgQ =r33l -----END PGP SIGNATURE----- --6x9U2bVK3Ck0J0ubshPdo6NdpOdDFP3ql-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 19:46:32 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6AFF43D; Fri, 5 Sep 2014 19:46:32 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 816621452; Fri, 5 Sep 2014 19:46:32 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id z60so12575746qgd.11 for ; Fri, 05 Sep 2014 12:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Sglwefd/EOCM4/UBcfoVnBMrrXV0sJTJazRIxcCaZKw=; b=QUUNUjdQGD8aRI39YrQ7T8iQztIp06876ru4J4j7Zm3ktydvK+0A5RNm6+xQ/WWltg ENPheJkY5TT6giM0JyxmKE2WZ2eBusE5KFRMw80zVTjOvjnrxwCBby4+5G0VwsMBndtv 5ihJhNIOYOpsJbfkJu7k4oYxlaBilFZxBlALia2Irm8Bx61wlzd2/l6/Y1S6ipa+ON6A f50mz1w7lyeZObr4iwzPjoSGF4BSAUio/FTYmWNWlA4Dgf6zGIBrweYxxkt1DFqKdGra HxRv3v6iQovG2qI1kWnChYd3CXLc5nIp6JU0JCH36Y/3Kr8ekQAs7fuUL9Tj5uNMgUq3 0ogA== MIME-Version: 1.0 X-Received: by 10.224.86.5 with SMTP id q5mr22739376qal.36.1409946391495; Fri, 05 Sep 2014 12:46:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 5 Sep 2014 12:46:31 -0700 (PDT) In-Reply-To: <20140905123826.GP2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> <5409A4F8.6020204@degoeje.nl> <20140905123826.GP2737@kib.kiev.ua> Date: Fri, 5 Sep 2014 12:46:31 -0700 X-Google-Sender-Auth: uv6O2xPDJd4xaGdJHJ6Vkw4Ti-A Message-ID: Subject: Re: mmap MAP_NOSYNC regression in 10.x From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Alan Cox , Pieter de Goeje , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 19:46:32 -0000 Is this worth putting into the regression test suite? -a On 5 September 2014 05:38, Konstantin Belousov wrote: > On Fri, Sep 05, 2014 at 01:56:40PM +0200, Pieter de Goeje wrote: >> Thanks, works for me! > > I realized that the patch contains yet another bug. The oflags page > flags update is protected by the exclusive vm object lock, which is only > held in shared mode on the fast path. Below is the fixed patch, where > I take the page lock around setting VPO_NOSYNC (exclusive lock owners > cannot race with fast path since we own shared lock, and two parallel > fast path execution would be handled by the page lock). > > diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c > index 30b0456..f327ab0 100644 > --- a/sys/vm/vm_fault.c > +++ b/sys/vm/vm_fault.c > @@ -174,6 +174,54 @@ unlock_and_deallocate(struct faultstate *fs) > } > } > > +static void > +vm_fault_dirty(vm_map_entry_t entry, vm_page_t m, vm_prot_t prot, > + vm_prot_t fault_type, int fault_flags, boolean_t set_wd) > +{ > + > + if (((prot & VM_PROT_WRITE) != 0 || > + (fault_flags & VM_FAULT_DIRTY) != 0) && > + (m->oflags & VPO_UNMANAGED) == 0) { > + if (set_wd) > + vm_object_set_writeable_dirty(m->object); > + > + /* > + * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC > + * if the page is already dirty to prevent data written with > + * the expectation of being synced from not being synced. > + * Likewise if this entry does not request NOSYNC then make > + * sure the page isn't marked NOSYNC. Applications sharing > + * data should use the same flags to avoid ping ponging. > + */ > + if (entry->eflags & MAP_ENTRY_NOSYNC) { > + if (m->dirty == 0) { > + if (!set_wd) > + vm_page_lock(m); > + m->oflags |= VPO_NOSYNC; > + if (!set_wd) > + vm_page_unlock(m); > + } > + } else { > + m->oflags &= ~VPO_NOSYNC; > + } > + > + /* > + * If the fault is a write, we know that this page is being > + * written NOW so dirty it explicitly to save on > + * pmap_is_modified() calls later. > + * > + * Also tell the backing pager, if any, that it should remove > + * any swap backing since the page is now dirty. > + */ > + if (((fault_type & VM_PROT_WRITE) != 0 && > + (fault_flags & VM_FAULT_CHANGE_WIRING) == 0) || > + (fault_flags & VM_FAULT_DIRTY) != 0) { > + vm_page_dirty(m); > + vm_pager_page_unswapped(m); > + } > + } > +} > + > /* > * TRYPAGER - used by vm_fault to calculate whether the pager for the > * current object *might* contain the page. > @@ -321,11 +369,8 @@ RetryFault:; > vm_page_hold(m); > vm_page_unlock(m); > } > - if ((fault_type & VM_PROT_WRITE) != 0 && > - (m->oflags & VPO_UNMANAGED) == 0) { > - vm_page_dirty(m); > - vm_pager_page_unswapped(m); > - } > + vm_fault_dirty(fs.entry, m, prot, fault_type, fault_flags, > + FALSE); > VM_OBJECT_RUNLOCK(fs.first_object); > if (!wired) > vm_fault_prefault(&fs, vaddr, 0, 0); > @@ -898,42 +943,7 @@ vnode_locked: > if (hardfault) > fs.entry->next_read = fs.pindex + faultcount - reqpage; > > - if (((prot & VM_PROT_WRITE) != 0 || > - (fault_flags & VM_FAULT_DIRTY) != 0) && > - (fs.m->oflags & VPO_UNMANAGED) == 0) { > - vm_object_set_writeable_dirty(fs.object); > - > - /* > - * If this is a NOSYNC mmap we do not want to set VPO_NOSYNC > - * if the page is already dirty to prevent data written with > - * the expectation of being synced from not being synced. > - * Likewise if this entry does not request NOSYNC then make > - * sure the page isn't marked NOSYNC. Applications sharing > - * data should use the same flags to avoid ping ponging. > - */ > - if (fs.entry->eflags & MAP_ENTRY_NOSYNC) { > - if (fs.m->dirty == 0) > - fs.m->oflags |= VPO_NOSYNC; > - } else { > - fs.m->oflags &= ~VPO_NOSYNC; > - } > - > - /* > - * If the fault is a write, we know that this page is being > - * written NOW so dirty it explicitly to save on > - * pmap_is_modified() calls later. > - * > - * Also tell the backing pager, if any, that it should remove > - * any swap backing since the page is now dirty. > - */ > - if (((fault_type & VM_PROT_WRITE) != 0 && > - (fault_flags & VM_FAULT_CHANGE_WIRING) == 0) || > - (fault_flags & VM_FAULT_DIRTY) != 0) { > - vm_page_dirty(fs.m); > - vm_pager_page_unswapped(fs.m); > - } > - } > - > + vm_fault_dirty(fs.entry, fs.m, prot, fault_type, fault_flags, TRUE); > vm_page_assert_xbusied(fs.m); > > /* > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index f12b76c..a45648d 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -147,7 +147,7 @@ struct vm_page { > uint16_t hold_count; /* page hold count (P) */ > uint16_t flags; /* page PG_* flags (P) */ > uint8_t aflags; /* access is atomic */ > - uint8_t oflags; /* page VPO_* flags (O) */ > + uint8_t oflags; /* page VPO_* flags (OM) */ > uint8_t queue; /* page queue index (P,Q) */ > int8_t psind; /* pagesizes[] index (O) */ > int8_t segind; > @@ -163,8 +163,9 @@ struct vm_page { > /* > * Page flags stored in oflags: > * > - * Access to these page flags is synchronized by the lock on the object > - * containing the page (O). > + * Access to these page flags is synchronized by the exclusive lock on > + * the object containing the page, or combination of shared object > + * lock and the page lock (OM). > * > * Note: VPO_UNMANAGED (used by OBJT_DEVICE, OBJT_PHYS and OBJT_SG) > * indicates that the page is not under PV management but From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 21:42:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9377AE6 for ; Fri, 5 Sep 2014 21:42:20 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB9A1257 for ; Fri, 5 Sep 2014 21:42:20 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id z10so2915137pdj.34 for ; Fri, 05 Sep 2014 14:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B2yk4sdu9xBonwvPZuvMBqrd2ZT64c5nQxVY1eH5AjY=; b=gp1kflQBl53iLvQf3omtUzossLYyz+Pg4rQ9X+kNe9ObhrUwHwyOub0KqMbAUh5gpS QoA7BkzzTz8R2R5eX7onWQsG3+ZI5ge4e26sbqdoqwMlQ/LHm1kcaOS9ZnBM1vIktFz0 HZ3f7S+p4thhVOCfZ6tBqxjUr7bQTgP12tsyzEaCdQzkEcQEwSJEEOaYlJfD4e13xIVn FLzZ65DwOL38ICX508C83czXZxSexc8N8QzX4k7p15kdDnDwfzdURajdOqU9ac/IH/M6 k3dCwFTrZRT2sMiJuMx9NwNCyQOEigAEEkFAB0i0HeL+T/dYnGZd+Sjmx6Hrn5ePsbTE bSCA== MIME-Version: 1.0 X-Received: by 10.66.155.2 with SMTP id vs2mr25539785pab.60.1409953339976; Fri, 05 Sep 2014 14:42:19 -0700 (PDT) Received: by 10.70.93.169 with HTTP; Fri, 5 Sep 2014 14:42:19 -0700 (PDT) In-Reply-To: <5409F23B.2070806@gentoo.org> References: <5409D85C.6040803@rlwinm.de> <5409F23B.2070806@gentoo.org> Date: Fri, 5 Sep 2014 23:42:19 +0200 Message-ID: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Lionel Cons To: Richard Yao Content-Type: text/plain; charset=UTF-8 Cc: Freebsd hackers list , Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:42:20 -0000 On 5 September 2014 19:26, Richard Yao wrote: > On 09/05/2014 11:35 AM, Jan Bramkamp wrote: >> On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which can be >> used to access ZFS and NFSv4 alternate >>> data streams on FreeBSD? >> >> Are you looking for lsextattr(8) and getextattr(8)? >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > Do you mean Solaris extended attributes? Those tend to be called > resource forks on other platforms. Unifying extended attributes and > resource forks was clever. > Yes, they are also called resource forks, or alternate data streams. The attribute files which can be accessed via O_XATTR or cd -@ file/dir on newer ksh/ksh93/bash revisions. Lionel From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 22:14:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A540BDCD for ; Fri, 5 Sep 2014 22:14:20 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6161723 for ; Fri, 5 Sep 2014 22:14:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EABA0ClSDaFve/2dsb2JhbABag2BXBIJ4xg4KhnlTAYEfd4QDAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIgZCA2peJU8AReBLI1QAQEbNAeCeYFTBZVug3uEX4pDiQeDfSEvB4EIOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,475,1406606400"; d="scan'208";a="153068980" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Sep 2014 18:13:10 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B02FBB402B; Fri, 5 Sep 2014 18:13:10 -0400 (EDT) Date: Fri, 5 Sep 2014 18:13:10 -0400 (EDT) From: Rick Macklem To: Lionel Cons Message-ID: <1538621043.33014113.1409955190712.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Freebsd hackers list , Richard Yao , Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:14:20 -0000 Lionel Cons wrote: > On 5 September 2014 19:26, Richard Yao wrote: > > On 09/05/2014 11:35 AM, Jan Bramkamp wrote: > >> On 05.09.2014 16:25, Lionel Cons wrote:> Is there any tool which > >> can be > >> used to access ZFS and NFSv4 alternate > >>> data streams on FreeBSD? > >> > >> Are you looking for lsextattr(8) and getextattr(8)? > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to > >> "freebsd-hackers-unsubscribe@freebsd.org" > >> > > > > Do you mean Solaris extended attributes? Those tend to be called > > resource forks on other platforms. Unifying extended attributes and > > resource forks was clever. > > > > Yes, they are also called resource forks, or alternate data streams. > The attribute files which can be accessed via O_XATTR or cd -@ > file/dir on newer ksh/ksh93/bash revisions. > For FreeBSD's NFSv4 the answer is definitely no. Because the Linux/FreeBSD style setextattr() assumes an atomic replacement of the extended attribute, it is not semantically compatible (ie. cannot be accurately emulated) by resource forks. I do not know of any work for ZFS on FreeBSD w.r.t. this, but I'm not a ZFS guy. rick > Lionel > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 07:48:57 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41EF044E; Sat, 6 Sep 2014 07:48:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3910115F; Sat, 6 Sep 2014 07:48:56 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s867mnL6052062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2014 10:48:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s867mnL6052062 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s867mn8A052061; Sat, 6 Sep 2014 10:48:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Sep 2014 10:48:49 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: mmap MAP_NOSYNC regression in 10.x Message-ID: <20140906074849.GS2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> <5409A4F8.6020204@degoeje.nl> <20140905123826.GP2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mNBVAe7IuEHr0DBJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Alan Cox , Pieter de Goeje , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 07:48:57 -0000 --mNBVAe7IuEHr0DBJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 05, 2014 at 12:46:31PM -0700, Adrian Chadd wrote: > Is this worth putting into the regression test suite? I do not have opinion on this. Feel free to do if you consider it worth. Note that the code needs some tweaking to become automated test. Also, there is no copyright assigned on the test, so you need to handle this as well. --mNBVAe7IuEHr0DBJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCrxhAAoJEJDCuSvBvK1B/moQAJKgMrWAfAGTtJob5BzXGmey rcC1Liqqoj1NCHrkhhKBLKpa8lp96zz2NMZaXzbhqhgM1Vu93/aeX3RlfRyRM40k U6KLZExe00uFfkJVNz4YfTgOsjyNQkyk4FibcbZrPJIWf+i6fldo6NM5KdjVSuoR VfDBTGHoazIjCqBUROy9ZMnqwJ+6FRqn+zgN/KjrzI3g8v0fuPuJzucIwfuUEN0O IvRYx0kbgi4l0Pmjd3yVHfT4yBP/8Zv+gC0VwCftKr8muIX2Te48AQp21myjm2fu 7B9nMGvzvHtZ6Kj8CLLM9qVOyUckDOZtzdbiCrEawzBhjG9TOnqxuyIYXuTp+HQf jf2lhxrAz3b+5t8VYxXdRRfoFspWPkt6X27Rpl8NO6SqXEzEg5pF4Vzlqwia0w/R gnPNZepAFssPOq0z7e5jFbT8C91BAmnUj1PuSXJ8RT1FIOKxOEL0PRHA11I/Z2Oq pcoq+FwtClTzV7IiQP/GVS/gj4tLqQCc0jMmCzABdZUlChpaU1xek/a735+mPD3g OjD21/R698XvyhN3MTjnCN2EQV0SM95tfEhm3LBJjXlkF7BRFEmfXXzOlN+J6S0f GKgkkL4WtF9c/EaS5T/gmqB0+TB61upB11qp66smQ+gYoNgeQZUU9KqbWsinbTEG qNcrMEozoMgVoQ2C3YmB =qmp9 -----END PGP SIGNATURE----- --mNBVAe7IuEHr0DBJ-- From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 15:16:44 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86A3CECD; Sat, 6 Sep 2014 15:16:44 +0000 (UTC) Received: from out145-ams.mf.surf.net (out145-ams.mf.surf.net [145.0.1.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12923118E; Sat, 6 Sep 2014 15:16:43 +0000 (UTC) Received: from out42-ams.mf.surf.net (out42-ams.mf.surf.net [145.0.1.42]) by fbout1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s86FB60t014982; Sat, 6 Sep 2014 17:11:06 +0200 Received: from smtps.utwente.nl (smtp-o1.utsp.utwente.nl [130.89.2.9]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s86FAwIt017491; Sat, 6 Sep 2014 17:10:58 +0200 Received: from [130.89.165.91] (nox.student.utwente.nl [130.89.165.91]) by smtps.utwente.nl (8.13.8) with ESMTP id s86FAvBt005511; Sat, 6 Sep 2014 17:10:58 +0200 Message-ID: <540B23F4.1040608@degoeje.nl> Date: Sat, 06 Sep 2014 17:10:44 +0200 From: Pieter de Goeje User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Adrian Chadd Subject: Re: mmap MAP_NOSYNC regression in 10.x References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> <5409A4F8.6020204@degoeje.nl> <20140905123826.GP2737@kib.kiev.ua> <20140906074849.GS2737@kib.kiev.ua> In-Reply-To: <20140906074849.GS2737@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-Spam-Score: -0.50 () [Tag at 5.00] 2450(0),CC(NL:-0.5) X-CanIt-Geo: ip=130.89.2.9; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMLPaWHg - 933dfbf3cab3 - 20140906 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: Alan Cox , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 15:16:44 -0000 Konstantin Belousov schreef op 6-9-2014 9:48: > On Fri, Sep 05, 2014 at 12:46:31PM -0700, Adrian Chadd wrote: >> Is this worth putting into the regression test suite? > I do not have opinion on this. Feel free to do if you consider it worth. > > Note that the code needs some tweaking to become automated test. > Also, there is no copyright assigned on the test, so you need > to handle this as well. > I can take a stab at converting it to something suitable for inclusion under tools/regression. One issue is that the test uses a heuristic to determine success or failure. I don't really see a way around that, although it certainly could be improved. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 15:41:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4636CC1F; Sat, 6 Sep 2014 15:41:17 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC9761481; Sat, 6 Sep 2014 15:41:16 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s86Ff9oH069013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2014 18:41:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s86Ff9oH069013 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s86Ff9w6069012; Sat, 6 Sep 2014 18:41:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Sep 2014 18:41:09 +0300 From: Konstantin Belousov To: Pieter de Goeje Subject: Re: mmap MAP_NOSYNC regression in 10.x Message-ID: <20140906154109.GV2737@kib.kiev.ua> References: <540903FF.6010602@degoeje.nl> <20140905080633.GM2737@kib.kiev.ua> <5409A4F8.6020204@degoeje.nl> <20140905123826.GP2737@kib.kiev.ua> <20140906074849.GS2737@kib.kiev.ua> <540B23F4.1040608@degoeje.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iQrD/dScPhU9JStb" Content-Disposition: inline In-Reply-To: <540B23F4.1040608@degoeje.nl> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Alan Cox , Adrian Chadd , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 15:41:17 -0000 --iQrD/dScPhU9JStb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 06, 2014 at 05:10:44PM +0200, Pieter de Goeje wrote: > Konstantin Belousov schreef op 6-9-2014 9:48: > > On Fri, Sep 05, 2014 at 12:46:31PM -0700, Adrian Chadd wrote: > >> Is this worth putting into the regression test suite? > > I do not have opinion on this. Feel free to do if you consider it wort= h. > > > > Note that the code needs some tweaking to become automated test. > > Also, there is no copyright assigned on the test, so you need > > to handle this as well. > > >=20 > I can take a stab at converting it to something suitable for inclusion=20 > under tools/regression. One issue is that the test uses a heuristic to=20 > determine success or failure. I don't really see a way around that,=20 > although it certainly could be improved. This is sort of what I mean about tweaking, besides using the standard test report format. If you provide complete patch for test case, somebody (or me if nobody else volunteer) will definitely commit it. --iQrD/dScPhU9JStb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCysVAAoJEJDCuSvBvK1B9VAP/ika/6y8YlZQ7KN/mIx8shvM A+wZaIYlS7ahHeyAKKfzS+591qwTlmcB4xP101m4jSSJvm3REFmTcA3UjmQyu6Jc HQNcvUfoynbZyhQWm8vQk3wVKv8XEjQ9v9rDSaacA0CX/hVd/PD+4e75q8w8/jaF HiG7voQd/zDXCGz6rQfRvRG6O/S+xZqaT7n0UZpmABZmZu+ZA24wHB1+SEFQAwrQ OyiQzhe+HdVm4X8tzsrIb5G95lzLwJ0FUFU+qhcDwxN1XVMz4xxSNWdmPlgLWDc5 IZ3QRFvUqDcA/RaamBmRuKuodvqhj+nUbHIZWxMO0voxeNx0fVcfy3k00MIyDRmJ MTFknpAZYbzIycHv0Wj3R89SmlBPzTocaiLUfnQntEKUudBqm2uIpSWa9WUks5IP +B8FJTemRrR3BGhCCh++UwNKplhqE4H//UbhtPiPcg2oC101j3TeTAijZGKJX63y V3gYXLyu0H4ED9txJDDz3rxW3tFC4Fg/O4y7OkfbnqMyT51lA+3TUMcpidojrypP IflsyLSQqn7HV600x46CFFSZmK/PBgu/VqZOUl4dihmEdUcDcCxzIbpbjx9bewTC XKTqQsWYOcjYnia44HYPkh4i1qGKOJ082wW5XsH1WdnSVX7LlRBtpoa0CeWIxUw+ iJ3mKt1Frf47N9yC0Z2n =2RJr -----END PGP SIGNATURE----- --iQrD/dScPhU9JStb-- From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 19:06:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1054CC4; Sat, 6 Sep 2014 19:06:17 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id B268519CB; Sat, 6 Sep 2014 19:06:15 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 6 Sep 2014 15:06:09 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Sat, 6 Sep 2014 12:06:08 -0700 From: "Pokala, Ravi" To: "Sinha, Prokash" , "jhb@freebsd.org" Subject: Re: freebsd-hackers Digest, Vol 594, Issue 5 Thread-Topic: freebsd-hackers Digest, Vol 594, Issue 5 Thread-Index: AQHPycod3KXCJVYQj0yC5DwayeCbt5v0mSKA Date: Sat, 6 Sep 2014 19:06:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <2863A5586548A84099F931833BC059BB@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2014 19:06:09.0088 (UTC) FILETIME=[9DF6D400:01CFCA05] Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 19:06:17 -0000 >Date: Fri, 5 Sep 2014 11:18:50 -0400 >From: John Baldwin >To: "Sinha, Prokash" >Cc: "freebsd-hackers@freebsd.org" >Subject: Re: PXE boot >Message-ID: <201409051118.50416.jhb@freebsd.org> >Content-Type: Text/Plain; charset=3D"iso-8859-2" > >On Thursday, September 04, 2014 5:23:19 pm Sinha, Prokash wrote: >>On 9/4/14 2:22 PM, "Sinha, Prokash" wrote: >>>Yeah, something going on that I don't understand. I defined that macro, >>>and for quick verify - >>>make -v >>>Warning: Object directory not changed from original >>>/.automount/nfs.paneast.panasas.com/root/home/psinha/psinha-bug-pa/src/f >>>re >>>e >>>bsd-c/sys/boot/i386/pxeldr >>>cc -O2 -fno-strict-aliasing -pipe -ffreestanding >>>-mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>>-mno-sse3 -m32 -march=3Di386 -DALWAYS_SERIAL -c pxeldr.S >>>cc -O2 -fno-strict-aliasing -pipe -ffreestanding >>>-mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>>-mno-sse3 -m32 -march=3Di386 -DALWAYS_SERIAL -nostdlib -m elf_i386_fbs= d >>>-N >>>-e start -Ttext 0x7c00 -Wl,-S,--oformat,binary -o pxeldr pxeldr.o >>>make: don't know how to make pxeboot.8. Stop >>> >>>=3D=3D> The variable is defined and the correct flag is included in the = cc >>>... >>> >>> >>>But I still don't get the messages from pxe_enable or pxe_init... >>> >>>Need to sit back and look further... >>> >>>John, much appreciated for the help... > >Weird. Are you using COM1 at 9600? Aside from that, do you get logs of >calls >once interact() starts and loader.conf is parsed? Prokash and I work together, so I can answer this one. :-) We are using COM1, 9600-8-n-1. We get the normal loader splash-screen / menu on the serial port. -Ravi >-- >John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 19:57:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E00A318 for ; Sat, 6 Sep 2014 19:57:42 +0000 (UTC) Received: from bein.link (vps-6159-8629.cloud.tilaa.com [37.252.124.82]) by mx1.freebsd.org (Postfix) with ESMTP id 254801E2C for ; Sat, 6 Sep 2014 19:57:41 +0000 (UTC) Received: from quad.localnet (unknown [188.134.8.193]) by bein.link (Postfix) with ESMTPSA id D511640520 for ; Sat, 6 Sep 2014 21:57:38 +0200 (CEST) From: Maxim V FIlimonov To: freebsd-hackers@freebsd.org Subject: What to do if USB stack seems dead Date: Sat, 06 Sep 2014 23:57:37 +0400 Message-ID: <1455331.JKPkSxLmbq@quad> User-Agent: KMail/4.12.5 (FreeBSD/10.0-RELEASE-p7; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 19:57:42 -0000 Lately, I've been heavily experimenting with different USB devices (for instance, USB to TTL one, but that's another story), and at a moment I encountered that the system doesn't react on new USB devices connected. The connected devices work fine, though. The question is: what can I do in such a case if I don't want to reboot my box? -- wbr, Maxim Filimonov che@bein.link From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 6 21:21:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFD94374 for ; Sat, 6 Sep 2014 21:21:23 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DE0C17DB for ; Sat, 6 Sep 2014 21:21:22 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 45AD91FE027; Sat, 6 Sep 2014 23:21:14 +0200 (CEST) Message-ID: <540B7AC4.9060504@selasky.org> Date: Sat, 06 Sep 2014 23:21:08 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Maxim V FIlimonov , freebsd-hackers@freebsd.org Subject: Re: What to do if USB stack seems dead References: <1455331.JKPkSxLmbq@quad> In-Reply-To: <1455331.JKPkSxLmbq@quad> 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.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 21:21:23 -0000 On 09/06/14 21:57, Maxim V FIlimonov wrote: > Lately, I've been heavily experimenting with different USB devices (for > instance, USB to TTL one, but that's another story), and at a moment I > encountered that the system doesn't react on new USB devices connected. The > connected devices work fine, though. The question is: what can I do in such a > case if I don't want to reboot my box? > Hi, If a TTY port is not closed, it will prevent other USB devices on that particular USB controller from enumerating. --HPS