From owner-freebsd-hackers@freebsd.org Sun Apr 1 00:27:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7076EF6B935 for ; Sun, 1 Apr 2018 00:27:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 015817EF73 for ; Sun, 1 Apr 2018 00:27:33 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ot0-x232.google.com with SMTP id j8-v6so5135240ota.7 for ; Sat, 31 Mar 2018 17:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0058BcE/Rfm9GBXM97Y9/r5DWPutpSepDf28BnU7g4U=; b=sAoiWT6d1PO2rZqhfbOqoXSK411Hkbp21FjrZvRbUsD6oUQvZXX+dPA3KGw+h3HJEc eHoiTJ9tIn2fkSIEEFVOgNzAYO970OnwTCHDndX1LdIwtW0tE6TPkcLV2WgLvjt7Y4rx 0Las6epzsVZgdRbzm4dMO7PW+3FQGfmr7Lekv2PwVWmM+Jr9xGZcv+PWcVjt5GEZDCFc YkG5pG6JFgGCZIw3OLSvB5UYSabbaISbIJN+DI20xBpnKSFxAZROagUJBXiOKk53zxP1 MDTmhoyXPMlqWHZWZxUtHw6qtYSxz1rgkKitOE6CVt9aivITEenChqXphOW119CVZKEJ hRuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0058BcE/Rfm9GBXM97Y9/r5DWPutpSepDf28BnU7g4U=; b=oCA5dn3vLwwHylUXXIz8qDwf4OmM4uxQSbFWlZlDwwGuAQVrX4N5yQ+IfMTH9aKlST JLUyKNWekX1xo2vz0sQTCunFKipG04MjtjyPI/9INqZLFw0hxoLHVHTqFGm/0RXMjqn2 8Gmy/WIfnCeT4Dv/oapjuXUhpcMP96yVAq+5MiVITBvZMRJBjudx/eNh0tcWthfjGlPj om1y1A52fLv9HS6YpmZPSqn3AgLnP2K74SsXu8dWcLWAx0kbj1HLAWtbUvSDxgyTSXy/ VydBZpy+tfIqmsXB/ioYjZ9kes4Pv49pGNVMnbUr1wzSnzxiKS3IwVCp6W5CLPjlQvpw 4qsQ== X-Gm-Message-State: AElRT7Hk8Bmwlm/5Dvbg5kGDxUXx6xMwGNDP/d1HV4pjajyabGW/j8Hh X2rR1JDd/lP3vT8E8b+kveqvWwzRew4FKxdD4CNYsQ== X-Google-Smtp-Source: AIpwx4/xKSsJTaA61XYYyacRFxR9cwtvu7rAwRfuUaLnZw3wx2CuwnRt32G/OSzs9RuNeA7NDOwHbxIxLb+sQdEhq9c= X-Received: by 2002:a9d:621a:: with SMTP id g26-v6mr2434589otj.288.1522542452039; Sat, 31 Mar 2018 17:27:32 -0700 (PDT) MIME-Version: 1.0 From: Ben Woods Date: Sun, 01 Apr 2018 00:27:21 +0000 Message-ID: Subject: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 00:27:33 -0000 Hi everyone, Please review my patch to add the -Z option to syslogd(8) to use ISO 8601 timestamps in UTC: https://reviews.freebsd.org/D14918 This patch was taken from OpenBSD, and is the first of many features from RFC5424 that we should be looking to add to syslogd(8) in FreeBSD. BACKGROUND: I have been centralising my logs lately, and found that they had different timezones, but the RFC3164 syslog timestamp format does not include the timezone. The servers had their timezones set to UTC, whilst the workstations had their timezones set to the local timezone. This made it difficult to correlate events across machines, as my log analysis tool had simultaneous events entered with timestamps many hours apart. I have added a few people to the review who last touched syslogd(8) - sorry to those people, just trying to get reviewers :) Regards, Ben -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-hackers@freebsd.org Sun Apr 1 03:25:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A13BF77409 for ; Sun, 1 Apr 2018 03:25:41 +0000 (UTC) (envelope-from julian@freebsd.org) 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 EE13486300 for ; Sun, 1 Apr 2018 03:25:40 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-20-68.dyn.iinet.net.au [115.166.20.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w313Pa79042014 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 31 Mar 2018 20:25:39 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: Ben Woods , "freebsd-hackers@freebsd.org" References: From: Julian Elischer Message-ID: <4fd424ca-ff93-315c-fa87-fb9c738b9b50@freebsd.org> Date: Sun, 1 Apr 2018 11:25:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 03:25:41 -0000 On 1/4/18 8:27 am, Ben Woods wrote: > Hi everyone, > > Please review my patch to add the -Z option to syslogd(8) to use ISO 8601 > timestamps in UTC: YES!  I was just looking into doing this myself.. Just goes to show that if one procrastinates enough, someone else will do the work! is there a matching change for syslog(3) to actually generate new timestamps? The syslog protocol is unique that either end can be responsible for the timestamp. In the case of the new timestamp form you would have to strip off the incoming old form timestamp and replace it. From owner-freebsd-hackers@freebsd.org Sun Apr 1 03:45:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97F8CF784AF for ; Sun, 1 Apr 2018 03:45:16 +0000 (UTC) (envelope-from raul.palomaki@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F24C086F23 for ; Sun, 1 Apr 2018 03:45:15 +0000 (UTC) (envelope-from raul.palomaki@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id a22-v6so16803808lfg.9 for ; Sat, 31 Mar 2018 20:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=BLULDcum1wXIJIt5wqw5ApXIPkmV41PS8vGdDdN3owo=; b=O0+ZCCE9MIIi54chhb7hwW86K1HON/fpUfIESDKDewUjBVrxC4qIJxElFjUVuYsSqo CKX0/V2OthKM8kk7oUQX3pC6p6kRRZsgOZiRqQk35NR0KnCX7g42xI6VL7sN5CJAFBuW 0FoYBxhdQEyjCWP1GvDqE+e3va94oO3QApCJn9N2ZJqN/Q/HJd/dpf8qDhKOpABHorrs NO7QWw71iL0ylydW9rojKfUDYEslBu7EAxlZ0/aTzTOBltwXaISsJsN2erSv5R6DKUZt Z2l013nS/H069GOyua3wZ5Rl++cpAJ+JgqpP3khRCzZYbC6jPh/MPAfKj52X6hzhsfaj cstw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:in-reply-to:user-agent; bh=BLULDcum1wXIJIt5wqw5ApXIPkmV41PS8vGdDdN3owo=; b=GU6FYsvHvnmUtTMlsvi/5t9Z6hdOoNg/UtmK7CbWUFv1mk1ocrHXe8ffQdt2FDZp0q /xQRJK0WBLohVyAYG/mpPTTHXL51lStUmmgnhR0WLjkZlYFen74L/v+vWW3xTkK60102 FY3ANN8sLdZi5Pch8lAsbXLGNJUgTRsgP/VX82RgkCcRzjIBuhO/+4PSFmQ6b+4V443c DSZyTG2f0BuLkQLdVerzsI53BWvDUf/D93J/swh6XWk9NUjbD7xHjLc4/txWtjDRdLzj EuqM1aRmkyt17Q2z/iLLtGE14VLPpf0ardRpOZETpYLc1WNNNr6e4xXZXxnmhgMOhlsf cztg== X-Gm-Message-State: ALQs6tAKQnwB0htuyN6sMipLUfFYODYXoSrQ9QFSJGb06VvgfsWmvqVe AoEt5qSwNiGAYGuuSb19H4YJV+d8 X-Google-Smtp-Source: AIpwx48p32K3euk0NYbRSRF2xO8wJxDppFxOWvv2dt25qX79AUKtwhpb5W289IalwLyZ8CF35Wz7Dg== X-Received: by 10.46.56.6 with SMTP id f6mr3012636lja.4.1522554313860; Sat, 31 Mar 2018 20:45:13 -0700 (PDT) Received: from tardis (dc376zynwcb3---v08zzy-3.rev.dnainternet.fi. [2001:14ba:15f7:aa01:7210:6fff:fe3e:e528]) by smtp.gmail.com with ESMTPSA id i125sm162180lji.26.2018.03.31.20.45.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 20:45:13 -0700 (PDT) Sender: Raul Becker Date: Sun, 1 Apr 2018 06:45:15 +0300 From: raul.becker@iki.fi To: freebsd-hackers@freebsd.org Subject: Re: Realtek RTS525A SD card reader Message-ID: <20180401034514.t4idseuyg53gap7g@tardis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171208 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 03:45:16 -0000 Hi, I somehow got the same idea just recently that it would be a fun learning experi ence to try to port rtsx from OpenBSD to FreeBSD and getting at the same time mo re familiar with C. I practically have zero experience in writing drivers. But I think that the relevant OpenBSD driver files are rtsx.c rtsxvar.h and rtsx reg.h. Browsing through the FreeBSD src/sys/dev directories for any of the curre ct drivers to see how the drivers are meant to be implemented in FreeBSD I found src/sys/dev/sdhci as a possible candidate. There are already driver modules for the sdhci.c which are atleast sdhci_pci.c, sdhci_fdt.c and sdhci_acpi.c. They a ll follow same organization where in the end they map the DEVMETHODs what the sd hci expects to get I believe. The sdhci_pci.c was abit overwhelming with all the quirks so I thought that maybe rtsx driver could be instead a separate driver m odule like sdhci_rtsx.c for example. This separation I think would be helpful es pecially when not too familiar with C and because it looks of like the task does not seem to be that straight forward to do either. The other mmc drivers are mo stly spread out and many are for arm boards. It would be sweet if someone could confirm that src/sys/dev/sdhci is a good loca tion where to try to implement a driver module and/or point at the right(er) dir ection. My device: none2@pci0:2:0:0: class=0xff0000 card=0x221417aa chip=0x522710ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS5227 PCI Express Card Reader' -- Raul Becker p.s. I hope this time I got the In-Reply-To header right. From owner-freebsd-hackers@freebsd.org Sun Apr 1 07:06:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 601CEF54DC1 for ; Sun, 1 Apr 2018 07:06:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F118A77EF2 for ; Sun, 1 Apr 2018 07:06:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id d5so14959602iob.9 for ; Sun, 01 Apr 2018 00:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DqoZ2ULNHu7P004Bg0QBQLuTu5RWlKxQ1b9qpJe3P7M=; b=KKec1KV24LhN/O7JnGwId0q115pJPSD5Lu906uUdtW7hq6VtkkGQsHG9zkIMqPGqZm 2Ah+Xii+1OcDhsgSpKjYLh3E0m/1nOBXLQ7+7Yp8JWWXCGzdVpJMf9qb0jjPe8SDA126 eXxf+fLbLf6p3rDXx8/aWXArVoDgLfYwg2uLzW9o4LStOIbQoM9eXxpWaU6sEkC1Ptbx pvWmMZzu4C9QP0/GAcIkHtmaK1Wbx5dGmW1QV+rlThZh8yrzzXFnsWOJm3U3fjJPlHn7 b9IjCT9XZJl6zeZaqb9MnTSjW4HNC4WXhWTyREirAKeSNOSw1oRe9raZpEEBu3kz0sto 3XZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DqoZ2ULNHu7P004Bg0QBQLuTu5RWlKxQ1b9qpJe3P7M=; b=Oq5XKBazEWk4JDBgPpEmiCfZi045CQVbc98KLspfA/lJvcFOS8kkFz0BkS9T1T1/FS pvKDQa3vW+LVLoVBkfidwHnP+fQRVrjP5ty253Dl186wXIqBL3dIC/dKdlaK5UT1/aqn U94JRNEHARSIUWFmhMA9jRHvh9laFJ6wpWrs8Qq1wFng+EJzvyZG7FymX2CrUAPRLoyx 8cRGJVD+pEMb3jUioykmzDrUn9hGL+9Pn113pb7UwEzfRkzso6mKqml4221sJ/Cbn6/c gcx+M3p4Vp+kB4LBh7wFBcDesqjNxnzsJ29ogvNZthGmuTnhAb7g9KbCImskhQCioAde t8ag== X-Gm-Message-State: AElRT7Frn4z8Z9KDL0eUlq7QOiVltoyNEEc/mqpPvqtf0gGx3VAjexdW xJ0e1youl/HBjbQ17G8v6E721kQX0YcUD7v5QoeDWQ== X-Google-Smtp-Source: AIpwx48mdnZe0dfY1yo/PsVVBTewBiDKIil1BhrFsm2y1hS3MGDqVfpYNIUY2e0n6RBaDquWKWNssXkA2xlDwuylUfQ= X-Received: by 10.107.58.134 with SMTP id h128mr4449700ioa.299.1522566384992; Sun, 01 Apr 2018 00:06:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Sun, 1 Apr 2018 00:06:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180401034514.t4idseuyg53gap7g@tardis> References: <20180401034514.t4idseuyg53gap7g@tardis> From: Warner Losh Date: Sun, 1 Apr 2018 01:06:23 -0600 X-Google-Sender-Auth: O1hrrkoEztxQQVen5CkTl61pCGM Message-ID: Subject: Re: Realtek RTS525A SD card reader To: raul.becker@iki.fi Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 07:06:26 -0000 On Sat, Mar 31, 2018 at 9:45 PM, wrote: > Hi, > > I somehow got the same idea just recently that it would be a fun learning > experi > ence to try to port rtsx from OpenBSD to FreeBSD and getting at the same > time mo > re familiar with C. I practically have zero experience in writing drivers. > > But I think that the relevant OpenBSD driver files are rtsx.c rtsxvar.h > and rtsx > reg.h. Browsing through the FreeBSD src/sys/dev directories for any of the > curre > ct drivers to see how the drivers are meant to be implemented in FreeBSD I > found > src/sys/dev/sdhci as a possible candidate. There are already driver > modules for > the sdhci.c which are atleast sdhci_pci.c, sdhci_fdt.c and sdhci_acpi.c. > They a > ll follow same organization where in the end they map the DEVMETHODs what > the sd > hci expects to get I believe. The sdhci_pci.c was abit overwhelming with > all the > quirks so I thought that maybe rtsx driver could be instead a separate > driver m > odule like sdhci_rtsx.c for example. This separation I think would be > helpful es > pecially when not too familiar with C and because it looks of like the > task does > not seem to be that straight forward to do either. The other mmc drivers > are mo > stly spread out and many are for arm boards. > You don't want a sdhci_rtsz.c. sdhci is the name of a protocol to talk to a device. PCI is the bus attachment. rtsz is a different protocol to talk to a device, so it should be it's own driver. > It would be sweet if someone could confirm that src/sys/dev/sdhci is a > good loca > tion where to try to implement a driver module and/or point at the > right(er) dir > ection. > sdhci is a good, full function driver. However, it handles a lot of odd-ball exceptions and edge cases common in a popular interface that's chasing an evolving standard, so it may be a bit overwhelming. Here's a quick outline. You'll need a rtsz_pci.c that handles claiming the device (probe) and initializing it (attach). Most of the initialization will be the same as OpenBSD, though the glue into the system is somewhat different between OpenBSD and FreeBSD (which is why I'm suggesting rtsz_pci.c to help keep that walled off). busdma is similar, but the details are different between the systems. They've evolved from a common ancestor, though, so that's good. Bus_space is the same, but the resource allocations will be different (see bus_alloc_resource). Interrupt handling will be different. The interface you want to look for is the mmcbr_if.m inteface. In sdhci, these routines implement the mmc interface: sdhci_pci.c: DEVMETHOD(mmcbr_update_ios, sdhci_generic_update_ios), sdhci_pci.c: DEVMETHOD(mmcbr_switch_vccq, sdhci_generic_switch_vccq), sdhci_pci.c: DEVMETHOD(mmcbr_tune, sdhci_generic_tune), sdhci_pci.c: DEVMETHOD(mmcbr_retune, sdhci_generic_retune), sdhci_pci.c: DEVMETHOD(mmcbr_request, sdhci_generic_request), sdhci_pci.c: DEVMETHOD(mmcbr_get_ro, sdhci_generic_get_ro), sdhci_pci.c: DEVMETHOD(mmcbr_acquire_host, sdhci_generic_acquire_host), sdhci_pci.c: DEVMETHOD(mmcbr_release_host, sdhci_generic_release_host), rtsz will almost certainly need it's own versions of these routines (which is why I suggest having your own driver will be simpler: otherwise each of these routines would be if (rtsz) do_rtsz_stuff(); else do_sdhci_stuff(); which won't end well and would be uncomittable to FreeBSD. You can see how other chips implement these methods by grepping for them in the tree. You may not need a tune/retune if rtsz doesn't support the latest, fastest cards, for example. Switch vccq may not be needed either. update_ios will be needed, and request is needed. Acquire and release host may be able to be done as a dummy routine if there's only one slot. I know this is a super-quick gloss of what needs to be done. Warner > My device: > > none2@pci0:2:0:0: class=0xff0000 card=0x221417aa chip=0x522710ec > rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTS5227 PCI Express Card Reader' > > -- > Raul Becker > > p.s. I hope this time I got the In-Reply-To header right. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sun Apr 1 10:24:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C674BF80400 for ; Sun, 1 Apr 2018 10:24:59 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D96D826DD; Sun, 1 Apr 2018 10:24:59 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id f47-v6so4318797oth.2; Sun, 01 Apr 2018 03:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xpd4lSXq+pjYwP4TVATcHAtMF587pqHGpz2Ru3KzZPs=; b=juF6g/LlJ552j78u2JxCXWBTXsGJGY9tp2lB4kQzJvyHryv6YWmuenNXJGbPw8RkOb 7qA2rBi+ZtSWFO29GeM4+FohI0Z5FK/3rWpRovif3QbVAM2iWcmSfhVkP0HvB4TRfexT tpWEZMlzD5BoFzsvHaQXRsBCtW8tc9HJLM2fUucfgxFDSTBXsyO/4Q3Nlrh0TNVMeJVQ AEblt/rq4EVD9JFW8SHfgsGavpMVNSUVg5d8zrQQy1t4A2hme7KgG6QcH9Mr5sWc7pR8 iOyxUbHfT2iSP7TYedReVhErBBCMfabiAHM0p8O1XsiSZH+F1hvwMIguTaZzQBzYqU0w k6rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xpd4lSXq+pjYwP4TVATcHAtMF587pqHGpz2Ru3KzZPs=; b=cKacDVgmiE/WRNDZ5SUYCRZm6qMlK9pl6v4hcR8JpRKZkDw34ElJ8pOw9biiq4zgCC DEk/Wbz0DjK8EyZUeXjU32VTAUkm++Sht8vVkvX1hhMTru8PsKPUINm1arhL6S9taiAe cPqays8HGVm8cFzJKLQvl8/S0SzA8BlRugJHpjJPCS0+NODJcAi5ML2fxRtQGh1LfFOh B31cdM2jdEl9aYP6JAYPpPcYQOaPy385nsnJoVAMS+Pgn3NFCO/MNmKFfeuT+DbPWP1C ZM5zS2foW9hLt0yQ3EBGidzCcm/ugxW828IKPd5zmjmBX0VzL93DEiRMFx+1WA1wOvSf hhMQ== X-Gm-Message-State: ALQs6tDWAuXJCL/Crx70Zqz5X3myueEmRBasygbHpoENCnxb3dSjKCE7 JJqE4lcuDJPRWtVKRN3HygGaPGh6ift5J6C8Nws3PFoj X-Google-Smtp-Source: AIpwx4/SqXQhwg6IqiLzFV7pFU6+Txs0xbe8MBDf48/d6r+z3IwWHSgLY7VpSVe8/d4gu6SQkj/iDGdJE0ExaJyJrmU= X-Received: by 2002:a9d:2785:: with SMTP id c5-v6mr3456907otb.260.1522578298467; Sun, 01 Apr 2018 03:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.15.247 with HTTP; Sun, 1 Apr 2018 03:24:57 -0700 (PDT) In-Reply-To: <4fd424ca-ff93-315c-fa87-fb9c738b9b50@freebsd.org> References: <4fd424ca-ff93-315c-fa87-fb9c738b9b50@freebsd.org> From: Ben Woods Date: Sun, 1 Apr 2018 18:24:57 +0800 Message-ID: Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: Julian Elischer Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 10:25:00 -0000 On 1 April 2018 at 11:25, Julian Elischer wrote: > is there a matching change for syslog(3) to actually generate new > timestamps? > > The syslog protocol is unique that either end can be responsible for the > timestamp. > The approach the OpenBSD team has taken has been to remove all timestamping from syslog(3): "Do not include a timestamp in the syslog message. There is no need -- syslogd will fill it in immediately upon reception on the other side of sendsyslog(2). Our libc only talks to our syslogd, which will fix the timestamp before forwarding. syslog_r has done this for a long time already. ok tedu bluhm" https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/syslog.c.diff?r1=1.32&r2=1.33&f=h https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/syslog_r.c.diff?r1=1.9&r2=1.10&f=h The FreeBSD syslog(3) code still adds a timestamp, so there is an option to either remove this code from syslog(3) similar to OpenBSD, or update the syslog(3) code to support either timestamp. My testing shows that if syslogd(8) is not running at the time a message comes in from syslog(3), the message is dropped (not buffered until syslogd is once again running). This means there would be no significant time delay issues causing incorrect timestamps if syslogd(8) adds the timestamp instead of syslog(3). https://svnweb.freebsd.org/base/head/lib/libc/gen/syslog.c?revision=326025&view=markup#l171 Note that when testing my patch with the logger(1) tool, which uses syslog(3), I have found that the RFC3164 timestamp format applied by syslog(3) is replaced with the RFC5424 timestamp format in syslogd(8), as per the description below. In the case of the new timestamp form you would have to strip off the > incoming old form timestamp and replace it. > Indeed. This is handled by the changes in the parsemsg() function, which effectively sets the -T option (RemoteAddDate = 1) if it detects the old timestamp format when the -Z option has been set. Note that my proposed implementation does not convert the old format to the new format (and assume the current year), but instead simply strips the old timestamp and applies a new one. This is as per OpenBSD's implementation. Regards, Ben From owner-freebsd-hackers@freebsd.org Sun Apr 1 14:13:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3A66F9E99E for ; Sun, 1 Apr 2018 14:13:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 458706E230 for ; Sun, 1 Apr 2018 14:13:51 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e34b07f2-35b6-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e34b07f2-35b6-11e8-91c6-33ffc249f3e8; Sun, 01 Apr 2018 14:13:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w31EDdwk075763; Sun, 1 Apr 2018 08:13:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1522592019.49673.166.camel@freebsd.org> Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps From: Ian Lepore To: Ben Woods , Julian Elischer Cc: "freebsd-hackers@freebsd.org" Date: Sun, 01 Apr 2018 08:13:39 -0600 In-Reply-To: References: <4fd424ca-ff93-315c-fa87-fb9c738b9b50@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 14:13:52 -0000 On Sun, 2018-04-01 at 18:24 +0800, Ben Woods wrote: > My testing shows that if syslogd(8) is not running at the time a > message > comes in from syslog(3), the message is dropped (not buffered until > syslogd > is once again running). > This means there would be no significant time delay issues causing > incorrect timestamps if syslogd(8) adds the timestamp instead of > syslog(3). > https://svnweb.freebsd.org/base/head/lib/libc/gen/syslog.c?revision=3 > 26025&view=markup#l171 The important issue with source-side timestamping doesn't have to do with whether syslogd is running or not, it has to do with mutiple threads and processes feeding data to syslogd at high speed and accurately timestamping the events being logged. Mutexes are involved in libc syslog(3) for multithreaded apps, and buffers are involved which can lead to arbitrary ordering of messages generated by various processes, and only source-side timestamps can make it clear in what order things really happened. In addition, milliseconds are not nearly fine-grained enough for fractional seconds. Even microseconds aren't really good enough on modern hardware. -- Ian From owner-freebsd-hackers@freebsd.org Sun Apr 1 19:33:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30C4BF76AC6 for ; Sun, 1 Apr 2018 19:33:58 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 995937A288 for ; Sun, 1 Apr 2018 19:33:57 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-lf0-x241.google.com with SMTP id c78-v6so18220015lfh.1 for ; Sun, 01 Apr 2018 12:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iPU7MxA08wctjLm7nCPyNOnmaCnqH/UBY/npTlH6xoA=; b=TatQ81diHjKcbqogvXvXFeBiX0K+kU8/J631Tkz6coEClL6F9G6QckMCYtubfTHzgl /m8/Gp8az1y6K678fTpdLbHciDLZrzGQNyHEYfReh9cBQHX2SbbA6Cw9JRYjTzI+mFGL +izIw3FZjEryJRcyXIju+1I7pYn+PA3sp2QwnYgWygMOD1HmWgERN7y3c+27swjt7vYJ VVeftvaioPKOcVrpilrtPzG2uEJ5Gya0C+KyieIKAfunNy2epBplyAN6SdhJhSgCSYlL fXouA6ejBc3cdx6qPU0Ve7trgWzssydYBjKWN6Wo0cMZ6ubq+Nj5YOJQ5WYPm6BlphtQ o0iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iPU7MxA08wctjLm7nCPyNOnmaCnqH/UBY/npTlH6xoA=; b=Et4u1SvRc9RHPg99Y5BBozSNFoaKmum9DLabPwkHpdHt/1snjlutqe2rAegW0zcu3j ECA47f110S2WHcIfRMBX209MmEeSRXLdA//TI1Nd6dkC/LYwce2iQsr4ydYmfP/+mSMs xRxD0K6Il2Wv0KKn/FSW/j0VrjsuMl+aiX+HbIM8Jh02Kme2AOpRt8TtK7kgdp9jJfR6 mKBVlMRzUaBCqshe8FMoSd1Y6h5qNz3R4So7YWRDjjL0bHrpwDTlN/po/ktqGtr98DAd 8+Us0oIVa9FK9nbJCzqZFi58TzoNiNCuGFFkcpxLjKS3odzhRbjtlHIVCTram31vQJoo 5p7g== X-Gm-Message-State: AElRT7HiinPgqlf0EJ38JgzUpRl1IHpfQbeIrkE6xt8XdSNChD7RMP8X jv8memiB6lZOcoIZAyOU6VvMMzzDvcfXYzr5n5tqzQ== X-Google-Smtp-Source: AIpwx4/GaNqmP/U6R/QtFETEIv3GBL6Fu5IqCePf4BZTKJrFBxcdEbLxS0sJZmMpiX7pI3nnW+A3dJ/h1tDbBBQPFFY= X-Received: by 10.46.156.149 with SMTP id x21mr4058558lji.81.1522611235140; Sun, 01 Apr 2018 12:33:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e9c2:0:0:0:0:0 with HTTP; Sun, 1 Apr 2018 12:33:24 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Sun, 1 Apr 2018 21:33:24 +0200 Message-ID: Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: Ben Woods Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 19:33:58 -0000 Hi Ben, 2018-04-01 2:27 GMT+02:00 Ben Woods : > Hi everyone, > > Please review my patch to add the -Z option to syslogd(8) to use ISO 8601 > timestamps in UTC: > https://reviews.freebsd.org/D14918 > > This patch was taken from OpenBSD, and is the first of many features from > RFC5424 that we should be looking to add to syslogd(8) in FreeBSD. > > BACKGROUND: > I have been centralising my logs lately, and found that they had different > timezones, but the RFC3164 syslog timestamp format does not include the > timezone. The servers had their timezones set to UTC, whilst the > workstations had their timezones set to the local timezone. This made it > difficult to correlate events across machines, as my log analysis tool had > simultaneous events entered with timestamps many hours apart. > > I have added a few people to the review who last touched syslogd(8) - sorry > to those people, just trying to get reviewers :) Wow! That's a coincidence. I actually started working on something in the same area a couple of days ago. One of our customers requires sub-second precision of log entries, which is why I implemented RFC 5424 support for FreeBSD's syslogd a couple of days ago. I sent out a pull request a couple of minutes ago and only noticed your email just now. https://reviews.freebsd.org/D14926 This patch doesn't change the output format of syslogd. It only adds the RFC 5424 parsing and changes the internal model of syslogd to be based on RFC 5424. Changing the output format to use ISO 8601 formatting was planned for a separate change. What are your thoughts on my pull request? If you like it, maybe it makes more sense to land my change first before applying yours? -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-hackers@freebsd.org Sun Apr 1 21:33:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 796E2F7D6C2 for ; Sun, 1 Apr 2018 21:33:56 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic312-22.consmr.mail.gq1.yahoo.com (sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F37407EB64 for ; Sun, 1 Apr 2018 21:33:55 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: LJWjjPkVM1lBbkCAqLEhXZwCmfXs3q0ANb39gxtBjcY41nSItRNBGQAacqdb9JE QTVa715ZN4xVJyj0eGgUoF_tRcAs.0GgFCF0rgdUiADH4rfB9GQW3odgZnXYPHzvI3AEXwfM1JCJ YpNmFplqapjRCE.rFAHl1Zm.K2zHQjrRjPT_t4AXIMC772NhrT88bZZuu_G5K0i81Q.0edMLIUhI XoDIU9PcrzHZ_g8I60APqQ4lFUA901OL7HPFxDlO7figczbeckcvCtegXjpvFVWrR1BxVLZpd6V9 .2qxTHr76FvoqXNcVdUZO1y8i8dRl19ZcP3BSD_zGoGXXlr_LUBmwCFdlkVd8rroyqAYPh1y4E.8 yzvEp40AK9Tmz0pLiGUraQTkbepD5.J7lAoBEM_c6ZUBMr8MgJP_tVFyw1PQ2_sG0XoR9wHgFPID sH5NbDiTYd1Gzi.5rY5ZHesTK9AdxHnwAXqrJVUti9EYddC1FD5JM1tx3zKH4DpgDYxZtZ83WrEw zYQ6RincT1zDohvaBwiDeRddvghbEsg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Apr 2018 21:33:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c89bb7fd000d589b52f8f7b1312f48ea; Sun, 01 Apr 2018 21:23:37 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? Message-Id: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> Date: Sun, 1 Apr 2018 14:23:36 -0700 To: FreeBSD Current , FreeBSD Hackers , freebsd-amd64@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 21:33:56 -0000 For: # uname -apKU FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 = amd64 1200060 1200060 I get: . . . pci0: at device 7.3 (no driver attached) . . . intsmb0: at device 7.3 on pci0 intsmb0: Could not allocate I/O space device_attach: intsmb0 attach returned 6 on a Ryzen Threadripper 1950X where FreeBSD is being run under Hyper-V (on a Windows 10 Pro machine). Is this expected? Did I misconfigure something in Hyper-V? This may have been true for a long time and I just had not noticed until now. For reference: # pciconf -l hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x71928086 rev=3D0x03 hdr=3D0x00 isab0@pci0:0:7:0: class=3D0x060100 card=3D0x00001414 = chip=3D0x71108086 rev=3D0x01 hdr=3D0x00 atapci0@pci0:0:7:1: class=3D0x010180 card=3D0x00000000 = chip=3D0x71118086 rev=3D0x01 hdr=3D0x00 none0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 = chip=3D0x71138086 rev=3D0x02 hdr=3D0x00 vgapci0@pci0:0:8:0: class=3D0x030000 card=3D0x00000000 = chip=3D0x53531414 rev=3D0x00 hdr=3D0x00 # pciconf -l -v 0:0:7:3 none0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 = chip=3D0x71138086 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ACPI' class =3D bridge And . . . Hyper-V Version: 10.0.16299 [SP0] = Features=3D0x2e7f PM Features=3D0x0 [C2] Features3=3D0xbed7b2 Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.73-MHz = K8-class CPU) Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1 = Stepping=3D1 = Features=3D0x1783fbff = Features2=3D0xfed83203 AMD Features=3D0x2e500800 AMD Features2=3D0x3f3 Structured Extended = Features=3D0x201c01a9 XSAVE Features=3D0xf AMD Extended Feature Extensions ID EBX=3D0x4 Hypervisor: Origin =3D "Microsoft Hv" real memory =3D 53687091200 (51200 MB) avail memory =3D 52206305280 (49787 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs FreeBSD/SMP: 1 package(s) x 29 core(s) The local changes to /usr/src/ are mostly tied to powerpc64 and powerpc experimental activity, but there is some arm64 and arm material: # svnlite status /usr/src/ | sort ? /usr/src/nohup.out ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/dts/arm/a83t.dtsi ? /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts ? /usr/src/sys/dts/arm/sun8i-a83t.dtsi ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/modules/dtb/allwinner/Makefile M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/usr.bin/top/machine.c I've modified top to show "MaxObsUsed" (Maximum Observed used) for Swap when it is positive: Swap: 194G Total, 4235M Used, 4235M MaxObsUsed, 190G Free, 2% Inuse, = 416K In =3D=3D=3D Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sun Apr 1 22:03:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D038F7F114 for ; Sun, 1 Apr 2018 22:03:45 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3906800C0 for ; Sun, 1 Apr 2018 22:03:44 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io0-x231.google.com with SMTP id y128so16098772iod.4 for ; Sun, 01 Apr 2018 15:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GBJGU5TTiG0iwO5myeOUk8nBjMqzCdtTdcRbHIuXk4Y=; b=NBHeLZA/yKYpLisdeZHpwEo44rMNeJ7xUz8y8ZLLyGIqYQGhRKFBkHIM4+YhrgEzkY zRN7F6K7D4WhK6jYx6kO03iLGCVnNNKRz54o3e/tIvoFUVw8Sb82+F9CNLzejkFhEhKR lS0GBjSR3rtbp4QJ88wyESkNjWC2lCJZzKCP9eN3ueaHos2sJ0jJaI+ysfQAgDrX1LwZ RXyFwuTd8ElcJeacvy4AzquuxpWK4Y6G1CFPZX4fktJ1qWjM98qy+1Pwbn0tZoV9ugqT xo9bavaTCmloK+4qgSrcmIp3mcPnkXu19NJeQbNxGCGUzQRMAoOVMyjnR/awoq7UFLqS v0qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GBJGU5TTiG0iwO5myeOUk8nBjMqzCdtTdcRbHIuXk4Y=; b=eIbgCg7lC4yFB4V4K99scXK4Za3bSwdLHGFkCcdLWqoUx/wwHUIlqYxFIYhNdZkh38 IxniXNpyvACPJ6sW0jAqPVfzfWVxfTkKsL+aOPJvsVlJ1hNH7XPiibLCkU58/Yp9AMjO ThhvikV8j4qstXHe+IdMRhqeQ8QOOpu7zcEQOLAETexckzjKOPWUWgaHBy4gh+4IEPPs WMizpizJlmoUW3A82bu6L3MTJpMV1M5JHbe/upfG1W4T4wNrdk4oSfm6CYPZQkhshcoZ ETiXlKQd+gTZmF9xKP/p8pKqGcXPYUn8fUn5IKleTmW/RINRZi+ths07x/KYLveRBlKp Z0Aw== X-Gm-Message-State: ALQs6tDYru/zZurxsuw3hxKTqJJLEiMBVc+kH2lSu/Zc6HSYV1S4PqU7 KDBnVQcl8YBvL4j2Y7hHN0NKTDx6+pd1rgLTmw== X-Google-Smtp-Source: AIpwx48ZzldXBUIAH5dP9nZw4s5n6lW3/Zp84/FvbRyN/DGgH1D+yVVIbvFgANMAsfiLGcqok1nixssjVUg4zNBI/fE= X-Received: by 10.107.192.131 with SMTP id q125mr6324043iof.184.1522620223752; Sun, 01 Apr 2018 15:03:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Sun, 1 Apr 2018 15:03:43 -0700 (PDT) From: Zaphod Beeblebrox Date: Sun, 1 Apr 2018 18:03:43 -0400 Message-ID: Subject: On UEFI dual booting. To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 22:03:45 -0000 I've put in about 6 hours of trying to get UEFI dual booting to work. At this point, the "dual boot" part works fine, but the FreeBSD part fails in several interesting ways. In case anyone cares, the hardware is an HP zBook 15 (with no suffixes). It's a i7-4900 machine with a dual (Quadro 2100 and Intel) graphics personality. Don't worry about that bit, tho, we don't get that far. The system has two disks --- both sata. One is m.2 sata and the other is 2.5 inch sata. I've installed "refind" on the EFI patition that Windows created on the 2.5 inch drive. I'm trying to get FreeBSD to be happy on the m.2 drive. The FreeBSD install (so far) has a UFS, swap and ZFS GPT partitions. I can boot the 11.1 CD as UEFI. Critically, the 11.1 CD seems to use "loader.efi" directly. This works. The CD boots and is usable as such. The problem starts with boot1.efi. It seems to use text mode ... or 800x600... or something. It seems to work. Loader then runs in the same screen mode, but when the kernel starts, it's all over the screen... one pixel wide strips of white. Like the kernel is writing to the wrong resolution of screen. loader.efi also seems to get the size of things wrong. After filling 25 lines, anything you type or have displayed overwrites the 25th line of the screen. So... I can try starting loader.efi directly from the EFI partition. This, however, seems to completely ignore the partitions on the other disk (and their types). I've even tried using refinds "volume" setting and/or setting the command line arguments to loader.efi to tune either "currdev or rootdev" environment variables. The right partition (for the ufs pre-boot partition" is "part7:" in terms of loader. It would seem that I can get loader.efi to work IFF I put all of FreeBSD's /boot onto the DOS EFI partition. Windows only made it 500 megabytes, but I'm considering the hack. This may be the only way it works, but it seems it's not the way we "meant" it to work. So... asking the group: Is there a way for boot1.efi to support EFI graphical console, or, is there a way to get loader.efi smarter about searching for partitions to boot, or, can we get the kernel to better initialize the EFI console as it boots? Note, BTW, that the kernel never seems to get the console correct... even after booting. I can type blind, but that's it. From owner-freebsd-hackers@freebsd.org Sun Apr 1 22:55:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B64A2F819A4 for ; Sun, 1 Apr 2018 22:55:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4081F81F89 for ; Sun, 1 Apr 2018 22:55:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id e98-v6so16518660itd.4 for ; Sun, 01 Apr 2018 15:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yT23lzxxlbKlB6XYI9xPp5ZBqzDqs+TeDYRofgzCUFY=; b=UBhzqr2Ko8H6016NBD0Rm6xC0dFQP1JAB8TELD6B34Udr3I+OgBL9ILAeNnF8UcJKm Yca7ItHIpWy8TApXnYRUxzaECOl1fz66OMH4Lfw7fDlXF5p6S22P33LfnBwC8jGcjQuM cFKzC0iuBtr4LnVv1SQXfLblGG25p2wp9kerhXpvdCbBmiNbFyJf2lPyM5AcM9/67ZHu UmA34GYKFXo20VyQb27op1+VXWIRxrc4311VxNhcCg6+x78onW+QT22yGpl/4WfIfqA2 swcNa4T2x+m6w0uC7kDrEPgmB6nLRWz92U9eZ2LzXpHEVrNYSsF35wDg69uZUynamq8Q vZ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yT23lzxxlbKlB6XYI9xPp5ZBqzDqs+TeDYRofgzCUFY=; b=U+bE8BZK0tSdGmHSlBwuZQl0RIaZx5dG8JkrULhMrXI4l/OH/5o0Y5qKfmYISRDQ2j HtJr9Ugl/H5sYTjnZpL7ceUL2zHJCju6KrVKVcu7ibjBDeQ3r+l9ax6krRwMMp9s1bxK HhWwMGbz+MzSxdSl+S87p/5qGc9qGcOcp5B2Pj1S+wpEmJA9bYKZETzidKESThw06E7r qkhfPTYFSwHDj4J/BepteM5nkvbZ4l9bPhbIpZ4vxYdHsWXe1dwKxSv+ltslAIIVofB4 l/LPoBFik20gaHYwCFTTkdTy58DZWJzuUtOSWf93zuXk3LeCHBCDkaZNab3phPK0wY0B U1iw== X-Gm-Message-State: ALQs6tDbqhVbUBPbia9wRy84Qnkee71mRkLwemmQCyT/SU7verCMWPsB l0NB3fxoIrI3kAk811XPu7RqY2caszh1WSp74PrXOg== X-Google-Smtp-Source: AIpwx4/GzNnDYPIcusryA+9GsYCg9aaS1KTMoKRzzP7diPKhChRXCwlumpDfxrR3z0H1i4SEUzJw12VbNyoYVs078ME= X-Received: by 2002:a24:cac6:: with SMTP id k189-v6mr10246302itg.57.1522623336144; Sun, 01 Apr 2018 15:55:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Sun, 1 Apr 2018 15:55:35 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Sun, 1 Apr 2018 16:55:35 -0600 X-Google-Sender-Auth: 4JCCBcQzWR5WxDhMn0uSAoLOKIE Message-ID: Subject: Re: On UEFI dual booting. To: Zaphod Beeblebrox Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 22:55:37 -0000 Dual boot doesn't work with UEFI. boot1.efi and loader.efi have different sets of issues, but basically they guess what to boot, and that's incompatible with selecting this or that. This is a problem I've been working on for the past 9 months. I've peeled away many layers of this onion (and gotten side tracked by lua for a bit), but I'm finally back to the point where I have a loader.efi that can be on the ESP (the DOS partition) and that's setup to finish implementing the UEFI boot manager protocol.... Warner On Sun, Apr 1, 2018 at 4:03 PM, Zaphod Beeblebrox wrote: > I've put in about 6 hours of trying to get UEFI dual booting to work. At > this point, the "dual boot" part works fine, but the FreeBSD part fails in > several interesting ways. > > In case anyone cares, the hardware is an HP zBook 15 (with no suffixes). > It's a i7-4900 machine with a dual (Quadro 2100 and Intel) graphics > personality. Don't worry about that bit, tho, we don't get that far. > > The system has two disks --- both sata. One is m.2 sata and the other is > 2.5 inch sata. I've installed "refind" on the EFI patition that Windows > created on the 2.5 inch drive. I'm trying to get FreeBSD to be happy on > the m.2 drive. > > The FreeBSD install (so far) has a UFS, swap and ZFS GPT partitions. > > I can boot the 11.1 CD as UEFI. Critically, the 11.1 CD seems to use > "loader.efi" directly. This works. The CD boots and is usable as such. > > The problem starts with boot1.efi. It seems to use text mode ... or > 800x600... or something. It seems to work. Loader then runs in the same > screen mode, but when the kernel starts, it's all over the screen... one > pixel wide strips of white. Like the kernel is writing to the wrong > resolution of screen. loader.efi also seems to get the size of things > wrong. After filling 25 lines, anything you type or have displayed > overwrites the 25th line of the screen. > > So... I can try starting loader.efi directly from the EFI partition. This, > however, seems to completely ignore the partitions on the other disk (and > their types). I've even tried using refinds "volume" setting and/or > setting the command line arguments to loader.efi to tune either "currdev or > rootdev" environment variables. The right partition (for the ufs pre-boot > partition" is "part7:" in terms of loader. > > It would seem that I can get loader.efi to work IFF I put all of FreeBSD's > /boot onto the DOS EFI partition. Windows only made it 500 megabytes, but > I'm considering the hack. This may be the only way it works, but it seems > it's not the way we "meant" it to work. > > So... asking the group: Is there a way for boot1.efi to support EFI > graphical console, or, is there a way to get loader.efi smarter about > searching for partitions to boot, or, can we get the kernel to better > initialize the EFI console as it boots? > > Note, BTW, that the kernel never seems to get the console correct... even > after booting. I can type blind, but that's it. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Apr 2 10:22:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48898F82630 for ; Mon, 2 Apr 2018 10:22:09 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC71578030 for ; Mon, 2 Apr 2018 10:22:08 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ot0-x22c.google.com with SMTP id n40-v6so15150034otd.3 for ; Mon, 02 Apr 2018 03:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dc/jqHXb8z6U5Ef67tnsRpkB5O7Ua0OHG4RAYB0J/9c=; b=eHK93hi2/Ve5EZlRLAu9MV2odCfLiEeEjzU3f5TlaHa7NX5fVg+wbwMwZY9KAEFFl6 p/+lx3H3eJslkxoPx8R/Db5ySHSxglspUSdmj635nZn4XmXLVdZ15j1lpKDCbBc1JmK5 s5M4z7T9nC0Cch/ioz3Sg6ExF4s0jFRo2cvugetMCmxn4a7rWHP7tneBfaBA22nd28L+ hdvXDwo/3XSh1XRtVsTmCVW16WkwYUl20mN20LUzi6NdE5nKOcI0BwRi2cjpKa5Rswp0 IDLQVIRtFmSDC/qiKYxVZg5YQ7GZusg/xW5KJf4IjmkUhvsqxPf1G+xDSgLjn0oZsMmv cnXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dc/jqHXb8z6U5Ef67tnsRpkB5O7Ua0OHG4RAYB0J/9c=; b=IYea0PcmTTou8cHUwgRQ8da321vdGnl7EMviJ5WUyXExceKztSzuFXlp+GdGBmfBSH NJ2aH4mkEybqmqYMFgI7Zxo6TDeqai1EhI7cpBC7PWEpwk4Gi6vmSVfQp2L/0JWgf/8/ rUJc6e9xKvbXwBK5Ee2NMGbJhXLhqzwMUXiTH8dmIp38I0m6ZqGGodEMyc+JqTI3al8U EvbvHbWGvTKChz8rwyChJHlcZZFLhjvZc7D/Jhz9/QFw3cZINJgI8k7bUlpDsltyq6o/ dsB6XNS761LjW1DT6YTI4tO6On+9B8J6ZDgo9eTtdl+GIyJGF+Q97h1KoipFJDEQsj8O oLyw== X-Gm-Message-State: ALQs6tC+0lSvzjtREzJswlnkSxGNENnMNG7bOVhC2YwffVyFFCWU8Ace h4f7BdvgSjcI4jMptHQGqhn1pPmE4Z/carrneNyXboWG X-Google-Smtp-Source: AIpwx491sSPRlAf06A1yzulwdJ1bqvfkIZ6GLQg6Wkjqu5DN4q+gxadhedxunuS1nH+jZ9v7fbdUQ4QjIrZ8GBQDsMQ= X-Received: by 2002:a9d:1722:: with SMTP id i34-v6mr5508789ota.195.1522664528229; Mon, 02 Apr 2018 03:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.15.247 with HTTP; Mon, 2 Apr 2018 03:22:07 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Mon, 2 Apr 2018 18:22:07 +0800 Message-ID: Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: Ed Schouten Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 10:22:09 -0000 On 2 April 2018 at 03:33, Ed Schouten wrote: > Wow! That's a coincidence. I actually started working on something in > the same area a couple of days ago. One of our customers requires > sub-second precision of log entries, which is why I implemented RFC > 5424 support for FreeBSD's syslogd a couple of days ago. I sent out a > pull request a couple of minutes ago and only noticed your email just > now. > > https://reviews.freebsd.org/D14926 > > This patch doesn't change the output format of syslogd. It only adds > the RFC 5424 parsing and changes the internal model of syslogd to be > based on RFC 5424. Changing the output format to use ISO 8601 > formatting was planned for a separate change. > > What are your thoughts on my pull request? If you like it, maybe it > makes more sense to land my change first before applying yours? > > -- > Ed Schouten > Nuxi, 's-Hertogenbosch, the Netherlands > Hi Ed, That is a coincidence. Having looked through your code, I realise it is far better than mine, and mine actually resulted in the syslogd output being non-compliant with both RFC3164 and RFC5424 (by using the RFC5424 timestamp format with the remainder of the log matching the RFC3164 format). I have therefore abandoned my review in favour of yours. My effort has not been wasted though, as it meant that I was recently familiar with the syslogd.c code, and the contents of RFC3164 and RFC5424, and therefore had a headstart in reviewing your patch. I have provided some comments in phabricator for your consideration. I think you have already handled the hard part of the migration to RFC5424, which is the updated parsing logic. Whilst you have yet changed the log output format to RFC5424, I suspect that will be the easy bit. When it comes time to change the output format, it is worth noting that NetBSD has provided the "-o" syslogd argument to allow the sysadmin to select the output format: -o output_format Select output message format. bsd, rfc3164 traditional BSD Syslog format (default) syslog, rfc5424 new syslog-protocol format Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-hackers@freebsd.org Mon Apr 2 13:17:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9262F584C7 for ; Mon, 2 Apr 2018 13:17:10 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 077EB7DDC8 for ; Mon, 2 Apr 2018 13:17:10 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-wm0-x22c.google.com with SMTP id v21so25470150wmc.1 for ; Mon, 02 Apr 2018 06:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ETsZqPs0PKO3cvMAhHf1DO+Djk/tDQYZjTom28ipcoo=; b=LUunaTq9mLD093AdDgWAEjEJljUWu87tWunmh/o3jcuIl5LasjDPyEpf8q83L5gfgU So/z2FkNal7rcLQem5eAYRzCVs1DM9cAi1zURwup3g1dn4o6xNiiqz+tKAxsl6gOeZPV gTL9UuiW5IEZ9UIYpu1v7Y/i2ZPiKNVxDdB+luOwgE8B+1HrEsfbHQz2OLoqGOph38MR N+YmcLB1ZlcKejsyUXE1FE/K4pQ+MaA++tbugDQCuf4HKihnNmjAwc0w5lQIwd3HEn57 s4CLt8rFEJNaF7839xMSW9IwtqWEinqgL1Cg0FYXD/BoMeynbmiHNv4cGTIpihCb4M3I 1bEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ETsZqPs0PKO3cvMAhHf1DO+Djk/tDQYZjTom28ipcoo=; b=aCjyVai5UXoWJLMw6IvXTn/H4Z7sRKjzN5JmTKPdCN5RUIdj+BDiU7gbgiGuRDQpgK sS6mkdhtJNX21b5n4zO3QAfIc6alezIckR9xvtrSgDkQwRz3kfFTaUdTrsuEC6Muqfkp QmMLh/1sO0U8SqvKmJRqe0StOd+wtL73Ltc3f4PMvg/tsqaR1Kiz/sDIEr8ELfp/4ZT9 oYhufIdNS/OCoembmLb5GlP8j8ziq4P269YMB3Fq5VcQ/BCKdr1NA3y6N0ihGLP2zT+R qhVSi4ehoxMWk6mkzz4zTAp/E3W3po3cCNj/qE3h5+g1fMJl8Ge/UvBi8FWrD23AHVO3 E67A== X-Gm-Message-State: ALQs6tA3wj1Q5kgv/oeWG44qiGLX772yy8HB0MZaia2aPW1KK/jGGY7G G5Bja2ENC/5fzFcFVZul8EiAHRkN6JUf1dfsKpRfeQ== X-Google-Smtp-Source: AIpwx4+UoMbhRKVRU+yCOYlrcmzqo1DVosBjZIdZAOWXWqFonnw1PLyvuRapV/fY3VJwRUF8SIJhwfts6vxI8jKdLww= X-Received: by 10.46.154.145 with SMTP id p17mr5809473lji.28.1522675028157; Mon, 02 Apr 2018 06:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e9c2:0:0:0:0:0 with HTTP; Mon, 2 Apr 2018 06:16:37 -0700 (PDT) In-Reply-To: References: From: Ed Schouten Date: Mon, 2 Apr 2018 15:16:37 +0200 Message-ID: Subject: Re: Add option -Z to syslogd(8) to use ISO 8601 timestamps To: Ben Woods Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 13:17:11 -0000 Hi Ben, 2018-04-02 12:22 GMT+02:00 Ben Woods : > That is a coincidence. Having looked through your code, I realise it is far > better than mine, and mine actually resulted in the syslogd output being > non-compliant with both RFC3164 and RFC5424 (by using the RFC5424 timestamp > format with the remainder of the log matching the RFC3164 format). I have > therefore abandoned my review in favour of yours. > > My effort has not been wasted though, as it meant that I was recently > familiar with the syslogd.c code, and the contents of RFC3164 and RFC5424, > and therefore had a headstart in reviewing your patch. I have provided some > comments in phabricator for your consideration. Yes, exactly! Having someone who can review my changes thoroughly is incredibly useful. Thanks a lot for your feedback so far! I'll take a look at it later today and revise my patch where needed. > I think you have already handled the hard part of the migration to RFC5424, > which is the updated parsing logic. Whilst you have yet changed the log > output format to RFC5424, I suspect that will be the easy bit. Exactly. We do have to investigate whether we also want to use RFC 5424 to format console messages. It may be a bit too verbose, especially for 80 column consoles. This is exactly why I left changing the output format to another change. > When it comes time to change the output format, it is worth noting that > NetBSD has provided the "-o" syslogd argument to allow the sysadmin to > select the output format: > > -o output_format > Select output message format. > bsd, rfc3164 traditional BSD Syslog format (default) > syslog, rfc5424 new syslog-protocol format Yes! Being compatible with NetBSD here sounds like a good idea indeed. No need to deviate unnecessarily. Best regards, -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands From owner-freebsd-hackers@freebsd.org Mon Apr 2 14:39:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0CF9F6E5D0 for ; Mon, 2 Apr 2018 14:39:33 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9BDEF81357 for ; Mon, 2 Apr 2018 14:39:32 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from blue.vangyzen.net (173-28-118-115.client.mchsi.com [173.28.118.115]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4BAC35646B; Mon, 2 Apr 2018 09:39:26 -0500 (CDT) Subject: Re: Realtek RTS525A SD card reader To: Warner Losh , raul.becker@iki.fi Cc: "freebsd-hackers@freebsd.org" References: <20180401034514.t4idseuyg53gap7g@tardis> From: Eric van Gyzen Message-ID: <22ca4f05-3e3a-114d-ef95-d974541ee6d8@vangyzen.net> Date: Mon, 2 Apr 2018 09:39:19 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 14:39:34 -0000 On 04/01/2018 02:06, Warner Losh wrote: > The interface you want to look for is the mmcbr_if.m inteface. In sdhci, > these routines implement the mmc interface: > sdhci_pci.c: DEVMETHOD(mmcbr_update_ios, sdhci_generic_update_ios), > sdhci_pci.c: DEVMETHOD(mmcbr_switch_vccq, sdhci_generic_switch_vccq), > sdhci_pci.c: DEVMETHOD(mmcbr_tune, sdhci_generic_tune), > sdhci_pci.c: DEVMETHOD(mmcbr_retune, sdhci_generic_retune), > sdhci_pci.c: DEVMETHOD(mmcbr_request, sdhci_generic_request), > sdhci_pci.c: DEVMETHOD(mmcbr_get_ro, sdhci_generic_get_ro), > sdhci_pci.c: DEVMETHOD(mmcbr_acquire_host, sdhci_generic_acquire_host), > sdhci_pci.c: DEVMETHOD(mmcbr_release_host, sdhci_generic_release_host), > > rtsz will almost certainly need it's own versions of these routines (which > is why I suggest having your own driver will be simpler: otherwise each of > these routines would be if (rtsz) do_rtsz_stuff(); else do_sdhci_stuff(); > which won't end well and would be uncomittable to FreeBSD. You can see how > other chips implement these methods by grepping for them in the tree. You > may not need a tune/retune if rtsz doesn't support the latest, fastest > cards, for example. Switch vccq may not be needed either. update_ios will > be needed, and request is needed. Acquire and release host may be able to > be done as a dummy routine if there's only one slot. > > I know this is a super-quick gloss of what needs to be done. This mmc part was helpful, since I know nothing about this interface. Thanks! Eric From owner-freebsd-hackers@freebsd.org Mon Apr 2 16:43:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F198F76859 for ; Mon, 2 Apr 2018 16:43:28 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDE6A86B52 for ; Mon, 2 Apr 2018 16:43:27 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id u62-v6so8239672ita.5 for ; Mon, 02 Apr 2018 09:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=38zAtiR2l2pGjRRCtIKNUq854O2FEHaljBstp/bhgXg=; b=jG4pl6i0h78giNiKLIltVqQLApCuOjncbC1Q+w8sVoe/HZh9EiLXXC1KR45USLBGH2 +YEG2W/EmNqKJBu0NztYHyji0sa5j8vzafoi8nM1RQyRCrR18T2cXhaSMPQ9yi8wMo/V l+7DmjeKaF1Wf9WnyUnwTxOLp48woxCqrdHZvFVVLIrMf0QLbFYttcr5tf+jNRWn3REM xQczHDPyXJk9h/ttmHKl9ITmHFoDsb9zKyQNZkNKiA5Kti/s7uB7me1EFjiOnHpWLWLK m02enNkjusVBtWuZZB/1PkIFHcVV2tglJbTV7pYtXplgC8TrR79xlUfErMTC8s5NBuU8 qpsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=38zAtiR2l2pGjRRCtIKNUq854O2FEHaljBstp/bhgXg=; b=ha91npB1y0UMvdceLyE6NL84log7zBgU1TGPcWyz1+wGqVf5Ndt752uXWsMxWglkPH NKQhnwkhsFsO4ePqwibdUvuPoE3bKl8LETRkTlb0DiVhlgaHbMpVAeWSt8OPbWMZ9WT6 B/fBvgsyxk3xSqiDkm2gRfVskdtORbeTF7sL1iPxidnhviHiyNDACJE39694bLCGcXsF kqKVhEvykCNKW1ETVTWBaOocVNsBsIEjY54NzgS9L+uVImBXs+6ZxhNYcV46Kpq+5VY8 YDz7Rnsu49cOB3Swz/jvEPd7RrUB1+f1JkI8x/cxP7HZTNkw8H3oNG80/PIC1WWoF8QV U2Ng== X-Gm-Message-State: ALQs6tAybTv8EkiX43Ns7c7QEI23aW8Pe0yQFmYp8i3USQI/2UqHX7jq iuFHgIeRIGfMtQeGYOH3uW7vreohLsIZ+UMVNA== X-Google-Smtp-Source: AIpwx4/9zW6/1FdTny/KmRh0or0dwiboPg6i6H0ABrXCej2n65Ye3wO1S0SN4onTS1H0jORc927e/nf73V5sRGxE+bo= X-Received: by 2002:a24:5f51:: with SMTP id r78-v6mr1656909itb.119.1522687406929; Mon, 02 Apr 2018 09:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Mon, 2 Apr 2018 09:43:26 -0700 (PDT) In-Reply-To: References: From: Zaphod Beeblebrox Date: Mon, 2 Apr 2018 12:43:26 -0400 Message-ID: Subject: Re: On UEFI dual booting. To: Warner Losh Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2018 16:43:28 -0000 I suppose my subject was a bit of a misnomer. I'm not trying to get boot1.efi or loader.efi to do the dual-booting thing. I've got a tool called "refind" doing that. It presents a menu and allows you to call various other efi things. The problem is that, even if I weren't dual booting, the twin problems (graphical mode errors using boot1.efi, partition selection errors using loader) prevent even regular booting. The sole outlier is cd9660 booting --- loader.efi comes from the CD image and continues to boot by accessing /boot on the CD image. I was trying emphasize that solving the first problem might be as simple as vigorously resetting the video mode when the kernel started. Both boo1.efi and loader.efi seem to understand boot1's fallback to EFI text mode (if that is, what I understand, they are doing). This all fails when the kernel starts ... as if the screen is just in the painfully wrong mode. The second problem is solvable in two ways. One, a hack, it seems if I expand the default EFI partition to a gig (or two), I can put the contents of /boot, including the kernel, on the FAT EFI partition. loader.efi seems willing to read things there. M$ default EFI partition is only 100 meg... so not enough room for even minimal boot files, I don't think. I'll be trying this when the new disk arrives tomorrow. The second solution to the second problem is allowing command line arguments to loader to point it at a disk. refind seems to suggest that UUID and partition name (both GPT properties) are good choices. I have tried setting "currdev" and "rootdev" ... neither seem to work. currdev seems to be set on startup to the EFI disk. rootdev doesn't seem to take effect ... I know that "part7:" is the right value there ... if it would accept it. I would be willing to do some testing, BTW, and FWIW, I even have a single port KVM that could be hooked to said laptop, if required. On Sun, Apr 1, 2018 at 6:55 PM, Warner Losh wrote: > Dual boot doesn't work with UEFI. boot1.efi and loader.efi have different > sets of issues, but basically they guess what to boot, and that's > incompatible with selecting this or that. > > This is a problem I've been working on for the past 9 months. I've peeled > away many layers of this onion (and gotten side tracked by lua for a bit), > but I'm finally back to the point where I have a loader.efi that can be on > the ESP (the DOS partition) and that's setup to finish implementing the > UEFI boot manager protocol.... > > Warner > > On Sun, Apr 1, 2018 at 4:03 PM, Zaphod Beeblebrox > wrote: > >> I've put in about 6 hours of trying to get UEFI dual booting to work. At >> this point, the "dual boot" part works fine, but the FreeBSD part fails in >> several interesting ways. >> >> In case anyone cares, the hardware is an HP zBook 15 (with no suffixes). >> It's a i7-4900 machine with a dual (Quadro 2100 and Intel) graphics >> personality. Don't worry about that bit, tho, we don't get that far. >> >> The system has two disks --- both sata. One is m.2 sata and the other is >> 2.5 inch sata. I've installed "refind" on the EFI patition that Windows >> created on the 2.5 inch drive. I'm trying to get FreeBSD to be happy on >> the m.2 drive. >> >> The FreeBSD install (so far) has a UFS, swap and ZFS GPT partitions. >> >> I can boot the 11.1 CD as UEFI. Critically, the 11.1 CD seems to use >> "loader.efi" directly. This works. The CD boots and is usable as such. >> >> The problem starts with boot1.efi. It seems to use text mode ... or >> 800x600... or something. It seems to work. Loader then runs in the same >> screen mode, but when the kernel starts, it's all over the screen... one >> pixel wide strips of white. Like the kernel is writing to the wrong >> resolution of screen. loader.efi also seems to get the size of things >> wrong. After filling 25 lines, anything you type or have displayed >> overwrites the 25th line of the screen. >> >> So... I can try starting loader.efi directly from the EFI partition. >> This, >> however, seems to completely ignore the partitions on the other disk (and >> their types). I've even tried using refinds "volume" setting and/or >> setting the command line arguments to loader.efi to tune either "currdev >> or >> rootdev" environment variables. The right partition (for the ufs pre-boot >> partition" is "part7:" in terms of loader. >> >> It would seem that I can get loader.efi to work IFF I put all of FreeBSD's >> /boot onto the DOS EFI partition. Windows only made it 500 megabytes, but >> I'm considering the hack. This may be the only way it works, but it seems >> it's not the way we "meant" it to work. >> >> So... asking the group: Is there a way for boot1.efi to support EFI >> graphical console, or, is there a way to get loader.efi smarter about >> searching for partitions to boot, or, can we get the kernel to better >> initialize the EFI console as it boots? >> >> Note, BTW, that the kernel never seems to get the console correct... even >> after booting. I can type blind, but that's it. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-hackers@freebsd.org Tue Apr 3 17:07:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 083DBF6F03F for ; Tue, 3 Apr 2018 17:07:23 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5610877FC for ; Tue, 3 Apr 2018 17:07:22 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id EC37B5A9F16; Tue, 3 Apr 2018 17:07:21 +0000 (UTC) Date: Tue, 3 Apr 2018 17:07:21 +0000 From: Brooks Davis To: freebsd-hackers@freebsd.org Cc: Ali Mashtizadeh Subject: getlogin caching and setlogin issues Message-ID: <20180403170721.GC8598@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 17:07:23 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Ali found this issue while looking at pulling syscalls out of libc.] getlogin() is a wrapper around _getlogin() which caches the value returned and sets a and internal _logname_valid flag. Some implementations of setlogin() clear that flag on return, the arm, mips, and riscv ones use the default assembly and do not. This leaves me two questions: 1) Does this cache make sense? Sure login rarely changes, but is getlogin called frequently in real software? 2) If the cache makes sense, does clearing the cache belong in __sys_setlogin() or should it be done in a C wrapper in setlogin() or _setlogin()? I think it should likely be pulled up to _setlogin(). 3) If yes to 1 and no to 2, do we need to fix arm, mips, and riscv? -- Brooks --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaw7TJAAoJEKzQXbSebgfA15QIAJnsY3P/nd+neY81bWVkAgO1 qUe02VlNXzYughKlT+nqFZ0JsztXN/BprvemrPiJ+lYZNlw3tHzNIZTFxAEDWtMK malwWwY52AphcWt/wRbJVkqSXd8VStEHc9ozql7TIIKLmQzPvfUbDiKxDmeniQMC VaVGF6NtVMsHL7j2x+aU209gbYMP8mDnh3cEn9d5tzo9ZmeGrJj5R3m5DhP6+5nw s94vorII3naIceP4//thQV9B5mZlI5ro9OX8/lPu5nfoWym5aMFHlKgswaXnjbVY UvbxUzwmXnuJKb+hEZupwvKoBi8kIDPoQal1yjmvBFKuMgRvbOz/uKErc5hOTDY= =crVp -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From owner-freebsd-hackers@freebsd.org Tue Apr 3 21:17:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3974CF814ED for ; Tue, 3 Apr 2018 21:17:44 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C051A753E4; Tue, 3 Apr 2018 21:17:43 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by mail-oi0-x244.google.com with SMTP id u84-v6so17322950oie.10; Tue, 03 Apr 2018 14:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cCnqh2/CexMKar2BVFOXYEQ9wQxVhfrtsFpMsgJKpxI=; b=Wp9XDyoeBWc3gZ1nPfnrIGlSQMiU6YEhtwEIzDPynYikv07PpJLab/58e5/SMQtN7C AGoO0QBpTKHwUKv+ZMEuKk5hNq2M7RC6fbTlW0lRmChzeSRkIhDqb77zKuupBilYMjhX 1h1BieD32F4rdJ0vhYqs9XWiBty5X9n5QL/PWhcPcGJzLS399dEZwJjYXK5tC4XwDvE8 USWYH+9yCmmGbFGjpzaPHWSSdZJDd7I+pj+ecwdlXO28tvlQwMuqeH7T/7eJ7fpBsfF6 Y4RlebCKYD0OHevXd2hOxJogOhVB+YhSeYErlccK8BvzM54+dHZaVnZEsaOww4ybKaGV U89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cCnqh2/CexMKar2BVFOXYEQ9wQxVhfrtsFpMsgJKpxI=; b=dUweIzjamI4aH8pokQ02LaeBS4PYcH4h/93Fwu2xdSz3TBqVwoz3kCGPk6XDXzYfoT GnDb2r6mCdzK50QfRLpYYqwxy7EG+QGcB8pLqH5pZz2cFKwi0HTs6N7Mo4363sdWIHRj SZGO1bqitPmQQ7gS07g+lyLKG554+NZAbYtk8CtCLjMOFvJZJHlU12DLi5MSVwNKBsx3 qA7hjB5aK3sAfLjo3Z9wHJ4d2+zuPMXP5dcAHvWZ7vTJO6ryEeGMdougY/KO5GQmlQvA VtytG59pd+3Cbi8ChWNacDbhtaqx1o4yagaslWtFLBDKBpo9wCWlpAoUDvXka3k4pyHe czmw== X-Gm-Message-State: ALQs6tB5idojqg8ysHZNG8BI2GFnEY03oxRSFcyEPKBZuKsj946l8Jq/ 3VZvtG9vOhgglE5MsBP4Pau8SELovE4pBjuXnoo= X-Google-Smtp-Source: AIpwx4+nvz2fJuwwKOPmX+ILbD5B/36ykT0dy3fccn5U/cytjXBsRSMGydPiIE9+whubvGDV5erAmKWKpBdnEXT0wfg= X-Received: by 2002:aca:e043:: with SMTP id x64-v6mr8076191oig.164.1522790263081; Tue, 03 Apr 2018 14:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.208.19 with HTTP; Tue, 3 Apr 2018 14:17:42 -0700 (PDT) In-Reply-To: <20180403170721.GC8598@spindle.one-eyed-alien.net> References: <20180403170721.GC8598@spindle.one-eyed-alien.net> From: Ali Mashtizadeh Date: Tue, 3 Apr 2018 17:17:42 -0400 Message-ID: Subject: Re: getlogin caching and setlogin issues To: Brooks Davis Cc: FreeBSD Hackers , Ali Mashtizadeh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:17:44 -0000 In addition, I couldn't find a reason for sigreturn() to be custom assembly in i386/amd64/arm/aarch64. Best, Ali On Tue, Apr 3, 2018 at 1:07 PM, Brooks Davis wrote: > [Ali found this issue while looking at pulling syscalls out of libc.] > > getlogin() is a wrapper around _getlogin() which caches the value > returned and sets a and internal _logname_valid flag. Some > implementations of setlogin() clear that flag on return, the arm, mips, > and riscv ones use the default assembly and do not. This leaves me two > questions: > > 1) Does this cache make sense? Sure login rarely changes, but is > getlogin called frequently in real software? > > 2) If the cache makes sense, does clearing the cache belong in > __sys_setlogin() or should it be done in a C wrapper in setlogin() or > _setlogin()? I think it should likely be pulled up to _setlogin(). > > 3) If yes to 1 and no to 2, do we need to fix arm, mips, and riscv? > > -- Brooks From owner-freebsd-hackers@freebsd.org Tue Apr 3 21:22:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABEA6F81AF3 for ; Tue, 3 Apr 2018 21:22:22 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57896758F6 for ; Tue, 3 Apr 2018 21:22:22 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 9A9345A9F17; Tue, 3 Apr 2018 21:22:21 +0000 (UTC) Date: Tue, 3 Apr 2018 21:22:21 +0000 From: Brooks Davis To: Ali Mashtizadeh Cc: FreeBSD Hackers , Ali Mashtizadeh Subject: Re: getlogin caching and setlogin issues Message-ID: <20180403212221.GC23045@spindle.one-eyed-alien.net> References: <20180403170721.GC8598@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:22:22 -0000 --p2kqVDKq5asng8Dg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 03, 2018 at 05:17:42PM -0400, Ali Mashtizadeh wrote: > In addition, I couldn't find a reason for sigreturn() to be custom assembly > in i386/amd64/arm/aarch64. See https://reviews.freebsd.org/D14953 -- Brooks --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaw/CMAAoJEKzQXbSebgfA/ZkH+wWx2c+5Y0+GH6b2XIDcLmAQ g5HHk4ZrHUtU7WvbZZGjxgUzZF6klxL5rTkLCRO6j1Kd/6Nxt9PUgKBGMWq+6ig9 6Kdww55FTGxE2bTG3250VNmZKJwQp1odQCEKJ5BJFzeBcnfIxIhAzv4QA80/j6/O C12KBrtr3b2BWAWdxwwLEA8A89ZZL60ItV89yfN0hooSGw1edzOGNOWabablFhcg yj3LyG+i5pB8nFljLzHF5yx7wUDXuJh/9C45D7MhviKY3c8MlAwU8tp6okFPOx9m zu51KoHx1a/XKUW+NUO3AI9Q7zap4PEaaJAU7JYBDVLDkQYwV/Rno6GewCk08IA= =WSry -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg-- From owner-freebsd-hackers@freebsd.org Wed Apr 4 02:37:32 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E812DF87BB8 for ; Wed, 4 Apr 2018 02:37:31 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6809183662 for ; Wed, 4 Apr 2018 02:37:31 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3YIhfraUMXziT3YIifnx2z; Tue, 03 Apr 2018 20:37:29 -0600 X-Authority-Analysis: v=2.3 cv=X6B81lbe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=6JMU3_lveSxv2Xq34zgA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id A0B7F1211 for ; Tue, 3 Apr 2018 19:37:26 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w342bPZU036030 for ; Tue, 3 Apr 2018 19:37:25 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w342bPop036027 for ; Tue, 3 Apr 2018 19:37:25 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804040237.w342bPop036027@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-hackers@freebsd.org Subject: mips.mips64elhf and mips.mips64el buildworld Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Apr 2018 19:37:25 -0700 X-CMAE-Envelope: MS4wfJxWoGcQK+521fiskcKFUGLRsCa4Mt0FT/lkV20sH8ILx1zarHD4alea15MXcUAJSQwuJpwz9t+kZNvUvXgcArQ2xteY4FGkiYlk2HwTVPxMjDfl2xOK IsmnjurpxTnCCgJzLvPkFv05OxLgCE1Z4+VHa8WM61noyo3hHnGnMX6u/OfnfGHl0Ofh+w8NUoAXug== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:37:32 -0000 Hi Building world within the krb5 project branch after having made heimdal private, as of LLVM 6 the following errors are produced /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u sr/lib32 /libprivateasn1.so: could not read symbols: File in wrong format and /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el/obj-lib32/tmp/usr /lib32/l ibprivateasn1.so: could not read symbols: File in wrong format File reports, universe12b$ file /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el hf/obj-lib32/tmp/usr/lib32/libprivateasn1.so.11 /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u sr/lib32/libprivateasn1.so.11: ELF 32-bit MSB shared object, MIPS, MIPS-III version 1 (FreeBSD), dynamically linked, not stripped universe12b$ Similarly for mips64el. All other architectures built successfully. For the stupid question: AFAICT the files are correct. Does anyone have any ideas? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Wed Apr 4 07:06:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26DF2F98020 for ; Wed, 4 Apr 2018 07:06:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3A0F8FBA1 for ; Wed, 4 Apr 2018 07:06:10 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.0.15] (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EEB3E3FAFF; Wed, 4 Apr 2018 09:06:02 +0200 (CEST) From: Dimitry Andric Message-Id: <06A6FF73-A15B-4EA1-854A-B2B741FB7E63@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1871B193-52B6-457E-BF1E-554DCC870732"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: mips.mips64elhf and mips.mips64el buildworld Date: Wed, 4 Apr 2018 09:06:04 +0200 In-Reply-To: <201804040237.w342bPop036027@slippy.cwsent.com> Cc: freebsd-hackers@freebsd.org To: Cy Schubert References: <201804040237.w342bPop036027@slippy.cwsent.com> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:06:11 -0000 --Apple-Mail=_1871B193-52B6-457E-BF1E-554DCC870732 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 4 Apr 2018, at 04:37, Cy Schubert wrote: > > Building world within the krb5 project branch after having made heimdal > private, as of LLVM 6 the following errors are produced Since mips is built with gcc (still), this hasn't got anything to do with clang. :) > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u > sr/lib32 > /libprivateasn1.so: could not read symbols: File in wrong format > > and > > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el/obj-lib32/tmp/usr > /lib32/l > ibprivateasn1.so: could not read symbols: File in wrong format > > File reports, > > universe12b$ file /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el > hf/obj-lib32/tmp/usr/lib32/libprivateasn1.so.11 > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u > sr/lib32/libprivateasn1.so.11: ELF 32-bit MSB shared object, MIPS, > MIPS-III version 1 (FreeBSD), dynamically linked, not stripped > universe12b$ > > Similarly for mips64el. > > All other architectures built successfully. > > For the stupid question: AFAICT the files are correct. Does anyone have > any ideas? Which program is producing the "could not read symbols" output? The linker? Maybe it trips up over these 32-bit shared libraries. It would probably help a bit if you posted the buildworld output somewhere, so it is more easily visible how the libraries are built, and by which program(s) they are processed. -Dimitry --Apple-Mail=_1871B193-52B6-457E-BF1E-554DCC870732 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsR5XAAKCRCwXqMKLiCW o+vgAJoDmUpk9QAjmCNGEeHaR2vHcaTYOwCg33/IH3u9IY+hetitE/fjpJoVGms= =Ur89 -----END PGP SIGNATURE----- --Apple-Mail=_1871B193-52B6-457E-BF1E-554DCC870732-- From owner-freebsd-hackers@freebsd.org Wed Apr 4 15:02:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6583F95551 for ; Wed, 4 Apr 2018 15:02:57 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2668580230; Wed, 4 Apr 2018 15:02:56 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3jvzfSx8WLkoz3jw1fCpSm; Wed, 04 Apr 2018 09:02:49 -0600 X-Authority-Analysis: v=2.3 cv=OeS28CbY c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=x_7VaVDMseffngnHUWIA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 6E98E273B; Wed, 4 Apr 2018 08:02:46 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w34F2iHf061217; Wed, 4 Apr 2018 08:02:44 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w34F2iEC061198; Wed, 4 Apr 2018 08:02:44 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804041502.w34F2iEC061198@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric cc: Cy Schubert , freebsd-hackers@freebsd.org Subject: Re: mips.mips64elhf and mips.mips64el buildworld In-Reply-To: Message from Dimitry Andric of "Wed, 04 Apr 2018 09:06:04 +0200." <06A6FF73-A15B-4EA1-854A-B2B741FB7E63@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Apr 2018 08:02:44 -0700 X-CMAE-Envelope: MS4wfNIGZxzQ0ZRrSYWqpE1UE78irA7Q0OZQAJSYE/dC6036voWzE6Cyn7IoGO9laaod5pv/skeKFOjK4Ry5VT5FwbRrKKKqHy9pl2PP9iGjUusC+nzGYqbT DY2ltulhDrnIYObhc8DIiJVMMI4QnQhZwCe1tzfigCkF32rpi0GN02QpljJfVwq3CDco+2MdyX4ELfYVn2wldzD24yp6JtVXdc9Ih5PLgDdNnxy1vEN4GOP+ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:02:58 -0000 In message <06A6FF73-A15B-4EA1-854A-B2B741FB7E63@FreeBSD.org>, Dimitry Andric w rites: > > > --Apple-Mail=_1871B193-52B6-457E-BF1E-554DCC870732 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii > > On 4 Apr 2018, at 04:37, Cy Schubert wrote: > > > > Building world within the krb5 project branch after having made heimdal > > private, as of LLVM 6 the following errors are produced > > Since mips is built with gcc (still), this hasn't got anything to do > with clang. :) > > > > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u > > sr/lib32 > > /libprivateasn1.so: could not read symbols: File in wrong format > > > > and > > > > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el/obj-lib32/tmp/usr > > /lib32/l > > ibprivateasn1.so: could not read symbols: File in wrong format > > > > File reports, > > > > universe12b$ file /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64el > > hf/obj-lib32/tmp/usr/lib32/libprivateasn1.so.11 > > /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u > > sr/lib32/libprivateasn1.so.11: ELF 32-bit MSB shared object, MIPS, > > MIPS-III version 1 (FreeBSD), dynamically linked, not stripped > > universe12b$ > > > > Similarly for mips64el. > > > > All other architectures built successfully. > > > > For the stupid question: AFAICT the files are correct. Does anyone have > > any ideas? > > Which program is producing the "could not read symbols" output? The > linker? Maybe it trips up over these 32-bit shared libraries. Yes, it appears to be the linker. > > It would probably help a bit if you posted the buildworld output > somewhere, so it is more easily visible how the libraries are built, > and by which program(s) they are processed. Do you have access to universe12b.freebsd.org? The output is in /home/cy/projects/pvt/_.mips.mips64elhf.buildworld and /home/cy/projects/pvt/_.mips.mips64el.buildworld. The Makefile building the library in question is kerberos5/lib/libasn1/M akefile. My alterations are: universe12b$ svn diff -cr323334 kerberos5/lib/libasn1/Makefile Index: kerberos5/lib/libasn1/Makefile =================================================================== --- kerberos5/lib/libasn1/Makefile (revision 323333) +++ kerberos5/lib/libasn1/Makefile (revision 323334) @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= asn1 +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined INCS= asn1_err.h asn1-common.h heim_asn1.h der.h der-protos.h der-private.h LIBADD= com_err roken @@ -21,7 +22,8 @@ timegm.c \ ${GEN:S/.x$/.c/:S/.hx$/.h/} -CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H}/libroken -I. GEN_RFC2459= asn1_rfc2459_asn1.x rfc2459_asn1.hx rfc2459_asn1-priv.hx GEN_CMS= asn1_cms_asn1.x cms_asn1.hx cms_asn1-priv.hx universe12b$ $_LD is defined as $CC. --- libprivatekrb5.so.11.full --- building shared library libprivatekrb5.so.11 cc -DCOMPAT_32BIT -march=mips3 -mabi=32 -L/scratch/tmp/cy/obj/home/cy/pr ojects/pvt/mips.mips64elhf/obj-lib32/tmp/usr/lib32 --sysroot=/scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-l ib32/tmp -B/scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/tmp/ usr/bin -B/scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-l ib32/tmp/usr/lib32 -isystem /scratch/tmp/cy/obj/home/cy/projects/pvt/mip s.mips64elhf/obj-lib32/tmp/usr/include -Wl,--no-undefined -Wl,--version-script=/home/cy/projects/pvt/crypto/heimdal/lib/krb5/versi on-script.map -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libprivatekrb5.so.11.full -Wl,-soname,libprivatekrb5.so.11 `NM='nm' NMFLAGS='' lorder acache.pico acl.pico add_et_list.pico addr_families.pico aname_to_localname.pico appdefault.pico asn1_glue.pico auth_context.pico build_ap_req.pico build_auth.pico cache.pico changepw.pico codec.pico config_file.pico constants.pico context.pico convert_creds.pico copy_host_realm.pico crc.pico creds.pico crypto-aes.pico crypto-algs.pico crypto-arcfour.pico crypto-des-common.pico crypto-des.pico crypto-des3.pico crypto-evp.pico crypto-null.pico crypto-pk.pico crypto-rand.pico crypto.pico data.pico deprecated.pico digest.pico doxygen.pico eai_to_heim_errno.pico error_string.pico expand_hostname.pico expand_path.pico fcache.pico free.pico free_host_realm.pico generate_seq_number.pico generate_subkey.pico get_addrs.pico get_cred.pico get_default_principal. pico get_default_realm.pico get_for_creds.pico get_host_realm.pico get_in_tkt.pico get_port.pico init_creds.pico init_creds_pw.pico kcm.pico keyblock.pico keytab.pico keytab_any.pico keytab_file.pico keytab_keyfile.pico keytab_memory.pico krbhst.pico kuserok.pico log.pico mcache.pico misc.pico mit_glue.pico mk_error.pico mk_priv.pico mk_rep.pico mk_req.pico mk_req_ext.pico mk_safe.pico n-fold.pico net_read.pico net_write.pico pac.pico padata.pico pcache.pico pkinit.pico plugin.pico principal.pico prog_setup.pico prompter_posix.pico rd_cred.pico rd_error.pico rd_priv.pico rd_rep.pico rd_req.pico rd_safe.pico read_message.pico recvauth.pico replay.pico salt-aes.pico salt-arcfour.pico salt-des.pico salt-des3.pico salt.pico scache.pico send_to_kdc.pico sendauth.pico set_default_realm.pico sock_principal.pico store-int.pico store.pico store_emem.pico store_fd.pico store_mem.pico ticket.pico time.pico transited.pico verify_init.pico verify_user.pico version.pico warn.pico write_message.pico heim_err.pico k524_err.pico krb5_err.pico krb_err.pico | tsort -q` -lprivateasn1 -lcom_err -lcrypt -lcrypto -lprivatehx509 -lprivateroken -lprivatewind -lprivateheimbase -lprivateheimipcc /scratch/tmp/cy/obj/home/cy/projects/pvt/mips.mips64elhf/obj-lib32/tmp/u sr/lib32/libprivateasn1.so: could not read symbols: File in wrong format *** [libprivatekrb5.so.11.full] Error code 1 -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Wed Apr 4 21:13:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C066DF76CB8 for ; Wed, 4 Apr 2018 21:13:57 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46247743B9 for ; Wed, 4 Apr 2018 21:13:57 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.ee.lbl.gov (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w34LDqlM071135 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 4 Apr 2018 14:13:55 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.ee.lbl.gov To: FreeBSD Hackers From: Craig Leres Subject: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map Message-ID: Date: Wed, 4 Apr 2018 14:13:52 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------5C6DD70BDC44436AA37B5DA7" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-26009-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:13:58 -0000 This is a multi-part message in MIME format. --------------5C6DD70BDC44436AA37B5DA7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I freebsd-upgrade'd one of my 10.3-RELEASE poudriere build servers to 11.1-RELEASE-p8 yesterday and have found that starting virtualbox panic's the system with: ncpus is 0 with non-zero map virtualbox-ose-5.2.8_1 General-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-5.2.8_1 VirtualBox kernel module for FreeBSD I have a custom kernel but the changes are minor (MAXCPU=64, PPS_SYNC, DDB/GDB, etc.) It doesn't look like virtualbox-ose or virtualbox-ose-kmod have changed very recently so I'm not sure how to debug this. But I'm not 100% sure I ran virtual box with the current version of the virtualbox-ose-kmod kernel modules loaded. The system has a X5690 processor with 24 cores. I've attached dmesg.boot Craig --------------5C6DD70BDC44436AA37B5DA7 Content-Type: text/plain; charset=UTF-8; name="dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMTcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4xLVJFTEVBU0UtcDkg IzEgcjc6IFdlZCBBcHIgIDQgMTM6MTQ6MTkgUERUIDIwMTgKICAgIGxlcmVzQHppbmMuZWUu bGJsLmdvdjovdXNyL3NyYy9zeXMvYW1kNjQvY29tcGlsZS9MQkwgYW1kNjQKRnJlZUJTRCBj bGFuZyB2ZXJzaW9uIDQuMC4wICh0YWdzL1JFTEVBU0VfNDAwL2ZpbmFsIDI5NzM0NykgKGJh c2VkIG9uIExMVk0gNC4wLjApClZUKHZnYSk6IHJlc29sdXRpb24gNjQweDQ4MApDUFU6IElu dGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBYNTY5MCAgQCAzLjQ3R0h6ICgzNDY2Ljg3 LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luPSJHZW51aW5lSW50ZWwiICBJZD0weDIwNmMy ICBGYW1pbHk9MHg2ICBNb2RlbD0weDJjICBTdGVwcGluZz0yCiAgRmVhdHVyZXM9MHhiZmVi ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIs UEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxT U0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4OWVlM2ZkPFNTRTMsRFRFUzY0LE1P TixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLFBDSUQsRENB LFNTRTQuMSxTU0U0LjIsUE9QQ05UPgogIEFNRCBGZWF0dXJlcz0weDJjMTAwODAwPFNZU0NB TEwsTlgsUGFnZTFHQixSRFRTQ1AsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBW VC14OiBQQVQsSExULE1URixQQVVTRSxFUFQsVUcsVlBJRAogIFRTQzogUC1zdGF0ZSBpbnZh cmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gMjU3NzM5OTgw ODAgKDI0NTgwIE1CKQphdmFpbCBtZW1vcnkgPSAyNDkzOTA0NDg2NCAoMjM3ODMgTUIpCkV2 ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA2MDAKQUNQSSBBUElDIFRhYmxlOiA8MDgwMzEy IEFQSUMxNTIxPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVk OiAyNCBDUFVzCkZyZWVCU0QvU01QOiAyIHBhY2thZ2UocykgeCA2IGNvcmUocykgeCAyIGhh cmR3YXJlIHRocmVhZHMKcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KQUNQSSBCSU9TIFdh cm5pbmcgKGJ1Zyk6IDMyLzY0WCBsZW5ndGggbWlzbWF0Y2ggaW4gRkFEVC9HcGUwQmxvY2s6 IDEyOC82NCAoMjAxNzAzMDMvdGJmYWR0LTc0OCkKaW9hcGljMTogQ2hhbmdpbmcgQVBJQyBJ RCB0byA3CmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQK aW9hcGljMSA8VmVyc2lvbiAyLjA+IGlycXMgMjQtNDcgb24gbW90aGVyYm9hcmQKU01QOiBB UCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxMiBMYXVuY2hlZCEKU01QOiBBUCBD UFUgIzE4IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNiBMYXVuY2hlZCEKU01QOiBBUCBDUFUg IzEwIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTQgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM0 IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzEzIExh dW5jaGVkIQpTTVA6IEFQIENQVSAjMTEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5j aGVkIQpTTVA6IEFQIENQVSAjMTYgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyMSBMYXVuY2hl ZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxNyBMYXVuY2hlZCEK U01QOiBBUCBDUFUgIzIwIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjNSBMYXVuY2hlZCEKU01Q OiBBUCBDUFUgIzE5IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMjIgTGF1bmNoZWQhClNNUDog QVAgQ1BVICM5IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMjMgTGF1bmNoZWQhClNNUDogQVAg Q1BVICMxNSBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzggTGF1bmNoZWQhClRpbWVjb3VudGVy ICJUU0MtbG93IiBmcmVxdWVuY3kgMTczMzQzMzQwMiBIeiBxdWFsaXR5IDEwMDAKcmFuZG9t OiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UKbmV0bWFwOiBsb2FkZWQgbW9k dWxlCm1vZHVsZV9yZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAodmVzYSwgMHhmZmZmZmZmZjgw ZmJiYmIwLCAwKSBlcnJvciAxOQprYmQxIGF0IGtiZG11eDAKbmV4dXMwCnZ0dmdhMDogPFZU IFZHQSBkcml2ZXI+IG9uIG1vdGhlcmJvYXJkCmNyeXB0b3NvZnQwOiA8c29mdHdhcmUgY3J5 cHRvPiBvbiBtb3RoZXJib2FyZAphY3BpMDogPFNNQ0kgPiBvbiBtb3RoZXJib2FyZAphY3Bp MDogUG93ZXIgQnV0dG9uIChmaXhlZCkKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUx OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1Mzog PEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU0OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTU6IDxB Q1BJIENQVT4gb24gYWNwaTAKY3B1NjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU3OiA8QUNQ SSBDUFU+IG9uIGFjcGkwCmNwdTg6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1OTogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxMDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxMTogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxMjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxMzogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxNDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxNTogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxNjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxNzogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUxODogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxOTogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUyMDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyMTogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUyMjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyMzogPEFDUEkg Q1BVPiBvbiBhY3BpMAphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg0MyBpcnEg MCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMTAwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEg OCBvbiBhY3BpMApFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0 eSAwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAw MDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0 MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSAzNTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSAzNDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSAzNDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSAzNDAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQg My41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhv c3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBudW1hLWRvbWFpbiAwIG9uIGFjcGkw CnBjaWIwOiBfT1NDIHJldHVybmVkIGVycm9yIDB4MTAKcGNpMDogPEFDUEkgUENJIGJ1cz4g bnVtYS1kb21haW4gMCBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0 IGRldmljZSAxLjAgbnVtYS1kb21haW4gMCBvbiBwY2kwCnBjaTE6IDxBQ1BJIFBDSSBidXM+ IG51bWEtZG9tYWluIDAgb24gcGNpYjEKaWdiMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdv cmsgQ29ubmVjdGlvbiwgVmVyc2lvbiAtIDIuNS4zLWs+IHBvcnQgMHhlYzAwLTB4ZWMxZiBt ZW0gMHhmYmRlMDAwMC0weGZiZGZmZmZmLDB4ZmJkYzAwMDAtMHhmYmRkZmZmZiwweGZiZDlj MDAwLTB4ZmJkOWZmZmYgaXJxIDI4IGF0IGRldmljZSAwLjAgbnVtYS1kb21haW4gMCBvbiBw Y2kxCmlnYjA6IFVzaW5nIE1TSVggaW50ZXJydXB0cyB3aXRoIDkgdmVjdG9ycwppZ2IwOiBF dGhlcm5ldCBhZGRyZXNzOiAwMDoyNTo5MDozYjpmNzpiNAppZ2IwOiBCb3VuZCBxdWV1ZSAw IHRvIGNwdSAwCmlnYjA6IEJvdW5kIHF1ZXVlIDEgdG8gY3B1IDEKaWdiMDogQm91bmQgcXVl dWUgMiB0byBjcHUgMgppZ2IwOiBCb3VuZCBxdWV1ZSAzIHRvIGNwdSAzCmlnYjA6IEJvdW5k IHF1ZXVlIDQgdG8gY3B1IDQKaWdiMDogQm91bmQgcXVldWUgNSB0byBjcHUgNQppZ2IwOiBC b3VuZCBxdWV1ZSA2IHRvIGNwdSA2CmlnYjA6IEJvdW5kIHF1ZXVlIDcgdG8gY3B1IDcKaWdi MDogbmV0bWFwIHF1ZXVlcy9zbG90czogVFggOC8xMDI0LCBSWCA4LzEwMjQKaWdiMTogPElu dGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiwgVmVyc2lvbiAtIDIuNS4zLWs+ IHBvcnQgMHhlODgwLTB4ZTg5ZiBtZW0gMHhmYmQ2MDAwMC0weGZiZDdmZmZmLDB4ZmJkNDAw MDAtMHhmYmQ1ZmZmZiwweGZiZDFjMDAwLTB4ZmJkMWZmZmYgaXJxIDQwIGF0IGRldmljZSAw LjEgbnVtYS1kb21haW4gMCBvbiBwY2kxCmlnYjE6IFVzaW5nIE1TSVggaW50ZXJydXB0cyB3 aXRoIDkgdmVjdG9ycwppZ2IxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyNTo5MDozYjpmNzpi NQppZ2IxOiBCb3VuZCBxdWV1ZSAwIHRvIGNwdSA4CmlnYjE6IEJvdW5kIHF1ZXVlIDEgdG8g Y3B1IDkKaWdiMTogQm91bmQgcXVldWUgMiB0byBjcHUgMTAKaWdiMTogQm91bmQgcXVldWUg MyB0byBjcHUgMTEKaWdiMTogQm91bmQgcXVldWUgNCB0byBjcHUgMTIKaWdiMTogQm91bmQg cXVldWUgNSB0byBjcHUgMTMKaWdiMTogQm91bmQgcXVldWUgNiB0byBjcHUgMTQKaWdiMTog Qm91bmQgcXVldWUgNyB0byBjcHUgMTUKaWdiMTogbmV0bWFwIHF1ZXVlcy9zbG90czogVFgg OC8xMDI0LCBSWCA4LzEwMjQKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMy4wIG51bWEtZG9tYWluIDAgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBudW1h LWRvbWFpbiAwIG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDUuMCBudW1hLWRvbWFpbiAwIG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gbnVt YS1kb21haW4gMCBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA3LjAgbnVtYS1kb21haW4gMCBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG51 bWEtZG9tYWluIDAgb24gcGNpYjQKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgOS4wIG51bWEtZG9tYWluIDAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVzPiBu dW1hLWRvbWFpbiAwIG9uIHBjaWI1CnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVw dCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kw OiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDIw LjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJy dXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBj aTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2Ug MjAuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQp1aGNpMDogPEludGVsIDgyODAxSkkgKElDSDEw KSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweGRjMDAtMHhkYzFmIGlycSAxNiBhdCBk ZXZpY2UgMjYuMCBudW1hLWRvbWFpbiAwIG9uIHBjaTAKdWhjaTA6IExlZ1N1cCA9IDB4MmYw MAp1c2J1czAgbnVtYS1kb21haW4gMCBvbiB1aGNpMAp1c2J1czA6IDEyTWJwcyBGdWxsIFNw ZWVkIFVTQiB2MS4wCnVoY2kxOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9s bGVyIFVTQi1FPiBwb3J0IDB4ZDg4MC0weGQ4OWYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG51 bWEtZG9tYWluIDAgb24gcGNpMAp1aGNpMTogTGVnU3VwID0gMHgyZjAwCnVzYnVzMSBudW1h LWRvbWFpbiAwIG9uIHVoY2kxCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAK dWhjaTI6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUY+IHBv cnQgMHhkODAwLTB4ZDgxZiBpcnEgMTkgYXQgZGV2aWNlIDI2LjIgbnVtYS1kb21haW4gMCBv biBwY2kwCnVoY2kyOiBMZWdTdXAgPSAweDJmMDAKdXNidXMyIG51bWEtZG9tYWluIDAgb24g dWhjaTIKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAplaGNpMDogPEludGVs IDgyODAxSkkgKElDSDEwKSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUI+IG1lbSAweGZiZWRh MDAwLTB4ZmJlZGEzZmYgaXJxIDE4IGF0IGRldmljZSAyNi43IG51bWEtZG9tYWluIDAgb24g cGNpMAp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMzIG51bWEtZG9tYWluIDAgb24g ZWhjaTAKdXNidXMzOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWhjaTM6IDxJbnRl bCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhkNDgwLTB4 ZDQ5ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgbnVtYS1kb21haW4gMCBvbiBwY2kwCnVoY2kz OiBMZWdTdXAgPSAweDJmMDAKdXNidXM0IG51bWEtZG9tYWluIDAgb24gdWhjaTMKdXNidXM0 OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1aGNpNDogPEludGVsIDgyODAxSkkgKElD SDEwKSBVU0IgY29udHJvbGxlciBVU0ItQj4gcG9ydCAweGQ0MDAtMHhkNDFmIGlycSAxOSBh dCBkZXZpY2UgMjkuMSBudW1hLWRvbWFpbiAwIG9uIHBjaTAKdWhjaTQ6IExlZ1N1cCA9IDB4 MmYwMAp1c2J1czUgbnVtYS1kb21haW4gMCBvbiB1aGNpNAp1c2J1czU6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVoY2k1OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250 cm9sbGVyIFVTQi1DPiBwb3J0IDB4ZDA4MC0weGQwOWYgaXJxIDE4IGF0IGRldmljZSAyOS4y IG51bWEtZG9tYWluIDAgb24gcGNpMAp1aGNpNTogTGVnU3VwID0gMHgyZjAwCnVzYnVzNiBu dW1hLWRvbWFpbiAwIG9uIHVoY2k1CnVzYnVzNjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjAKZWhjaTE6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIDIuMCBjb250cm9sbGVyIFVT Qi1BPiBtZW0gMHhmYmVkODAwMC0weGZiZWQ4M2ZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBu dW1hLWRvbWFpbiAwIG9uIHBjaTAKdXNidXM3OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNyBu dW1hLWRvbWFpbiAwIG9uIGVoY2kxCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wCnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgbnVtYS1k b21haW4gMCBvbiBwY2kwCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG51bWEtZG9tYWluIDAgb24g cGNpYjYKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGY5MDAwMDAw LTB4ZjlmZmZmZmYsMHhmYWZmYzAwMC0weGZhZmZmZmZmLDB4ZmIwMDAwMDAtMHhmYjdmZmZm ZiBpcnEgMTggYXQgZGV2aWNlIDEuMCBudW1hLWRvbWFpbiAwIG9uIHBjaTYKdmdhcGNpMDog Qm9vdCB2aWRlbyBkZXZpY2UKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMx LjAgbnVtYS1kb21haW4gMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBudW1hLWRvbWFpbiAw IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0gxMCBTQVRBMzAwIGNvbnRyb2xsZXI+IHBv cnQgMHhkMDAwLTB4ZDAwNywweGNjMDAtMHhjYzAzLDB4Yzg4MC0weGM4ODcsMHhjODAwLTB4 YzgwMywweGM0ODAtMHhjNDhmLDB4YzQwMC0weGM0MGYgaXJxIDE5IGF0IGRldmljZSAzMS4y IG51bWEtZG9tYWluIDAgb24gcGNpMAphdGEyOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwg MCBvbiBhdGFwY2kwCmF0YTM6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGF0YXBj aTAKYXRhcGNpMTogPEludGVsIElDSDEwIFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGMw MDAtMHhjMDA3LDB4YmMwMC0weGJjMDMsMHhiODgwLTB4Yjg4NywweGI4MDAtMHhiODAzLDB4 YjQ4MC0weGI0OGYsMHhiNDAwLTB4YjQwZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjUgbnVtYS1k b21haW4gMCBvbiBwY2kwCmF0YTQ6IDxBVEEgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGF0 YXBjaTEKYXRhNTogPEFUQSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYXRhcGNpMQphY3Bp X2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBj b250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2Jk MDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2Jk MDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMw CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IG1vZGVsIEludGVsbGlNb3VzZSBFeHBsb3Jl ciwgZGV2aWNlIElEIDQKdWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4 LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKdWFydDE6IDwxNjU1MCBvciBjb21w YXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwCnFwaTA6IDxRUEkgc3lz dGVtIGJ1cz4gb24gbW90aGVyYm9hcmQKcGNpYjc6IDxRUEkgSG9zdC1QQ0kgYnJpZGdlPiBw Y2lidXMgMjU1IG9uIHFwaTAKcGNpNzogPFBDSSBidXM+IG9uIHBjaWI3CnBjaWI4OiA8UVBJ IEhvc3QtUENJIGJyaWRnZT4gcGNpYnVzIDI1NCBvbiBxcGkwCnBjaTg6IDxQQ0kgYnVzPiBv biBwY2liOApvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2Zm ZiBvbiBpc2EwCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmVzdDA6IDxF bmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTAKZXN0MTogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQplc3QyOiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyCmVzdDM6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMKZXN0NDogPEVuaGFu Y2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1NAplc3Q1OiA8RW5oYW5j ZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU1CmVzdDY6IDxFbmhhbmNl ZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTYKZXN0NzogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Nwplc3Q4OiA8RW5oYW5jZWQg U3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHU4CmVzdDk6IDxFbmhhbmNlZCBT cGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTkKZXN0MTA6IDxFbmhhbmNlZCBT cGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEwCmVzdDExOiA8RW5oYW5jZWQg U3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxMQplc3QxMjogPEVuaGFuY2Vk IFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTIKZXN0MTM6IDxFbmhhbmNl ZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEzCmVzdDE0OiA8RW5oYW5j ZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxNAplc3QxNTogPEVuaGFu Y2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTUKZXN0MTY6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTE2CmVzdDE3OiA8RW5o YW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxNwplc3QxODogPEVu aGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MTgKZXN0MTk6IDxF bmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTE5CmVzdDIwOiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyMAplc3QyMTog PEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MjEKZXN0MjI6 IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTIyCmVzdDIz OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUyMwpaRlMg ZmlsZXN5c3RlbSB2ZXJzaW9uOiA1ClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbjogZmVhdHVy ZXMgc3VwcG9ydCAoNTAwMCkKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpu dm1lIGNhbSBwcm9iZSBkZXZpY2UgaW5pdAp1Z2VuNi4xOiA8SW50ZWwgVUhDSSByb290IEhV Qj4gYXQgdXNidXM2CnVnZW4wLjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCPiBhdCB1c2J1czAK dWdlbjEuMTogPEludGVsIFVIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMQp1Z2VuNC4xOiA8SW50 ZWwgVUhDSSByb290IEhVQj4gYXQgdXNidXM0CnVnZW4zLjE6IDxJbnRlbCBFSENJIHJvb3Qg SFVCPiBhdCB1c2J1czMKdWdlbjUuMTogPEludGVsIFVIQ0kgcm9vdCBIVUI+IGF0IHVzYnVz NQp1Z2VuNy4xOiA8SW50ZWwgRUhDSSByb290IEhVQj4gYXQgdXNidXM3CnVnZW4yLjE6IDxJ bnRlbCBVSENJIHJvb3QgSFVCPiBhdCB1c2J1czIKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM2CnVodWIx OiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYnVzMwp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWh1YjQ6IDxJbnRlbCBVSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVo dWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMAp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUKdWh1YjY6IDxJbnRlbCBFSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM3 CnVodWI3OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHVi MzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAphZGEwIGF0IGF0YTIgYnVzIDAgc2NidXMwIHRh cmdldCAwIGx1biAwCmFkYTA6IDxJTlRFTCBTU0RTQzJLRjE4MEg2IExTRjAzMVA+IEFDUy0z IEFUQSBTQVRBIDMueCBkZXZpY2UKYWRhMDogU2VyaWFsIE51bWJlciBDVkxUNjE3NjAwMTIx ODBCR04KYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTUsIFBJ TyA4MTkyYnl0ZXMpCmFkYTA6IDE3MTcwNU1CICgzNTE2NTE4ODggNTEyIGJ5dGUgc2VjdG9y cykKYWRhMSBhdCBhdGEyIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMSBsdW4gMAphZGExOiA8SU5U RUwgU1NEU0MyS1c0ODBINiBMU0YwMzFDPiBBQ1MtMyBBVEEgU0FUQSAzLnggZGV2aWNlCmFk YTE6IFNlcmlhbCBOdW1iZXIgQ1ZMVDYyNDQwNlJBNDgwRUdOCmFkYTE6IDMwMC4wMDBNQi9z IHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE1LCBQSU8gODE5MmJ5dGVzKQphZGExOiA0NTc4 NjJNQiAoOTM3NzAzMDg4IDUxMiBieXRlIHNlY3RvcnMpCmFkYTIgYXQgYXRhMyBidXMgMCBz Y2J1czEgdGFyZ2V0IDAgbHVuIDAKYWRhMjogPElOVEVMIFNTRFNDMktGMTgwSDYgTFNGMDMx UD4gQUNTLTMgQVRBIFNBVEEgMy54IGRldmljZQphZGEyOiBTZXJpYWwgTnVtYmVyIENWTFQ2 MTc2MDVZMjE4MEJHTgphZGEyOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBV RE1BNSwgUElPIDgxOTJieXRlcykKYWRhMjogMTcxNzA1TUIgKDM1MTY1MTg4OCA1MTIgYnl0 ZSBzZWN0b3JzKQphZGEzIGF0IGF0YTMgYnVzIDAgc2NidXMxIHRhcmdldCAxIGx1biAwCkdF T01fTUlSUk9SYWRhMzogPElOVEVMIFNTRFNDMktXNDgwSDYgTFNGMDMxQz4gQUNTLTMgQVRB IFNBVEEgMy54IGRldmljZQphZGEzOiBTZXJpYWwgTnVtYmVyIENWTFQ2MjUwMDdZRTQ4MEVH TgphZGEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNSwgUElPIDgx OTJieXRlcykKYWRhMzogNDU3ODYyTUIgKDkzNzcwMzA4OCA1MTIgYnl0ZSBzZWN0b3JzKQo6 IERldmljZSBtaXJyb3IvZ20wIGxhdW5jaGVkICgxLzIpLgpHRU9NX01JUlJPUjogRGV2aWNl IGdtMDogcmVidWlsZGluZyBwcm92aWRlciBhZGEwLgpUcnlpbmcgdG8gbW91bnQgcm9vdCBm cm9tIHVmczovZGV2L21pcnJvci9nbTBwMiBbcnddLi4uCnVodWIxOiA2IHBvcnRzIHdpdGgg NiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjogNiBwb3J0cyB3aXRoIDYgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWdlbjEuMjogPEFtZXJpY2FuIE1lZ2F0cmVuZHMgSW5jLiBW aXJ0dWFsIEtleWJvYXJkIGFuZCBNb3VzZT4gYXQgdXNidXMxCnVrYmQwIG51bWEtZG9tYWlu IDAgb24gdWh1YjcKdWtiZDA6IDxLZXlib2FyZCBJbnRlcmZhY2U+IG9uIHVzYnVzMQprYmQy IGF0IHVrYmQwCnVtczAgbnVtYS1kb21haW4gMCBvbiB1aHViNwp1bXMwOiA8TW91c2UgSW50 ZXJmYWNlPiBvbiB1c2J1czEKaWdiMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCkFjY291 bnRpbmcgZW5hYmxlZAo= --------------5C6DD70BDC44436AA37B5DA7-- From owner-freebsd-hackers@freebsd.org Wed Apr 4 21:26:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10BFDF77ADE for ; Wed, 4 Apr 2018 21:26:03 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E2174D23 for ; Wed, 4 Apr 2018 21:26:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 775443FB66; Wed, 4 Apr 2018 23:25:59 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: mips.mips64elhf and mips.mips64el buildworld Date: Wed, 4 Apr 2018 23:25:58 +0200 In-Reply-To: <201804041502.w34F2iEC061198@slippy.cwsent.com> Cc: freebsd-hackers@freebsd.org To: Cy Schubert References: <201804041502.w34F2iEC061198@slippy.cwsent.com> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 21:26:03 -0000 --Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 4 Apr 2018, at 17:02, Cy Schubert wrote: > > In message <06A6FF73-A15B-4EA1-854A-B2B741FB7E63@FreeBSD.org>, Dimitry > Andric writes: ... >> Which program is producing the "could not read symbols" output? The >> linker? Maybe it trips up over these 32-bit shared libraries. > > Yes, it appears to be the linker. > >> >> It would probably help a bit if you posted the buildworld output >> somewhere, so it is more easily visible how the libraries are built, >> and by which program(s) they are processed. > > Do you have access to universe12b.freebsd.org? The output is in > /home/cy/projects/pvt/_.mips.mips64elhf.buildworld and > /home/cy/projects/pvt/_.mips.mips64el.buildworld. > > The Makefile building the library in question is kerberos5/lib/libasn1/M > akefile. My alterations are: > > universe12b$ svn diff -cr323334 kerberos5/lib/libasn1/Makefile FWIW, a clean head checkout as of r332035 can build world just fine for mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to /dev/null. So it's likely due to your changes, I'll try those tomorrow. -Dimitry --Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsVC5gAKCRCwXqMKLiCW o/ixAJ9IInE/NWFKxCwwZ4a5D/OLug33AgCglP4Dyv+6QS2iYjftv9ySpl3+wwo= =ltv8 -----END PGP SIGNATURE----- --Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13-- From owner-freebsd-hackers@freebsd.org Wed Apr 4 22:33:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D2B6F7BEC8 for ; Wed, 4 Apr 2018 22:33:20 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 100DE77643 for ; Wed, 4 Apr 2018 22:33:19 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C40271446B for ; Wed, 4 Apr 2018 22:33:13 +0000 (UTC) Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: freebsd-hackers@freebsd.org References: From: Allan Jude Message-ID: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> Date: Wed, 4 Apr 2018 18:33:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="63qcE3B0M0IZ6tD1wlkjZsTiQJd3MXmPY" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 22:33:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --63qcE3B0M0IZ6tD1wlkjZsTiQJd3MXmPY Content-Type: multipart/mixed; boundary="EF9SCBqfFtb44tdx0iHbIDxncWv57apxK"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map References: In-Reply-To: --EF9SCBqfFtb44tdx0iHbIDxncWv57apxK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-04-04 17:13, Craig Leres wrote: > I freebsd-upgrade'd one of my 10.3-RELEASE poudriere build servers to > 11.1-RELEASE-p8 yesterday and have found that starting virtualbox > panic's the system with: ncpus is 0 with non-zero map >=20 > =C2=A0=C2=A0=C2=A0 virtualbox-ose-5.2.8_1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 General-purpose full virtualizer for > x86 hardware > =C2=A0=C2=A0=C2=A0 virtualbox-ose-kmod-5.2.8_1=C2=A0=C2=A0=C2=A0 Virtua= lBox kernel module for FreeBSD >=20 > I have a custom kernel but the changes are minor (MAXCPU=3D64, PPS_SYNC= , > DDB/GDB, etc.) It doesn't look like virtualbox-ose or > virtualbox-ose-kmod have changed very recently so I'm not sure how to > debug this. But I'm not 100% sure I ran virtual box with the current > version of the virtualbox-ose-kmod kernel modules loaded. The system ha= s > a X5690 processor with 24 cores. >=20 > I've attached dmesg.boot >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Craig >=20 >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 So are you loading the virtualbox module from 10.3 into an 11.1 kernel? You'll need to rebuild the virtualbox-ose-kmod port to match the kernel you are running. --=20 Allan Jude --EF9SCBqfFtb44tdx0iHbIDxncWv57apxK-- --63qcE3B0M0IZ6tD1wlkjZsTiQJd3MXmPY 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) iQIcBAEBAgAGBQJaxVKxAAoJEBmVNT4SmAt+/8oP/jhP0qmzmwHF+r9smAzST64M yMCm3LmFQN34oztfPjZM89QnnerM0lyvnI0A09Ta8VFyBLoyjxe8YK+BnsfL530e LQsK1nEmxV32HvtWq7ULwmzCjD7fCI6AoExKg+F9yRFiX83KQVKYAfCE8+sd+ND9 wnWwgZKSILXbdCi7kCT5kq+M5wtYRSpZVVLYzC3QNsyW1EiO4Y2hlhouNq2JNViS I/nuYUdx9nIlA8emAtL3Vd4AaSqSCdx1f9W9rSAIKE4Q0OJAv7GstjzNERRMkE3i /nUbSTlhBYO+yM/YOPnuNCb7HyZk6vosmLUG4Klv9p9Zj7/9nlFwfF5c+6qh3fek HobAiVuCYIkkPVA6k9KxB2n2h1gvrtzdjdizvi9qpwCp3bcdYGoR1DpqYWEbbPB6 2a9gkSVu1JgXGbQmEfKV9mbQAN9uyCq186Q8wCG2ZDfnaU95M9JOU6UNXe4iQfZH gixkLivDokd21U0xuAaj5jxsBS4dqDmS4M9txwD9nWcVdR3nSfiRYXnplQOuye1X 9C9XEuXbgqlJawqoztiPClmAawyiFtbMAVCXd8XZEIFVtsUDZTFsyfNbFhF2FJFu WZLg7WkM43ZjAkdx1/w8yTSxpq4kYvJVIGn3WIZX8RSUC2yvk8awyVajr/HZYrxc QNkShEAFkW32WOKuY74P =K9Om -----END PGP SIGNATURE----- --63qcE3B0M0IZ6tD1wlkjZsTiQJd3MXmPY-- From owner-freebsd-hackers@freebsd.org Wed Apr 4 22:42:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0B94F7C9D2 for ; Wed, 4 Apr 2018 22:42:16 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4922C77CF1; Wed, 4 Apr 2018 22:42:16 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.ee.lbl.gov (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w34MgCGv076955 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 15:42:14 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.ee.lbl.gov Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: Allan Jude , freebsd-hackers@freebsd.org References: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> From: Craig Leres Message-ID: Date: Wed, 4 Apr 2018 15:42:12 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2464-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 22:42:16 -0000 On 04/04/18 15:33, Allan Jude wrote: > So are you loading the virtualbox module from 10.3 into an 11.1 kernel? > > You'll need to rebuild the virtualbox-ose-kmod port to match the kernel > you are runnin As part of the upgrade I removed all packages (pkg delete -fya), after I used enough pkg.freebsd.org packages to be able to run poudriere to rebuild all of the packages I use. Then I reinstalled all packages from my pkg server (pkg clean -ay ; pkg upgrade -yf ; pkg clean -ay). I just verified that /boot/modules/vbox*.ko match the ones in the package in /public/FreeBSD:11:amd64/latest/All/virtualbox-ose-kmod-5.2.8_1.txz on my server. Craig From owner-freebsd-hackers@freebsd.org Wed Apr 4 22:50:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B98B3F7D343 for ; Wed, 4 Apr 2018 22:50:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 6E8187839E for ; Wed, 4 Apr 2018 22:50:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3EA3F144CE for ; Wed, 4 Apr 2018 22:50:58 +0000 (UTC) Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: freebsd-hackers@freebsd.org References: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> From: Allan Jude Message-ID: <1288458d-d0dd-40d8-eaf9-32fcd0ca6137@freebsd.org> Date: Wed, 4 Apr 2018 18:51:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 22:50:59 -0000 On 2018-04-04 18:42, Craig Leres wrote: > On 04/04/18 15:33, Allan Jude wrote: >> So are you loading the virtualbox module from 10.3 into an 11.1 kernel? >> >> You'll need to rebuild the virtualbox-ose-kmod port to match the kernel >> you are runnin > > As part of the upgrade I removed all packages (pkg delete -fya), after I > used enough pkg.freebsd.org packages to be able to run poudriere to > rebuild all of the packages I use. Then I reinstalled all packages from > my pkg server (pkg clean -ay ; pkg upgrade -yf ; pkg clean -ay). > > I just verified that /boot/modules/vbox*.ko match the ones in the > package in > /public/FreeBSD:11:amd64/latest/All/virtualbox-ose-kmod-5.2.8_1.txz on > my server. > >         Craig > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" The official packages are built for the GENERIC kernel, I think specifically changing the MAXCPU will change the size of one of the structs used by the module, causing this issue. -- Allan Jude From owner-freebsd-hackers@freebsd.org Wed Apr 4 23:18:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C344BF7EC5D for ; Wed, 4 Apr 2018 23:18:42 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C14F79484; Wed, 4 Apr 2018 23:18:42 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.ee.lbl.gov (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w34NIeI7079404 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 16:18:41 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.ee.lbl.gov Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: Allan Jude , freebsd-hackers@freebsd.org References: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> <1288458d-d0dd-40d8-eaf9-32fcd0ca6137@freebsd.org> From: Craig Leres Message-ID: Date: Wed, 4 Apr 2018 16:18:40 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1288458d-d0dd-40d8-eaf9-32fcd0ca6137@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2439-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 23:18:42 -0000 On 04/04/18 15:51, Allan Jude wrote: > The official packages are built for the GENERIC kernel, I think > specifically changing the MAXCPU will change the size of one of the > structs used by the module, causing this issue. I'm not so sure about that. I believe MAXCPU changes some data structure sizes and allows for kernels that have up to that many cores. I don't believe loadable drivers care what it is. They system I built the virtualbox-ose-kmod package on was running the same 64 MAXCPU kernel at the time (I built and booted the custom kernel before building packages). Craig From owner-freebsd-hackers@freebsd.org Wed Apr 4 23:19:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 066E6F7EC98 for ; Wed, 4 Apr 2018 23:19:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79E5E794D3; Wed, 4 Apr 2018 23:19:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 3rgAfjG9GYxCT3rgCfjTkA; Wed, 04 Apr 2018 17:19:01 -0600 X-Authority-Analysis: v=2.3 cv=cav8UELM c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=Kd1tUaAdevIA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=iCCEnvsy0L29R531B7AA:9 a=2Zto1anFngujXxAO:21 a=UzxhtWZoYfper-gM:21 a=QEXdDO2ut3YA:10 a=69C-Jw9LTyA5UGwCVs4A:9 a=jDifZ_MuaYFOLR3S:21 a=pFlbwcwcUVTkQ6PL:21 a=VYtK0f202Yp4cofb:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.85.100.44] (unknown [24.244.29.75]) by spqr.komquats.com (Postfix) with ESMTPSA id 45A6732A4; Wed, 4 Apr 2018 16:18:57 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map Date: Wed, 4 Apr 2018 17:19:03 -0600 To: Allan Jude , "freebsd-hackers@freebsd.org" Message-Id: <20180404231857.45A6732A4@spqr.komquats.com> X-CMAE-Envelope: MS4wfElvADGw3HKwfLxW8jkVpgkI1At9J2fja3CzPpKnN6nXLFIfjDCGZ1p3ZgPSxHtHAFpaBR5gs+ZWxOqPjrnVtClZHaz8FBhBMb7+qcn4kd/ukxpQdFs8 XmYeVqvyAD6fMKWCtLtmVCNJZdSnr9kAJ1kQAwi1y2diK+hbVLkcmA9anpZmldtq4DoXZbFukb8jtllQaqpW0u7oIVrxC84EfQvaC6SUxV7QxBybBcJl15uK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 23:19:09 -0000 I had the same problem on -current last week. Rebuilding the vbox kld resol= ved the panic. I also rebuilt the GUI for clean and healthy living. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Allan Jude Sent: 04/04/2018 16:52 To: freebsd-hackers@freebsd.org Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero ma= p On 2018-04-04 18:42, Craig Leres wrote:=0A= > On 04/04/18 15:33, Allan Jude wrote:=0A= >> So are you loading the virtualbox module from 10.3 into an 11.1 kernel?= =0A= >>=0A= >> You'll need to rebuild the virtualbox-ose-kmod port to match the kernel= =0A= >> you are runnin=0A= > =0A= > As part of the upgrade I removed all packages (pkg delete -fya), after I= =0A= > used enough pkg.freebsd.org packages to be able to run poudriere to=0A= > rebuild all of the packages I use. Then I reinstalled all packages from= =0A= > my pkg server (pkg clean -ay ; pkg upgrade -yf ; pkg clean -ay).=0A= > =0A= > I just verified that /boot/modules/vbox*.ko match the ones in the=0A= > package in=0A= > /public/FreeBSD:11:amd64/latest/All/virtualbox-ose-kmod-5.2.8_1.txz on=0A= > my server.=0A= > =0A= > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Craig=0A= > _______________________________________________=0A= > freebsd-hackers@freebsd.org mailing list=0A= > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= "=0A= =0A= The official packages are built for the GENERIC kernel, I think=0A= specifically changing the MAXCPU will change the size of one of the=0A= structs used by the module, causing this issue.=0A= =0A= -- =0A= Allan Jude=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= From owner-freebsd-hackers@freebsd.org Wed Apr 4 23:22:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15C21F7F072 for ; Wed, 4 Apr 2018 23:22:06 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 98ACA7996A; Wed, 4 Apr 2018 23:22:05 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.ee.lbl.gov (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w34NM1Dq079671 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Apr 2018 16:22:02 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.ee.lbl.gov Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: Cy Schubert , Allan Jude , "freebsd-hackers@freebsd.org" References: <20180404231857.45A6732A4@spqr.komquats.com> From: Craig Leres Message-ID: <6e714c3e-b98e-a7a6-3f76-c7ba34448b39@freebsd.org> Date: Wed, 4 Apr 2018 16:22:01 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180404231857.45A6732A4@spqr.komquats.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-1761-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 23:22:06 -0000 On 04/04/18 16:19, Cy Schubert wrote: > I had the same problem on -current last week. Rebuilding the vbox kld resolved the panic. > > I also rebuilt the GUI for clean and healthy living. I rebuild all packages I use daily so I'll reinstall it once I catch up with the p9 update. Thanks! Craig From owner-freebsd-hackers@freebsd.org Thu Apr 5 02:40:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33262F8C82A for ; Thu, 5 Apr 2018 02:40:45 +0000 (UTC) (envelope-from ilovefd@topaz.plala.or.jp) Received: from msc12.plala.or.jp (msc12.plala.or.jp [IPv6:2400:7800:0:502e::22]) by mx1.freebsd.org (Postfix) with ESMTP id 3716881A64 for ; Thu, 5 Apr 2018 02:40:43 +0000 (UTC) (envelope-from ilovefd@topaz.plala.or.jp) Received: from [192.168.89.79] (really [119.104.40.17]) by msc12.plala.or.jp with ESMTP id <20180405024040.CEZG22728.msc12.plala.or.jp@[192.168.89.79]> for ; Thu, 5 Apr 2018 11:40:40 +0900 From: ilovefd Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?B?UmU6IFtGcmVlQlNELXVzZXJzLWpwIDk2MjA0XSAgRnJlZWJzZDEw?= =?utf-8?B?LjHjga7jgqvjg7zjg43jg6tuYXTjgadzbXRw44GM6YCa44KJ44Gq44GE?= Date: Thu, 5 Apr 2018 11:40:37 +0900 References: <87156DB8-3D5C-4404-8B3D-597617DC43EA@topaz.plala.or.jp> To: freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <3BD7D6EE-B400-42D6-98A5-3DC2647A16AB@topaz.plala.or.jp> X-Mailer: Apple Mail (2.3273) X-VirusScan: Outbound; mvir-ac12; Thu, 5 Apr 2018 11:40:41 +0900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 02:40:45 -0000 6KW/5p2R44Gn44GZDQoNCuOBguOCiuOBjOOBqOOBhuOBlOOBluOBhOOBvuOBmeOAgg0K5b2T44Gf 44KK44Gu44KI44GG44Gn44GZ44CCDQrjgq/jg6njgqTjgqLjg7Pjg4jlgbTjga5OQVTjgYzljp/l m6DjgafjgZfjgofjgYbjgYvvvJ8NCg0KPiB0ZWxuZXQgZ21haWwtc210cC1pbi5sLmdvb2dsZS5j b20gPGh0dHA6Ly9nbWFpbC1zbXRwLWluLmwuZ29vZ2xlLmNvbS8+IDI1IOOBquOBqeS7luOBuFNN VFDmjqXntprjgafjgY3jgb7jgZvjgpPjgafjgZfjgZ/jgIINCg0KDQrjgqTjg7Pjgr/jg7zjg43j g4Pjg4jlgbTjgYvjgolOQVQtQeOBruWGheWBtOOBrlNNVFDjgrXjg7zjg5Djgat0ZWxuZXQgIGhv Z2UuaG9nZS5jb20gPGh0dHA6Ly9ob2dlLmhvZ2UuY29tLz4gMjXjgZnjgovloLTlkIjjgIHmraPn orrjgavjgYTjgYbjgajjgqTjg7Pjgr/jg7zjg43jg4Pjg4jlgbTjga7nq6/mnKvjgoJOQVTjg6vj g7zjgr/jgaTjgb7jgopOQVQtQuOBruWGheWBtOOBq+WFpeOBo+OBpuOBhOOBvuOBmeOAguOBneOB k+OBp05BVC1CKEZyZWVCU0QxMC4xKeOBq+ODreOCsOOCpOODs+OBl+OAgU5BVC1B44Gu5YaF5YG0 44GuU01UUOOBq3RlbG5ldCAgaG9nZS5ob2dlLmNvbSA8aHR0cDovL2hvZ2UuaG9nZS5jb20vPiAy NeOBl+OBpuOBv+OBvuOBl+OBn+OCieOBhuOBvuOBj+OBhOOBjeOBvuOBl+OBny4NCg0KJCB0ZWxu ZXQgaG9nZS5ob2dlLXdpa2kuY29tIDI1DQpUcnlpbmcgMjE5LlhYLlhYLlhYLi4uDQpDb25uZWN0 ZWQgdG8gaG9nZS5ob2dlLXdpa2kuY29tLg0KRXNjYXBlIGNoYXJhY3RlciBpcyAnXl0nLg0KMjIw IG1haWw1LmhvZ2UuY29tIEVTTVRQDQpxdWl0DQoyMjEgMi4wLjAgQnllDQpDb25uZWN0aW9uIGNs b3NlZCBieSBmb3JlaWduIGhvc3QuDQokIA0KDQrljp/lm6Djga/jg6Hjg7zjg6vjgq/jg6njgqTj gqLjg7Pjg4jjga7nva7jgYTjgabjgYLjgovlgbTjga5OQVQtQuODq+ODvOOCv+OBruOCiOOBhuOB p+OBmeOAgg0KTkFULULjgYvjgolOQVQtQeWGheWBtFNNUFTjgavnm7TmjqV0ZWxuZXQgMjXjgZnj govjga7jga8qT0vjgaDjgZHjgalOQVQtQuWGheWBtOerr+acq+OBi+OCieOBi+OCiU5BVC1B5YaF 5YG0U01QVOOBq3RlbG5ldCAyNeOBmeOCi+OBruOBr+WkseaVl+OBl+OBvuOBmeOAgg0KDQrjgb7j gZ/nj77lnKhOQVQtQuOBruWGheWBtOOBruODoeODvOODq+err+acq+OBruODoeODvOODq+OCveOD leODiOOBi+OCiXBsYWxh44Gr5a++44GX44Gm44GvaW1hcOOCr+ODqeOCpOOCouODs+ODiOOBp+mA geWPl+S/oeOBp+OBjeOBpuOBhOOCi+OBruOBq+OAgU5BVC1B44Gu5YaF5YG044GuU01QVOOBq+OB r+mAgeWPl+S/oeOBp+OBjeOBpuOBhOOBquOBhOOBruOBp+OAgeOBk+OCjOOBq+OBpOOBhOOBpuOB r++8ku+8leOBp+OBquOBj++8le+8mO+8l+OBq+OBmeOCjOOBsOmAmuOCi+OBqOOBhOOBhuOBk+OB qOOBquOBruOBp+OBl+OCh+OBhuOBi+OAgg0KDQoNCg0K From owner-freebsd-hackers@freebsd.org Thu Apr 5 04:15:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA10EF86052 for ; Thu, 5 Apr 2018 04:15:14 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 295F7862E5 for ; Thu, 5 Apr 2018 04:15:14 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.ee.lbl.gov (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w354FBBe098206 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 4 Apr 2018 21:15:12 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.ee.lbl.gov To: FreeBSD Hackers From: Craig Leres Subject: Supermicro IPMIView with 11.1-RELEASE Message-ID: <5402cf9a-20d3-1a0d-5602-531747cf3df3@freebsd.org> Date: Wed, 4 Apr 2018 21:15:11 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-32767-c Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:15:15 -0000 I'm working with 11.1-RELEASE via ipmi for the first time and there's something funny going on with the console. The first time I used a real vga console that everything was shifted a bit and that I needed to auto-calibrate my lcd panel. But I see now when I use the KVM supermicro ipmi console viewer that the bottom line is cut in half. And actually the last column is missing! stty says the console is 30x80 so I wrote a script to fill it with numbers and not output a final newline (see attached). It sure looks like everything is shifted right 1/2 character width (or more) and down 1/2 character height. Anybody know what's going on? Craig From owner-freebsd-hackers@freebsd.org Thu Apr 5 04:15:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4FB7F8615F for ; Thu, 5 Apr 2018 04:15:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 345808635F; Thu, 5 Apr 2018 04:15:38 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w354FPXk034276 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 06:15:25 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: leres@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w354FLkd013877 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2018 11:15:21 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: Craig Leres , Allan Jude , freebsd-hackers@freebsd.org References: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> From: Eugene Grosbein Message-ID: <5AC5A2D4.2080202@grosbein.net> Date: Thu, 5 Apr 2018 11:15:16 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:15:39 -0000 05.04.2018 5:42, Craig Leres wrote: > I just verified that /boot/modules/vbox*.ko match the ones in the package > in /public/FreeBSD:11:amd64/latest/All/virtualbox-ose-kmod-5.2.8_1.txz on my server. This is known problem that was raised multiple times in several mailing lists. In short: you cannot use kernel modules from packages reliably, period. You *must* use all kernel modules compiled using corresponding /usr/src tree, this includes kernel modules from ports too. Sometimes packaged modules may work, but there is no guarantee, because packages are built using previous supported release from same branch but kernel modules have to be built with exactly same release sources to match the kernel. From owner-freebsd-hackers@freebsd.org Thu Apr 5 04:29:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3692DF8716B for ; Thu, 5 Apr 2018 04:29:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B285286D71 for ; Thu, 5 Apr 2018 04:29:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w354T18O034356 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 06:29:02 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ilovefd@topaz.plala.or.jp Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w354SYlA014019 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2018 11:28:34 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: =?UTF-8?Q?Re:_[FreeBSD-users-jp_96204]_Freebsd10.1=e3=81=ae?= =?UTF-8?B?44Kr44O844ON44OrbmF044Gnc210cOOBjOmAmuOCieOBquOBhA==?= To: ilovefd , freebsd-hackers@freebsd.org References: <87156DB8-3D5C-4404-8B3D-597617DC43EA@topaz.plala.or.jp> <3BD7D6EE-B400-42D6-98A5-3DC2647A16AB@topaz.plala.or.jp> From: Eugene Grosbein Message-ID: <5AC5A5EE.4060805@grosbein.net> Date: Thu, 5 Apr 2018 11:28:30 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3BD7D6EE-B400-42D6-98A5-3DC2647A16AB@topaz.plala.or.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 04:29:09 -0000 05.04.2018 9:40, ilovefd wrote: > 西村です > > ありがとうございます。 > 当たりのようです。 > クライアント側のNATが原因でしょうか？ I would appreciate you use English only for this list. I'd love to use Russian here but that would be inappropriate, too. From owner-freebsd-hackers@freebsd.org Thu Apr 5 05:01:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9242FF89A88 for ; Thu, 5 Apr 2018 05:01:05 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 F0C9D68862; Thu, 5 Apr 2018 05:01:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w355115w096043; Wed, 4 Apr 2018 22:01:02 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w35511KB096042; Wed, 4 Apr 2018 22:01:01 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804050501.w35511KB096042@pdx.rh.CN85.dnsmgr.net> Subject: Re: Supermicro IPMIView with 11.1-RELEASE In-Reply-To: <5402cf9a-20d3-1a0d-5602-531747cf3df3@freebsd.org> To: Craig Leres Date: Wed, 4 Apr 2018 22:01:01 -0700 (PDT) CC: FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 05:01:05 -0000 > I'm working with 11.1-RELEASE via ipmi for the first time and there's > something funny going on with the console. The first time I used a real > vga console that everything was shifted a bit and that I needed to > auto-calibrate my lcd panel. But I see now when I use the KVM supermicro > ipmi console viewer that the bottom line is cut in half. And actually > the last column is missing! > > stty says the console is 30x80 so I wrote a script to fill it with > numbers and not output a final newline (see attached). It sure looks > like everything is shifted right 1/2 character width (or more) and down > 1/2 character height. > > Anybody know what's going on? The new "vt" graphical console is borked, it is known to have issues with KVM's and impi consoles. Its graphics timing signals are off standard just enough to mess things up. You can probably get around your issue by switching to syscons console. IIRC you can drop to the loader prompt, and type: kern.vty=sc boot to work around this issue. But this may create issues with EFI bios. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Apr 5 05:03:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8B0EF89CFD for ; Thu, 5 Apr 2018 05:03:09 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 5ADB668A9C; Thu, 5 Apr 2018 05:03:09 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8665A147CF; Thu, 5 Apr 2018 05:03:07 +0000 (UTC) Subject: Re: Supermicro IPMIView with 11.1-RELEASE To: freebsd-hackers@freebsd.org References: <201804050501.w35511KB096042@pdx.rh.CN85.dnsmgr.net> Cc: Kyle Evans From: Allan Jude Message-ID: <96febeb0-d7f0-1b74-eb23-a3a2884eddf4@freebsd.org> Date: Thu, 5 Apr 2018 01:03:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201804050501.w35511KB096042@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 05:03:09 -0000 On 2018-04-05 01:01, Rodney W. Grimes wrote: >> I'm working with 11.1-RELEASE via ipmi for the first time and there's >> something funny going on with the console. The first time I used a real >> vga console that everything was shifted a bit and that I needed to >> auto-calibrate my lcd panel. But I see now when I use the KVM supermicro >> ipmi console viewer that the bottom line is cut in half. And actually >> the last column is missing! >> >> stty says the console is 30x80 so I wrote a script to fill it with >> numbers and not output a final newline (see attached). It sure looks >> like everything is shifted right 1/2 character width (or more) and down >> 1/2 character height. >> >> Anybody know what's going on? > > The new "vt" graphical console is borked, it is known to have issues > with KVM's and impi consoles. Its graphics timing signals are off > standard just enough to mess things up. > > You can probably get around your issue by switching to syscons console. > > IIRC you can drop to the loader prompt, and type: > kern.vty=sc > boot > > to work around this issue. But this may create issues with EFI bios. > I can donate access to a machine or 3 if someone would actually fix this. -- Allan Jude From owner-freebsd-hackers@freebsd.org Thu Apr 5 05:24:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10FAAF8B2F8 for ; Thu, 5 Apr 2018 05:24:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B2A66991A; Thu, 5 Apr 2018 05:24:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w355OFXS034716 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Apr 2018 07:24:16 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w355OBBJ014616 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2018 12:24:11 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Supermicro IPMIView with 11.1-RELEASE To: "Rodney W. Grimes" , Craig Leres References: <201804050501.w35511KB096042@pdx.rh.CN85.dnsmgr.net> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <5AC5B2F7.8090406@grosbein.net> Date: Thu, 5 Apr 2018 12:24:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201804050501.w35511KB096042@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 05:24:25 -0000 05.04.2018 12:01, Rodney W. Grimes wrote: > You can probably get around your issue by switching to syscons console. > > IIRC you can drop to the loader prompt, and type: > kern.vty=sc > boot > > to work around this issue. But this may create issues with EFI bios. "man vt" says that it supports text mode: hw.vga.textmode=1 That might be useful for EFI users. I personally have not tested it, though. From owner-freebsd-hackers@freebsd.org Thu Apr 5 19:17:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B79BF9BF2F for ; Thu, 5 Apr 2018 19:17:34 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp003.me.com (mr11p00im-asmtp003.me.com [17.110.69.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B425E6C570 for ; Thu, 5 Apr 2018 19:17:33 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp003.me.com by mr11p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P6Q004007K2VB00@mr11p00im-asmtp003.me.com> for freebsd-hackers@freebsd.org; Thu, 05 Apr 2018 19:17:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=04042017; t=1522955844; bh=t3ehTDvL7mlU/C5J9xep9cY9ALJkf03bp98VqFrw/nA=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=YhDp4xbyCj6+2iPoWJYlqV2geawnvmdPJr31VTL2cFPiiPz+dD9kskyU6MHQP88Wn eGxuqD7cHq0+/sDqB4A4S/fvlzfMFufLmWHzdftfBr7kDZ7zg7N+Aewg2bukaC2Zt7 UytpGWsAziJ3HSGuN316UJFuz45X3W/h5Gb1zp1w3SMBeJypJYAF8fHDEq5KMYvUcD fJp2tszMwD937AFzwIQDhP41aewkPu87Dc8eQQekWeN6avqjOv88Uz+iM2NNbAlIrr S7RNBmtOg2gFNggEDALeoB2vgWhTyt66e5/bvJL3lZeYLhUfp2oT1pdaUOpmx35fnF cjh2I/IuBFQZg== Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P6Q004V888Y5N20@mr11p00im-asmtp003.me.com> for freebsd-hackers@freebsd.org; Thu, 05 Apr 2018 19:17:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-04-05_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1804050196 User-Agent: Microsoft-MacOutlook/10.b.0.180311 Date: Thu, 05 Apr 2018 12:17:21 -0700 Subject: Request for Data: `ipmitool fru print' From: Ravi Pokala To: "freebsd-hackers@freebsd.org" Message-id: Thread-topic: Request for Data: `ipmitool fru print' MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 05 Apr 2018 20:03:15 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 19:17:34 -0000 Greetings, I'm looking for some data with which to berate a vendor about their IPMI implementation. If you have hardware which meets the following specifications, I would appreciate it if you could send me some information. Hardware Requirements: - Vendor other than Intel or Super Micro (I already have data for them) - Swappable power-supplies Command (serial numbers, etc stripped out by the `sed'): ipmitool fru print | sed -E -e 's/(^ .* :) .*/\1/g' If you also have a system where multiple nodes share the same enclosure, it would be great if you ran the command without the `sed' on a few nodes, compare the output, and describe any differences. Thanks, Ravi (rpokala@) From owner-freebsd-hackers@freebsd.org Thu Apr 5 20:14:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AC25F9F87A for ; Thu, 5 Apr 2018 20:14:46 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 431226F13A for ; Thu, 5 Apr 2018 20:14:45 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-wr0-x233.google.com with SMTP id 80so30454662wrb.2 for ; Thu, 05 Apr 2018 13:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n5NUXGEAVj57jYJVcKHMVw7RnheT0o/PupZEplxIteI=; b=WchG6UMszKB0HSvkyGi+FMNagusLrSo/OX7V0yeiPbcTI+oZ8pcB1BnHz4nx2ra3zW 8ZqXDOYQGMB3FrsUehrHdcjw9Ck8n5gK5AEyDRhQWGSVupQZdTRMmOGDchuLXtAhH7iM ouHHM41PZZsYqQtm2RiLO0curqMLrnewYi6Hs7SAtRQ1Sj0aJL6xJROra7g1zqI7eiE1 KVS/8jssz9f1Rxg9myAnGI6Im2RDBIsIvUOv0Gjv+8ZurTUjaeaySUnvpT6KPUW0C28X Z5oO8jC4c9xvpQeNtDkqdKOQLxpc4yA/oxuB3o9SEOwxkaTYjU6rYl62PZXzEsL1iYnW YL0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n5NUXGEAVj57jYJVcKHMVw7RnheT0o/PupZEplxIteI=; b=UhZCFZMPzcj2RXCl+Ab/VZJMXkQ1F263Sq4Sc1adhs4zp1pmwcZzRhGsk9vP8dTGHh bPL0Mnl9SoNLsbCBqVkPvi6NGnc7SimARvxXCnNgBEX9iMZkJfsboUquo4Oba/xTnDnj nJCI/b3uSbOxUZKHWLz5ifmLksnq/LuftfZbmeSmmgKoeXJl6tffuCpfpj1U5/9gWpv5 Ly+FnwbgpZRjr9IzyrdB7N46TA923ffgneGh5jVk+kNk1fisN4gluffHC0TV+b65Vdms x+zF6yGWGisoKt9Xg/AEZ2Pj9kRMBLwTkDq7iKbkoMBB2l8tNFIiD9yP/3ZpGNDWLerw rkhQ== X-Gm-Message-State: AElRT7Ebp1Gct6n0jg/71FZ8Nz8EX6ff3DQBtmVIf8HfZNF3fZzwCdFJ bU3j+jSj/VzgggVPE/9LcMGthgqaGFKaDcr9sGg7MQ== X-Google-Smtp-Source: AIpwx4+EFemwdj29d+07zhMpt6o+A1/nALrGjYwjolj9P960vwcDyIE4jW1ixLcjuw12FjQxRWmxF1JyiWHJh4hS33s= X-Received: by 10.223.163.87 with SMTP id d23mr17023680wrb.103.1522959284124; Thu, 05 Apr 2018 13:14:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.147.130 with HTTP; Thu, 5 Apr 2018 13:14:03 -0700 (PDT) In-Reply-To: References: From: "Jack L." Date: Thu, 5 Apr 2018 13:14:03 -0700 Message-ID: Subject: Re: Request for Data: `ipmitool fru print' To: Ravi Pokala Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:14:46 -0000 dell 1950 ipmitool fru print | sed -E -e 's/(^ .* :) .*/\1/g' FRU Device Description : Builtin FRU Device (ID 0) Chassis Type : Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : Product Manufacturer : FRU Device Description : DRAC 5 Chassis Type : Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : Product Manufacturer : FRU Device Description : Storage (ID 2) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : PS 1 (ID 3) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : PS 2 (ID 4) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : Storage (ID 5) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : DRAC 5 (ID 0) Chassis Type : Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : Product Manufacturer : dell r610 FRU Device Description : Builtin FRU Device (ID 0) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : Product Manufacturer : Product Name : Product Version : Product Serial : FRU Device Description : PS 1 (ID 2) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : PS 2 (ID 3) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : Storage (ID 5) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : Storage (ID 4) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : dell c1100 FRU Device Description : Builtin FRU Device (ID 0) FRU Device Description : Front Panel (ID 1) Chassis Type : Board Mfg Date : Board Part Number : On Thu, Apr 5, 2018 at 12:17 PM, Ravi Pokala wrote: > Greetings, > > I'm looking for some data with which to berate a vendor about their IPMI implementation. If you have hardware which meets the following specifications, I would appreciate it if you could send me some information. > > Hardware Requirements: > - Vendor other than Intel or Super Micro (I already have data for them) > - Swappable power-supplies > > Command (serial numbers, etc stripped out by the `sed'): > ipmitool fru print | sed -E -e 's/(^ .* :) .*/\1/g' > > If you also have a system where multiple nodes share the same enclosure, it would be great if you ran the command without the `sed' on a few nodes, compare the output, and describe any differences. > > Thanks, > > Ravi (rpokala@) > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Apr 5 20:25:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AB16FA02B8 for ; Thu, 5 Apr 2018 20:25:08 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCE2F6F7A2 for ; Thu, 5 Apr 2018 20:25:07 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZdWawydoc7Qas777JW4DFAXEnED7JP2TLzxX94ciq4E=; b=PuiryKikdEbkI1xyuUCSk8/YIv EuGB+9FKwvrur2OBw90Z5c/wzgLBJb290YdG34cxoeGWmnE5RzZEgOs3cbP1v7aBR9KDE/EuHkoR9 YuJF0i1dsjjh+Jusi2u3AMOIv7vIuBmYG9BOA5FRufKNBRa9rd/U14i0cN/KHpmifmA4=; Received: from [2600:1700:210:b18f:cd2c:9713:35dc:1958] (port=59010 helo=[192.168.200.50]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1f4BRS-000Eje-41; Thu, 05 Apr 2018 15:25:06 -0500 User-Agent: Microsoft-MacOutlook/10.d.0.180401 Date: Thu, 05 Apr 2018 15:24:54 -0500 Subject: Re: Request for Data: `ipmitool fru print' From: Larry Rosenman To: Ravi Pokala , "freebsd-hackers@freebsd.org" Message-ID: <5238AC2A-14E8-4610-80BA-16DF4C4264F0@lerctr.org> Thread-Topic: Request for Data: `ipmitool fru print' References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 20:25:08 -0000 Dell R710: borg.lerctr.org /home/ler $ sudo ipmitool fru print | sed -E -e 's/(^ .* :)= .*/\1/g' FRU Device Description : Builtin FRU Device (ID 0) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : Product Manufacturer : Product Name : Product Version : Product Serial : Product Asset Tag : FRU Device Description : PS 1 (ID 2) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : PS 2 (ID 3) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : Storage (ID 5) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : FRU Device Description : Storage (ID 4) Board Mfg Date : Board Mfg : Board Product : Board Serial : Board Part Number : borg.lerctr.org /home/ler $ --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 =EF=BB=BFOn 4/5/18, 3:03 PM, "Ravi Pokala" wrote: Greetings, =20 I'm looking for some data with which to berate a vendor about their IPM= I implementation. If you have hardware which meets the following specificati= ons, I would appreciate it if you could send me some information. =20 Hardware Requirements: - Vendor other than Intel or Super Micro (I already have data for them) - Swappable power-supplies =20 Command (serial numbers, etc stripped out by the `sed'): ipmitool fru print | sed -E -e 's/(^ .* :) .*/\1/g' =20 If you also have a system where multiple nodes share the same enclosure= , it would be great if you ran the command without the `sed' on a few nodes,= compare the output, and describe any differences. =20 Thanks, =20 Ravi (rpokala@) =20 =20 _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" =20 From owner-freebsd-hackers@freebsd.org Fri Apr 6 04:04:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED7B7F9DFBB for ; Fri, 6 Apr 2018 04:04:11 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75295829B3; Fri, 6 Apr 2018 04:04:11 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2620:83:8000:102::cb; helo=hot.ee.lbl.gov; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from hot.ee.lbl.gov (hot.ee.lbl.gov [IPv6:2620:83:8000:102:0:0:0:cb]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w36447Qd097420 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Apr 2018 21:04:08 -0700 (PDT) (envelope-from leres@freebsd.org) Subject: Re: 11.1-RELEASE virtualbox-ose panic: ncpus is 0 with non-zero map To: Eugene Grosbein , Allan Jude , freebsd-hackers@freebsd.org References: <3fd9fbd1-26ef-c176-2c4b-cf02f89ea680@freebsd.org> <5AC5A2D4.2080202@grosbein.net> From: Craig Leres Message-ID: <7c0a41c4-01a2-140f-2628-6aa7e1da976f@freebsd.org> Date: Thu, 5 Apr 2018 21:04:07 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5AC5A2D4.2080202@grosbein.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2970-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 04:04:12 -0000 On 04/04/18 21:15, Eugene Grosbein wrote: > 05.04.2018 5:42, Craig Leres wrote: > >> I just verified that /boot/modules/vbox*.ko match the ones in the package >> in /public/FreeBSD:11:amd64/latest/All/virtualbox-ose-kmod-5.2.8_1.txz on my server. > > This is known problem that was raised multiple times in several mailing lists. Thanks for that; once I went looking I found this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219913 Due to ABI difference (vboxdrv passes cpuset_t parameter (bitfield with CPU_SETSIZE -> MAXCPU bits) into smp_rendezvous_cpus()) kernel panics with "ncpus is 0 with non-zero map" message. Part of my normal FreeBSD upgrade process was to raise MAXCPU to 64. As it turns out that is already the default for 10 and the default was *raised* to 256 for 11. So the solution is: don't mess with MAXCPU. Craig From owner-freebsd-hackers@freebsd.org Fri Apr 6 05:59:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACBAAF829D6 for ; Fri, 6 Apr 2018 05:59:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 17B81866E6; Fri, 6 Apr 2018 05:59:44 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4KPPf8MKpXziT4KPRfy7jK; Thu, 05 Apr 2018 23:59:37 -0600 X-Authority-Analysis: v=2.3 cv=X6B81lbe c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=exrVsgjqny4mTf_Mh2wA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id C6834759; Thu, 5 Apr 2018 22:59:34 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w365xYGf039360; Thu, 5 Apr 2018 22:59:34 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w365xY0T039346; Thu, 5 Apr 2018 22:59:34 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804060559.w365xY0T039346@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric cc: Cy Schubert , freebsd-hackers@freebsd.org Subject: Re: mips.mips64elhf and mips.mips64el buildworld In-Reply-To: Message from Dimitry Andric of "Wed, 04 Apr 2018 23:25:58 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Apr 2018 22:59:34 -0700 X-CMAE-Envelope: MS4wfFCZOsQXvlzpVRTmfAlu31ATHiQRBLjyTQHX9ucjwmizqNJHr0r012keXT1nLlY3HQvKx+RcdL83SY9OecgkXP50sKHT7XvFhCUGpDMlMS1EUZS4faQw OjmC55HQSBUhXZIoLqDpD2nOkCbNhC6o/JETERtXZCDPgh96GIv1qbuFDx14iuwftywHdsCpvuoM2jIkg7oASegsp90gciAYIw1Xs+/s8uavUdsJoIPDc/GR X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 05:59:45 -0000 In message , Dimitry Andric w rites: > > > --Apple-Mail=_E66CB1B0-06CC-4CF6-A1CF-8037AA029C13 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=us-ascii > > On 4 Apr 2018, at 17:02, Cy Schubert wrote: > > > > In message <06A6FF73-A15B-4EA1-854A-B2B741FB7E63@FreeBSD.org>, Dimitry > > Andric writes: > ... > >> Which program is producing the "could not read symbols" output? The > >> linker? Maybe it trips up over these 32-bit shared libraries. > > > > Yes, it appears to be the linker. > > > >> > >> It would probably help a bit if you posted the buildworld output > >> somewhere, so it is more easily visible how the libraries are built, > >> and by which program(s) they are processed. > > > > Do you have access to universe12b.freebsd.org? The output is in > > /home/cy/projects/pvt/_.mips.mips64elhf.buildworld and > > /home/cy/projects/pvt/_.mips.mips64el.buildworld. > > > > The Makefile building the library in question is kerberos5/lib/libasn1/M > > akefile. My alterations are: > > > > universe12b$ svn diff -cr323334 kerberos5/lib/libasn1/Makefile > > FWIW, a clean head checkout as of r332035 can build world just fine for > mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to > /dev/null. So it's likely due to your changes, I'll try those tomorrow. Agreed. I might be onto it. Building to verify my hypothesis. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri Apr 6 11:05:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44CE4F9C5D4 for ; Fri, 6 Apr 2018 11:05:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C307074652 for ; Fri, 6 Apr 2018 11:05:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F0D0644DBF; Fri, 6 Apr 2018 13:05:40 +0200 (CEST) From: Dimitry Andric Message-Id: <54034076-5964-4A06-94FA-1D56E284EE96@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: mips.mips64elhf and mips.mips64el buildworld Date: Fri, 6 Apr 2018 13:05:40 +0200 In-Reply-To: <201804060559.w365xY0T039346@slippy.cwsent.com> Cc: freebsd-hackers@freebsd.org To: Cy Schubert References: <201804060559.w365xY0T039346@slippy.cwsent.com> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 11:05:49 -0000 --Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 Apr 2018, at 07:59, Cy Schubert wrote: >=20 > In message , Dimitry > Andric writes: ... >>=20 >> FWIW, a clean head checkout as of r332035 can build world just fine = for >> mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to >> /dev/null. So it's likely due to your changes, I'll try those = tomorrow. >=20 > Agreed. I might be onto it. Building to verify my hypothesis. Adding your changes leads to the following buildworld error, at first: --- includes_subdir_kerberos5/lib --- install: target directory = `/home/dim/obj/head/home/dim/src/head/mips.mips64elhf/tmp/usr/include/priv= ate/asn1/' does not exist usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] [-B suffix] [-l linkflags] [-N dbdir] file1 file2 install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] [-B suffix] [-l linkflags] [-N dbdir] file1 ... fileN directory install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner] [-M log] [-D dest] [-h hash] [-T tags] directory ... --- includes_subdir_kerberos5/usr.bin --- --- includes_subdir_kerberos5/usr.bin/kinit --- =3D=3D=3D> kerberos5/usr.bin/kinit (includes) --- includes_subdir_kerberos5/lib --- *** [_INCSINS] Error code 64 so I added that directory to mtree, using: Index: etc/mtree/BSD.usr.dist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/mtree/BSD.usr.dist (revision 332040) +++ etc/mtree/BSD.usr.dist (working copy) @@ -9,6 +9,8 @@ .. include private + asn1 + .. bsdstat .. event but then it leads to many errors like the following: --- common.pico --- In file included from = /home/dim/src/head/crypto/heimdal/lib/ipc/common.c:36: /home/dim/src/head/crypto/heimdal/lib/ipc/hi_locl.h:57:25: error: = asn1-common.h: No such file or directory and: --- client.o --- /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = 'unix_socket_ipc': /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:391: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:392: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:405: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:406: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:408: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:413: error: = dereferencing pointer to incomplete type /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = 'heim_ipc_async': /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:562: error: storage = size of 'rcv' isn't known E.g. for some reason the required headers aren't found anymore. I never get to the stage where linking fails, in any case. :) -Dimitry --Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsdUhAAKCRCwXqMKLiCW ozc5AJ0UUGlxiniSfonfrVp5hYxfzE2E/wCgsw/oN58H3QVqsWB3kKHNuntv3yg= =Mqtn -----END PGP SIGNATURE----- --Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616-- From owner-freebsd-hackers@freebsd.org Fri Apr 6 15:18:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C713F8D90C for ; Fri, 6 Apr 2018 15:18:04 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BECD380EEA for ; Fri, 6 Apr 2018 15:18:03 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: by mail-ot0-x242.google.com with SMTP id h26-v6so1530542otj.12 for ; Fri, 06 Apr 2018 08:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=y0vPg5QtNSsLmWCJqO5BdLFgnkZzs6P4mbUIArPgpVs=; b=rpVpAFtCM0QzxivML2/jAtVc3Jpga8BLr+7LROGUKVmFA5CBmd4Qg6F1B4toQkj6gK 5Bofh3OXLPiu5mHbZQfaO5yWT4lOxXMqnEMN7JAjsfwmuMZPCh6pV5qGO32qLymwNLpS 8kTfqaD51EIP0wYnRHcHJ+KAGPzu4Q1W7eQo31xWKg/4277UCeJNt80A4cJCukZvEsSI dTnMKjO+Gswjdei1qvK4tQwAM955R/BYxY8H+O3daTsNzZ7jQ89a9Bk1ouTs2ceU8H/4 OvfAcF1hrcMwyEuTWRx+aZltIytagT1QTMDHeslGUW1xrJt/l+IURFzmpG53syvXhz9R 0zPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=y0vPg5QtNSsLmWCJqO5BdLFgnkZzs6P4mbUIArPgpVs=; b=ly7VWqFbqxrHixmzr0gdHJCH0HrW7H2CyCuw/2Hy5oHRuXVr/AdrJ4ZW15qhlOUxn1 lDQZl0mR55CemfTb4OLjGPemkC3PrpxwegI+0srkHUOFtjlzoXEpzqx9q8FwRO58I/DU 2FQXubIguh+x7C5DnqhUp/oLQcf7ErH3vQ2W52STjibuDMyHqTCEIH0k/Plcfoduz+EG CGCRh/4wa1fooHFprtlw3cnoAokjbH42DWriwK6PjUiPqX/YXlZ3af+zk2JEE2buAh0X tl64u4w0Qr8KPanOyNGPZjZVYmh67QOjoEQ8y1cUtBzQDn99Me9xFnwdX8LImyhMe9ID zMVQ== X-Gm-Message-State: ALQs6tAUUiwCUAyAKoZ3A3m8/wDHBEW+MRvq08mDBjJkEnc8lFJpeOJG QW/IF4tBnC93pef+NER2pLzezN/rNsj+Yn9lT6vzvQ== X-Google-Smtp-Source: AIpwx4+Gg25i+FhxBUBC3h0BVpJUqD3ugf4bXgJjA6vC9HYtxfiRHEntOZNDSLKuYonYTPlDOb7Vd4qjg7MhNzkuSM4= X-Received: by 2002:a9d:2b54:: with SMTP id f20-v6mr15426148otd.277.1523027882945; Fri, 06 Apr 2018 08:18:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.208.19 with HTTP; Fri, 6 Apr 2018 08:18:02 -0700 (PDT) From: Ali Mashtizadeh Date: Fri, 6 Apr 2018 11:18:02 -0400 Message-ID: Subject: Broken exect() libc call To: FreeBSD Hackers Cc: Ali Mashtizadeh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 15:18:04 -0000 Hello Everyone, I noticed exect() is an old BSD specific libc function that is supposed to enable tracing on the child process. In all modern platforms it has a faulty implementation dating back to the CSRG source code. FreeBSD lacks the code for several platforms and it appears that there are no users. Even gdb in the CSRG repository used the ptrace(PT_TRACE_ME, ...) function that is portable. Originally, on the VAX exect() sets the trap flag (PSL_T) which does not trigger a trap until the new executable image is loaded. This is because a trace fault is raised when the PSL_TP flag is set. exect() code would set PSL_T which during the execution of an instruction the processor copies the value of PSL_T to PSL_TP at the end of its cycle. The instruction that sets the trap flag does not set PSL_TP and the system call instruction copies PSL_T to PSL_TP. The the first instruction in the executable image will trigger a trace fault. See E.5.3 in [1] below and CSRG source [2]. Other platforms either called execve (when the processor does not allow user space to directly control tracing) or provided the same faulty implementation (present in the i386 version). If you search the CSRG repository this system call was only used by adb/sdb which at the time contained ptrace(PT_TRACE_ME,....) call as well. Older versions of Mac OS X contained the documentation for the call, but it has since been removed. NetBSD/OpenBSD contains a deprecated function that calls to execve written in C that warns you when you link against it. If there's no objects I've copied the NetBSD file, removed any MD assemblies still present, and amended the man page. Alternative solutions: 1) Provide C code to call ptrace(PT_TRACE_ME, ...) + execve. This more closely emulates exect(). 2) Remove the call entirely https://reviews.freebsd.org/D14989 [1] http://www.livingcomputers.org/Discover/Online-Systems/ User-Documentation/OpenVMS-7-3/5_VAX_Macro_Assembler_Reference.aspx [2] https://svnweb.freebsd.org/csrg/lib/libc/vax/sys/exect.s? revision=61222&view=markup [3] http://gnats.netbsd.org/51700 Best, Ali Mashtizadeh From owner-freebsd-hackers@freebsd.org Fri Apr 6 18:24:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3395FF9C2A8 for ; Fri, 6 Apr 2018 18:24:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A76D56D33E; Fri, 6 Apr 2018 18:23:59 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4W1lfRctHU5pn4W1mfTEhW; Fri, 06 Apr 2018 12:23:58 -0600 X-Authority-Analysis: v=2.3 cv=Tai4SyYh c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=XAfuqQ4JLLCGJg_28wQA:9 a=9Fa2kvWeBO14R3vi:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 0B2F01699; Fri, 6 Apr 2018 11:23:57 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w36INuvB044736; Fri, 6 Apr 2018 11:23:56 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w36INua7044731; Fri, 6 Apr 2018 11:23:56 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804061823.w36INua7044731@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric cc: Cy Schubert , freebsd-hackers@freebsd.org Subject: Re: mips.mips64elhf and mips.mips64el buildworld In-Reply-To: Message from Dimitry Andric of "Fri, 06 Apr 2018 13:05:40 +0200." <54034076-5964-4A06-94FA-1D56E284EE96@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Apr 2018 11:23:56 -0700 X-CMAE-Envelope: MS4wfMB8Xt/5BlCGWW0zWAnvyR3KsEeVsKD+4CCtJXY0L7Tta/j7czM0SASQ18WYMeP9d+Lm2a/kU62JYUJ1s7UX3sRYBB/+H0uYeFUEvb/VA9DxjVqqDdWP mTevTndX3XfLDAxUORGjDXD79JrgDqT6ITydnEgXhkW4xqmGRPfci8d7UYJqVTPVZ+B1NOxg2pLAuXuCgOV5ssbhKnURf8bah4qLiWUQqbP6b51Un6INhEHJ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:24:00 -0000 In message <54034076-5964-4A06-94FA-1D56E284EE96@FreeBSD.org>, Dimitry Andric w rites: > > > --Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On 6 Apr 2018, at 07:59, Cy Schubert wrote: > >=20 > > In message , Dimitry > > Andric writes: > ... > >>=20 > >> FWIW, a clean head checkout as of r332035 can build world just fine = > for > >> mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to > >> /dev/null. So it's likely due to your changes, I'll try those = > tomorrow. > >=20 > > Agreed. I might be onto it. Building to verify my hypothesis. > > Adding your changes leads to the following buildworld error, at first: > > --- includes_subdir_kerberos5/lib --- > install: target directory = > `/home/dim/obj/head/home/dim/src/head/mips.mips64elhf/tmp/usr/include/priv= > ate/asn1/' does not exist > usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] > [-M log] [-D dest] [-h hash] [-T tags] > [-B suffix] [-l linkflags] [-N dbdir] > file1 file2 > install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] > [-M log] [-D dest] [-h hash] [-T tags] > [-B suffix] [-l linkflags] [-N dbdir] > file1 ... fileN directory > install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner] > [-M log] [-D dest] [-h hash] [-T tags] > directory ... > --- includes_subdir_kerberos5/usr.bin --- > --- includes_subdir_kerberos5/usr.bin/kinit --- > =3D=3D=3D> kerberos5/usr.bin/kinit (includes) > --- includes_subdir_kerberos5/lib --- > *** [_INCSINS] Error code 64 > > so I added that directory to mtree, using: > > Index: etc/mtree/BSD.usr.dist > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- etc/mtree/BSD.usr.dist (revision 332040) > +++ etc/mtree/BSD.usr.dist (working copy) > @@ -9,6 +9,8 @@ > .. > include > private > + asn1 > + .. > bsdstat > .. > event > > > but then it leads to many errors like the following: > > --- common.pico --- > In file included from = > /home/dim/src/head/crypto/heimdal/lib/ipc/common.c:36: > /home/dim/src/head/crypto/heimdal/lib/ipc/hi_locl.h:57:25: error: = > asn1-common.h: No such file or directory > > and: > > --- client.o --- > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = > 'unix_socket_ipc': > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:391: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:392: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:405: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:406: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:408: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:413: error: = > dereferencing pointer to incomplete type > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = > 'heim_ipc_async': > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:562: error: storage = > size of 'rcv' isn't known > > E.g. for some reason the required headers aren't found anymore. > > I never get to the stage where linking fails, in any case. :) I committed the fix in r332124. I forgot to fully remove an early workaround I was using early during the conversion effort. Building tinderbox on universe12b completed successfully. I'll put together a patch from the krb5 branch for my exp-run PR and post a copy here. That should make it simpler for people to test. I'll try to have the patch posted tomorrow when I have more than a few minutes alone (we're babysitting a grandchild today, my day off from $JOB). -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Sat Apr 7 02:58:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63A8AF9E6F7 for ; Sat, 7 Apr 2018 02:58:19 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C52BD83EBA for ; Sat, 7 Apr 2018 02:58:18 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id g203-v6so2987725lfg.11 for ; Fri, 06 Apr 2018 19:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=C22rTm6S0PV7PTtJ1CVRh7XtFRTo/f/gVZ6q0dqKCHQ=; b=vavVav3i5oeYMMkmzXlUtS0IzsEpnt+tNu8xXWR4NPbTCBb8FDl5Ti2VhkXeY2cAV7 UrMgH2AnkHL+LcOLuHrkbQFObAW7j1Qydekk1oiHkQxbttvhwG6ag1O/zbdK67RFW1v4 Xd7hLPA20gSN8Ndrs7AFevBRIBJDnCiThNhECX0wYSuMIuiRz8+n+O0Q8hgqlwzldXFP zzaBFLrU/PsfpbyeB5+W1nMMyiiHDH2Dh8fwQ3gKygyH1bdAmXaushdvDkXb5QwnMl88 +mCIaKwdxczZwI9fFemvdGWOrXiAOaKao2QrWmJ5QwqXWs90maKMd/NG2qVf3XobgVsS Ry3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mime-version:content-disposition:user-agent; bh=C22rTm6S0PV7PTtJ1CVRh7XtFRTo/f/gVZ6q0dqKCHQ=; b=rhmZkeCdRtIMaHd/LM6TgOGwxyxp5kUVVN+Q1XWDZTLf7g7HktLhQVSRayd4xMXoT3 WG3QTcbaK+zVNYLDGHBqZY04YnM9WMqxxfvOxoaSa0uVFvIB07pGxK6pBrY/Hyk2DVY1 WwAQCoByoMcLDCh10WK9bvecSns+uo7cjbJf5nlMUJVToSz0FEaN6Dy8LuO4baextj5m Ut7rDkcNXEOERJaZusmHRGlULJ7pAjVewJf4fwOuzFOi2r+FndEoi4j6VvdvkCf3Yvik pvO9kFL5zHpuccnTClKlxPAkyCOIl7jN4vgh1iDE6bbgJxoBc1nMLMJlzcnk9iIpclG4 xh0Q== X-Gm-Message-State: ALQs6tDkaAbVLlciT8Op5jz6TM5fsjEyyUYd4L85jUIehQXfwohBw9J6 qZ/1km9n4gtOxTY1Ah3NbIOe6Q== X-Google-Smtp-Source: AIpwx4/cgcsqwhcYpE3Ljq8zwKkVxBh9H45vdnBbqEOP2xDYzwCBD2JKTXLWqFRbSXDWoUV+csU3gA== X-Received: by 10.46.120.24 with SMTP id t24mr5475985ljc.68.1523069896032; Fri, 06 Apr 2018 19:58:16 -0700 (PDT) Received: from kloomba ([217.65.211.123]) by smtp.gmail.com with ESMTPSA id y1sm1962953lji.59.2018.04.06.19.58.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 19:58:15 -0700 (PDT) Sender: Roman Bogorodskiy Date: Sat, 7 Apr 2018 06:58:09 +0400 From: Roman Bogorodskiy To: freebsd-hackers@freebsd.org Subject: Getting /dev entry by interface name Message-ID: <20180407025807.GA18883@kloomba> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 02:58:19 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have the following scenario: 1. Create tap(4) like that: # ifconfig tap create tap2 # 2. Rename it # ifconfig tap2 name testif testif Now I can do 'ifconfig testif' and there'll be no signs that it was named 'tap2' previously, however, in /dev it's still /dev/tap2. The question is: given that I didn't save the original name before renaming, what are the ways to map 'testif' to its /dev entry (/dev/tap2 in our example)? The only way I found so far is to iterate over /dev/tap*, calling TAPGIFNAME and checking if result matches the name I'm trying to look up. This approach doesn't look good for a number of reasons, main are: 1. It's inefficient, esp. if there are many tap(4) devices, 2. It has annoying side effects, such as if the interface was up, after opening it it will be down (unless net.link.tap.up_on_open is set to 1, which I don't want to rely on). Is there a cleaner way maybe? I wasn't able to get this information via data returned by getifaddrs(3) for example, but probably I'm missing something. Roman Bogorodskiy --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJayDO/AAoJEMltX/4IwiJqAa8IAKibUjov9RQtCjT77H2jYXI7 OcnLt+GDIBB/dIHTwL1defUBI/lkyXLoyVfaUKDGOMXXxvdZ0qG1fhAAMRtguUHM rl7P6nEF+EnZZmbnbrcWY0L7ViY2o+w5RbLtUy1YBi669I6PDNWXl1MJf9bMJBg4 ydO1QQDN6jSj8GAT3yVhRSW3pVqkibtPeUneA4X5RnGtCYNR0NfoqioMEorDRRyG CYATAl6t8ReqrIULsp5FQqDbwmjL/y5dbp5sPnP6C2/dMPjz65NAhqn6vSv5IQ5D WC0vtt1AToPJH5/8Cb546RoYdVyrWzTH3l27I4hG4etE0BCvZD22mx8xkvPMyrA= =nFLX -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-hackers@freebsd.org Sat Apr 7 08:09:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A96DDF9598E for ; Sat, 7 Apr 2018 08:09:00 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CD4873456 for ; Sat, 7 Apr 2018 08:08:59 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w3788kl9013393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 7 Apr 2018 10:08:47 +0200 To: freebsd-hackers@freebsd.org From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Subject: [diskless] pkg takes 100% of a CPU Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: Date: Sat, 7 Apr 2018 10:08:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 08:09:00 -0000 Hello, I have installed a diskless FreeBSD (11.1-RELEASE). This workstation runs a customized kernel to use Realtek re driver as I have seen some bugs in FreeBSD one's. Since I have upgraded 11.0 to 11.1, each night, pkg stalls and takes 100% of a CPU : PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 65609 root 1 103 0 51320K 12956K CPU1 1 425:16 98.43% pkg I can removed this command from crontab, but I'm pretty sure there is a bug somewhere between FreeBSD, pkg and nfs root. For information, my server runs NetBSD 8 (thus root nfs is mounted with v3/TCP). Best regards, JB From owner-freebsd-hackers@freebsd.org Sat Apr 7 08:17:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90646F962F4 for ; Sat, 7 Apr 2018 08:17:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1267E76096; Sat, 7 Apr 2018 08:17:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id D8076273D5; Sat, 7 Apr 2018 08:17:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w378HTMB037080 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Apr 2018 08:17:29 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w378HTbw037079; Sat, 7 Apr 2018 08:17:29 GMT (envelope-from phk) To: Roman Bogorodskiy cc: freebsd-hackers@freebsd.org Subject: Re: Getting /dev entry by interface name In-reply-to: <20180407025807.GA18883@kloomba> From: "Poul-Henning Kamp" References: <20180407025807.GA18883@kloomba> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37077.1523089049.1@critter.freebsd.dk> Date: Sat, 07 Apr 2018 08:17:29 +0000 Message-ID: <37078.1523089049@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 08:17:31 -0000 -------- In message <20180407025807.GA18883@kloomba>, Roman Bogorodskiy writes: >1. Create tap(4) like that: > ># ifconfig tap create >tap2 ># > >2. Rename it > ># ifconfig tap2 name testif >testif > >Now I can do 'ifconfig testif' and there'll be no signs that it was >named 'tap2' previously, however, in /dev it's still /dev/tap2. I would argue that is an error. The /dev entry should also be renamed, or maybe better, a symlink with the new name should be created, pointing to the /dev/tap%d entry. However, I dont know if that is actually possible, is the device driver even even told about the new interface name ? There is also a name-space validation issue to think about: ifconfig tap2 name ../etc -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@freebsd.org Sat Apr 7 08:39:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8483F980D0 for ; Sat, 7 Apr 2018 08:39:55 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 663BA8210D; Sat, 7 Apr 2018 08:39:55 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-oi0-x22e.google.com with SMTP id x9-v6so3218476oig.7; Sat, 07 Apr 2018 01:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iVcgPQjEc3M9sQ6ObabfhHyZZgO+dExthQAbu5D3Uik=; b=DiHD1IvejOnJir87GmuQ5yPNejYcNvgZZCXEWh8GY8dpZ7kWXFB20wPv8x1mJJQJsP VxfsdxVQtSLlHc8ZCLP9TMYxQaj7/dRYyymGi9LK2BgHU7js7UUTvjooxSaLO826Ov7S YD5Pc8wX+iVNrCYLEiBJCnGM+i3UFp8UnWbCA+i4HIH+cEgTkztyQgPY/XuVzXMI+cNZ rlGE/OjcIxxMrzWXttzX1ix0WWizlzsDreCdTOkM0Xhy74WOhb//bacm7FgRxQcN99V5 TtLooyYBIMWyZkTG45TW6WkVEOfhD3x9FdnH0yfh4l+6lvaFo8itWX7tZtLayr1Mvp3q OVoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iVcgPQjEc3M9sQ6ObabfhHyZZgO+dExthQAbu5D3Uik=; b=GfHGkXD8jVBwpc2vN/0GsUCnrJko4H4J0vPw0YI33GU6Nt4wsub6xXPlRl7iIC+HF4 roIqUT/IFROJBUelWuybclTTusW7st4IhsGQnoGQTVxieuD+rbbLoa0YYyxk29tA64oN 5fEZXTd/e+9RQ8lZBV5keVnWpsqRExBTNDixy39/+oIBRiwpiUR05iuJDZH/ATycNF79 n9+2obNVpUjEVphFFVJSeBYGdYe0YtE7DMBCZ6Yt8JGIMmWNIJAdnLrdcT7bgn62Skda ysaldl4DZRAJ3QlrNy+ynAVWOk57zYXz+PK266TfTF9RzklSTbo6LIrko9txhEKoe6oJ 9epw== X-Gm-Message-State: ALQs6tCTwnHljgMq+3qkI5NvtXDZlYiKtjL3/ykdBfGt+rgATSoU+IbK DW629SwM8ndjyr70jcIPTzn4BnEJBJxVeFV1h0M= X-Google-Smtp-Source: AIpwx4/Mn2gJTI5Fqgt3TIFYrQXA+QRuQPOW3rEUKXn5BeuAtPRpqffPYkzCipR9CfWHWbFFrSXIhEovMX+enfV3RK0= X-Received: by 2002:aca:a654:: with SMTP id p81-v6mr16087276oie.149.1523090394744; Sat, 07 Apr 2018 01:39:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.208 with HTTP; Sat, 7 Apr 2018 01:39:54 -0700 (PDT) In-Reply-To: <37078.1523089049@critter.freebsd.dk> References: <20180407025807.GA18883@kloomba> <37078.1523089049@critter.freebsd.dk> From: Stefan Blachmann Date: Sat, 7 Apr 2018 10:39:54 +0200 Message-ID: Subject: Re: Getting /dev entry by interface name To: Poul-Henning Kamp Cc: Roman Bogorodskiy , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 08:39:56 -0000 Does FreeBSD have anything comparable to the udev rules which are available on the systemd-ized Linuces? Afaiu such could achieve what the OP intended. On 4/7/18, Poul-Henning Kamp wrote: > -------- > In message <20180407025807.GA18883@kloomba>, Roman Bogorodskiy writes: > >>1. Create tap(4) like that: >> >># ifconfig tap create >>tap2 >># >> >>2. Rename it >> >># ifconfig tap2 name testif >>testif >> >>Now I can do 'ifconfig testif' and there'll be no signs that it was >>named 'tap2' previously, however, in /dev it's still /dev/tap2. > > I would argue that is an error. > > The /dev entry should also be renamed, or maybe better, a symlink > with the new name should be created, pointing to the /dev/tap%d > entry. > > However, I dont know if that is actually possible, is the device > driver even even told about the new interface name ? > > There is also a name-space validation issue to think about: > > ifconfig tap2 name ../etc > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat Apr 7 09:32:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3159F9BAAE for ; Sat, 7 Apr 2018 09:32:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEC17CA95; Sat, 7 Apr 2018 09:32:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0DD23273D1; Sat, 7 Apr 2018 09:32:45 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id w379WTi3037456 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Apr 2018 09:32:30 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id w379WTpN037455; Sat, 7 Apr 2018 09:32:29 GMT (envelope-from phk) To: Stefan Blachmann cc: Roman Bogorodskiy , freebsd-hackers@freebsd.org Subject: Re: Getting /dev entry by interface name In-reply-to: From: "Poul-Henning Kamp" References: <20180407025807.GA18883@kloomba> <37078.1523089049@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37453.1523093549.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 07 Apr 2018 09:32:29 +0000 Message-ID: <37454.1523093549@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 09:32:49 -0000 -------- In message , Stefan Blachmann writes: >Does FreeBSD have anything comparable to the udev rules which are Se devd(8) I use it, amongst other things, to add symlinks to USB-serial adapters based on serial numbers. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Sat Apr 7 09:44:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BD19F9C6CB for ; Sat, 7 Apr 2018 09:44:10 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC43782E4A for ; Sat, 7 Apr 2018 09:44:09 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x234.google.com with SMTP id g203-v6so3680945lfg.11 for ; Sat, 07 Apr 2018 02:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fW/yxOJiVcF4xou0xha5yAwdJ62NQAel8B5CaTZba3E=; b=jDZOn4SQX4rkgfDioCLuC8YIZqH6VLhSXS7s+CxIteA8H6mzB+sx1k0TsdZ/Dp41/6 PkPOSVJBbmljd6NZxze43zlPTE4RMFpV+5y2HeiFW24tCmb62cSnnPtvSJgeU8w0Q0cF aFEggS+aWxjiFlKMWqa9eyvOb7rxDw6qJQvZPypNccfIHL3X62CCnrbAtq3s6li4pDPT D3Jwu+fy5U9SJP8V1vixDAv98SskS5ZTG49baDrUuNvDCvwFiKOZM4+cJf23FGgkJ0fI ykXpVu7ON9wbaV+nPNjeS88AmE3A5WQRXTcfndweo3v8BlpvXhkMypNbfaGpSvYnFQJ6 zweg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fW/yxOJiVcF4xou0xha5yAwdJ62NQAel8B5CaTZba3E=; b=izZ1MMQE18gZkfOtFPgj7E4wCRmRf1U1h5A+CwUhr09jF2lafYdKewSZc6HHC7AOCF UffEZHd8NuL5wDv1CrLk3ypjyPpSHPSWgZdPuAnNA6POPbuECfwTPOm2ZE+NHLTU792/ AttNNW2ndWjYc8e6SIxyqgQgxpxeMh0zZ9ZdAttmSTe8p5hexnI6RnSNQ5i5u8xDudbk +Wsnh2h5CxPfr2dC/6b80jB1+0j6cgfL7kWWpD8ezhdvA2/PSBr4rcJYvcnIJZOsLhwD L0UAhQZnYsibFAndhKf72+Ak3t9TuKpQrd5agxvg77l2i2yNwy4FoXN5zhierHoKbZR6 F/TQ== X-Gm-Message-State: ALQs6tBwm+GKMYty0sWjFhBnHs0v20TfXIHQkeB33glseFnwRxnJ5b2c 3lDGuf1kA9Ch4oGsn258RXI90E46Kg4ceRWfNE3+KQyR X-Google-Smtp-Source: AIpwx4+Qbkc0P6hflNCIPsos0YeY8dgHpW0T1WsSy4FK7v5m0oqwKFuRTG1tHCcXXTc9fvhDP3z+bvIEZUtpYvnk7VI= X-Received: by 2002:a19:d78a:: with SMTP id q10-v6mr17948937lfi.94.1523094247976; Sat, 07 Apr 2018 02:44:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Hartland Date: Sat, 07 Apr 2018 09:43:57 +0000 Message-ID: Subject: Re: [diskless] pkg takes 100% of a CPU To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 09:44:10 -0000 When we=E2=80=99ve seen it using 100% it=E2=80=99s been doing comprehension= stuff which usually finishes you just have to wait. Not sure if that=E2=80=99s what you= =E2=80=99re seeing? On Sat, 7 Apr 2018 at 09:12, BERTRAND Jo=C3=ABl wrote: > Hello, > > I have installed a diskless FreeBSD (11.1-RELEASE). This > workstation > runs a customized kernel to use Realtek re driver as I have seen some > bugs in FreeBSD one's. > > Since I have upgraded 11.0 to 11.1, each night, pkg stalls and > takes > 100% of a CPU : > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 65609 root 1 103 0 51320K 12956K CPU1 1 425:16 98.43% pkg > > I can removed this command from crontab, but I'm pretty sure ther= e > is a > bug somewhere between FreeBSD, pkg and nfs root. For information, my > server runs NetBSD 8 (thus root nfs is mounted with v3/TCP). > > Best regards, > > JB > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sat Apr 7 09:50:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E8A1F9CCD4 for ; Sat, 7 Apr 2018 09:50:25 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B04286624 for ; Sat, 7 Apr 2018 09:50:24 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w379oCMr019241 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 7 Apr 2018 11:50:12 +0200 Subject: Re: [diskless] pkg takes 100% of a CPU To: freebsd-hackers@freebsd.org References: From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: Date: Sat, 7 Apr 2018 11:50:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 09:50:25 -0000 Steven Hartland a écrit : > When we’ve seen it using 100% it’s been doing comprehension stuff which > usually finishes you just have to wait. Not sure if that’s what you’re > seeing? Yesterday, I have killed pkg after more than 100 hours of CPU time... Best regards, JB From owner-freebsd-hackers@freebsd.org Sat Apr 7 10:06:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24AA9F9DF90 for ; Sat, 7 Apr 2018 10:06:06 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80A686EF5A for ; Sat, 7 Apr 2018 10:06:05 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22b.google.com with SMTP id g203-v6so3724020lfg.11 for ; Sat, 07 Apr 2018 03:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdkNRveStYm0IYxssoShckfwUtCLFwiwWTSKUh5lcog=; b=S+ev4FEIcNqsHU0SWPYWjkfFJcUm8tx0HGfgxXz70U8mOtRO+Kyj+KnYU8oZ769Bk6 pMOo4bmpLp/dkO2uXjfrnCqeXRv7kXRS6bukGdBozzIRNml+Vnjbmxn+d4pXb+WBT/aK Agqr+1w+iN2zEbyR99R+KmHmqu25jsTBmCXVDvVd1rLVSOEmMPZ2ZVvMs6BNjd1kR4mm to8gZr/dPpH6zv5WLp+V88gJ1Sq/uj8BtjROuFWTnT82bWz+F168X5JYeoYK6jlkbtEY dg+MAsY1LQG3MK5HMfYzEZNdBoRL4QaW7KXa2juGnChA3OJAXuCKol8gh0L1u0sw981W 79jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sdkNRveStYm0IYxssoShckfwUtCLFwiwWTSKUh5lcog=; b=aoNUXgEil4rxnVCa3ZsfbbI/urjLkC/21vzcoJWzfad8/kZE8GY2P+9djU4ueDTbz2 6bDZgZkKRAWOrBa7hIahFZo3ggXDajr+5zYyac5iSDvAoWzkxtIHJNQQOp2rpPUah+fj PfxbuhGpO3wGyH4AWbjDlNQZYAxE0a5QxM7nms5GN7EtEXxNk13EkHb2iUlcf6qtTVCP PPKPqElVoKh9swmasOa7dVD35YPtIZCwZhcNNODjaop4UKzVe5GvQYCOtzXzxVtzcu+8 kA/gyS5YRdeeuuyDOTGYFyKfqHUq6v9f4qIT5SXp0mrISp/e3vtvBPTL+5yb9LRh41ym ETdg== X-Gm-Message-State: ALQs6tBBnIvoEdcPMlAG6rJ/maqtzdMzTmF+FZ6mL/ni9LwhW1TKHluD MQtTXUxbU7ugZwMokn1auV4q/OdvyfFkB4P45XMzh3T1 X-Google-Smtp-Source: AIpwx4+SqP/RJrh/1Vr59iw6hWfuHdtKlqhuoTsweC6DpeVm7OOB0ZGxm+7wCQFDcH3s44p41Sx2BeTHJE7pj0889L0= X-Received: by 2002:a19:2b84:: with SMTP id r126-v6mr18157900lfr.24.1523095564124; Sat, 07 Apr 2018 03:06:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Hartland Date: Sat, 07 Apr 2018 10:05:53 +0000 Message-ID: Subject: Re: [diskless] pkg takes 100% of a CPU To: =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 10:06:06 -0000 What operation where you performing? If you kill with -SEGV you should get a core dump which can be investigated. Alternatively connect gdb to the process and get stack traces On Sat, 7 Apr 2018 at 10:54, BERTRAND Jo=C3=ABl wrote: > Steven Hartland a =C3=A9crit : > > When we=E2=80=99ve seen it using 100% it=E2=80=99s been doing comprehen= sion stuff which > > usually finishes you just have to wait. Not sure if that=E2=80=99s what= you=E2=80=99re > > seeing? > > Yesterday, I have killed pkg after more than 100 hours of CPU > time... > > Best regards, > > JB > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sat Apr 7 14:20:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CDF1F8BFAD for ; Sat, 7 Apr 2018 14:20:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 2D4167AEBC for ; Sat, 7 Apr 2018 14:20:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c010082c-3a6e-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id c010082c-3a6e-11e8-91c6-33ffc249f3e8; Sat, 07 Apr 2018 14:19:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w37EJpkJ093122; Sat, 7 Apr 2018 08:19:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1523110791.40504.15.camel@freebsd.org> Subject: Re: [diskless] pkg takes 100% of a CPU From: Ian Lepore To: BERTRAND =?ISO-8859-1?Q?Jo=EBl?= , freebsd-hackers@freebsd.org Date: Sat, 07 Apr 2018 08:19:51 -0600 In-Reply-To: References: Content-Type: text/plain; charset="iso-2022-jp" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 14:20:03 -0000 On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > Steven Hartland a crit: > > > > When we$B!G(Bve seen it using 100% it$B!G(Bs been doing comprehension stuff which > > usually finishes you just have to wait. Not sure if that$B!G(Bs what you$B!G(Bre > > seeing? > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > Best regards, > > JB For me, pkg(8) quit working on systems that have /var/db mounted from nfs long ago, maybe as much as a year ago at this point. I mentioned it on irc, and was told "It's probably something to do with locking", but I already have boot.nfsroot.options="nolockd" in loader.conf (because that's pretty much the only option because the rc(8) system was broken years ago when it comes to nfsroot). -- Ian From owner-freebsd-hackers@freebsd.org Sat Apr 7 14:35:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED4B1F8CFC6 for ; Sat, 7 Apr 2018 14:35:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 4480583AF8; Sat, 7 Apr 2018 14:35:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w37EZeAa008616; Sat, 7 Apr 2018 07:35:40 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w37EZeqw008615; Sat, 7 Apr 2018 07:35:40 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804071435.w37EZeqw008615@pdx.rh.CN85.dnsmgr.net> Subject: Re: [diskless] pkg takes 100% of a CPU In-Reply-To: <1523110791.40504.15.camel@freebsd.org> To: Ian Lepore Date: Sat, 7 Apr 2018 07:35:40 -0700 (PDT) CC: =?ISO-8859-1?Q?BERTRAND_Jo=EBl?= , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 14:35:46 -0000 > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > Steven Hartland a crit: > > > > > > When we?ve seen it using 100% it?s been doing comprehension stuff which > > > usually finishes you just have to wait. Not sure if that?s what you?re > > > seeing? > > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > > > Best regards, > > > > JB > > For me, pkg(8) quit working on systems that have /var/db mounted from > nfs long ago, maybe as much as a year ago at this point. I mentioned > it on irc, and was told "It's probably something to do with locking", > but I already have boot.nfsroot.options="nolockd" in loader.conf > (because that's pretty much the only option because the rc(8) system > was broken years ago when it comes to nfsroot). My understanding of the current broken state of afairs is that pkg does not work over nfs unless you have proper and full lockd support, AND set NFS_WITH_PROPER_LOCKING in pkg's environment. This really really really just needs to work without a lot of fuss out of the box. The /etc/rc.initdiskless is presenty (11.x and later) in a usable state, though it has some issues if your /usr is seperate from /, and you have to override the default size of /var due to bloat, though I think the sizes of all the tmpfs's got bumped in ^head/. I had a very nice working iPXE based boot menu system that you could boot all of {10|11|12-snaps}{i386|amd54}, but it is for some strange reason having a problem with the NFS load of the kernel going at an abismal pace, like 10 to 15 minutes to load the kernel. Stuff before and after that is normal speed. I believe this to be my fault, I changed something some place, and it broke, and I did not notice for a good long time. Now I do not know what it was that I changed that broken it :-(. The only real special thing in the above setup was a pxeboot that I got from a very specific point in time that has a nfsroot fix in it, without that you can not easily override the nfsroot ip:path from iPXE menu. /boot/pxeboot before and after this specific version is/was broke (since my test system is borked I can not test ^/heads latest pxeboot). Regards, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Apr 7 14:45:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33FFFF8DD2B for ; Sat, 7 Apr 2018 14:45:23 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 A285769837; Sat, 7 Apr 2018 14:45:22 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w37EjKob008765; Sat, 7 Apr 2018 07:45:20 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w37EjKp2008764; Sat, 7 Apr 2018 07:45:20 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804071445.w37EjKp2008764@pdx.rh.CN85.dnsmgr.net> Subject: Re: [diskless] pkg takes 100% of a CPU In-Reply-To: <1523110791.40504.15.camel@freebsd.org> To: Ian Lepore Date: Sat, 7 Apr 2018 07:45:20 -0700 (PDT) CC: =?ISO-8859-1?Q?BERTRAND_Jo=EBl?= , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 14:45:23 -0000 [ Charset ISO-2022-JP unsupported, converting... ] > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > Steven Hartland a crit: > > > > > > When we?ve seen it using 100% it?s been doing comprehension stuff which > > > usually finishes you just have to wait. Not sure if that?s what you?re > > > seeing? > > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > > > Best regards, > > > > JB > > For me, pkg(8) quit working on systems that have /var/db mounted from > nfs long ago, maybe as much as a year ago at this point. I mentioned > it on irc, and was told "It's probably something to do with locking", > but I already have boot.nfsroot.options="nolockd" in loader.conf > (because that's pretty much the only option because the rc(8) system > was broken years ago when it comes to nfsroot). Further information in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213611 -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Apr 7 16:52:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68EBBF96D47 for ; Sat, 7 Apr 2018 16:52:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 EBB4770BE2 for ; Sat, 7 Apr 2018 16:52:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 208a6246-3a84-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 208a6246-3a84-11e8-91c6-33ffc249f3e8; Sat, 07 Apr 2018 16:53:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w37GqqYl093505; Sat, 7 Apr 2018 10:52:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1523119972.89422.1.camel@freebsd.org> Subject: Re: [diskless] pkg takes 100% of a CPU From: Ian Lepore To: "Rodney W. Grimes" Cc: freebsd-hackers@freebsd.org Date: Sat, 07 Apr 2018 10:52:52 -0600 In-Reply-To: <201804071435.w37EZeqw008615@pdx.rh.CN85.dnsmgr.net> References: <201804071435.w37EZeqw008615@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 16:52:59 -0000 On Sat, 2018-04-07 at 07:35 -0700, Rodney W. Grimes wrote: > > > > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > > > > > Steven Hartland a crit: > > > > > > > > > > > > When we?ve seen it using 100% it?s been doing comprehension stuff which > > > > usually finishes you just have to wait. Not sure if that?s what you?re > > > > seeing? > > > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > > > > > Best regards, > > > > > > JB > > For me, pkg(8) quit working on systems that have /var/db mounted from > > nfs long ago, maybe as much as a year ago at this point. I mentioned > > it on irc, and was told "It's probably something to do with locking", > > but I already have boot.nfsroot.options="nolockd" in loader.conf > > (because that's pretty much the only option because the rc(8) system > > was broken years ago when it comes to nfsroot). > My understanding of the current broken state of afairs is that pkg > does not work over nfs unless you have proper and full lockd support, > AND set NFS_WITH_PROPER_LOCKING in pkg's environment.This really > really really just needs to work without a lot of fuss out of the > box. > nfs locking support is compiled into the kernel on both the server and client side, and rpc.lockd is running on both, but there is no need for actual locking on the mount because the rootfs isn't accessed by multiple clients at once -- each of my arm boards has its own private rootfs exported from the server. I'm pretty sure I tried remounting root I agree that pkg(8) needs to just work. > The /etc/rc.initdiskless is presenty (11.x and later) in a usable > state, though it has some issues if your /usr is seperate from /, > and you have to override the default size of /var due to bloat, > though I think the sizes of all the tmpfs's got bumped in ^head/. > I don't want an mfs-based /var. I want /var, which is just a dir in the rootfs, to work the way it's supposed to even if rootfs is nfs-mounted. Changes to the rc(8) subsystem done long ago, related to managing pidfiles, cause the bulk of the problems. The problem would be fixable if we had an mfs-based /run filesystem mounted very early to hold such things, then later during rc processing a symlink could be made so that /var/run would point to /run. I'm afraid all of that is easy to say, but probably has a zillion little nits and "that won't work in my crazy setup" objections from people, so I've never pursued it seriously. -- Ian From owner-freebsd-hackers@freebsd.org Sat Apr 7 17:08:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D4A4F97F22 for ; Sat, 7 Apr 2018 17:08:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 F41D579239; Sat, 7 Apr 2018 17:08:32 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w37H8TbR009360; Sat, 7 Apr 2018 10:08:29 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w37H8Ts8009359; Sat, 7 Apr 2018 10:08:29 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804071708.w37H8Ts8009359@pdx.rh.CN85.dnsmgr.net> Subject: Re: [diskless] pkg takes 100% of a CPU In-Reply-To: <1523119972.89422.1.camel@freebsd.org> To: Ian Lepore Date: Sat, 7 Apr 2018 10:08:29 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 17:08:34 -0000 > On Sat, 2018-04-07 at 07:35 -0700, Rodney W. Grimes wrote: > > > > > > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > > > > > > > Steven Hartland a crit: > > > > > > > > > > > > > > > When we?ve seen it using 100% it?s been doing comprehension stuff which > > > > > usually finishes you just have to wait. Not sure if that?s what you?re > > > > > seeing? > > > > Yesterday, I have killed pkg after more than 100 hours of CPU time... > > > > > > > > Best regards, > > > > > > > > JB > > > For me, pkg(8) quit working on systems that have /var/db mounted from > > > nfs long ago, maybe as much as a year ago at this point. I mentioned > > > it on irc, and was told "It's probably something to do with locking", > > > but I already have boot.nfsroot.options="nolockd" in loader.conf > > > (because that's pretty much the only option because the rc(8) system > > > was broken years ago when it comes to nfsroot). > > My understanding of the current broken state of afairs is that pkg > > does not work over nfs unless you have proper and full lockd support, > > AND set NFS_WITH_PROPER_LOCKING in pkg's environment.??This really > > really really just needs to work without a lot of fuss out of the > > box. > > > > nfs locking support is compiled into the kernel on both the server and > client side, and rpc.lockd is running on both, but there is no need for > actual locking on the mount because the rootfs isn't accessed by > multiple clients at once -- each of my arm boards has its own private > rootfs exported from the server. I'm pretty sure I tried remounting > root pkg wants to do locking, multiple copies of pkg may be running on one client, you might get pkg to work for you if you do the echo "NFS_WITH_PROPER_LOCKING = true;" >> /usr/local/etc/pkg.conf I mentioned in my follow up. > > I agree that pkg(8) needs to just work. :-) > > The /etc/rc.initdiskless is presenty (11.x and later) in a usable > > state, though it has some issues if your /usr is seperate from /, > > and you have to override the default size of /var due to bloat, > > though I think the sizes of all the tmpfs's got bumped in ^head/. > > > > I don't want an mfs-based /var. I want /var, which is just a dir in the > rootfs, to work the way it's supposed to even if rootfs is nfs-mounted. > Changes to the rc(8) subsystem done long ago, related to managing > pidfiles, cause the bulk of the problems. The problem would be fixable > if we had an mfs-based /run filesystem mounted very early to hold such > things, then later during rc processing a symlink could be made so that > /var/run would point to /run. I'm afraid all of that is easy to say, > but probably has a zillion little nits and "that won't work in my crazy > setup" objections from people, so I've never pursued it seriously. I agree we should support a non mfs based /var. I'll take a crack at seeing how hard it is to turn that off. What about making /var/run mfs based when rc.initdiskless runs? I think you can actually get that done under the current scheme once I get /var turned off from doing the mfs/var.cpio.gz extract. Need to see if it processes conf/var/run/*, I do not think so. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Apr 7 19:47:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89B88FA268B for ; Sat, 7 Apr 2018 19:47:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E15216A766; Sat, 7 Apr 2018 19:47:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 4toPfrx96Lkoz4toQfPBCf; Sat, 07 Apr 2018 13:47:47 -0600 X-Authority-Analysis: v=2.3 cv=OeS28CbY c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=Kd1tUaAdevIA:10 a=XldT38RWNwACPDQzwzUA:9 a=VxmjJ2MpAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=gXoP5rPZ3cKXclSns1UA:9 a=9Fa2kvWeBO14R3vi:21 a=CjuIK1q_8ugA:10 a=WAITogFhzp5CLcs6mpMA:9 a=hquHOILUSkIA:10 a=ics_IjAVWSmO8OVX31YA:9 a=BOg4e644cxQA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 1A503514; Sat, 7 Apr 2018 12:47:45 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w37JliHt004073; Sat, 7 Apr 2018 12:47:44 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w37Jli8Z004070; Sat, 7 Apr 2018 12:47:44 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804071947.w37Jli8Z004070@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dimitry Andric , freebsd-hackers@freebsd.org Subject: Re: mips.mips64elhf and mips.mips64el buildworld In-Reply-To: Message from Cy Schubert of "Fri, 06 Apr 2018 11:23:56 -0700." <201804061823.w36INua7044731@slippy.cwsent.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1523130233_38710" Date: Sat, 07 Apr 2018 12:47:44 -0700 X-CMAE-Envelope: MS4wfHKpK3MAixCU97sFIo5dqWGAv2nZdaG/9o3CiuwxM9gqt5goQNKSspccd1aE6LiFlNFVV2vgLYHpByzxjQ2bSjvAxrRSddvHgzM7agEklxVd3umtanLr FJgC9LR1VgDhMYIZwlRknl3jJa+QSv0GrE1CLQd/xpSibCLuJVcx57HGSHRV/6XCiB97Q8zpnHmH83d71FpKJghd1o4SupA9zRY07bhOQOIykZc5ERstTp/m X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 19:47:51 -0000 This is a multipart MIME message. --==_Exmh_1523130233_38710 Content-Type: text/plain; charset=us-ascii In message <201804061823.w36INua7044731@slippy.cwsent.com>, Cy Schubert writes: > In message <54034076-5964-4A06-94FA-1D56E284EE96@FreeBSD.org>, Dimitry > Andric w > rites: > > > > > > --Apple-Mail=_6F848AAA-AFAC-4D7C-A7F0-E25476750616 > > Content-Transfer-Encoding: quoted-printable > > Content-Type: text/plain; > > charset=us-ascii > > > > On 6 Apr 2018, at 07:59, Cy Schubert wrote: > > >=20 > > > In message , Dimitry > > > Andric writes: > > ... > > >>=20 > > >> FWIW, a clean head checkout as of r332035 can build world just fine = > > for > > >> mips.mips64elhf, that is with __MAKE_CONF and SRCCONF both set to > > >> /dev/null. So it's likely due to your changes, I'll try those = > > tomorrow. > > >=20 > > > Agreed. I might be onto it. Building to verify my hypothesis. > > > > Adding your changes leads to the following buildworld error, at first: > > > > --- includes_subdir_kerberos5/lib --- > > install: target directory = > > `/home/dim/obj/head/home/dim/src/head/mips.mips64elhf/tmp/usr/include/priv= > > ate/asn1/' does not exist > > usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] > > [-M log] [-D dest] [-h hash] [-T tags] > > [-B suffix] [-l linkflags] [-N dbdir] > > file1 file2 > > install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner] > > [-M log] [-D dest] [-h hash] [-T tags] > > [-B suffix] [-l linkflags] [-N dbdir] > > file1 ... fileN directory > > install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner] > > [-M log] [-D dest] [-h hash] [-T tags] > > directory ... > > --- includes_subdir_kerberos5/usr.bin --- > > --- includes_subdir_kerberos5/usr.bin/kinit --- > > =3D=3D=3D> kerberos5/usr.bin/kinit (includes) > > --- includes_subdir_kerberos5/lib --- > > *** [_INCSINS] Error code 64 > > > > so I added that directory to mtree, using: > > > > Index: etc/mtree/BSD.usr.dist > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- etc/mtree/BSD.usr.dist (revision 332040) > > +++ etc/mtree/BSD.usr.dist (working copy) > > @@ -9,6 +9,8 @@ > > .. > > include > > private > > + asn1 > > + .. > > bsdstat > > .. > > event > > > > > > but then it leads to many errors like the following: > > > > --- common.pico --- > > In file included from = > > /home/dim/src/head/crypto/heimdal/lib/ipc/common.c:36: > > /home/dim/src/head/crypto/heimdal/lib/ipc/hi_locl.h:57:25: error: = > > asn1-common.h: No such file or directory > > > > and: > > > > --- client.o --- > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = > > 'unix_socket_ipc': > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:384: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:391: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:392: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:396: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:405: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:406: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:407: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:408: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:410: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:413: error: = > > dereferencing pointer to incomplete type > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c: In function = > > 'heim_ipc_async': > > /home/dim/src/head/crypto/heimdal/lib/ipc/client.c:562: error: storage = > > size of 'rcv' isn't known > > > > E.g. for some reason the required headers aren't found anymore. > > > > I never get to the stage where linking fails, in any case. :) > > I committed the fix in r332124. I forgot to fully remove an early > workaround I was using early during the conversion effort. Building > tinderbox on universe12b completed successfully. > > I'll put together a patch from the krb5 branch for my exp-run PR and > post a copy here. That should make it simpler for people to test. I'll > try to have the patch posted tomorrow when I have more than a few > minutes alone (we're babysitting a grandchild today, my day off from > $JOB). The attached patch applies cleanly to and builds on r332165, verified on universe12b. The exp-run I requested is PR 222745. --==_Exmh_1523130233_38710 Content-Type: text/plain ; name="heim-pvt.diff"; charset=us-ascii Content-Description: heim-pvt.diff Content-Disposition: attachment; filename="heim-pvt.diff" diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc index 7bf1da796a7..c72ce804f1c 100644 --- a/ObsoleteFiles.inc +++ b/ObsoleteFiles.inc @@ -555,6 +555,122 @@ OLD_DIRS+=usr/share/openssl/man/cat1 OLD_DIRS+=usr/share/openssl/man/cat3 OLD_DIRS+=usr/share/openssl/man/en.ISO8859-1/cat1 OLD_DIRS+=usr/share/openssl/man/en.ISO8859-1/cat3 +# 20170831: hemdal becomes private +OLD_FILES+=usr/include/asn1-common.h +OLD_FILES+=usr/include/asn1_err.h +OLD_FILES+=usr/include/base64.h +OLD_FILES+=usr/include/cms_asn1.h +OLD_FILES+=usr/include/crmf_asn1.h +OLD_FILES+=usr/include/der-private.h +OLD_FILES+=usr/include/der-protos.h +OLD_FILES+=usr/include/der.h +OLD_FILES+=usr/include/digest_asn1.h +OLD_FILES+=usr/include/getarg.h +OLD_FILES+=usr/include/hdb-protos.h +OLD_FILES+=usr/include/hdb.h +OLD_FILES+=usr/include/hdb_asn1.h +OLD_FILES+=usr/include/hdb_err.h +OLD_FILES+=usr/include/heim_asn1.h +OLD_FILES+=usr/include/heim_err.h +OLD_FILES+=usr/include/heim_threads.h +OLD_FILES+=usr/include/heimbase.h +OLD_FILES+=usr/include/heimntlm-protos.h +OLD_FILES+=usr/include/heimntlm.h +OLD_FILES+=usr/include/hex.h +OLD_FILES+=usr/include/hx509-private.h +OLD_FILES+=usr/include/hx509-protos.h +OLD_FILES+=usr/include/hx509.h +OLD_FILES+=usr/include/hx509_err.h +OLD_FILES+=usr/include/k524_err.h +OLD_FILES+=usr/include/kafs.h +OLD_FILES+=usr/include/kdc-protos.h +OLD_FILES+=usr/include/kdc.h +OLD_FILES+=usr/include/krb5-private.h +OLD_FILES+=usr/include/krb5-protos.h +OLD_FILES+=usr/include/krb5-types.h +OLD_FILES+=usr/include/krb5.h +OLD_FILES+=usr/include/krb5_asn1.h +OLD_FILES+=usr/include/krb5_ccapi.h +OLD_FILES+=usr/include/krb5_err.h +OLD_FILES+=usr/include/kx509_asn1.h +OLD_FILES+=usr/include/ntlm_err.h +OLD_FILES+=usr/include/ocsp_asn1.h +OLD_FILES+=usr/include/parse_bytes.h +OLD_FILES+=usr/include/parse_time.h +OLD_FILES+=usr/include/parse_units.h +OLD_FILES+=usr/include/pkcs10_asn1.h +OLD_FILES+=usr/include/pkcs12_asn1.h +OLD_FILES+=usr/include/pkcs8_asn1.h +OLD_FILES+=usr/include/pkcs9_asn1.h +OLD_FILES+=usr/include/pkinit_asn1.h +OLD_FILES+=usr/include/resolve.h +OLD_FILES+=usr/include/rfc2459_asn1.h +OLD_FILES+=usr/include/roken-common.h +OLD_FILES+=usr/include/roken.h +OLD_FILES+=usr/include/rtbl.h +OLD_FILES+=usr/include/wind.h +OLD_FILES+=usr/include/wind_err.h +OLD_FILES+=usr/include/xdbm.h +OLD_LIBS+=usr/lib/libasn1.a +OLD_LIBS+=usr/lib/libasn1.so +OLD_LIBS+=usr/lib/libasn1.so.11 +OLD_LIBS+=usr/lib/libasn1_p.a +OLD_LIBS+=usr/lib/libgssapi_krb5.a +OLD_LIBS+=usr/lib/libgssapi_krb5.so +OLD_LIBS+=usr/lib/libgssapi_krb5.so.10 +OLD_LIBS+=usr/lib/libgssapi_krb5_p.a +OLD_LIBS+=usr/lib/libgssapi_ntlm.a +OLD_LIBS+=usr/lib/libgssapi_ntlm.so +OLD_LIBS+=usr/lib/libgssapi_ntlm.so.10 +OLD_LIBS+=usr/lib/libgssapi_ntlm_p.a +OLD_LIBS+=usr/lib/libgssapi_spnego.a +OLD_LIBS+=usr/lib/libgssapi_spnego.so +OLD_LIBS+=usr/lib/libgssapi_spnego.so.10 +OLD_LIBS+=usr/lib/libgssapi_spnego_p.a +OLD_LIBS+=usr/lib/libhdb.a +OLD_LIBS+=usr/lib/libhdb.so +OLD_LIBS+=usr/lib/libhdb.so.11 +OLD_LIBS+=usr/lib/libhdb_p.a +OLD_LIBS+=usr/lib/libheimbase.a +OLD_LIBS+=usr/lib/libheimbase.so +OLD_LIBS+=usr/lib/libheimbase.so.11 +OLD_LIBS+=usr/lib/libheimbase_p.a +OLD_LIBS+=usr/lib/libheimntlm.a +OLD_LIBS+=usr/lib/libheimntlm.so +OLD_LIBS+=usr/lib/libheimntlm.so.11 +OLD_LIBS+=usr/lib/libheimntlm_p.a +OLD_LIBS+=usr/lib/libhx509.a +OLD_LIBS+=usr/lib/libhx509.so +OLD_LIBS+=usr/lib/libhx509.so.11 +OLD_LIBS+=usr/lib/libhx509_p.a +OLD_LIBS+=usr/lib/libkadm5clnt.a +OLD_LIBS+=usr/lib/libkadm5clnt.so +OLD_LIBS+=usr/lib/libkadm5clnt.so.11 +OLD_LIBS+=usr/lib/libkadm5clnt_p.a +OLD_LIBS+=usr/lib/libkadm5srv.a +OLD_LIBS+=usr/lib/libkadm5srv.so +OLD_LIBS+=usr/lib/libkadm5srv.so.11 +OLD_LIBS+=usr/lib/libkadm5srv_p.a +OLD_LIBS+=usr/lib/libkafs5.a +OLD_LIBS+=usr/lib/libkafs5.so +OLD_LIBS+=usr/lib/libkafs5.so.11 +OLD_LIBS+=usr/lib/libkafs5_p.a +OLD_LIBS+=usr/lib/libkdc.a +OLD_LIBS+=usr/lib/libkdc.so +OLD_LIBS+=usr/lib/libkdc.so.11 +OLD_LIBS+=usr/lib/libkdc_p.a +OLD_LIBS+=usr/lib/libkrb5.a +OLD_LIBS+=usr/lib/libkrb5.so +OLD_LIBS+=usr/lib/libkrb5.so.11 +OLD_LIBS+=usr/lib/libkrb5_p.a +OLD_LIBS+=usr/lib/libroken.a +OLD_LIBS+=usr/lib/libroken.so +OLD_LIBS+=usr/lib/libroken.so.11 +OLD_LIBS+=usr/lib/libroken_p.a +OLD_LIBS+=usr/lib/libwind.a +OLD_LIBS+=usr/lib/libwind.so +OLD_LIBS+=usr/lib/libwind.so.11 +OLD_LIBS+=usr/lib/libwind_p.a # 20170802: ksyms(4) ioctl interface was removed OLD_FILES+=usr/include/sys/ksyms.h # 20170722: new clang import which bumps version from 4.0.0 to 5.0.0. diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist index 3e76838a5ad..954318879c9 100644 --- a/etc/mtree/BSD.usr.dist +++ b/etc/mtree/BSD.usr.dist @@ -9,14 +9,34 @@ .. include private + asn1 + .. bsdstat .. event .. + hdb + .. + heimbase + .. + heimntlm + .. + hx509 + .. + kafs5 + .. + kdc + .. + krb5 + .. + roken + .. sqlite3 .. ucl .. + wind + .. zstd .. .. diff --git a/kerberos5/Makefile.inc b/kerberos5/Makefile.inc index eeb8d3a20bb..d00bd919427 100644 --- a/kerberos5/Makefile.inc +++ b/kerberos5/Makefile.inc @@ -6,7 +6,7 @@ NO_LINT= KRB5DIR= ${SRCTOP}/crypto/heimdal -CFLAGS+= -DHAVE_CONFIG_H -I${.CURDIR:H:H}/include +CFLAGS+= -DHAVE_CONFIG_H -I${.CURDIR:H:H}/include -I${KRB5DIR}/include .if ${MK_OPENLDAP} != "no" && !defined(COMPAT_32BIT) OPENLDAPBASE?= /usr/local diff --git a/kerberos5/lib/libasn1/Makefile b/kerberos5/lib/libasn1/Makefile index d9594392cb7..696adbd347e 100644 --- a/kerberos5/lib/libasn1/Makefile +++ b/kerberos5/lib/libasn1/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= asn1 +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined INCS= asn1_err.h asn1-common.h heim_asn1.h der.h der-protos.h der-private.h LIBADD= com_err roken @@ -21,7 +22,8 @@ SRCS= asn1_err.c \ timegm.c \ ${GEN:S/.x$/.c/:S/.hx$/.h/} -CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H}/libroken -I. GEN_RFC2459= asn1_rfc2459_asn1.x rfc2459_asn1.hx rfc2459_asn1-priv.hx GEN_CMS= asn1_cms_asn1.x cms_asn1.hx cms_asn1-priv.hx diff --git a/kerberos5/lib/libgssapi_krb5/Makefile b/kerberos5/lib/libgssapi_krb5/Makefile index 905b824d0a5..d2763e8bc55 100644 --- a/kerberos5/lib/libgssapi_krb5/Makefile +++ b/kerberos5/lib/libgssapi_krb5/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= gssapi_krb5 +PRIVATELIB= true LDFLAGS= -Wl,-Bsymbolic -Wl,--no-undefined LIBADD= gssapi krb5 crypto roken asn1 com_err SHLIB_MAJOR= 10 @@ -77,8 +78,16 @@ CFLAGS+=-I${KRB5DIR}/lib/gssapi CFLAGS+=-I${KRB5DIR}/lib/gssapi/krb5 CFLAGS+=-I${KRB5DIR}/lib/gssapi/gssapi CFLAGS+=-I${KRB5DIR}/lib/krb5 +CFLAGS+=-I${.OBJDIR:H}/libkrb5 CFLAGS+=-I${KRB5DIR}/lib/asn1 -CFLAGS+=-I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${.OBJDIR:H}/libasn1 +CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${.OBJDIR:H}/libroken +CFLAGS+=-I${KRB5DIR}/lib/wind +CFLAGS+=-I${.OBJDIR:H}/libwind +CFLAGS+=-I${KRB5DIR}/lib/hx509 +CFLAGS+=-I${.OBJDIR:H}/libhx509 +CFLAGS+=-I${KRB5DIR}/base -I. .include diff --git a/kerberos5/lib/libgssapi_ntlm/Makefile b/kerberos5/lib/libgssapi_ntlm/Makefile index b5edb08a8d4..957d62c0ae0 100644 --- a/kerberos5/lib/libgssapi_ntlm/Makefile +++ b/kerberos5/lib/libgssapi_ntlm/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= gssapi_ntlm +PRIVATELIB= true LDFLAGS= -Wl,-Bsymbolic -Wl,--no-undefined LIBADD= crypto gssapi krb5 heimntlm roken SHLIB_MAJOR= 10 @@ -41,7 +42,14 @@ CFLAGS+=-I${KRB5DIR}/lib/gssapi CFLAGS+=-I${KRB5DIR}/lib/gssapi/gssapi CFLAGS+=-I${KRB5DIR}/lib/gssapi/ntlm CFLAGS+=-I${KRB5DIR}/lib/krb5 +CFLAGS+=-I${.OBJDIR:H}/libkrb5 CFLAGS+=-I${KRB5DIR}/lib/ntlm +CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${.OBJDIR:H}/libroken +CFLAGS+=-I${KRB5DIR}/lib/asn1 +CFLAGS+=-I${.OBJDIR:H}/libasn1 +CFLAGS+=-I${KRB5DIR}/lib/ntlm +CFLAGS+=-I${.OBJDIR:H}/libheimntlm .include diff --git a/kerberos5/lib/libgssapi_spnego/Makefile b/kerberos5/lib/libgssapi_spnego/Makefile index 1ccf1377e8b..3982c843496 100644 --- a/kerberos5/lib/libgssapi_spnego/Makefile +++ b/kerberos5/lib/libgssapi_spnego/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= gssapi_spnego +PRIVATELIB= true LDFLAGS= -Wl,-Bsymbolic -Wl,--no-undefined LIBADD= gssapi heimbase asn1 roken SHLIB_MAJOR= 10 @@ -31,8 +32,11 @@ CFLAGS+=-I${KRB5DIR}/lib/gssapi CFLAGS+=-I${KRB5DIR}/lib/gssapi/gssapi CFLAGS+=-I${KRB5DIR}/lib/gssapi/spnego CFLAGS+=-I${KRB5DIR}/lib/asn1 +CFLAGS+=-I${.OBJDIR:H}/libasn1 CFLAGS+=-I${SRCTOP}/lib/libgssapi -CFLAGS+=-I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${.OBJDIR:H}/libroken +CFLAGS+=-I${KRB5DIR}/base -I. CLEANFILES= ${GEN} ${GEN:S/.x$/.c/:S/.hx$/.h/} \ spnego_asn1_files spnego_asn1-template.c diff --git a/kerberos5/lib/libhdb/Makefile b/kerberos5/lib/libhdb/Makefile index df67359404c..268b5c10fce 100644 --- a/kerberos5/lib/libhdb/Makefile +++ b/kerberos5/lib/libhdb/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= hdb +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined ${LDAPLDFLAGS} VERSION_MAP= ${KRB5DIR}/lib/hdb/version-script.map LIBADD= asn1 com_err krb5 roken sqlite3 @@ -56,9 +57,13 @@ SRCS= common.c \ print.c \ ${GEN:S/.x$/.c/:S/.hx$/.h/} -CFLAGS+=-I${KRB5DIR}/lib/hdb -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/lib/roken -I${SRCTOP}/contrib/sqlite3/ \ - -I${KRB5DIR}/lib/krb5 \ +CFLAGS+=-I${KRB5DIR}/lib/hdb -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ + -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${SRCTOP}/contrib/sqlite3/ \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H}/libkrb5 \ + -I${KRB5DIR}/lib/wind -I${.OBJDIR:H}/libwind \ + -I${KRB5DIR}/lib/hx509 -I${.OBJDIR:H}/libhx509 \ + -I${KRB5DIR}/base \ -I. ${LDAPCFLAGS} CFLAGS+=-DHDB_DB_DIR="\"/var/heimdal\"" diff --git a/kerberos5/lib/libheimbase/Makefile b/kerberos5/lib/libheimbase/Makefile index b6bf526b352..6feb1088031 100644 --- a/kerberos5/lib/libheimbase/Makefile +++ b/kerberos5/lib/libheimbase/Makefile @@ -1,6 +1,7 @@ #$FreeBSD$ LIB= heimbase +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined LIBADD= pthread VERSION_MAP= ${KRB5DIR}/base/version-script.map diff --git a/kerberos5/lib/libheimipcc/Makefile b/kerberos5/lib/libheimipcc/Makefile index 9ec71257237..badf85b6578 100644 --- a/kerberos5/lib/libheimipcc/Makefile +++ b/kerberos5/lib/libheimipcc/Makefile @@ -9,6 +9,8 @@ SRCS= \ common.c CFLAGS+= -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/base \ -I${KRB5DIR}/lib/ipc \ -I${KRB5DIR}/include diff --git a/kerberos5/lib/libheimipcs/Makefile b/kerberos5/lib/libheimipcs/Makefile index b1201f65a84..9aa5b538bd5 100644 --- a/kerberos5/lib/libheimipcs/Makefile +++ b/kerberos5/lib/libheimipcs/Makefile @@ -8,7 +8,8 @@ SRCS= \ server.c \ common.c -CFLAGS+= -I${KRB5DIR}/lib/roken \ +CFLAGS+= -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ -I${KRB5DIR}/base \ -I${KRB5DIR}/lib/ipc -I. diff --git a/kerberos5/lib/libheimntlm/Makefile b/kerberos5/lib/libheimntlm/Makefile index bcb45f3b8f0..90c6e0681a9 100644 --- a/kerberos5/lib/libheimntlm/Makefile +++ b/kerberos5/lib/libheimntlm/Makefile @@ -1,11 +1,15 @@ # $FreeBSD$ LIB= heimntlm +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined LIBADD= crypto com_err krb5 roken SRCS= ntlm.c ntlm_err.c ntlm_err.h INCS= heimntlm.h heimntlm-protos.h ntlm_err.h -CFLAGS+=-I${KRB5DIR}/lib/ntlm -I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/ntlm -I${.OBJDIR:H}/libheimntlm \ + -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H}/libkrb5 \ + -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 VERSION_MAP= ${KRB5DIR}/lib/ntlm/version-script.map MAN= ntlm_buf.3 \ diff --git a/kerberos5/lib/libhx509/Makefile b/kerberos5/lib/libhx509/Makefile index 553eac13f0e..23b3208a94d 100644 --- a/kerberos5/lib/libhx509/Makefile +++ b/kerberos5/lib/libhx509/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= hx509 +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined VERSION_MAP= ${KRB5DIR}/lib/hx509/version-script.map LIBADD= asn1 com_err crypto roken wind @@ -209,9 +210,9 @@ SRCS+= ${GEN_OCSP:S/.x$/.c/:S/.hx$/.h/} \ CFLAGS+=-I${KRB5DIR}/lib/hx509 CFLAGS+=-I${KRB5DIR}/lib/hx509/ref -CFLAGS+=-I${KRB5DIR}/lib/asn1 -CFLAGS+=-I${KRB5DIR}/lib/wind -CFLAGS+=-I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 +CFLAGS+=-I${KRB5DIR}/lib/wind -I${.OBJDIR:H}/libwind +CFLAGS+=-I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken -I. GEN_OCSP= \ asn1_OCSPBasicOCSPResponse.x \ diff --git a/kerberos5/lib/libkadm5clnt/Makefile b/kerberos5/lib/libkadm5clnt/Makefile index 1f3401e636d..281fc65ae5b 100644 --- a/kerberos5/lib/libkadm5clnt/Makefile +++ b/kerberos5/lib/libkadm5clnt/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= kadm5clnt +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined LIBADD= com_err krb5 roken @@ -34,7 +35,10 @@ SRCS= ad.c \ rename_c.c \ send_recv.c -CFLAGS+=-I${KRB5DIR}/lib/kadm5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/kadm5 -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ + -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H}/libkrb5 \ + -I${KRB5DIR}/lib/hdb -I${.OBJDIR:H}/libhdb -I. .include diff --git a/kerberos5/lib/libkadm5srv/Makefile b/kerberos5/lib/libkadm5srv/Makefile index adf49a5b1af..1e80e509d14 100644 --- a/kerberos5/lib/libkadm5srv/Makefile +++ b/kerberos5/lib/libkadm5srv/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= kadm5srv +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined LIBADD= com_err hdb krb5 roken VERSION_MAP= ${KRB5DIR}/lib/kadm5/version-script.map @@ -35,7 +36,10 @@ SRCS= acl.c \ set_keys.c \ set_modifier.c -CFLAGS+=-I${KRB5DIR}/lib/kadm5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/kadm5 -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ + -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H}/libkrb5 \ + -I${KRB5DIR}/lib/hdb -I${.OBJDIR:H}/libhdb -I. .include diff --git a/kerberos5/lib/libkafs5/Makefile b/kerberos5/lib/libkafs5/Makefile index 24400b8b2ed..eab4c4de8ef 100644 --- a/kerberos5/lib/libkafs5/Makefile +++ b/kerberos5/lib/libkafs5/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= kafs5 +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined LIBADD= asn1 krb5 roken INCS= kafs.h @@ -27,7 +28,10 @@ SRCS= afssys.c afskrb5.c common.c CFLAGS+= -I${KRB5DIR}/lib/kafs \ -I${KRB5DIR}/lib/krb5 \ -I${.OBJDIR:H}/libkrb5 \ - -I${KRB5DIR}/lib/roken + -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/asn1 \ + -I${.OBJDIR:H}/libasn1 CLEANFILES= kafs5.3 diff --git a/kerberos5/lib/libkdc/Makefile b/kerberos5/lib/libkdc/Makefile index 14b0797e273..423b20d0dc8 100644 --- a/kerberos5/lib/libkdc/Makefile +++ b/kerberos5/lib/libkdc/Makefile @@ -1,6 +1,7 @@ #$FreeBSD$ LIB= kdc +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined VERSION_MAP= ${KRB5DIR}/kdc/version-script.map LIBADD= roken hdb hx509 krb5 heimntlm asn1 crypto @@ -25,10 +26,15 @@ SRCS= \ process.c \ windc.c -CFLAGS+= -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/krb5 \ - -I${KRB5DIR}/lib/hdb \ - -I${KRB5DIR}/kdc +CFLAGS+= -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H}/libkrb5 \ + -I${KRB5DIR}/lib/wind -I${.OBJDIR:H}/libwind \ + -I${KRB5DIR}/lib/hx509 -I${.OBJDIR:H}/libhx509 \ + -I${KRB5DIR}/lib/hdb -I${.OBJDIR:H}/libhdb \ + -I${KRB5DIR}/lib/ntlm -I${.OBJDIR:H}/libheimntlm \ + -I${KRB5DIR}/kdc \ + -I${KRB5DIR}/base .include diff --git a/kerberos5/lib/libkrb5/Makefile b/kerberos5/lib/libkrb5/Makefile index 0eac57c803f..034b59e7bb3 100644 --- a/kerberos5/lib/libkrb5/Makefile +++ b/kerberos5/lib/libkrb5/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= krb5 +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined VERSION_MAP= ${KRB5DIR}/lib/krb5/version-script.map LIBADD= asn1 com_err crypt crypto hx509 roken wind heimbase heimipcc @@ -618,8 +619,10 @@ SRCS+= heim_err.c \ krb_err.h CFLAGS+= -I${KRB5DIR}/lib/krb5 \ - -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H}/libasn1 \ + -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken \ + -I${KRB5DIR}/lib/wind -I${.OBJDIR:H}/libwind \ + -I${KRB5DIR}/lib/hx509 -I${.OBJDIR:H}/libhx509 \ -I${KRB5DIR}/lib/ipc \ -I${KRB5DIR}/base -I. diff --git a/kerberos5/lib/libroken/Makefile b/kerberos5/lib/libroken/Makefile index 95505d2a1ff..448d78cf8a5 100644 --- a/kerberos5/lib/libroken/Makefile +++ b/kerberos5/lib/libroken/Makefile @@ -1,6 +1,7 @@ # $FreeBSD$ LIB= roken +PRIVATELIB= true LIBADD= crypt VERSION_MAP= ${KRB5DIR}/lib/roken/version-script.map INCS= roken.h \ diff --git a/kerberos5/lib/libsl/Makefile b/kerberos5/lib/libsl/Makefile index 71a38a5729d..18afc97b3c7 100644 --- a/kerberos5/lib/libsl/Makefile +++ b/kerberos5/lib/libsl/Makefile @@ -3,7 +3,7 @@ LIB= sl INTERNALLIB= SRCS= sl.c -CFLAGS+=-I${KRB5DIR}/lib/sl +CFLAGS+=-I${KRB5DIR}/lib/sl -I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken .include diff --git a/kerberos5/lib/libwind/Makefile b/kerberos5/lib/libwind/Makefile index a489566efbb..1f90e3c3e33 100644 --- a/kerberos5/lib/libwind/Makefile +++ b/kerberos5/lib/libwind/Makefile @@ -1,6 +1,7 @@ #$FreeBSD$ LIB= wind +PRIVATELIB= true LDFLAGS= -Wl,--no-undefined VERSION_MAP= ${KRB5DIR}/lib/wind/version-script.map LIBADD= com_err roken @@ -27,7 +28,7 @@ SRCS= bidi.c \ SRCS+= wind_err.c \ wind_err.h -CFLAGS+=-I${KRB5DIR}/lib/roken -I. +CFLAGS+=-I${KRB5DIR}/lib/roken -I${.OBJDIR:H}/libroken -I. .include diff --git a/kerberos5/libexec/digest-service/Makefile b/kerberos5/libexec/digest-service/Makefile index 840f2c4d2fe..764006cf71a 100644 --- a/kerberos5/libexec/digest-service/Makefile +++ b/kerberos5/libexec/digest-service/Makefile @@ -2,12 +2,23 @@ PROG= digest-service MAN= -CFLAGS+= -I${KRB5DIR}/kdc \ +CFLAGS+= -I${KRB5DIR}/base \ + -I${KRB5DIR}/kdc \ -I${KRB5DIR}/lib/asn1 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ -I${KRB5DIR}/lib/ipc \ -I${KRB5DIR}/lib/wind \ - -I${KRB5DIR}/lib/roken + -I${.OBJDIR:H:H}/lib/libwind \ + -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${KRB5DIR}/lib/hx509 \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${KRB5DIR}/lib/ntlm \ + -I${.OBJDIR:H:H}/lib/libheimntlm LIBADD= hdb kdc heimipcs krb5 roken asn1 crypto vers heimntlm LDFLAGS=${LDAPLDFLAGS} diff --git a/kerberos5/libexec/hprop/Makefile b/kerberos5/libexec/hprop/Makefile index b267571315f..680daf569e0 100644 --- a/kerberos5/libexec/hprop/Makefile +++ b/kerberos5/libexec/hprop/Makefile @@ -8,8 +8,18 @@ CFLAGS+=-I${KRB5DIR}/lib/krb5 CFLAGS+=-I${KRB5DIR}/lib/asn1 CFLAGS+=-I${KRB5DIR}/lib/hx509 CFLAGS+=-I${KRB5DIR}/lib/ntlm +CFLAGS+=-I${KRB5DIR}/lib/wind +CFLAGS+=-I${KRB5DIR}/lib/hdb +CFLAGS+=-I${KRB5DIR}/base CFLAGS+=-I${KRB5DIR}/kdc CFLAGS+=-I${.OBJDIR:H:H}/lib/libkrb5 +CFLAGS+=-I${.OBJDIR:H:H}/lib/libroken +CFLAGS+=-I${.OBJDIR:H:H}/lib/libasn1 +CFLAGS+=-I${.OBJDIR:H:H}/lib/libhx509 +CFLAGS+=-I${.OBJDIR:H:H}/lib/libheimntlm +CFLAGS+=-I${.OBJDIR:H:H}/lib/libwind +CFLAGS+=-I${.OBJDIR:H:H}/lib/libhdb +CFLAGS+=-I${.OBJDIR:H:H}/lib/libheimbase LIBADD= hdb krb5 roken vers DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/libexec/hpropd/Makefile b/kerberos5/libexec/hpropd/Makefile index 9f7f9e71283..b85c0fae60b 100644 --- a/kerberos5/libexec/hpropd/Makefile +++ b/kerberos5/libexec/hpropd/Makefile @@ -3,7 +3,20 @@ PROG= hpropd MAN= hpropd.8 CFLAGS+=-I${KRB5DIR}/lib/roken -I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/kdc ${LDAPCFLAGS} + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${KRB5DIR}/lib/ntlm \ + -I${KRB5DIR}/kdc \ + -I${KRB5DIR}/base \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + ${LDAPCFLAGS} LIBADD= hdb krb5 roken vers DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/libexec/ipropd-master/Makefile b/kerberos5/libexec/ipropd-master/Makefile index 9f0bddbae4f..10ce1cdfe74 100644 --- a/kerberos5/libexec/ipropd-master/Makefile +++ b/kerberos5/libexec/ipropd-master/Makefile @@ -4,7 +4,13 @@ PROG= ipropd-master MAN= iprop.8 SRCS= ipropd_common.c ipropd_master.c kadm5_err.h CFLAGS+=-I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libhdb \ -I. ${LDAPCFLAGS} + LIBADD= kadm5srv hdb krb5 roken vers DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/libexec/ipropd-slave/Makefile b/kerberos5/libexec/ipropd-slave/Makefile index cae84aa5ffb..3913499b3ab 100644 --- a/kerberos5/libexec/ipropd-slave/Makefile +++ b/kerberos5/libexec/ipropd-slave/Makefile @@ -4,6 +4,11 @@ PROG= ipropd-slave MAN= SRCS= ipropd_common.c ipropd_slave.c kadm5_err.h CFLAGS+=-I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libroken \ -I. ${LDAPCFLAGS} LIBADD= kadm5srv hdb krb5 roken vers DPADD= ${LDAPDPADD} diff --git a/kerberos5/libexec/kadmind/Makefile b/kerberos5/libexec/kadmind/Makefile index 27200d6d98c..4af001b57d0 100644 --- a/kerberos5/libexec/kadmind/Makefile +++ b/kerberos5/libexec/kadmind/Makefile @@ -8,6 +8,16 @@ SRCS= rpc.c \ kadm_conn.c CFLAGS+=-I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/base \ + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ ${LDAPCFLAGS} LIBADD= kadm5srv gssapi hdb krb5 roken vers DPADD= ${LDAPDPADD} diff --git a/kerberos5/libexec/kcm/Makefile b/kerberos5/libexec/kcm/Makefile index fa7a0cfce9c..b20d558e82c 100644 --- a/kerberos5/libexec/kcm/Makefile +++ b/kerberos5/libexec/kcm/Makefile @@ -18,7 +18,13 @@ SRCS= acl.c \ renew.c CFLAGS+=-I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/kcm -I${KRB5DIR}/lib/ipc ${LDAPCFLAGS} + -I${KRB5DIR}/kcm -I${KRB5DIR}/lib/ipc \ + -I${KRB5DIR}/lib/ntlm \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + ${LDAPCFLAGS} LIBADD= krb5 roken heimntlm heimipcs crypto DPADD= ${LDAPDPADD} LDADD= ${LIBVERS} ${LDAPLDADD} diff --git a/kerberos5/libexec/kdc/Makefile b/kerberos5/libexec/kdc/Makefile index aa4584e4ac7..9b22469705d 100644 --- a/kerberos5/libexec/kdc/Makefile +++ b/kerberos5/libexec/kdc/Makefile @@ -9,7 +9,20 @@ SRCS= config.c \ main.c CFLAGS+=-I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/kdc ${LDAPCFLAGS} + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${KRB5DIR}/lib/ntlm \ + -I${KRB5DIR}/kdc \ + -I${KRB5DIR}/base \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + ${LDAPCFLAGS} LIBADD= kdc hdb krb5 roken crypt vers LDFLAGS=${LDAPLDFLAGS} diff --git a/kerberos5/libexec/kdigest/Makefile b/kerberos5/libexec/kdigest/Makefile index 5f3fb245064..6fbaa74a13c 100644 --- a/kerberos5/libexec/kdigest/Makefile +++ b/kerberos5/libexec/kdigest/Makefile @@ -4,7 +4,15 @@ PROG= kdigest MAN= kdigest.8 CFLAGS+= -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/sl -I. + -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${KRB5DIR}/lib/ntlm \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + -I. LIBADD= krb5 heimntlm roken crypto edit sl vers SRCS= kdigest.c \ kdigest-commands.c \ diff --git a/kerberos5/libexec/kfd/Makefile b/kerberos5/libexec/kfd/Makefile index 82df3adbb6d..395091f183b 100644 --- a/kerberos5/libexec/kfd/Makefile +++ b/kerberos5/libexec/kfd/Makefile @@ -3,7 +3,11 @@ PROG= kfd MAN= kfd.8 CFLAGS+= -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/lib/roken + -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libkrb5 LIBADD= krb5 roken vers .include diff --git a/kerberos5/libexec/kimpersonate/Makefile b/kerberos5/libexec/kimpersonate/Makefile index 3c94db6857d..5daefb7ae7d 100644 --- a/kerberos5/libexec/kimpersonate/Makefile +++ b/kerberos5/libexec/kimpersonate/Makefile @@ -5,7 +5,13 @@ MAN= kimpersonate.8 CFLAGS+= -I${KRB5DIR}/lib/hx509 \ -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/sl -I. + -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I. LIBADD= krb5 roken asn1 vers .include diff --git a/kerberos5/libexec/kpasswdd/Makefile b/kerberos5/libexec/kpasswdd/Makefile index ec36c24fc03..db1e7ae24de 100644 --- a/kerberos5/libexec/kpasswdd/Makefile +++ b/kerberos5/libexec/kpasswdd/Makefile @@ -2,7 +2,15 @@ PROG= kpasswdd MAN= kpasswdd.8 -CFLAGS+=-I${KRB5DIR}/lib/roken -I${KRB5DIR}/lib/libhdb ${LDAPCFLAGS} +CFLAGS+=-I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/asn1 \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + ${LDAPCFLAGS} LIBADD= kadm5srv hdb krb5 roken vers asn1 DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/tools/asn1_compile/Makefile b/kerberos5/tools/asn1_compile/Makefile index 68715facfcb..20482e207b5 100644 --- a/kerberos5/tools/asn1_compile/Makefile +++ b/kerberos5/tools/asn1_compile/Makefile @@ -2,7 +2,7 @@ PROG= asn1_compile MAN= -LIBROKEN_A= ${.OBJDIR:H:H}/lib/libroken/libroken.a +LIBROKEN_A= ${.OBJDIR:H:H}/lib/libroken/libprivateroken.a LIBADD= vers LDADD= ${LIBROKEN_A} DPADD= ${LIBROKEN_A} diff --git a/kerberos5/tools/slc/Makefile b/kerberos5/tools/slc/Makefile index 34092a56644..b6bd2a2b4ca 100644 --- a/kerberos5/tools/slc/Makefile +++ b/kerberos5/tools/slc/Makefile @@ -1,7 +1,7 @@ # $FreeBSD$ PROG= slc -LIBROKEN_A= ${.OBJDIR:H:H}/lib/libroken/libroken.a +LIBROKEN_A= ${.OBJDIR:H:H}/lib/libroken/libprivateroken.a LIBADD= vers LDADD= ${LIBROKEN_A} DPADD= ${LIBROKEN_A} diff --git a/kerberos5/usr.bin/hxtool/Makefile b/kerberos5/usr.bin/hxtool/Makefile index af85a446928..ae70e20add4 100644 --- a/kerberos5/usr.bin/hxtool/Makefile +++ b/kerberos5/usr.bin/hxtool/Makefile @@ -5,6 +5,9 @@ MAN= CFLAGS+= -I${KRB5DIR}/lib/hx509 \ -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libroken \ -I${KRB5DIR}/lib/sl -I. LIBADD= hx509 roken asn1 crypto sl vers edit SRCS= hxtool.c hxtool-commands.c hxtool-commands.h diff --git a/kerberos5/usr.bin/kadmin/Makefile b/kerberos5/usr.bin/kadmin/Makefile index e7aff44c223..e36c449a2b8 100644 --- a/kerberos5/usr.bin/kadmin/Makefile +++ b/kerberos5/usr.bin/kadmin/Makefile @@ -25,7 +25,19 @@ SRCS= add_enctype.c \ util.c CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/sl -I. ${LDAPCFLAGS} + -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/base \ + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I. \ + ${LDAPCFLAGS} LIBADD= kadm5clnt kadm5srv hdb krb5 roken vers sl asn1 crypto edit DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/usr.bin/kcc/Makefile b/kerberos5/usr.bin/kcc/Makefile index 7c4b7ab3962..9f2db1698b1 100644 --- a/kerberos5/usr.bin/kcc/Makefile +++ b/kerberos5/usr.bin/kcc/Makefile @@ -7,7 +7,13 @@ LINKS= ${BINDIR}/kcc ${BINDIR}/klist \ CFLAGS+= -I${KRB5DIR}/lib/hx509 \ -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/sl -I. + -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I. LIBADD= krb5 roken asn1 kafs5 edit sl vers SRCS= kcc.c \ kcc-commands.c \ diff --git a/kerberos5/usr.bin/kdestroy/Makefile b/kerberos5/usr.bin/kdestroy/Makefile index 23e90237c65..19f5d5785a5 100644 --- a/kerberos5/usr.bin/kdestroy/Makefile +++ b/kerberos5/usr.bin/kdestroy/Makefile @@ -1,7 +1,12 @@ # $FreeBSD$ PROG= kdestroy -CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 LIBADD= kafs5 krb5 roken vers MAN= kdestroy.1 diff --git a/kerberos5/usr.bin/kf/Makefile b/kerberos5/usr.bin/kf/Makefile index 44d91830baa..f682f9a0644 100644 --- a/kerberos5/usr.bin/kf/Makefile +++ b/kerberos5/usr.bin/kf/Makefile @@ -3,7 +3,11 @@ PROG= kf MAN= kf.1 CFLAGS+= -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/lib/roken + -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 LIBADD= krb5 roken vers .include diff --git a/kerberos5/usr.bin/kgetcred/Makefile b/kerberos5/usr.bin/kgetcred/Makefile index 1451154f9cf..fec3f9c48d6 100644 --- a/kerberos5/usr.bin/kgetcred/Makefile +++ b/kerberos5/usr.bin/kgetcred/Makefile @@ -2,7 +2,12 @@ PROG= kgetcred CFLAGS+= -I${KRB5DIR}/lib/asn1 \ - -I${KRB5DIR}/lib/roken + -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 LIBADD= krb5 roken asn1 vers .include diff --git a/kerberos5/usr.bin/kinit/Makefile b/kerberos5/usr.bin/kinit/Makefile index 7622b8da956..db26b4f6888 100644 --- a/kerberos5/usr.bin/kinit/Makefile +++ b/kerberos5/usr.bin/kinit/Makefile @@ -1,7 +1,14 @@ # $FreeBSD$ PROG= kinit -CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${KRB5DIR}/lib/ntlm \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + -I${.OBJDIR:H:H}/lib/libasn1 LIBADD= kafs5 krb5 heimntlm roken crypto vers .include diff --git a/kerberos5/usr.bin/kpasswd/Makefile b/kerberos5/usr.bin/kpasswd/Makefile index 05e07dddc03..ee3fca98658 100644 --- a/kerberos5/usr.bin/kpasswd/Makefile +++ b/kerberos5/usr.bin/kpasswd/Makefile @@ -1,7 +1,11 @@ # $FreeBSD$ PROG= kpasswd -CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 LIBADD= hdb krb5 roken vers crypto LDFLAGS=${LDAPLDFLAGS} diff --git a/kerberos5/usr.bin/ksu/Makefile b/kerberos5/usr.bin/ksu/Makefile index ebd39c677b5..e5bee61ca6d 100644 --- a/kerberos5/usr.bin/ksu/Makefile +++ b/kerberos5/usr.bin/ksu/Makefile @@ -7,7 +7,12 @@ PRECIOUSPROG= .endif MAN= SRCS= su.c -CFLAGS+=-I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/lib/krb5 \ + -I${KRB5DIR}/lib/kafs \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 LIBADD= kafs5 krb5 roken vers crypto crypt .include diff --git a/kerberos5/usr.bin/string2key/Makefile b/kerberos5/usr.bin/string2key/Makefile index eb7b2043fac..c35fcdd08e5 100644 --- a/kerberos5/usr.bin/string2key/Makefile +++ b/kerberos5/usr.bin/string2key/Makefile @@ -6,7 +6,18 @@ CFLAGS+= -I${KRB5DIR}/kdc \ -I${KRB5DIR}/lib/asn1 \ -I${KRB5DIR}/lib/krb5 \ -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/lib/windc + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${KRB5DIR}/lib/ntlm \ + -I${KRB5DIR}/base \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libheimntlm LIBADD= krb5 roken crypto vers .include diff --git a/kerberos5/usr.bin/verify_krb5_conf/Makefile b/kerberos5/usr.bin/verify_krb5_conf/Makefile index ced75436e52..dafbce881ae 100644 --- a/kerberos5/usr.bin/verify_krb5_conf/Makefile +++ b/kerberos5/usr.bin/verify_krb5_conf/Makefile @@ -2,7 +2,15 @@ PROG= verify_krb5_conf MAN= verify_krb5_conf.8 -CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/roken +CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/roken \ + -I${KRB5DIR}/base \ + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libhx509 LIBADD= krb5 roken vers .include diff --git a/kerberos5/usr.sbin/iprop-log/Makefile b/kerberos5/usr.sbin/iprop-log/Makefile index 1f71f9b2a40..1253967036d 100644 --- a/kerberos5/usr.sbin/iprop-log/Makefile +++ b/kerberos5/usr.sbin/iprop-log/Makefile @@ -7,6 +7,12 @@ CFLAGS+= -I${KRB5DIR}/lib/kadm5 \ -I${KRB5DIR}/lib/krb5 \ -I${KRB5DIR}/lib/roken \ -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/lib/hdb \ + -I${KRB5DIR}/lib/asn1 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libasn1 \ -I. LIBADD= kadm5srv hdb krb5 roken edit sl vers LDFLAGS=${LDAPLDFLAGS} diff --git a/kerberos5/usr.sbin/kstash/Makefile b/kerberos5/usr.sbin/kstash/Makefile index d96c96c7512..65769ce1c30 100644 --- a/kerberos5/usr.sbin/kstash/Makefile +++ b/kerberos5/usr.sbin/kstash/Makefile @@ -3,7 +3,20 @@ PROG= kstash MAN= kstash.8 CFLAGS+=-I${KRB5DIR}/lib/asn1 -I${KRB5DIR}/lib/krb5 -I${KRB5DIR}/lib/roken \ - -I${KRB5DIR}/kdc ${LDAPCFLAGS} + -I${KRB5DIR}/kdc \ + -I${KRB5DIR}/base \ + -I${KRB5DIR}/lib/wind \ + -I${KRB5DIR}/lib/hx509 \ + -I${KRB5DIR}/lib/hdb \ + -I${KRB5DIR}/lib/ntlm \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libwind \ + -I${.OBJDIR:H:H}/lib/libhx509 \ + -I${.OBJDIR:H:H}/lib/libhdb \ + -I${.OBJDIR:H:H}/lib/libheimntlm \ + ${LDAPCFLAGS} LIBADD= hdb krb5 crypto vers DPADD= ${LDAPDPADD} LDADD= ${LDAPLDADD} diff --git a/kerberos5/usr.sbin/ktutil/Makefile b/kerberos5/usr.sbin/ktutil/Makefile index c79d09e6d94..a9f63ae5f94 100644 --- a/kerberos5/usr.sbin/ktutil/Makefile +++ b/kerberos5/usr.sbin/ktutil/Makefile @@ -16,7 +16,12 @@ SRCS= add.c \ remove.c \ rename.c -CFLAGS+=-I${KRB5DIR}/lib/roken -I${KRB5DIR}/lib/sl -I. +CFLAGS+=-I${KRB5DIR}/lib/roken -I${KRB5DIR}/lib/sl \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H}/lib/libroken \ + -I${.OBJDIR:H:H}/lib/libkrb5 \ + -I${.OBJDIR:H:H}/lib/libasn1 \ + -I. LIBADD= kadm5clnt krb5 roken crypto edit sl vers CLEANFILES= ktutil-commands.h ktutil-commands.c diff --git a/lib/libpam/modules/pam_krb5/Makefile b/lib/libpam/modules/pam_krb5/Makefile index 97fd4909229..b89e70cb80d 100644 --- a/lib/libpam/modules/pam_krb5/Makefile +++ b/lib/libpam/modules/pam_krb5/Makefile @@ -34,4 +34,15 @@ WARNS?= 3 LIBADD+= krb5 +# XXX Must be the same as in kerberos5/Makefile.inc +# XXX There will be a better way to reduce duplication but +# XXX for now this will do. +KRB5DIR= ${SRCTOP}/crypto/heimdal + +CFLAGS+= -I${SRCTOP}/kerberos5/include \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H:H:H}/kerberos5/lib/libkrb5 \ + -I${KRB5DIR}/lib/asn1 \ + -I${.OBJDIR:H:H:H:H}/kerberos5/lib/libasn1 + .include diff --git a/lib/libpam/modules/pam_ksu/Makefile b/lib/libpam/modules/pam_ksu/Makefile index 26f3f850daa..ad97914cf1c 100644 --- a/lib/libpam/modules/pam_ksu/Makefile +++ b/lib/libpam/modules/pam_ksu/Makefile @@ -30,4 +30,15 @@ MAN= pam_ksu.8 LIBADD+= krb5 +# XXX Must be the same as in kerberos5/Makefile.inc +# XXX There will be a better way to reduce duplication but +# XXX for now this will do. +KRB5DIR= ${SRCTOP}/crypto/heimdal + +CFLAGS+= -I${SRCTOP}/kerberos5/include \ + -I${KRB5DIR}/lib/krb5 \ + -I${.OBJDIR:H:H:H:H}/kerberos5/lib/libkrb5 \ + -I${KRB5DIR}/lib/asn1 \ + -I${.OBJDIR:H:H:H:H}/kerberos5/lib/libasn1 + .include diff --git a/lib/libtelnet/Makefile b/lib/libtelnet/Makefile index 27bd2d5a22e..9c047317998 100644 --- a/lib/libtelnet/Makefile +++ b/lib/libtelnet/Makefile @@ -3,6 +3,11 @@ .include +# XXX Must be the same as in kerberos5/Makefile.inc +# XXX There will be a better way to reduce duplication but +# XXX for now this will do. +KRB5DIR= ${SRCTOP}/crypto/heimdal + PACKAGE=lib${LIB} TELNETDIR= ${SRCTOP}/contrib/telnet .PATH: ${TELNETDIR}/libtelnet @@ -24,6 +29,9 @@ CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DSRA .if ${MK_KERBEROS_SUPPORT} != "no" SRCS+= kerberos5.c CFLAGS+= -DKRB5 -DFORWARD -Dnet_write=telnet_net_write +CFLAGS+= -I${SRCTOP}/kerberos5/include \ + -I${KRB5DIR}/lib/krb5 -I${.OBJDIR:H:H}/kerberos5/lib/libkrb5 \ + -I${KRB5DIR}/lib/asn1 -I${.OBJDIR:H:H}/kerberos5/lib/libasn1 .endif .include diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile index 5d6e4779c11..e18b0bac6f5 100644 --- a/secure/usr.bin/ssh/Makefile +++ b/secure/usr.bin/ssh/Makefile @@ -24,7 +24,11 @@ CFLAGS+= -DHAVE_LDNS=1 .endif .if ${MK_GSSAPI} != "no" && ${MK_KERBEROS_SUPPORT} != "no" -CFLAGS+= -include krb5_config.h +KRB5DIR= ${SRCTOP}/crypto/heimdal +KERBEROS5_DIR= ${SRCTOP}/kerberos5 +CFLAGS+= -include krb5_config.h \ + -I${KERBEROS5_DIR}/include \ + -I${KRB5DIR}/lib/krb5 SRCS+= krb5_config.h LIBADD+= gssapi .endif diff --git a/secure/usr.sbin/sshd/Makefile b/secure/usr.sbin/sshd/Makefile index 93832a9c758..faf5eab8153 100644 --- a/secure/usr.sbin/sshd/Makefile +++ b/secure/usr.sbin/sshd/Makefile @@ -48,7 +48,13 @@ LDFLAGS+=-L${LIBBLACKLISTDIR} .endif .if ${MK_GSSAPI} != "no" && ${MK_KERBEROS_SUPPORT} != "no" -CFLAGS+= -include krb5_config.h +KRB5DIR= ${SRCTOP}/crypto/heimdal +CFLAGS+= -include krb5_config.h \ + -I${KRB5DIR}/lib/krb5 \ + -I${SRCTOP}/kerberos5/include \ + -I${.OBJDIR:H:H:H}/kerberos5/lib/libkrb5 \ + -I${.OBJDIR:H:H:H}/kerberos5/lib/libroken \ + -I${.OBJDIR:H:H:H}/kerberos5/lib/libasn1 SRCS+= krb5_config.h LIBADD+= gssapi_krb5 gssapi krb5 .endif diff --git a/share/mk/src.libnames.mk b/share/mk/src.libnames.mk index c6ee3b5fef3..b467d055e1f 100644 --- a/share/mk/src.libnames.mk +++ b/share/mk/src.libnames.mk @@ -13,19 +13,34 @@ ____: .include _PRIVATELIBS= \ + asn1 \ atf_c \ atf_cxx \ bsdstat \ devdctl \ event \ + gssapi_krb5 \ + gssapi_ntlm \ + gssapi_spnego \ + hdb \ + heimbase \ heimipcc \ heimipcs \ + heimntlm \ ifconfig \ + hx509 \ + kadm5clnt \ + kadm5srv \ + kafs5 \ + kdc \ + krb5 \ ldns \ + roken \ sqlite3 \ ssh \ ucl \ unbound \ + wind \ zstd _INTERNALLIBS= \ @@ -58,7 +73,6 @@ _LIBRARIES= \ 80211 \ alias \ archive \ - asn1 \ auditd \ avl \ begemot \ @@ -104,21 +118,11 @@ _LIBRARIES= \ gnuregex \ gpio \ gssapi \ - gssapi_krb5 \ - hdb \ - heimbase \ - heimntlm \ heimsqlite \ - hx509 \ ipsec \ ipt \ jail \ - kadm5clnt \ - kadm5srv \ - kafs5 \ - kdc \ kiconv \ - krb5 \ kvm \ l \ lzma \ @@ -149,7 +153,6 @@ _LIBRARIES= \ pthread \ radius \ regex \ - roken \ rpcsec_gss \ rpcsvc \ rt \ @@ -175,7 +178,6 @@ _LIBRARIES= \ util \ uutil \ vmmapi \ - wind \ wrap \ xo \ y \ @@ -305,6 +307,8 @@ _DP_heimipcs= heimbase roken pthread _DP_kafs5= asn1 krb5 roken _DP_krb5+= asn1 com_err crypt crypto hx509 roken wind heimbase heimipcc _DP_gssapi_krb5+= gssapi krb5 crypto roken asn1 com_err +_DP_gssapi_ntlm+= crypto gssapi krb5 heimntlm roken +_DP_gssapi_spnego+= gssapi heimbase asn1 roken _DP_lzma= pthread _DP_ucl= m _DP_vmmapi= util diff --git a/usr.bin/compile_et/Makefile b/usr.bin/compile_et/Makefile index aeccbf3fd55..780bee4b58e 100644 --- a/usr.bin/compile_et/Makefile +++ b/usr.bin/compile_et/Makefile @@ -5,7 +5,11 @@ PROG= compile_et SRCS= compile_et.c parse.y lex.l LIBADD= roken vers -CFLAGS+=-I. -I${SRCTOP}/contrib/com_err +KRB5DIR= ${SRCTOP}/crypto/heimdal +CFLAGS+=-I. -I${SRCTOP}/contrib/com_err \ + -I${KRB5DIR}/lib/roken \ + -I${.OBJDIR:H:H}/kerberos5/lib/libroken \ + -I${.OBJDIR:H:H}/kerberos5/lib/libasn1 WARNS?= 0 diff --git a/usr.sbin/gssd/Makefile b/usr.sbin/gssd/Makefile index e40017016f1..318e9deb5fa 100644 --- a/usr.sbin/gssd/Makefile +++ b/usr.sbin/gssd/Makefile @@ -11,6 +11,11 @@ WARNS?= 1 LIBADD= gssapi .if ${MK_KERBEROS_SUPPORT} != "no" +KRB5DIR= ${SRCTOP}/crypto/heimdal +CFLAGS+= -I${KRB5DIR}/lib/krb5 \ + -I${SRCTOP}/kerberos5/include \ + -I${.OBJDIR:H:H}/kerberos5/lib/libkrb5 \ + -I${.OBJDIR:H:H}/kerberos5/lib/libasn1 LIBADD+= krb5 roken .else CFLAGS+= -DWITHOUT_KERBEROS --==_Exmh_1523130233_38710 Content-Type: text/plain; charset=us-ascii Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. --==_Exmh_1523130233_38710--