From owner-freebsd-hackers@freebsd.org Sun Oct 25 19:43:38 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABAA8835A for ; Sun, 25 Oct 2015 19:43:38 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45DF21FCA for ; Sun, 25 Oct 2015 19:43:38 +0000 (UTC) (envelope-from radovanovic@gmail.com) Received: by wijp11 with SMTP id p11so138735942wij.0 for ; Sun, 25 Oct 2015 12:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bzgUBzA20X2Il5ythAtmWXfAxJPAlvww2qNnjeB277A=; b=OfqCFTZAtrddMnCmGf1YOo5V5BaARm8X1DUnyEN0bZm5d1ox2mQSjxs4rrXiUe4Bbj sG2Mz4qSMbzmim0CAzyz1GL1zhseDSkvHUAcg1g+rmaxtDQh2Qz1gl1FjGoJ/pYPPgP3 NMBy67kP4p2zzc5g7vQQkUcAGeTS1AHpcVXcz5k+1ywdSmwUGC3M8xaxO915i94xxxHc fuNdjhLFbQAjXXy5w+kH/lv6C71pyT//NByavrCkoiPFymEfPRYQdpfLcsdJWwCmrIkB v2vTMXzWopilZGxZ3D6ks+ZqSXaoX++Hovy+ep8/UNKSlGTtLnffffGxllGdTgOFBCGI lUjw== X-Received: by 10.180.24.1 with SMTP id q1mr17356759wif.53.1445802216544; Sun, 25 Oct 2015 12:43:36 -0700 (PDT) Received: from zmaj.softwarehood.com (79-101-244-190.dynamic.isp.telekom.rs. [79.101.244.190]) by smtp.googlemail.com with ESMTPSA id ki7sm35025917wjc.28.2015.10.25.12.43.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Oct 2015 12:43:36 -0700 (PDT) Message-ID: <562D30E7.50300@gmail.com> Date: Sun, 25 Oct 2015 20:43:35 +0100 From: Ivan Radovanovic User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130812 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: Opening file to be used with kevent Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 19:43:38 -0000 Hi guys, What are recommended flags to use when opening file descriptor to be used later with kevent(2)? I was thinking to specify O_RDONLY but I guess that would prevent any other process from opening file with O_EXCL (and I don't care about file contents anyway, I just want to be notified when file is changed). Apparently Darwing has O_EVTONLY for this purpose, so I am wondering if FreeBSD has something equivalent (or what would be the weakest mode to pass to open(2))? Kind regards, Ivan From owner-freebsd-hackers@freebsd.org Sun Oct 25 21:52:24 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA1678466 for ; Sun, 25 Oct 2015 21:52:24 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A393613AB for ; Sun, 25 Oct 2015 21:52:24 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EBF15358C5A; Sun, 25 Oct 2015 22:52:20 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id CA8BE28494; Sun, 25 Oct 2015 22:52:20 +0100 (CET) Date: Sun, 25 Oct 2015 22:52:20 +0100 From: Jilles Tjoelker To: Ivan Radovanovic Cc: freebsd-hackers@FreeBSD.org Subject: Re: Opening file to be used with kevent Message-ID: <20151025215220.GA48903@stack.nl> References: <562D30E7.50300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562D30E7.50300@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 21:52:24 -0000 On Sun, Oct 25, 2015 at 08:43:35PM +0100, Ivan Radovanovic wrote: > What are recommended flags to use when opening file descriptor to be > used later with kevent(2)? > I was thinking to specify O_RDONLY but I guess that would prevent any > other process from opening file with O_EXCL (and I don't care about file > contents anyway, I just want to be notified when file is changed). O_RDONLY does not prevent any other process from doing anything to the file, except non-forced unmounting the filesystem it is on, like all open modes do. O_WRONLY and O_RDWR do prevent other processes from doing something: files open for writing cannot be executed as a program (execve(2) or similar will fail with [ETXTBSY]). > Apparently Darwing has O_EVTONLY for this purpose, so I am wondering if > FreeBSD has something equivalent (or what would be the weakest mode to > pass to open(2))? There is no equivalent but there are O_RDONLY and O_EXEC. I think the main issue to deal with is not permissions but unmounts. The approach with open(2) and kevent(2) prevents unmounting volumes if some application is monitoring a file on them. Ideally, monitoring a file would not prevent an unmount, and the unmount would generate a final event that the file is no longer accessible. On the other hand, getting notifications about the file contents does not make much sense if you are not allowed to read them. -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Mon Oct 26 02:59:47 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8177C8C6A; Mon, 26 Oct 2015 02:59:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 2DE1313D6; Mon, 26 Oct 2015 02:59:45 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f799c6d000001933-47-562d971edd9b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A3.A0.06451.E179D265; Sun, 25 Oct 2015 22:59:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t9Q2xf8d028728; Sun, 25 Oct 2015 22:59:41 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9Q2xbBC005829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Oct 2015 22:59:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9Q2xbd4023860; Sun, 25 Oct 2015 22:59:37 -0400 (EDT) Date: Sun, 25 Oct 2015 22:59:37 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2015 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrCs3XTfMYOInLotd106zW8x584HJ Yvvmf4wWh5uFHFg8ZnyazxLAGMVlk5Kak1mWWqRvl8CVceXWA8aCXx1sFfeO3WVrYFx5j6WL kYNDQsBEYul8wS5GTiBTTOLCvfVsILaQwGImientdl2MXED2RkaJTdMnskI4h5gkZvxYyQjh NDBKNB+YyQ7SwiKgLfH3/ktmEJtNQE3i8d5mVoixihKbT01iBtkmIiAvseC8PUiYWcBaYu66 9WAlwgK2Ek/XX2ABsXkFHCV+fJjABGKLCuhIrN4/BSouKHFy5hMWiF4tieXTt7FMYBSYhSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjODQlOTfwfjtoNIhRgEO RiUe3hc8umFCrIllxZW5hxglOZiURHnP1gKF+JLyUyozEosz4otKc1KLDzFKcDArifBmtQHl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeOOnAjUKFqWmp1akZeaU IKSZODhBhvMADf81BWR4cUFibnFmOkT+FKMxx6Np19YycayZcn8tkxBLXn5eqpQ4byPIOAGQ 0ozSPLhp4PSym0n1FaM40HPCvBtBqniAqQlu3iugVUxAq/KfaYKsKklESEk1MPq/m8h7XJqL +deiW7ESScxb/hhM8pacEmg3S/TVeu0niyX+Ni5dVqXOHLZSVy/itMjuM1tnebrf0/z5MKrs gmTx5t+/Fqw1vKD5cLVzhHhrK7fMGXvdfrcNuUJhDTvOxC0/Lv9M5WFBJ9NfP4bHKrY8jxvC T4cekNjxdrOU7AZO3aXqBbqmeUosxRmJhlrMRcWJABFBCNsKAwAA X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 02:59:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2015 The third quarter of 2015, from July to September, was again a period of busy activity for FreeBSD: for the second quarter in a row we have the largest report yet published. The Foundation continues to play a strong role, bringing both a developer and evangelist presence to conferences, funding much of the hardware that the cluster administration team uses to keep things running, and sponsoring many development projects for FreeBSD. This quarter we also hear from some of the student projects funded by Google Summer of Code 2015, ranging a wide gamut from the bootloader to additional ARM support, but also at a range of completion status. Some of the GSoC output is in the tree already, but others could benefit from additional attention to help out our budding new contributors as their schedules fill with the return to classes. ZFS and the network stack continue to be strong areas for FreeBSD, with both receiving active maintenance and feature improvements during this quarter. Substantial work continues on arm64, potentially putting it on the path toward a promotion to Tier-1 status, and a new port to the RISC-V architecture has made great headway in a short period of time. But it is not just our strengths and exciting new areas that have seen attention this cycle; there are also some parts of the system that are frequently perceived as unchanging infrastructure that have received attention and improvements, with truss and (k)gdb receiving significant overhauls, new implementations for the man page tools being brought in, the website receiving a new skin, and a brand new system for translating documentation that greatly lowers the barrier to entry. Nonetheless, despite its record length, this report does not and cannot cover all of the work being done on FreeBSD throughout the reporting period -- there are many bug fixes too minor to mention here, and developers too busy working on the next project to write up an entry for the previous project. It is not just the developers committing to Subversion that comprise the ongoing activities of FreeBSD, but also the users testing unreleased code or reporting bugs in released code, and participants on the mailing lists and forums helping each other solve their problems. Even the chats on IRC that wander far from the stated topic of a channel contribute to the community around FreeBSD; it is that community whose effectiveness and helpfulness is a key component of the effectiveness and usefulness of FreeBSD itself. Not just to the developers listed in this report, but to everyone in the community, thank you for making FreeBSD a great operating system. --Ben Kaduk __________________________________________________________________ Please submit status reports for the fourth quarter of 2015 (from October to December) by January 7, 2016. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * The FreeBSD Core Team Projects * automtud: Better Jumbo Frame Support * bhyve * Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 * DTrace and TCP * FreeBSD on the Acer C720 Chromebook * High Availability Clustering in CTL * Multipath TCP for FreeBSD * Porting bhyve to ARM-based Platforms * Root Remount * The Graphics Stack on FreeBSD * The nosh Project * UEFI Boot and Framebuffer Support * ZFS Code Sync with Latest Illumos * ZFS Support for UEFI Boot/Loader Kernel * Adding PCIe Hot-plug Support * Cavium LiquidIO Smart NIC Driver * CloudABI: Pure Capabilities Runtime Environment * FreeBSD Xen * ioat(4) Driver Import * IPsec Upgrades Architectures * Atomics * FreeBSD on Cavium ThunderX (arm64) * FreeBSD on the HiKey ARMv8 Board * FreeBSD/arm64 * FreeBSD/RISC-V Port Userland Programs * mandoc and roff Toolchain * pkg 1.6 * sesutil(8) * truss(1) * Updates to GDB Ports * Bringing GitLab into the Ports Collection * GNOME on FreeBSD * KDE on FreeBSD * Node.js Modules * Ports Collection * Ports on PowerPC * Xfce on FreeBSD Documentation * PO Translation Project * Website CSS Update Google Summer of Code * Allwinner A10/A20 Support * mtree Parsing and Manipulation Library * Multiqueue Testing * Update Ficl in Bootloader Miscellaneous * The FreeBSD Foundation * ZFSguru __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. Our primary cluster has been hosted as a guest in California for many years. Our ongoing project is relocating the core functionality to a location in New Jersey with a formal hosting arrangement. This is an equipment refresh, consolidation for better use of resources, and for better continuity of service. There is a significant amount of behind-the-scenes work to make this happen. The original cluster was implemented with a common, shared, assumed-to-be secure network with ubiquitous NFS everywhere. This structure does not lend itself well to being distributed across geographically diverse locations, particularly when Internet transit is required. The bulk of the work is rebuilding services to be portable, stand-alone components that do not depend on shared-network access and are safe enough to use across the insecure Internet. Highlights this quarter: * Many internal distribution systems switched from rsync to a distribution mesh using "syncthing". * We have implemented more code/data signing infrastructure with out-of-band verification. * New 32-core reference build hosts are online. * Internal admbugs switched from bugzilla 4.4 to 5.0 and packages were made available for the bugmeister team. * Finally switched from varnish3 to varnish4. * We exorcised hub.FreeBSD.org, the last survivor of the 2012 security incident. * vuxml and the legacy portaudit build system were converted to components and integrated. * https://download.FreeBSD.org/ is nearing completion (please do not use until officially announced). * A Taiwan node was brought into service for pkg, ftp, svn, and vuxml mirroring. * One of the freebsd-update mirrors was converted from lighttpd to nginx due to a data corruption bug. * We completed detachment of the svn repository from the old cluster and moved it to its new location. Ongoing: * The cluster runs a mixture of 11-current and 10-stable as part of our "eat our own dogfood" project. For this to be useful, we do monthly cluster refreshes to keep up with current code. * We build internal base system snapshots every few days and packages every day. * We also provide support for non-clusteradm-operated services including jenkins, reviews, portsnap, freebsd-update, bugzilla, package builders, git, and mercurial. This varies from as little as maintaining SSL front-ends through operating servers, distributing data or building packages/binaries to run. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 10.2-RELEASE announcement URL: https://www.freebsd.org/releases/10.2R/announce.html FreeBSD development snapshots URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ FreeBSD 10.3-RELEASE schedule URL: https://www.freebsd.org/releases/10.3R/schedule.html FreeBSD 11.0-RELEASE schedule URL: https://www.freebsd.org/releases/11.0R/schedule.html Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. In mid-August, the FreeBSD Release Engineering Team released FreeBSD 10.2-RELEASE, two weeks earlier than the original schedule anticipated. The FreeBSD Release Engineering Team would like to thank all that have tested the BETA and RC builds and reported issues during the release cycle. The FreeBSD Release Engineering Team, with approval from the FreeBSD Core Team, appointed Marius Strobl as the Deputy Lead. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The biggest task handled by the Core Team during this quarter was developing and publishing the new Code of Conduct. The Code of Conduct describes how people are expected to behave on all FreeBSD official communication channels, as well as how developers and other people involved with the project are to behave when representing the project in public. The Code of Conduct was generally well received and elicited numerous comments and suggestions for improvements from the community, many of which have been integrated. The next task handled by Core was the restoration of Babak Farrokhi's ports commit bit. Babak resides in Iran. A few years ago, legal advice suggested that allowing contributions from Iranian residents might violate US trade sanctions. After several years, Core was asked to revisit the issue. On the advice of counsel, Core decided that it could restore commit privileges to commmitters residing in Iran. The CTM service came under security review. Given that the lack of use of routine authenticity checking made the injection of trivial exploit code relatively easy, the service was held to be too risky to continue as an official part of the FreeBSD base system. CTM has very few remaining users but they should be able to install CTM from the Ports Collection in order to continue doing so. Core learned that ISC was ceasing its hosting service, which has entailed a rapid rework of plans on the movement of significant portions of the FreeBSD cluster to that data center. Cluster administration has taken ownership of the situation and is making progress. Core fielded an enquiry about NextBSD and whether this should be the future direction for the whole FreeBSD project. Core's position is that NextBSD is an interesting project, and we regard it, like the other BSD projects, as a potential source of good ideas. However, we currently have no plans to adopt NextBSD as the official FreeBSD distribution. Beyond these issues, Core also spent time in various routine activities. During this quarter we issued three new src commit bits, and took none in for safekeeping. Welcome to Allan Jude, Marcelo Araujo, and Andriy Voskoboinyk. __________________________________________________________________ automtud: Better Jumbo Frame Support Links jmgurney/automtud on github URL: https://github.com/jmgurney/automtud Contact: John-Mark Gurney The automtud script will allow a FreeBSD machine to send jumbo frames to machines that support them, while using normal-sized frames for other machines. There are various advantages to using jumbo frames, such as reduced protocol overhead. It also means that TCP streams will not be segmented as much, although TSO helps mitigate the disadvantages of such segmentation. In cases where LRO does not work well, fewer packets will be received. The script currently does not restore the system to its original state when it exits. This means that you must manually change the interface MTU and delete host routes after stopping the script. Open tasks: 1. Fix up various Ethernet drivers to better support jumbo frames. Most Ethernet drivers, though they support scatter/gather, use a physically contiguous zone to do so, which can cause resource shortages. 2. More testing is needed to ensure that things behave as expected. This means that when running the script, communication to all machines functions normally, without slowdown or connectivity issues. Check vmstat -z | grep mbuf to ensure that such issues are not due to running out of jumbo_9k or jumbo_16k buffers due to Ethernet driver issues. __________________________________________________________________ bhyve Links bhyve FAQ and talks URL: http://www.bhyve.org NE2000 device emulation GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/NE2000EmulationForBhyve Porting bhyve to ARM GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm ptnetmap support in bhyve GSoC project URL: https://wiki.FreeBSD.org/SummerOfCode2015/ptnetmapOnBhyve Windows support URL: http://docs.FreeBSD.org/cgi/mid.cgi?561187FB.8040506 Illumos support URL: http://docs.FreeBSD.org/cgi/mid.cgi?56118B2B.2040101 Contact: Peter Grehan Contact: Neel Natu Contact: Tycho Nightingale Contact: Allan Jude Contact: Michael Dexter bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, NetBSD/amd64, Illumos, and Windows Vista/7/8/10/2008r2/2012r2/2016 x64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. A combined bhyve and ZFS BoF was held during vBSDCon 2015, hosted by Michael Dexter and Allan Jude. Questions asked about bhyve included live migration and suspend/resume support, and configurations using ZFS. Three bhyve-related projects were selected for GSoC 2015: NE2000 device emulation, porting bhyve to ARM, and ptnetmap support. The major enhancement for bhyve this quarter was support for external firmware, along with a port of the Intel edk2 UEFI firmware. This allows bhyve to run Windows in headless mode, and also Illumos. Open tasks: 1. Improve the documentation. 2. bhyveucl is a work-in-progress script for starting bhyve instances based on a libUCL config file. More information at https://github.com/allanjude/bhyveucl. 3. Add support for virtio-scsi. 4. Flexible networking backends: wanproxy, vhost-net. 5. Support running bhyve as non-root. 6. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 7. Implement an abstraction layer for video (no X11 or SDL in base system). 8. Suspend/resume support. 9. Live migration. 10. Nested VT-x support (bhyve in bhyve). 11. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0 Links LLVM 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html Clang 3.7.0 Release Notes URL: http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html PR 201377 Ports exp-run URL: https://bugs.freebsd.org/201377 Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Contact: Davide Italiano We have updated clang, llvm, lldb, compiler-rt, and libc++ in base to the 3.7.0 release. These all contain numerous improvements. Please see the linked release notes for more detailed information. This brings us completely up-to-date with the latest upstream versions of these projects. Meanwhile, Ed Maste is working on importing the llvm.org version of libunwind. Like the 3.5.x and 3.6.x releases, these components require C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86. Currently, there are no solid plans to MFC these versions to any stable branches, due to the difficulties this would introduce for the usual upgrade scenarios. Thanks to Ed Maste and Andrew Turner for their help with this import, and thanks to Antoine Brodin for several ports exp-runs. During the first ports exp-run, some major problems were found, one introduced by a clang bug which caused pow() to generate floating point exceptions in some cases. This in turn caused libpng to fail to build, and one bug in libjpeg-turbo, which was caused by undefined behavior. These two problems took some time to fix, after which another exp-run was done, and this resulted in about a dozen newly failed ports. For almost all of these new failures, fixes were submitted and linked to the original PR 201377 for the exp-run. Open tasks: 1. Commit ports fixes for dependencies of PR 201377. 2. Test and report issues with the new tool chain. __________________________________________________________________ DTrace and TCP Links Commit adding trace points replacing TCPDEBUG URL: https://svnweb.freebsd.org/changeset/base/287759 Contact: George Neville-Neil With the advent of DTrace we are able to replace many of the internal kernel debugging options, such as TCPDEBUG, with statically defined tracepoints (SDTs). Tracepoints have now been added to the system that replicate the functionality of the TCPDEBUG kernel option. No new kernel options need to be added -- they are standard with any kernel that has DTrace, which is included in the default GENERIC kernels in 10.X and HEAD. This project is sponsored by Limelight Networks. __________________________________________________________________ FreeBSD on the Acer C720 Chromebook Links Blog post on how to get things working URL: http://blog.grem.de/pages/c720.html Blog post with links to commits in HEAD URL: http://blog.grem.de/sysadmin/FreeBSD-On-AcerC720-Merged-2015-07-25-23-30.html Backported patch for 10.2-RELEASE URL: http://blog.grem.de/sysadmin/FreeBSD-10.2-On-AcerC720-2015-09-19-17-00. html Contact: Michael Gmelin The Acer C720 Chromebook is an affordable (under $200) and powerful little laptop that provides a battery life of up to six hours running FreeBSD. It is a great machine for travelling and coding in general. The machine is fully functional, meaning that all essential devices work: keyboard, trackpad, light sensor, backlight control, display in VESA mode (fast), external Display on HDMI (only VESA mirror mode), sound, USB ports, SD card slot, camera, and Atheros wireless. This quarter, this project extended previous work on the boot process and keyboard driver as well as the smbus(4) driver. It added three new drivers: ig4(4) for the I2C bus, cyapa(4) for the trackpad, and isl(4), for the ambient light sensor. Much of the development was originally done in late 2014. Since then, the patches have been massively improved and merged into HEAD, so that all relevant devices work without manual patching. For those who are unable to run HEAD, there is a backported patch to 10.2-RELEASE. Thanks to everyone who helped in the process. I couldn't have done it without you (you know who you are). __________________________________________________________________ High Availability Clustering in CTL Contact: Alexander Motin CAM Target Layer (CTL), when originally developed by Copan/SGI, had support for High Availability clustering. Unfortunately, significant portions of the HA code were never published with the main body of the source code. Now, the missing part has been reimplemented from scratch, fixed, and improved. This code supports dual-node HA with Asynchronous LUN Unit Access (ALUA) in four modes: * Active/Unavailable without interlink between nodes, where the secondary node can report nothing except its presence. * Active/Standby with the secondary node handling only basic LUN discovery and reservation, synchronizing state and command execution with the primary node through the interlink. * Active/Active with both nodes processing commands and accessing the backing storage, synchronizing state and command execution with the primary node through the interlink. * Active/Active with the secondary node having no backing storage access, but instead working as a proxy, transferring all commands to the first node for execution through the interlink. In the case of lost interlink connectivity to primary node, the secondary node falls into the Transitioning state, which is like Unavailable and cannot answer most requests, but makes the initiator wait for recovery or cluster failover. CTL also got a large number of other improvements, including support for emulation of CD/DVD drives and removable disks, live LUN reconfiguration, and so on. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. This project is sponsored by iXsystems, Inc.. __________________________________________________________________ Multipath TCP for FreeBSD Links MPTCP for FreeBSD Project Website URL: http://caia.swin.edu.au/urp/newtcp/mptcp/ MPTCP for FreeBSD Source Repository URL: https://bitbucket.org/nw-swin/caia-mptcp-freebsd/ Contact: Nigel Williams Multipath TCP (MPTCP) is an extension to TCP that allows for the use of multiple network interfaces on a standard TCP session. The addition of new addresses and scheduling of data across them occurs transparently from the perspective of the TCP application. The goal of this project is to deliver an MPTCP kernel patch that interoperates with the reference MPTCP implementation, along with additional enhancements to aid network research. The v0.5 patch was released, which is the first patch of the re-written implementation. We are in the process of documenting the new design and addressing some feedback as provided from the community. Work has commenced on improved input handling, as the current method of receiving and reassembling segments has been the cause of some instability and stalls during connection shutdown. This will involve re-using the subflow receive buffers and an upcall to enqueue a MP-layer reassembly task without the need to take a lock on the MP control block. The improvements should also allow bypassing mptcp_usrreq for standard TCP connections. The MPTCP commit history was synchronized with hg-beta.FreeBSD.org, and we have made the repository available on BitBucket (see links). Future patch releases will be tagged there. The tree is now merged with FreeBSD head weekly. An updated v0.51 patch is ready for release. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Release the v0.51 patch. 2. Populate documentation and the issue tracker on the BitBucket repository. 3. Improvements to receive-side code before further testing. 4. Prepare a technical report detailing the design of the current patch. __________________________________________________________________ Porting bhyve to ARM-based Platforms Links Project Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm Contact: Mihai Carabas Contact: Peter Grehan This summer we have started porting bhyve onto ARMv7 platforms. The low-level routines for ARM processors were rewritten while trying to preserve the hypervisor API originally created for the x86 architectures. We managed to bring up a FreeBSD guest up to the point of initializing interrupts. There is still work to be done in order to virtualize the interrupts and the timer. Our short-term plan after finishing the interrupts and the timer is porting to a real hardware platform (Cubie2). Open tasks: 1. Virtualize interrupts and timer. 2. Port to a real hardware platform. 3. Create SMP support for bhyve-on-arm. 4. Port to ARMv8. __________________________________________________________________ Root Remount Links Userland code review URL: https://reviews.freebsd.org/D3693 Contact: Edward Tomasz Napierala A feature long missing from FreeBSD was the ability to boot up with a temporary rootfs, configure the kernel to be able to access the real rootfs, and then replace the temporary root with the real one. In Linux, this functionality is known as pivot_root. The reroot project aims to provide similar functionality in a different, slightly more user-friendly, way. Simply put, from the user's point of view it is as simple as running reboot -r. The system performs a partial shutdown, killing all processes and unmounting the rootfs, and then partial bringup, mounting the new rootfs, running init, and running the startup scripts as usual. The kernel part of the project has been committed to 11-CURRENT. The userland part is at the "finishing touches" stage, and is expected to be committed soon. A merge to stable/10 is planned and reroot support is planned be included in FreeBSD 10.3. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics stack roadmap and supported hardware matrix URL: https://wiki.FreeBSD.org/Graphics Graphics stack team blog URL: http://blogs.freebsdish.org/graphics/ Ports development tree on GitHub URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team The Mesa ports were updated to 10.6.8. At the same time, the ports received a major overhaul to make sure all ports are correctly configured. Dual version support was removed. There is only one Mesa version for all supported FreeBSD versions. The libosmesa port, which provided the off-screen version of Mesa, was merged into the Mesa framework. Another big item that was included in the Mesa port is OpenCL. There are two GPU-based OpenCL implementations: lang/clover for supported Radeon cards, and lang/beignet for supported Intel cards (currently only Ivybridge). Thanks go to Johannes Dieterich, O. Hartmann, and Koop Mast for making this happen. Now that Mesa is up-to-date, we can apply the same update procedure to the X.Org server. It is currently at 1.14, and an update to 1.17 is ready. It will be committed shortly. On the kernel side, progress has been made with the i915 update. The driver is able to attach. There are some reports that the X.Org server starts but Mesa is unhappy, so acceleration does not work yet. If you want to test, instructions will be posted on the wiki in the i915 update article (see links). At this stage, we can only accept patches, though -- we will not be able to provide support. We attended two conferences: XDC 2015 in Toronto and EuroBSDcon 2015 in Stockholm. Reports will be posted on the blog. Open tasks: 1. See the Graphics wiki page for up-to-date information. __________________________________________________________________ The nosh Project Links Introduction and blurb URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html FreeBSD binary packages URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/freebsd-binary-packages.html Installation How-To URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/timorous-admin-installation-how-to.html Roadmap URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/roadmap.html Commands URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/commands.html A slightly outdated nosh Guide URL: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/index.html Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems, and for managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d system, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It comprises a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. The past few months have seen a growth in the import mechanism, with full import of /etc/fstab and /etc/ttys available in version 1.18 in July, and importing PC-BSD Warden and FreeBSD 9 jails, and full import of gbde and geli mount/unmount mechanisms in version 1.21 in October. It has also gained the ability to automatically re-generate host.conf and sysctl.conf whenever their source files change. Other developments in the past few months include fully independent shutdown support, no longer relying upon an externally provided shutdown command from another toolset, and a full suite of binary packages. As of version 1.20, it became possible to have a fully-nosh-managed system, on both FreeBSD and Linux, using just precompiled binary packages. The biggest task remaining is one that was set a while ago: the creation of enough native service bundles and ancillary utilities to entirely supplant the rc.d system. A lot of this has been achieved, with the original target list of 157 items now down to just 39 remaining. These are the tricky ones, of course, where help is most needed. Open tasks: 1. There are still a few rc scripts left that should be easy to convert, such as /etc/rc.d/gptboot and /etc/rc.d/growfs as oneshot services, /etc/rc.d/routing, and /etc/rc.d/kldxref. 2. FreeBSD's /etc/rc.d/bluetooth is over 360 lines long. In 2011, Iain Hibbert wrote a "simpler" bluetooth for NetBSD. This can perhaps be used as a simpler basis for a nosh translation. 3. Add kernel support for passing a -b option to pid 1, and support for a boot_bare variable in the loader, to allow "emergency" (where even no shell dotfiles are loaded) and "rescue" mode bootstraps, akin to Linux. (History: The -b mechanism and idea date back to version 2.57d of Miquel van Smoorenburg's System 5 init clone, dated 1995-12-03, and was already known as "emergency boot" by 1997.) 4. Add support to FreeBSD's fsck(8) for outputting machine-readable progress reports to a designated file descriptor, so that nosh can provide progress bars for multiple fscks running in parallel. nosh already provides this functionality on Linux, where fsck(8) does provide machine-readable output. 5. Identify when the configuration import system needs to be triggered, such as when bsdconfig alters configuration files, and create the necessary hooks to import external configuration changes into nosh. 6. Investigate how FreeBSD/PC-BSD could be improved by taking advantage of some available nosh package mechanisms. __________________________________________________________________ UEFI Boot and Framebuffer Support Contact: Ed Maste Contact: Marcel Moolenaar A number of UEFI bug fixes were committed over the last quarter, improving compatibility with different UEFI implementations. This includes improvements to EFI's vt(4) framebuffer driver, efifb, to handle systems with high resolution displays and unusual framebuffer stride values. In particular, this improves compatibility with a large number of recent Apple MacBook Pros and other Macs. Open tasks: 1. Test FreeBSD head and FreeBSD-STABLE snapshots on a variety of UEFI implementations. __________________________________________________________________ ZFS Code Sync with Latest Illumos Contact: Alexander Motin The ZFS codebase received a significant batch of merges, and is now in sync with the latest Illumos. Among other things, this update includes: * LZ4 is now the default compression algorithm. * Improved prefetch for faster send/receive. * Reduced RAM usage by almost 50% for L2ARC. * Improved I/O aggregation. * Fine-grained checksumming in send/receive stream. * Reduced import time for pools with many datasets. * Reworked and simplified predictive prefetcher. The code is committed to FreeBSD head and was recently merged to the stable/10 branch. __________________________________________________________________ ZFS Support for UEFI Boot/Loader Contact: Eric McCorkle UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem, as described in the previous report. The ZFS-enabled loader.efi can be treated as a chainloader when using ZFS-enabled GRUB. During this quarter, several successful tests have been reported on simple ZFS setups, using both boot1.efi with loader.efi as well as GRUB and loader.efi. Successful tests have been reported for UFS with the patched boot1.efi and loader.efi as well. Open tasks: 1. Test reports are needed for more complex ZFS setups, such as with log/l2arc vdevs, mirroring, striping, and raidz. 2. Pending successful reports, the patch needs to be reviewed and committed. __________________________________________________________________ Adding PCIe Hot-plug Support Links PCIe Hot-plug Perforce Branch URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/pciehotplug Commit adding bridge save/restore URL: https://svnweb.FreeBSD.org/changeset/base/r281874 Github branch with patches URL: https://github.com/FreeBSDFoundation/freebsd/tree/pciehp Contact: John-Mark Gurney PCI Express (PCIe) hot-plug is used on both laptops and servers to allow peripheral devices to be added or removed while the system is running. Laptops commonly include hot-pluggable PCIe as either an ExpressCard slot or a Thunderbolt interface. ExpressCard has built-in USB support that is already supported by FreeBSD, but ExpressCard PCIe devices like Gigabit Ethernet adapters and eSATA cards are only supported when they are present at boot, and their removal may cause FreeBSD to crash. The goal of this project is to allow these devices to be inserted and removed while FreeBSD is running. This work will provide the basic infrastructure to support adding and removing devices, though it is expected that additional work will be needed to update individual drivers to support hot-plug. Current testing is focused on getting a simple UART device functional. Basic hot swap is currently functional. A set of the patches for the work done in this project is now available on github.com. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Get suspend/resume functional by saving and restoring the necessary registers. This should be addressed by r281874. 2. Make sure that upon suspend, devices are removed so that we are not fooled if they are replaced with different devices while the machine is suspended. 3. Improve how state transitions are handled, possibly by using a proper state machine. __________________________________________________________________ Cavium LiquidIO Smart NIC Driver Links LiquidIO product page URL: http://www.cavium.com/LiquidIO_Application_Acceleration_Adapters.html Contact: Stanislaw Kardach Contact: Zyta Racia This project aims to add support for the LiquidIO family of high-performance programmable accelerator 10/40-gigabit Ethernet network adapters. The currently developed kernel driver supports CN6640- and CN6880-based PCIe cards, enabling these features: * A CNNIC API for controlling/interacting with the smart NIC from user and kernel space including: + Handling multiple concurrent applications running on the same device + A request/reply mechanism for (a)synchronous ordered/unordered communication + Remote memory operations + Device shutdown/reset * A basic NIC module utilizing the CNNIC API and a Cavium-provided NIC firmware. This module provides: + Single/multi-queue TX + Hardware TCP/UDP checksum offloading + Large Receive Offload + Promiscous mode * Sysctl-based device statistics and configuration view * Custom firmware loading via user-built modules and FreeBSD's firmware(9) mechanism. The project is currently being developed in house and is being prepared for upstream. We plan on making it available in FreeBSD 11. This project is sponsored by Cavium, and Semihalf. Open tasks: 1. Upstream the code to FreeBSD head. __________________________________________________________________ CloudABI: Pure Capabilities Runtime Environment Links CloudABI project page URL: https://github.com/NuxiNL/cloudlibc CloudABI Ports Collection URL: https://github.com/NuxiNL/cloudabi-ports CloudABI presentation at FrOSCon URL: https://www.youtube.com/watch?v=LTHSZGVvLw4 Contact: Ed Schouten CloudABI is a POSIX-like runtime environment that uses Capsicum as its sole access control mechanism. CloudABI allows you to develop software that is better hardened against security vulnerabilities, is easier to test, and is easier to migrate across systems. As of August, all of the kernel modifications that are needed to run CloudABI programs have been integrated into FreeBSD head. After loading the cloudabi64 kernel module, you can either run CloudABI programs directly from the shell or by using the cloudabi-run tool (sysutils/cloudabi-utils). cloudabi-run allows you to inject sockets, files, and directories into the launched program in a more structured way. In the meantime, work has started on developing a Ports Collection that contains cross-compiled utilities and libraries for CloudABI. The intent is that this framework generates native packages for a number of operating systems, making it possible to develop CloudABI applications on any operating system, regardless of whether that operating system actually supports CloudABI. If you are interested in CloudABI, be sure to go to the project page on GitHub, watch recordings of talks at conferences, or wait for the upcoming edition of the FreeBSD Journal, which will feature an article on CloudABI. This project is sponsored by Nuxi, the Netherlands. Open tasks: 1. CloudABI is currently only available for amd64. It would make sense to port CloudABI to additional architectures like aarch64. 2. Support for CloudABI has only been integrated into FreeBSD. If we manage to upstream support for CloudABI into other operating systems, it should be possible to run the same binary on multiple operating systems without recompilation. 3. The CloudABI Ports Collection currently has only 60 packages. Although these packages already the building blocks of some interesting software, we are always interested in expanding. __________________________________________________________________ FreeBSD Xen Links FreeBSD PVH DomU wiki page URL: http://wiki.xen.org/wiki/FreeBSD_PVH FreeBSD PVH Dom0 wiki page URL: http://wiki.xen.org/wiki/FreeBSD_Dom0 Porting FreeBSD as a Xen ARM guest URL: http://www.xenproject.org/component/allvideoshare/video/latest/bsdcan-2015-how-to-port-bsd-as-a-xen-on-arm-guest.html Contact: Roger Pau Monn? Contact: Julien Grall Xen is a hypervisor using a microkernel design, providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen support for FreeBSD on x86 as a guest was introduced in version 8 and ARM support is currently being worked on. Support for running FreeBSD as an amd64 Xen host (Dom0) is available in HEAD. On the x86 front, most of the work during this quarter focused on the implementation of PVH inside Xen. Consequently, most of the activity happened inside of the hypervisor. Patches for a clean PVH implementation have been posted, with the aim of having them merged in the next Xen release (4.7). Once that is done, work will continue adding new features to both FreeBSD and Xen to have feature parity with traditional PV guests/hosts. Apart from this, work is ongoing to import a new netfront from Linux in order to support new features, like split event channel and multiple queue support. On the ARM front, this quarter's work focused on getting FreeBSD/arm64 booting as a Xen guest. The current activity is to upstream patches preparing Xen drivers to support arm64. This includes a rework of the console driver. This project is sponsored by Citrix Systems R&D. Open tasks: 1. Generalize the event channel code so it can be used on ARM. 2. Improve backend (netback, blkback) performance. 3. Work with upstream Xen to improve PVH and make it stable. 4. Improve the generic bounce buffer code for unmapped bios in order to support the alignment requirements of the blkfront driver. __________________________________________________________________ ioat(4) Driver Import Links Wikipedia article on IOAT URL: https://en.wikipedia.org/wiki/I/O_Acceleration_Technology Commit importing ioat(4) URL: https://svnweb.FreeBSD.org/base?view=revision&revision=r287117 Contact: Jim Harris Contact: Conrad Meyer A new driver, ioat(4), was added to the tree. ioat(4) supports Intel's I/O Acceleration Technology devices which are found on some Intel server systems. These devices are DMA offload engines, which can accelerate some I/O-heavy applications by offloading memory copies from the main CPU to the I/OAT unit. This acceleration is not transparent; applications must be adapted to take advantage of the hardware. Some I/OAT models support more advanced copying modes, such as XOR; these modes are not yet supported in the ioat(4) driver. This project is sponsored by Intel Corporation, and EMC / Isilon Storage Division. Open tasks: 1. Further testing, especially on a range of device models other than BDXDE (looking for volunteers here). 2. Support for the more advanced copy modes. __________________________________________________________________ IPsec Upgrades Contact: George Neville-Neil Contact: John-Mark Gurney Contact: Ermal Lu? IPsec is now enabled by default in the GENERIC kernel configuration, and work is proceeding to speed things up in various ways. The latest changes are the addition, by John-Mark Gurney, Ermal Lu?, and George V. Neville-Neil, of AES modes both in hardware and in software. Part of this work also includes more benchmarks undertaken using Conductor in the netperf project. Results have been reported at BSDCan and vBSDcon with more to come at EuroBSDcon and BSDCon Brasil. This project is sponsored by Netgate, and The FreeBSD Foundation. Open tasks: 1. Performance improvements and other tweaks are ongoing. __________________________________________________________________ Atomics Contact: Konstantin Belousov Contact: Alan Cox Contact: Bruce Evans Atomic operations serve two fundamental purposes. First, they are the building blocks for expressing synchronization algorithms in a single, machine-independent way using high-level languages. In essense, atomics abstract the different building blocks supported by the various architectures on which FreeBSD runs, making it easier to develop and reason about lock-less code by hiding hardware-level details. Atomics also provide the barrier operations that allow software to control the effects on memory of out-of-order and speculative execution in modern processors as well as optimizations by compilers. This capability is especially important to multithreaded software, such as the FreeBSD kernel, when running on systems where multiple processors communicate through a shared main memory. Each machine architecture defines a memory model, which specifies the possible effects on memory of out-of-order and speculative execution. More precisely, it specifies the extent to which the machine may visibly reorder memory accesses to optimize performance. Unfortunately, there are almost as many models as architectures. Some architectures, for example IA32 or Sparcv9 TSO, are relatively strongly ordered. In contrast, others, like PowerPC or ARM, are very relaxed. In effect, atomics define a very relaxed abstract memory model for FreeBSD's machine-independent code that can be efficiently realized on any of these architectures. Most FreeBSD development and testing still happens on x86 machines, which, when combined with x86's strongly ordered memory model, leads to errors in the use of atomics, specifically, barriers. In other words, the code is not properly written to FreeBSD's abstract memory model, but the strong ordering of the x86 architecture hides this fact. The architectures impacted by the code that incorrectly uses atomics are less popular or have limited availability, and the resulting bugs from the misuse of atomics are hard to diagnose. The goal of this project is to audit and upgrade the usage of lockless facilities, hopefully fixing bugs before they are observed in the wild. FreeBSD defines its own set of atomics operations, like many other operating systems. But unlike other operating systems, FreeBSD models its atomics and barriers on the release consistency model, which is also known as acquire/release model. This is the same model which is used by the C11 and C++11 language standards as well as the new 64-bit ARM architecture. Despite having syntactical differences, C11 and FreeBSD atomics share essentially the same semantics. Consequently, ample tutorials about the C11 memory model and algorithms expressed with C11 atomics can be trivially reused under FreeBSD. One facility of C11 that was missing from FreeBSD atomics was fences. Fences are bidirectional barrier operations which could not be expressed by the existing atomic+barrier accesses. They were added in r285283. Due to the strong memory model implemented by x86 processors, atomic_load_acq() and atomic_store_rel() can be implemented by plain load and store instructions with only a compiler barrier. No additional ordering constraints are required. This simplification of atomic_store_rel() was done some time ago in r236456. The atomic_load_acq() change was done in r285934, after careful review of all its uses in the kernel and user-space to ensure that no hidden dependency on a stronger implementation was left. The only reordering in memory accesses which is allowed on x86 is that loads may be reordered with older stores to different locations. This results from the use of store buffers at the micro-architecural level. So, to ensure sequentially consistent behavior on x86, a store/load barrier needs to be issued, which can be done with an MFENCE instruction or by any locked read-modify-write operation. The latter approach is recommended by the optimization guides from Intel and AMD. It was noted that careful selection of the scratch memory location, which is modified by the locked RMW operation, can reduce the cost of the barrier by avoiding false data dependencies. The corresponding optimization was committed in r284901. The atomic(9) man page was often a cause of confusion due to both erroneous and ambiguous statements. The most significant of these issues were addressed in changes r286513 and r286784. Some examples of our preemptive fixes to the misuse of atomics that would only become evident on weakly ordered machines are: * A very important lockless algorithm, used in both the kernel and libc, is the timekeeping functionality implemented in kern/kern_tc.c and the userspace __vdso_gettimeofday. This algorithm relied on x86 total store order (TSO) behavior. It was fixed in r284178 and r285286. * The kern/kern_intr.c lockless updates to the it_need indicator were corrected in r285607. * An issue with kern/subr_smp.c:smp_rendezvous_cpus() not guaranteeing the visibility of updates done on other CPUs to the caller was fixed in r285771. * The pthread_once() implementation was fixed to include missed barriers in r287556. This project is sponsored by The FreeBSD Foundation (Konstantin Belousov's work). __________________________________________________________________ FreeBSD on Cavium ThunderX (arm64) Contact: Dominik Ermel Contact: Wojciech Macek Contact: Zbigniew Bodek Cavium's ThunderX is a high-performance 64-bit ARMv8 CPU, available in configurations with up to 48 cores per package. ThunderX is the initial reference platform for the FreeBSD/arm64 porting effort. Additional Semihalf-sponsored work on ThunderX support brought brand new features such as: * Multi-socket operation: FreeBSD now runs on a two-node ThunderX server board with a total of 96 CPU cores! * Virtual Networking Interface Card driver: The VNIC driver consists of 4 elements (BGX, MDIO, and Physical and Virtual Functions) and is the second driver in FreeBSD to utilize SR-IOV capabilities. ThunderX is now able to use built-in networking interfaces at 1-40 Gbps. Moreover, previously introduced functionalities have been improved and committed to HEAD. This includes: * PCIe drivers for both internal and external controllers * ITS (Interrupt Translation Services) fixes * Platform-specific changes for ThunderX * Various other fixes to the kernel (PCI, UMA, etc.) The remaining features are being reviewed and will be integrated into HEAD soon. However, the GENERIC kernel already supports and runs on ThunderX. This project is sponsored by The FreeBSD Foundation, ARM Ltd., Cavium, and Semihalf. Open tasks: 1. Upstream the remaining features: 2-socket support, VNIC driver, and PCIe fixes __________________________________________________________________ FreeBSD on the HiKey ARMv8 Board Links HiKey wiki entry URL: https://wiki.FreeBSD.org/arm64/HiKey Hardware description URL: https://www.96boards.org/products/ce/hikey/ Contact: Andrew Turner The HiKey is a low-cost ARMv8 development board from the Linaro 96boards initiative. It contains a HiSilicon Kirin 6220 with eight ARMv8 cores and 1GB of ram. FreeBSD has been ported to run on the HiKey with a minimal set of drivers. As of this report, FreeBSD supports the micro-SD slot and USB host, and will boot off the SD card to multi-user mode using a recent arm64 snapshot. The kernel is missing a number of device drivers. However, it is at a usable state for people interested in testing FreeBSD on ARMv8 hardware. This project is sponsored by ABT Systems Ltd, and ARM Ltd. Open tasks: 1. A driver for SDIO and the onboard WiFi. 2. Fix the MMC driver to access the eMMC. 3. Support the USB in OTG mode. 4. Support a display via HDMI. 5. Add thermal management. __________________________________________________________________ FreeBSD/arm64 Links FreeBSD arm64 wiki page URL: https://wiki.FreeBSD.org/arm64 Contact: Andrew Turner Contact: Ed Maste Numerous cleanups and fixes have been applied to the arm64 kernel. This includes fixes to exception handling, asynchronous signals, ddb, and pmap. ddb has been updated to better handle accessing memory that may be unmapped. The pmap code was made more complete by implementing more functions as needed. Further work on SMP means that FreeBSD now boots on all 48 cores on the Cavium ThunderX platform. This includes adding support for the ARM GICv3 interrupt controllers and fixing the memory mapping to be shareable between CPUs. The test suite has been run on both qemu and hardware. Most of the test cases are passing, with around 30 tests either broken or failing. Work on diagnosing the issues with the remaining test cases is ongoing. This project is sponsored by The FreeBSD Foundation, and ABT Systems Ltd. Open tasks: 1. Port to more SoCs. __________________________________________________________________ FreeBSD/RISC-V Port Links FreeBSD wiki RISC-V URL: https://wiki.freebsd.org/riscv Single user boot log URL: https://people.freebsd.org/~br/riscv-singleuser.txt Contact: Ruslan Bukin Contact: Arun Thomas Contact: Ed Maste RISC-V is an open source Instruction Set Architecture (ISA) designed at UC Berkeley. It is freely available for all uses without requiring fees or license agreements. The RISC-V team intends to provide freely available BSD licensed CPU designs. Ruslan Bukin (University of Cambridge) now has FreeBSD booting to a single user shell on a RISC-V simulator. The porting effort started only two months ago and is very much a work in progress, requiring significant refactoring and clean up before it reaches a committable state. Nonetheless, this is exceptional progress in a short time. The porting effort also identified a number of proposed ISA improvements. The port currently uses the GNU tool chain (GCC and binutils), and runs on the Spike simulator. Improved RISC-V support in Clang/LLVM and related tools is highly desired. This project is sponsored by DARPA, AFRL. __________________________________________________________________ mandoc and roff Toolchain Links Heirloom doctools URL: https://github.com/n-t-roff/heirloom-doctools mandoc URL: http://mdocml.bsd.lv/ Contact: Baptiste Daroussin mandoc is a suite of tools for compiling mdoc, the roff macro language of choice for BSD manual pages. mandoc is the default renderer for manpages on FreeBSD head. This quarter, the apropos(1) utility was switched to use mandoc's version, which offers a new database format (in SQLite) bringing more powerful, fine-grained ways to search man pages. While mandoc is very good for man pages, we also provide lots of other documentation in plain roff format. The Heirloom toolchain is being studied to replace groff in base. The Heirloom nroff toolchain has multiple benefits: it has very good unicode support and very good compatibility with groff. A great deal of work as been done testing the Heirloom nroff toolchain with all the roff documents in the base system (including man pages), and upstream has been very proactive in fixing reported bugs. The soelim(1) utility has been replaced with a BSD-licensed version which is good enough to work with all available roff toolchains to ease the transition. This version of the soelim(1) utility, originally written solely for FreeBSD, is now part of the mandoc tool suite. In coordination with Ingo Schwarze from OpenBSD, the col(1) utility has been cleaned up and updated to recognize both SUSv2-style escape-digit and BSD-style escape-control-char sequences in the input stream. The checknr(1) utility has been cleaned up and extended to support modern roff(7) macros, including synchronizing code from NetBSD and the Heirloom doctools version. Many roff fixes were made to documentation and man pages, having been discovered while testing the new toolchain. __________________________________________________________________ pkg 1.6 Contact: FreeBSD pkg Team pkg 1.6.0 has been released. Many changes have been made since pkg 1.5: * The dependency solver is greatly improved * Lots of fixes in the three-way merge code * pkg add can now work without a version specified in the dependency line * pkg check -d now also checks the required libraries * Improved support for partial upgrades * Improved zsh completion support * Improved Linux support: all regression tests now pass on Linux * Messages can now be context-aware, showing a given message always, or only during installation, upgrade (conditional on the previous version), or removal * @keywords now accept new entries to add context-aware messages * Added the ability to generate graphiz's dot format representation of the solver's problem * pkg search now defaults to showing the pkg-comments of the matched packages * Lots of bug fixes and code cleanup * Improvements in cross-installation support Open tasks: 1. Add a notion of priority to the list of files to ensure that certain files are the first to be replaced. This was a blocker for packaging base. 2. Investigate replacing openssl by mbedtls. __________________________________________________________________ sesutil(8) Links Wikipedia: SCSI Enclosure Services (SES) URL: https://en.wikipedia.org/wiki/SCSI_Enclosure_Services Contact: Baptiste Daroussin Contact: Allan Jude sesutil(8) was originally created as a more universal way to blink the "locate" LEDs on most hot-swappable drive enclosures. This work is based on the original SES tools created by Matthew Jacob in 2000, which have been available in the share/examples section of the source tree, but were not built by default. The new utility extends the original code with a number of very useful features: * Print a map of all objects connected to the SES controller * Map device names (/dev/da5) to SES slot number * Blink the Locate and/or Fault LED of a drive by its SES slot number or device name * Check the status of the entire SES controller This project is sponsored by Gandi, and ScaleEngine Inc.. Open tasks: 1. Test sesutil(8) against more hardware. 2. Diagnose an issue where the locate command sometimes needs to be sent twice to activate the LED. 3. Add support for libxo output types. __________________________________________________________________ truss(1) Contact: John Baldwin Contact: Bryan Drewery The interface between the ABI-specific backends and the truss core was refactored, reducing duplicated code. This prompted additional follow-on work to add support for more ABIs, including aarch64 and CloudABI. ptrace(2) was extended to return more information about the currently executing system call. This restored behavior that had been present in a previous version of truss: knowing the correct number of arguments for all system calls. The fork-following support in truss was reworked to use native fork following in ptrace(2) rather than forking a new truss process for each child of a traced process. Support for decoding more arguments has been added in the last quarter as well. Open tasks: 1. Create a new libsysdecode library to hold shared code between truss(1) and kdump(1). 2. Decode more system call arguments. 3. Add appropriate system call decoding specifications for freebsd32 system calls. 4. Implement an ABI for 64-bit Linux binaries under FreeBSD/amd64. __________________________________________________________________ Updates to GDB Links Extend libkvm to support cross-debugging of vmcores URL: https://reviews.FreeBSD.org/D3341 Contact: John Baldwin Support for following children after forks for FreeBSD was implemented and merged upstream to GDB's master branch, and was included in GDB 7.10. Work has continued on porting kgdb to newer gdb. The amd64, i386, powerpc, powerpc64, and sparc64 backends have all been ported and are now available via a new KGDB option in the devel/gdb port. The MD backends for libkvm have been rewritten to support cross-debugging crashdumps, and the kgdb targets for amd64 and i386 have been reworked to support cross-debugging. Both i386 and amd64 kgdb binaries have been able to cross-debug the other architecture's vmcores with these changes. This changeset for libkvm is not yet in the tree, but is awaiting more testing. Open tasks: 1. Test the libkvm changes on platforms other than amd64, i386, and powerpc64. 2. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 3. Add support for more platforms (arm, mips, aarch64) to upstream gdb for both userland and kgdb. 4. Write a new 1:1-only thread target for FreeBSD that can be sent upstream. 5. Add support for debugging powerpc vector registers. __________________________________________________________________ Bringing GitLab into the Ports Collection Links PR for the new port URL: https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=202468 Installation guide URL: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md GitLab Source Tree URL: https://github.com/gitlabhq/gitlabhq/ Contact: Torsten Z?lsdorff Contact: Michael Fausten GitLab is a web-based Git repository manager with many features, used by more than 100.000 organizations, including NASA and Alibaba. It also is a very long-standing entry on the "Wanted Ports" list on the FreeBSD Wiki. In the last month there was steady progress, finally resulting in the PR for adding the new port. In addition to the many dependencies Philip M. Gollucci is working on, there was already a large amount of work done. Along with many new or updated rubygems, Rails 4.1 was resurrected. A large group of committers were involved in the process and guided us through the various problems and pitfalls. Because of the number of dependencies -- we nearly hit 100 -- making progress takes some time. In the meantime, a new major version of GitLab has already been released, requiring even more dependencies and updates. Work on this version is in progress, but the first goal is to get the latest stable version from the 7.14 branch into the ports tree. This project is sponsored by anyMOTION GRAPHICS GmbH, D?seldorf, Germany. Open tasks: 1. Closing all the PRs of the dependencies 2. Committing the GitLab port itself 3. Updating the port to the latest version of the 8.x branch __________________________________________________________________ GNOME on FreeBSD Links FreeBSD Gnome website URL: http://www.FreeBSD.org/gnome Devel repository URL: https://github.com/freebsd/freebsd-ports-gnome Upstream build bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/using-gnome.html Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. This quarter, GNOME 3.16 and MATE 1.10 were committed to the ports tree, followed up by some incremental improvements. A chapter covering the use of USE_GNOME within individual ports' Makefiles was written and committed to the Porter's Handbook. GNOME 3.18 has been ported. There are, however, some issues that need to be resolved before it can be committed to the ports tree. Open tasks: 1. The FreeBSD GNOME website is stale. Work is under way to improve it. 2. Please give feedback on and suggest improvements to the chapter in the Porter's Handbook on the USE_GNOME functionality. 3. Continue working on investigating the issues blocking GNOME 3.18. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD website URL: https://freebsd.kde.org/ KDE ports staging area URL: https://freebsd.kde.org/area51.php KDE on FreeBSD wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD mailing list URL: https://mail.kde.org/mailman/listinfo/kde-freebsd Development repository for integrating KDE 5 URL: http://src.mouf.net/area51/log/branches/plasma5 Contact: KDE on FreeBSD team Overall, we have updated the following ports this quarter: * CMake 3.3.1 (r396266) * Qt 4.8.7 (r397043) * QtCreator 3.5.0 (r395935) * Fixed some dependencies, typos and plists in Qt5-ports (r396044-r396047), spotted by Ralf Nolden In our development repository, we have done the following work: * Updated PyQt-bindings for qt4 to 4.11.4 and added qt5 bindings 5.5, contributed by Guido Falsi, and modified by Tobias Berner (area51) * Updated qt5 to 5.5.0. Ralf Nolden has contributed a handful of useful new ports, for example lang/qt5-l10n (area51/qt-5.5) * The plasma5 branch has been kept up to date with KDE's upstream and contains ports for Frameworks 5.14.0, Plasma Desktop 5.4.2 and Applications 15.08.1 (area51/plasma5) Open tasks: 1. Work on getting the stuff from plasma5 branch into ports. (This is a major update to nearly all KDE applications, so testers are very welcome.) 2. Finalize the work on PyQt5. 3. Port qt5-webengine. Qt-5.5 will probably be the last release shipping a www/webkit-qt5 port. __________________________________________________________________ Node.js Modules Links Node.js modules URL: https://www.assembla.com/spaces/cozycloud/subversion/source Pre-draft documentation URL: https://people.FreeBSD.org/~olivierd/porters-handbook/using-nodejs.html Contact: Olivier Duchateau Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. The goal of this project is to make it easy to install the modules available in the npm package registry. Currently, the repository contains more than 100 new ports, in particular: * CoffeeScript (a programming language that transcompiles to JavaScript) * node-gyp (allows building Node.js addons, often written in C or C++) * Request (a simplified HTTP client) We have also written several helpers for the porting, available in our experimental repository. Open tasks: 1. Bring in grunt.js (and modules), the JavaScript task runner. 2. Put more effort into support for node-gyp in the USES framework __________________________________________________________________ Ports Collection Links Ports Collection website URL: http://www.FreeBSD.org/ports/ Contributing to the Ports Collection URL: https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html Port Monitoring service URL: http://portsmon.FreeBSD.org/index.html Team Website URL: http://www.FreeBSD.org/portmgr/index.html Blog URL: http://blogs.freebsdish.org/portmgr/ Twitter feed URL: http://www.twitter.com/freebsd_portmgr/ Facebook page URL: http://www.facebook.com/portmgr Google+ page URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Ports Management Team As of the end of Q3 the ports tree holds just over 25,000 ports, and the PR count is above 2,000. The summer period saw less activity on the ports tree than during the previous quarter, with fewer than 7,000 commits performed by 120 active committers. Unfortunately, the number of problem reports closed also decreased significantly, with fewer than 1,500 problem reports fixed during Q3. In Q3 several commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (fluffy), or on committer's request (xmj, stefan, brix). One new developer was granted a ports commit bit (Jason Unovitch junovitch@FreeBSD.org), and one returning committer (Babak Farrokhi) had his commit bit reinstated. On the management side, no changes were made to the portmgr team during Q3. On the QA side, 25 exp-runs were performed to validate sensitive updates or cleanups. Amongst those, the noticeable changes are the update to pkg 1.6, the automake14 removal, and several important port updates such as doxygen to 1.8.10, gnome3 to 3.16, cmake to 3.3.1, and the Qt4 ports to 4.8.7. The default jdk was also set to openjdk8. Some infrastructure changes included the addition of new options helpers: opt_VARS, opt_VARS_OFF, opt_IMPLIES, and opt_PREVENTS. Some macros were also removed, such as UNIQUENAME and LATEST_LINK. Open tasks: 1. We would like to remind everyone that the ports tree is built and run by volunteers, and any help is greatly appreciated. This is more important than ever, since the number of problem reports cannot seem to stop increasing. So if you use ports or packages, please consider jumping in and helping! This is also true for existing porters: it would be great if you would consider the next step, which is to share your knowledge and mentor someone more junior with the ports tree internals. And if you already do these tasks, many thanks to you! __________________________________________________________________ Ports on PowerPC Contact: Alexey Dokuchaev The Ports Collection typically receives less attention on Tier-2 architectures than on Tier-1 architectures, although several build-runs were performed at various points in the past, and broken ports were marked as such at those times. Some of the Tier-2 platforms, such as PowerPC and ARM, have improved considerably recently, both on FreeBSD's and the compilers' sides, but as the tree is not rebuilt on the cluster very often, it was suspected that many ports are marked BROKEN while they in fact now build and run correctly. Over the past several weeks, 26 ports that were indeed broken on at least PowerPC had been fixed, 58 ports that were incorrectly marked as broken (leftovers from the old times) were marked as working, and fewer than 40 ports still have issues requiring further work. Open tasks: 1. The Ports Collection could benefit a lot from more frequent sweeps targeting Tier-2 systems. 2. Recent work on QEMU-backed emulators and the much-anticipated cross-building of ports are essential pieces to bring FreeBSD packages on par with the base system's support, architecture-wise. __________________________________________________________________ Xfce on FreeBSD Links FreeBSD Xfce Project URL: https://wiki.FreeBSD.org/Xfce FreeBSD Xfce Repository URL: https://www.assembla.com/spaces/xfce4/subversion/source Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. During this quarter, the team has kept these applications up-to-date: * science/xfce4-equake-plugin 1.3.8 * sysutils/xfce4-power-manager 1.5.2 * x11/libexo 0.10.7 * x11/xfce4-embed-plugin 1.6.0 * x11/xfce4-verve-plugin 1.1.0 * x11/xfce4-whiskermenu-plugin 1.5.1 * x11-wm/xfce4-desktop 4.12.3 * www/midori 0.5.11 We also follow the unstable releases (available in our experimental repository) of: * sysutils/xfce4-panel-switch 1.0.2 (utility to backup panel layouts) * x11/xfce4-dashboard 0.5.1 In the trunk branch, x11-wm/xfce4-panel contains a patch to support sysutils/xfce4-panel-switch (available through the panel preferences). Open tasks: 1. Test the new stable release of GLib 2.46.x with the kqueue/kevent backend enabled (it was disabled with revision r393663). Currently several features are broken, especially in Thunar, xfce4-panel, and Xfdashboard. __________________________________________________________________ PO Translation Project Links PO Translations URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/fdp-primer/po-translations.html German translation of the Leap Seconds article URL: https://www.FreeBSD.org/doc/de_DE.ISO8859-1/articles/leap-seconds/ Dutch translation of the Explaining BSD article URL: https://www.FreeBSD.org/doc/nl_NL.ISO8859-1/articles/explaining-bsd/ FreeBSD Translators mailing list URL: https://lists.FreeBSD.org/pipermail/freebsd-translators/ Contact: FreeBSD Documentation Team Contact: FreeBSD Translators Contact: Warren Block The FreeBSD documentation translation process has been in need of modernization for quite some time. The existing process was just too difficult for translators to keep translations up to date. With help from Benedict Reuschling, Shaun McCance, Ryan Lortie, Hiroki Sato, and many others, the availability of a new PO translation system was announced in August. PO translations handle most of the overhead of the translation process. Translators do not have to keep track of commits to the upstream English version. The actual work of translating is quicker and easier. PO editors show how much of the document has been translated. If a translation is already available for a given string, it can be easily reused. Early testing has been very successful. Most issues involve discovering and documenting the new processes rather than fixing bugs. New translations of English documents have already been committed. There will certainly be additional changes and improvements, but the system works. We will continue to discover how to share work between translation teams and the project as a whole. This work will be much easier now that the initial hurdle of being able to use PO software has been passed. Open tasks: 1. Continue testing. The system is new to us and there are bound to be bugs and situations with unexpected results. 2. Improve documentation on using the new PO translations. Much of this involves things that rarely happened with the old system, like adding a completely new language directory. 3. Add new translations for existing documents. There is much less work to create and update a translated document now. Existing and new translators are working on adding and updating translations of the English documentation. 4. Figure out how to generate and share translation memory with other members of a language team or translators outside the team. 5. Test new PO editors like Pootle and Virtaal. 6. Determine a method to allow translators commit access for translations. 7. Develop and test code to translate manual pages. __________________________________________________________________ Website CSS Update Links FreeBSD Main Site URL: https://www.FreeBSD.org/ Contact: Warren Block The FreeBSD website has remained essentially unchanged in appearance for many years. Like other legacy systems, it is difficult to change. It is heavily used and therefore subject to non-trivial bikeshedding. The CSS shrunk the reader's font from the size they had requested. It specified hardcoded font and object sizes in pixels. On wide monitors, only the middle third of the screen was used. Hardware has changed from what existed when this version of the site was created. Screens have become larger and wider, and increased in resolution at the same time. It was time for a change. Font sizes were set to percentages, with none smaller than 100%. The width of the main box was changed to 90%. Other small adjustments were added. These limited changes produced a rendered site that better respects the reader's settings, is much easier to read, and shows more information. Although no content changed, the appearance was so different that some viewers thought we had redesigned the site. It is gratifying to know that so many people are using it. We would also like to thank people for the response, which was overwhelmingly positive and hardly bikesheddy at all. Open tasks: 1. Fix other outdated assumptions in the CSS. Alternately, rework the entire site. However, that is a much more complex and ambitious project than it might seem. __________________________________________________________________ Allwinner A10/A20 Support Links Wiki page URL: https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner Contact: Luiz Otavio O Souza Contact: Pratik Singhal The Allwinner A10 and A20 chips are ARM CPUs found in increasingly common development boards and other devices, such as the Cubieboard/Cubieboard 2 and the Banana Pi. With the end of a GSoC project by Pratik Singhal, our A10 and A20 support has improved. Pratik helped with the implementation and testing of the SD card and SATA support for the Allwinner chips. Luiz Otavio O Souza added support for the dwc network interface on the A20, which is capable of gigabit speeds. Glen Barber kindly added support for official FreeBSD images for Cubieboard 2 and the Banana Pi. This project is sponsored by Google Summer of Code 2015 (partly). Open tasks: 1. Some drivers are still missing: audio, video/HDMI/framebuffer, IR, I2C, SPI, PWM. 2. Fix if_dwc for better performance. __________________________________________________________________ mtree Parsing and Manipulation Library Links Wiki page URL: https://wiki.FreeBSD.org/SummerOfCode2015/mtreeParsingLibrary Contact: Michal Ratajsky Contact: Brooks Davis FreeBSD includes several programs that work with file system hierarchy descriptions in the mtree(5) format. These descriptions, also called specifications, have a broad range of uses, from automatically creating directory structures to security auditing. Each of the programs, namely mtree, bsdtar, install, and makefs, has its own implementation of the mtree format. This not only adds maintenance overhead, but also makes interoperability difficult, as each of the implementations only supports a limited subset of the format. The goal of this project was to create a new libmtree library, implementing everything the mtree format has to offer, and wrapping it with an expressive API which all the listed programs can use. We also wanted libmtree to be portable, as one of the major users of the mtree format is libarchive, the library implementing most of bsdtar. Currently, the library is functionally complete, ready to be downloaded and receive everyone's attention. We have also decided to bundle the mtree program along with it. The bundled mtree has also been modified for better portability. The project included modifying libarchive, install and makefs to use libmtree. These modified versions are also available. Please see the Wiki page for more information, download locations, and an example of using the libmtree API. This project is sponsored by Google Summer of Code 2015. Open tasks: 1. Test and review the library code and API, and the modifications made to the programs. 2. Fix the known problems that are mentioned on the Wiki page. __________________________________________________________________ Multiqueue Testing Links Project Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/MultiqueueTestingProject Contact: Tiwei Bie Contact: Hiren Panchasara Contact: George Neville-Neil Contact: Robert Watson The aim of this project is to design and implement infrastructure to validate that a number of the network stack's multiqueue behaviours are functioning as expected. At present, most of this project has been implemented. It mainly consists of two parts: 1. A general mechanism to collect the per-ring per-cpu statistics that can be used by all NIC drivers, and extensions to netstat(1) to report these statistics. 2. A suite of network stack behavior testing programs that consists of: + a virtual multiqueue ethernet interface (vme) + a UDP packet generator based on vme + a UDP server based on socket(2) + a TCP client based on lwip and vme + a TCP server based on socket(2) However, it still needs further refinements to make it suitable for committing to FreeBSD head. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ Update Ficl in Bootloader Links Wiki Page URL: https://wiki.FreeBSD.org/SummerOfCode2015/UpdateFiclInBootloader Contact: Colin Lord The FreeBSD bootloader has used Ficl 3 for quite some time. This project was intended to update the version of Ficl in use to Ficl 4. Ficl 4 is not only faster but also has a smaller memory footprint, both being important advantages for a bootloader. As part of the Google Summer of Code program, I worked on importing the Ficl 4 sources to get a bootloader running Ficl 4. The first half of the summer consisted of setting up my test environment, as well as arranging the sources in the tree properly and modifying the build files to point to the new locations. Once that was complete, the sources had to be modified to build correctly and to add back in some of the FreeBSD-specific parts from Ficl 3. Unfortunately, after all those tasks were completed, a few bugs in the Ficl project were discovered that delayed the bootloader update, so it is not finished. The Illumos project has faced similar issues with Ficl 4 so I received some good tips from them, but since school has started back up I have not been able to put much work into fixing the bugs. This project is sponsored by Google Summer of Code 2015. __________________________________________________________________ The FreeBSD Foundation Links Foundation website URL: http://www.FreeBSDFoundation.org/ FreeBSD Journal URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Anne Dickison and Deb Goodkin attended OSCON to promote FreeBSD. Robert Watson organized and ran the Cambridge FreeBSD Developer Summit 2015 ("BSDCam"). We provided travel grants to two FreeBSD developers to attend the summit. Three Foundation board/staff members attended too. George V. Neville-Neil attended the ARM Partner Meeting where he met with 15 silicon and systems vendors to present the unique traits and qualities of FreeBSD and work on setting up partnerships with the companies building and deploying ARM hardware. George and Robert Watson collaborated in Cambridge on developing further FreeBSD-based teaching material at undergraduate and masters levels. Part of this project was funded by the Foundation. George planned and ran the DevSummit at vBSDCon 2015. We were proud to be a sponsor of vBSDCon 2015, Sept 11-13 in Washington DC. George V. Neville-Neil and Ed Maste presented "Supporting a BSD Project" at the conference. Dru Lavigne, Glen Barber, George V. Neville-Neil, and Ed Maste attended and represented the Foundation at both vBSDCon and the FreeBSD Developer Summit that preceded it. We had many people stop by our table to make a donation, and it was another great opportunity to talk and work with people face-to-face. Cheryl Blain and John Baldwin promoted the Foundation and FreeBSD at the SNIA 2015 Storage Developer Conference, in Santa Clara, California, Sept 21-24. The Foundation was also a sponsor. We sponsored Andy Turner to attend Linaro Connect in San Francisco, Sept 21-25. Ed Maste, our project development director, attended the X.Org Developer's Conference (XDC) in Toronto, Ontario. We sponsored the 2015 nginx Conference and sent FreeBSD community member John Baldwin. George Neville-Neil continued planning the 2015 Silicon Valley Vendor Summit, including securing the venue. Benedict Reuschling and Erwin Lansing helped plan and organize the EuroBSDCon FreeBSD Developer Summit. This included setting up the working groups, securing the venue, and getting the T-shirts made. Benedict helped organize, and he and Dru Lavigne participated in the FreeBSD Hackathon in the Linuxhotel in Essen, Germany. It was a successful weekend of fixing bugs and collaborating with others. Dru Lavigne taught a FreeBSD class in Berlin, Germany July 29-31. We were a sponsor of womENcourage 2015, in Uppsala Sweden, Sept 24-26. Dru was the moderator for a panel on Open Source as a Career Path. All the panelists were FreeBSD contributors including Dan Langille, Allan Jude, Benedict Reuschling, and Deb Goodkin. We also had a table at the job fair and talked to a lot of students and professors about the benefits of working on FreeBSD as an alternative to an internship, teaching about FreeBSD in university classes, and hosting FreeBSD events at their schools. Dan taught a workshop on How to Contribute to an Open Source project. Deb participated in this workshop and started a discussion on offering a similar workshop at BSD and non-BSD conferences. The workshop would be titled "How to Contribute to FreeBSD", and participants would learn how to contribute documentation to the Project. We continued to publish our monthly newsletters, keeping the community informed on what we are doing, including event recaps, testimonials, project updates, and upcoming events. We received testimonials from Microsoft, NYCBus, and ScaleEngine. We also continued to approach companies to provide us with testimonials to help promote their use of FreeBSD. Anne Dickison rebooted the Faces of FreeBSD series and is working with FreeBSD contributors on writing their stories. She continued to produce more FreeBSD Swag and literature to promote FreeBSD, as well as advocating for FreeBSD over our social channels and with new partnerships. We reached our 2015 goal of 10,000 FreeBSD Journal subscribers, and we published a new Open Journal article on our website, to help promote the Journal. We also started offering a new subscription bundle, where you can buy all the 2014 issues. The July/August issue was published. Justin T. Gibbs began teaching a semester-long FreeBSD class at a middle school in Boulder, Colorado. We are using the BeagleBone Black (BBB) to run FreeBSD connected to Macs and PCs. We have received a lot of support, both internally, and from the Project, to get the FreeBSD images to work on the BBB with the Macs and PCs. It has been a great collaborative effort with community members, and this will help future classes in being able to support inexpensive platforms for teaching FreeBSD. Work continued on creating a FreeBSD curriculum for a half day workshop. Hopefully this will be available in late Spring. We provided legal support for the Project including granting trademark permission for some users and companies who requested permission to put the FreeBSD logo on their websites and marketing literature. We met with commercial users to get their input on what they would like to see supported in FreeBSD. We also do this to help connect FreeBSD developers with commercial users to help facilitate collaboration. FreeBSD Foundation employee and Release Engineer Glen Barber was extremely busy during this quarter, working on a number of exciting areas of the FreeBSD Project. Some of the highlights include: * Code cleanup and bug fixes to several parts of the release build code, and finishing adding support for automatically uploading cloud provider images, which was merged to the stable/10 branch before the code freeze. The 10.2-RELEASE cycle spanned a 9-week timeframe overall, starting from the code slush. * With the FreeBSD Release Engineering Team, released two BETA builds and three RC builds for the 10.2-RELEASE cycle, with the final release announced mid-August, two weeks ahead of the original schedule. * With the FreeBSD Cluster Administrators Team, assisted with a number of general updates and enhancements to the FreeBSD infrastructure. __________________________________________________________________ ZFSguru Links Home page URL: http://zfsguru.com Forum post on Gnome 3 debugging URL: http://zfsguru.com/forum/zfsgurudevelopment/1038 Contact: Jason Edwards ZFSguru started as a front-end to ZFS but has since grown into a multifunctional server appliance with its own unique features. While the project is still in early development, it already offers multiple unique features not found in other projects. Unlike similar projects, nothing is stripped away from the base operating system, meaning ZFSguru behaves as a normal FreeBSD installation and thus is very versatile. The web-interface is designed to unite both novice and advanced users, providing both very easy to use basic functionality as well as features to be appreciated by more experienced users. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. On the 15th of August, version 0.3 of ZFSguru was released. Some highlights of the new version: * New build infrastructure allows for frequent releases of system images and services in a semi-automated way. * A new GuruDB database allows for a growing number of system images and servers, and provides good caching to accelerate pages. * The installation procedure was given a major overhaul. * In addition to the LiveCD, USB images are now available. The USB image supports both legacy MBR bootcode and UEFI boot. * Many libraries in the web-interface have been overhauled, in addition to many other additions to the web interface. * Many improvements were made to optional add-on services, such as the new Gnome 3 graphical environment. Other progress made in the months July, August, and September: * System image builds 001, 002, 003, and 004 have been released for all supported branches: 10.0, 10.1, 10.2, 10.3 (-STABLE), and 11.0 (-CURRENT). * Work on the 0.4 web-interface has started, which focuses on improving network support in the web-interface. * Work on a new visual theme for the web-interface has started. The new interface is likely to be included in the upcoming 0.4 release. * A new master server is being prepared, which is likely to be operational in December. * A new website is being worked on, to be launched the first of January, 2016. Open tasks: 1. The new Gnome 3 desktop does not work for everyone and still has issues. Anyone capable of diagnosing these issues can give the Gnome 3 LiveCD a try. Please see the linked forum thread for more information. 2. Several ports fail to compile with our own build infrastructure, and require bug reports in order to get them fixed upstream. 3. A 'State of the Project 2015' is due in Q4, providing an overview for future development of the project. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJWLZXJAAoJECjZpvNk63US9QkMIIp+DgtLqA1bt02ldMvtOQi8 UX2TkKTHJrJLtSl5Iv5JUJ9IaZR1gYRkTYS0vINCOMXwTsp3y+xb6ESiR5H0iJRF Jnw5gy8HBi8ZY+MLasFG/KdYTcIUVcfUxloak96FFDOA23ru+LWy4t8YxMMiBIde xnebJXxoKo1RxCePbbAyS6vri/jvP9KZth8rE0V8CgUbFo3IuROMrvYS7jVhzhrL yOJn2vER6LXEM8j11c8RYMNOtSrwCLrO2CI5u2frTAvPXEXPLx4WSX/Gw0R3mVS/ l12bjBK3i89q2XWiiglbXiMxK3JBHKtIZZowHwHCCwhgd2cxEHiP3XaKFtxFlQ1c Isk4hHp/rbzozdG6HX9m52Qg90ieQXjcCoJ46apV50VLK4eSe+WdD1/mhC8VE7GU o3Ako+zJlUnW9SKY82YG2ENQFqa2/CPEDM6N/l7cFqD9ixaNLWBjR1fJ3b2cvKiS m3nbMHPeJnNTMo83l9RNoZm0jGvNLikW+f47yjuoTXbFb54= =0xZT -----END PGP SIGNATURE----- From owner-freebsd-hackers@freebsd.org Mon Oct 26 13:28:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BF53867F for ; Mon, 26 Oct 2015 13:28:46 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B10A1AA7 for ; Mon, 26 Oct 2015 13:28:46 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by vkfw189 with SMTP id w189so98138432vkf.2 for ; Mon, 26 Oct 2015 06:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=DDR1UszZgSiuG+A8rZ7VzNA23D97hDW4rqIiEqcq0mE=; b=ZLUY/qYE3ikVDO1+2xdAOZh5Ns7NwTZECw4pOq1xSjwW5EeTDKm/JPjPHBIe5ABPAI Wa5Fuwf/ZlStVPQ+L1a5nQYl6gXJnoutg9IAOc/YIsXUy75sN3/9b6foTla4rkprVuGU MkTImz9N0Wpl267rX7HkT0zKE1xxgpWLeyXN9xWbb715YAHaZ+SsVEQRjPSEGIlCO2GW nGnrr7m1DIrNe+qqz8XJY759MfkytCTwDFV8fVzEh8SneUxgxy/ZOpFX1GomcZoXNhSx hSPM7tV4Un0Gk6RAjv61o71gQA4u9qHkJWVnWwdQdC3wSfF9H+dPs7SC/lB7kVNCeZUT okNw== X-Received: by 10.31.135.12 with SMTP id j12mr21014103vkd.73.1445866124942; Mon, 26 Oct 2015 06:28:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.66.66 with HTTP; Mon, 26 Oct 2015 06:28:15 -0700 (PDT) From: Jia-Shiun Li Date: Mon, 26 Oct 2015 21:28:15 +0800 Message-ID: Subject: vmtotal consumes significant portion of cpu cycles To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 13:28:46 -0000 Hi all, I noticed that 'sysctl -vm 1' consumes about 5% cpu time on a machine with 2x 6-core Xeon E5v3 and 64GB memory. That's a lot for a monitoring tool. After digging a while I found that it is vmtotal() in kernel that consumes major cycles. When memory usage is high the cost of vmtotal() rises too. It is reproducible with sysctl when memory utilization is high: % time repeat 100 sysctl vm.vmtotal > /dev/null 0.055u 8.102s 0:08.19 99.5% 31+175k 0+0io 0pf+0w % top last pid: 40272; load averages: 0.32, 4.74, 8.01 up 3+01:19:54 17:23:59 58 processes: 1 running, 57 sleeping CPU: 0.1% user, 0.0% nice, 1.6% system, 0.1% interrupt, 98.3% idle Mem: 4509M Active, 52G Inact, 2819M Wired, 1572M Buf, 2930M Free Swap: 3598M Total, 3598M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 46841 root 30 20 0 9248M 7930M kqread 9 20.8H 11.88% bhyve 49914 jsli 1 23 0 19320K 3884K select 5 134:08 4.79% systat In FreeBSD source tree systat and vmstat are major user. Other tools like bsnmpd may use it too via sysctl. I don't have idea yet how this can be improved. Shall I create a bug to keep track of it? -Jia-Shiun From owner-freebsd-hackers@freebsd.org Mon Oct 26 15:56:50 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A66288676 for ; Mon, 26 Oct 2015 15:56:50 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 84BD01C13 for ; Mon, 26 Oct 2015 15:56:50 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 66ED6D001 for ; Mon, 26 Oct 2015 15:56:44 +0000 (UTC) Subject: Re: vmtotal consumes significant portion of cpu cycles To: freebsd-hackers@freebsd.org References: From: Allan Jude Message-ID: <562E4D3F.8080204@freebsd.org> Date: Mon, 26 Oct 2015 11:56:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uI6NcDOoMFCR8POgvpaSlpLiCWWjfL7H3" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 15:56:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uI6NcDOoMFCR8POgvpaSlpLiCWWjfL7H3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-10-26 09:28, Jia-Shiun Li wrote: > Hi all, >=20 > I noticed that 'sysctl -vm 1' consumes about 5% cpu time on a machine w= ith > 2x 6-core Xeon E5v3 and 64GB memory. That's a lot for a monitoring tool= =2E >=20 > After digging a while I found that it is vmtotal() in kernel that consu= mes > major cycles. When memory usage is high the cost of vmtotal() rises too= =2E It > is reproducible with sysctl when memory utilization is high: >=20 > % time repeat 100 sysctl vm.vmtotal > /dev/null > 0.055u 8.102s 0:08.19 99.5% 31+175k 0+0io 0pf+0w >=20 > % top > last pid: 40272; load averages: 0.32, 4.74, 8.01 up 3+01:19:54 > 17:23:59 > 58 processes: 1 running, 57 sleeping > CPU: 0.1% user, 0.0% nice, 1.6% system, 0.1% interrupt, 98.3% idle > Mem: 4509M Active, 52G Inact, 2819M Wired, 1572M Buf, 2930M Free > Swap: 3598M Total, 3598M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU > COMMAND > 46841 root 30 20 0 9248M 7930M kqread 9 20.8H 11.88% b= hyve > 49914 jsli 1 23 0 19320K 3884K select 5 134:08 4.79% s= ystat >=20 >=20 > In FreeBSD source tree systat and vmstat are major user. Other tools li= ke > bsnmpd may use it too via sysctl. >=20 > I don't have idea yet how this can be improved. Shall I create a bug to= > keep track of it? >=20 >=20 > -Jia-Shiun > _______________________________________________ > 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 In the first 2 references you say 'sysctl', do you mean 'systat' in all instances? --=20 Allan Jude --uI6NcDOoMFCR8POgvpaSlpLiCWWjfL7H3 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) iQIcBAEBAgAGBQJWLk1CAAoJEBmVNT4SmAt+Lb0QAI5UjbsmNPLso7XGNTZenMLR yFGdVMdNYq+AcjP32PlKWUDrqdu/psHRgadX3PEpCrHZyfvaJUf7d7avzMK4/c7+ lLV953fn8B1ZWm4H45Paa7rG7UUB5Lj5iEhdQiCeP/WC1O5YbW6o1s2iOhL1E6fE uwIqO3v7wLTz48cRKAWnNRP3TxaB3NO/DroEMI5N8/IaQFV2yFS/oeue9TSo89lN j92E+9n6aOlJIYbWb0n+20F4m6H7pEB8dpCLcSi63J+kLjU15HHgk/M7lkf3Au7t lkbASff7xTnEs7R5dZZxtoZX1i0CWyl2YR3CoYr9gOcmeBTxCkd/OZyvnOx5yjed ziCQwCfi5oois/2flL4xQBydRg1ACVXNShWvTC9w/BvbR/FAoipOik2Rv0XP4dJJ cC02uBcFzJv605EPvlxCA9w0xk/QlbbuAdecduRrUm8QLTuV+g3AXUb4RTkbS/SA DUlmXub3EsyrRPCVsf+eOuVwMlvkvg7itD810MATnUG8dyPPsc3BffmPR2uIf9d7 7PP7QvWG7dKcwOc95+CXHaM3Z24eqBBFgBPt9ycLcaLQ6DDvecQKGv/XqtBZoi6P QTe1rjRD2+cKlMBQXCC+Te94evChsUvdkL0/3S00LprYQoB6YZPkJdSDEaiJDOX+ BDPUnHE/lK+YqnrptAx5 =JsuQ -----END PGP SIGNATURE----- --uI6NcDOoMFCR8POgvpaSlpLiCWWjfL7H3-- From owner-freebsd-hackers@freebsd.org Mon Oct 26 15:33:54 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71274A1D7F2 for ; Mon, 26 Oct 2015 15:33:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E2231839 for ; Mon, 26 Oct 2015 15:33:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iody8 with SMTP id y8so34517532iod.1 for ; Mon, 26 Oct 2015 08:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D1jreURCOLYzIYvYqm5kflvKiG/iSDB6eGOHN1oLcus=; b=0Zxa/q6kF6wE+z4Bfz6/Xx8uVzELtIHJpncki3We5iUUw4Nbp4wQoWuhJZ57Q3VwfI 8S8bGfiumxIeqPqBOVZZvZ+RDzKgIy6oWU0rJmGZzwi4dKHANZYFIGPfRzLMYEbnXT3V 4wHbp/nboOI3wYlgKY0DCqoKwnN4Npyw8OrfzbnOUcTraU73HPYALFa4GO/mO6s+IFlQ cmNChoKi2q8ybNFU815vE3gBv1PhVIhPPMVngHSj3FPWXZoE99nGuUyFEwdYbKw28oun WBg49H01aXwIaIGdandxlUOPBDs98+8DqIjG1m/pMeNgrSFCGk3u+z/1403ogJdg5rfd 98fw== MIME-Version: 1.0 X-Received: by 10.107.46.228 with SMTP id u97mr12418434iou.165.1445873633558; Mon, 26 Oct 2015 08:33:53 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 08:33:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2015 08:33:53 -0700 Message-ID: Subject: Re: vmtotal consumes significant portion of cpu cycles From: Adrian Chadd To: Jia-Shiun Li Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 26 Oct 2015 16:22:20 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 15:33:54 -0000 hiya, yes, please do. I recall there's some global vm lock and big hash/list walk involved when vmtotal() is called. :( -a On 26 October 2015 at 06:28, Jia-Shiun Li wrote: > Hi all, > > I noticed that 'sysctl -vm 1' consumes about 5% cpu time on a machine with > 2x 6-core Xeon E5v3 and 64GB memory. That's a lot for a monitoring tool. > > After digging a while I found that it is vmtotal() in kernel that consumes > major cycles. When memory usage is high the cost of vmtotal() rises too. It > is reproducible with sysctl when memory utilization is high: > > % time repeat 100 sysctl vm.vmtotal > /dev/null > 0.055u 8.102s 0:08.19 99.5% 31+175k 0+0io 0pf+0w > > % top > last pid: 40272; load averages: 0.32, 4.74, 8.01 up 3+01:19:54 > 17:23:59 > 58 processes: 1 running, 57 sleeping > CPU: 0.1% user, 0.0% nice, 1.6% system, 0.1% interrupt, 98.3% idle > Mem: 4509M Active, 52G Inact, 2819M Wired, 1572M Buf, 2930M Free > Swap: 3598M Total, 3598M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU > COMMAND > 46841 root 30 20 0 9248M 7930M kqread 9 20.8H 11.88% bhyve > 49914 jsli 1 23 0 19320K 3884K select 5 134:08 4.79% systat > > > In FreeBSD source tree systat and vmstat are major user. Other tools like > bsnmpd may use it too via sysctl. > > I don't have idea yet how this can be improved. Shall I create a bug to > keep track of it? > > > -Jia-Shiun > _______________________________________________ > 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 Oct 27 01:34:37 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07FB5A1C23A for ; Tue, 27 Oct 2015 01:34:37 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B01421B45; Tue, 27 Oct 2015 01:34:36 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by vkex70 with SMTP id x70so110619351vke.3; Mon, 26 Oct 2015 18:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1aSPuXp9tsOpFyn0iYM2Il/2PBwZBz5lo/huToee8Yk=; b=GRBRW+FSkgPSd+bjuw9jl6lWf0LBiQkQ4tn6woOestRPIz1O6dh2A4RzoqEswDOKJl MMwYPTXhuvr+briYzc/VnGhSnSRwr7+tEISKvHCgv8X3Y63OtS/DMnGT6fsaSQsGTmSn elJfCBX/vvZVTbILXOIE722jH74+8ksM5Y1BRsDzOB91Bqd6hsKWFWJj41aEaBTZSQFw 0LMVkJADF5/G7CNC7GBe4KV9Tg2VOmXhmaTvdA34Wh5Z5cxhhM5Nd4oXHAlHV+CU2bVb 9j48hkoIxSe1grvCHhW1DM3YBbUOcI2H1rzbGPK1uLYbC8LHtg+SgtWuKZVyNx4UraEB KWxg== X-Received: by 10.31.148.206 with SMTP id w197mr27568871vkd.100.1445909675599; Mon, 26 Oct 2015 18:34:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.66.66 with HTTP; Mon, 26 Oct 2015 18:34:06 -0700 (PDT) In-Reply-To: <562E4D3F.8080204@freebsd.org> References: <562E4D3F.8080204@freebsd.org> From: Jia-Shiun Li Date: Tue, 27 Oct 2015 09:34:06 +0800 Message-ID: Subject: Re: vmtotal consumes significant portion of cpu cycles To: Allan Jude Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 01:34:37 -0000 On Mon, Oct 26, 2015 at 11:56 PM, Allan Jude wrote: > On 2015-10-26 09:28, Jia-Shiun Li wrote: > > Hi all, > > > > I noticed that 'sysctl -vm 1' consumes about 5% cpu time on a machine > with > > 2x 6-core Xeon E5v3 and 64GB memory. That's a lot for a monitoring tool. > > > > After digging a while I found that it is vmtotal() in kernel that > consumes > > major cycles. When memory usage is high the cost of vmtotal() rises too. > It > > is reproducible with sysctl when memory utilization is high: > > > > % time repeat 100 sysctl vm.vmtotal > /dev/null > > 0.055u 8.102s 0:08.19 99.5% 31+175k 0+0io 0pf+0w > > > > % top > > last pid: 40272; load averages: 0.32, 4.74, 8.01 up 3+01:19:54 > > 17:23:59 > > 58 processes: 1 running, 57 sleeping > > CPU: 0.1% user, 0.0% nice, 1.6% system, 0.1% interrupt, 98.3% idle > > Mem: 4509M Active, 52G Inact, 2819M Wired, 1572M Buf, 2930M Free > > Swap: 3598M Total, 3598M Free > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU > > COMMAND > > 46841 root 30 20 0 9248M 7930M kqread 9 20.8H 11.88% > bhyve > > 49914 jsli 1 23 0 19320K 3884K select 5 134:08 4.79% > systat > > > > > > In FreeBSD source tree systat and vmstat are major user. Other tools like > > bsnmpd may use it too via sysctl. > > > > I don't have idea yet how this can be improved. Shall I create a bug to > > keep track of it? > > > > > > -Jia-Shiun > > _______________________________________________ > > 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" > > > > In the first 2 references you say 'sysctl', do you mean 'systat' in all > instances? > > Allan, sorry the first one is typo and should be 'systat -vm', or 'systat -vmstat 1'. And the steps to reproduce the unexpected loading can be minimized to getting sysctl variable vm.vmtotal, which systat uses to get vm and process stats. -Jia-shiun. From owner-freebsd-hackers@freebsd.org Tue Oct 27 02:11:02 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88917A1CB5C for ; Tue, 27 Oct 2015 02:11:02 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 431DF1B76 for ; Tue, 27 Oct 2015 02:11:02 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by vkex70 with SMTP id x70so111009418vke.3 for ; Mon, 26 Oct 2015 19:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8fAUd7SVumeCPU8rHsbRweSZvDy0W5sPQ09mUZx6bnM=; b=sl3rg35f7mHJ1u9N4LmJYAePEsgaNBg6jqOLvrQAWiTF3bDBCxbErDG/tH7Qt7zFU+ 0qpiuuw57ouOX+83fPCA9y34WZbt0huGk8njMrg5mbc0ahGVJ3xNI3SWApzeb31LlWld lP7w19ieKOqs+CAKWSnj5V9tWvoVkT7f6Oh/6Y5lOopj2y6D/+rrDnnxDda2y8p/3t/A 41gAPHbgZNA7nlkHO6TFNN513b6/JQ8s3AAmp8ty8f2bZW8/nB4fbZdkZGbiwgFKFFAc l6bI+gFZL9G1QDBbWdp+JbwsWj0SPBBnZlOQ3ApjcY8VwZg5DhduFXewDPmMFuAFSydR jkZQ== X-Received: by 10.31.178.136 with SMTP id b130mr25689009vkf.109.1445911861175; Mon, 26 Oct 2015 19:11:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.66.66 with HTTP; Mon, 26 Oct 2015 19:10:31 -0700 (PDT) In-Reply-To: References: From: Jia-Shiun Li Date: Tue, 27 Oct 2015 10:10:31 +0800 Message-ID: Subject: Re: vmtotal consumes significant portion of cpu cycles To: Adrian Chadd Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 02:11:02 -0000 On Mon, Oct 26, 2015 at 11:33 PM, Adrian Chadd wrote: > hiya, > > yes, please do. I recall there's some global vm lock and big hash/list > walk involved when vmtotal() is called. :( > > Ok. Created as kern/204049. -Jia-Shiun. From owner-freebsd-hackers@freebsd.org Tue Oct 27 02:37:58 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 021FAA1D055; Tue, 27 Oct 2015 02:37:58 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0078.outbound.protection.outlook.com [207.46.100.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A42F1324; Tue, 27 Oct 2015 02:37:56 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1801.namprd08.prod.outlook.com (10.162.218.23) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 02:22:34 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 02:22:33 +0000 From: "Pokala, Ravi" To: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" CC: "scottl@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" Subject: Low-level trace-buffers in CAM Thread-Topic: Low-level trace-buffers in CAM Thread-Index: AQHREF5W2DCPOIdjUUGMRg6fRJs3ww== Date: Tue, 27 Oct 2015 02:22:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1801; 5:bosRlMo+g5nFNnVCd6VhdoW/KG7GwEI4ZwVLrSTlJyHnJ3YC6qs41zWI4lE8cdAeOibcn0ZaPsO7nwIWzyfuS/43d9PWVKB5CqZ8ci6TZ5+K9Zp0AMyptFIA0XVgDdYBijhaBdVBFLPLVpEL9wsA2g==; 24:LUH48ETZdrNqLm82CtRWwkez6aCQ9C3kNBIFOnZAc7Lxdcp6aaujf94y4Zs1uFGrZiEZ7i7Bkmift25i3RMig7wVrFV8CAwAQs4ZZ6N1b8s=; 20:kkNZ5fBwStuD6qepFW788DbYHqGCO3OhxX2Hm2mZRcpFXZfv4Nw9g92mDGvIREXd7Ek4XXNWKhHUSreX11I6Lw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1801; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:CY1PR08MB1801; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1801; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(164054003)(189002)(189998001)(66066001)(5004730100002)(33656002)(5007970100001)(2900100001)(5008740100001)(551934003)(5001960100002)(229853001)(10400500002)(77096005)(2501003)(102836002)(92566002)(5002640100001)(81156007)(5001770100001)(97736004)(83506001)(82746002)(450100001)(106116001)(87936001)(40100003)(122556002)(105586002)(575784001)(86362001)(36756003)(99286002)(106356001)(50986999)(101416001)(2201001)(54356999)(83716003)(4001350100001)(427584002)(21314002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1801; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 02:22:33.6380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1801 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 02:37:58 -0000 SGkgZm9sa3MsDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgaXMgYW4gdXBkYXRlZCByZS1zZW5kIG9mIGEgbWVz c2FnZSBJIG9yaWdpbmFsbHkgc2VudCBhYm91dCBhIHllYXIgYWdvLCBkdXJpbmcgTWVldEJTRCAy MDE0LiBBIGZldyBwZW9wbGUgZXhwcmVzc2VkIGludGVyZXN0IGluIHBlcnNvbiwgYnV0IG5vIG9u ZSBldmVyIGZvbGxvd2VkIHVwIG9uIHRoZSBsaXN0cy4gSSdtIGJyaW5naW5nIHRoaXMgdXAgYWdh aW4sIGluIHRoZSBob3BlcyB0aGF0IEkgY2FuIGdldCBzb21lIGZlZWRiYWNrIGJlZm9yZSAvIGR1 cmluZyBuZXh0IHdlZWsncyBEZXYvVmVuZG9yIFN1bW1pdC4gSSdtIENDaW5nIHNvbWUgZm9sa3Mg d2hvIGV4cHJlc3NlZCBpbnRlcmVzdCBhdCB0aGF0IHRpbWUsIGFuZCBzb21lIGZvbGtzIHRoYXQg SSB3YXMgdG9sZCB3b3VsZCBiZSBpbnRlcmVzdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBdCBQYW5hc2FzLCB3 ZSBmb3VuZCBpdCB1c2VmdWwgdG8gaGF2ZSBhIHRyYWNlIGJ1ZmZlciBmb3IgZWFjaCBBVEEgZHJp dmUgaW4gdGhlIHN5c3RlbSwgZm9yIGdhdGhlcmluZyBpbmZvcm1hdGlvbiBhYm91dCBjb21tYW5k IHNlcXVlbmNlcyBhbmQgbGF0ZW5jeS4gSSBpbXBsZW1lbnRlZCB0aGF0IGZ1bmN0aW9uYWxpdHkg Zm9yIG91ciBvbGQgNy1pc2ggQVRBIGRyaXZlciwgYW5kIGl0IHdvcmtzIHF1aXRlIHdlbGwsIHdp dGggZmFpcmx5IGxvdyBvdmVyaGVhZC4gKEkgcmFuIG91ciB1c3VhbCBzdWl0ZSBvZiBwZXJmb3Jt YW5jZSB0ZXN0cywgYW5kIGFueSBkaWZmZXJlbmNlcyB3ZXJlIGxvc3QgaW4gdGhlIG5vaXNlLikg VGhlc2UgdHJhY2VzIGFsbG93ZWQgdXMgdG8gY2FwdHVyZSBhbmQgcmVwbGF5IGFjY2VzcyBwYXR0 ZXJucyAodGhvdWdoIG9idmlvdXNseSBub3Qgd2l0aCB0aGUgc2FtZSBkYXRhKSwgYW5hbHl6ZSBh bmQgY29tcGFyZSBsYXRlbmN5LCBldGMuDQoNCkFzIFBhbmFzYXMgbW92ZXMgdG93YXJkIGEgbW9y ZSBtb2Rlcm4gYmFzZSwgd2Ugd2FudCB0byByZS1pbXBsZW1lbnQgdGhpcyBmdW5jdGlvbmFsaXR5 IGZvciBBVEEsIFNDU0ksIE5WTWUsIGV0Yy4gQW5kIHB1c2ggaXQgdXBzdHJlYW0sIG9mIGNvdXJz ZSEgOi0pDQoNCkZpcnN0LCBzb21lIGV4YW1wbGUgb3V0cHV0OyBJIHdyb3RlIGNvZGUgZm9yIHRo cmVlIGRpZmZlcmVudCBmb3JtYXRzOg0KICAtIFRoZSBiaW5hcnkgdHJhY2UgYnVmZmVyIGR1bXAN CiAgICBVc2VmdWwgZm9yIG1hbmlwdWxhdGluZyBpbiBDOyB0aGUgb3RoZXIgdHdvIGZvcm1hdHMg YXJlIHBvc3QtcHJvY2Vzc2VkIG91dCBvZiB0aGlzLCBhbmQgSSBhbHNvIHdyb3RlIGEgcmVwbGF5 IHV0aWxpdHkgYW5kIGEgYmFzaWMgc3RhdHMgYW5hbHl6ZXIgd2hpY2ggb3BlcmF0ZWQgb24gdGhl IGJpbmFyeSBkdW1wLg0KICAtIFRhYnVsYXIgaGV4DQogICAgVXNlZnVsIGZvciBwYXJzaW5nIHdp dGggc2NyaXB0czsgSSBuZXZlciBhY3R1YWxseSB1c2VkIHRoaXMgZm9ybWF0LCBidXQgaXQgd2Fz IHRyaXZpYWwgc28gSSBqdXN0IHdlbnQgYWhlYWQgYW5kIHdyb3RlIGl0Lg0KICAtIEh1bWFuLXJl YWRhYmxlDQogICAgVXNlZnVsIGZvciBleWViYWxsaW5nOyBvbiBtb3JlIHRoYW4gb25lIG9jY2Fz aW9uLCBJIHdhcyBhYmxlIHRvIHNlZSB0aGF0IEkgaGFkIG1pcy1hc3NlbWJsZWQgYSBjb21tYW5k IGluIHVzZXJzcGFjZSwgZXRjLg0KDQpUaGVzZSBleGFtcGxlcyBhcmUgYWN0dWFsbHkgcmVhbGx5 IGxvbmcgbGluZXM7IEkndmUgYnJva2VuIHRoZW0gdXAgYW5kIGluZGVudGVkIGZvciB0aGUgc2Fr ZSBvZiBlbWFpbDoNCg0KICAgICMgVGFidWxhciBoZXggZm9ybWF0LCBmb3IgdXNlIHcvIHNjcmlw dHMNCiAgICAjIFJlcXVlc3QgdGltZSAgICAgICBBVEEgcmVxdWVzdCBpbmZvcm1hdGlvbiAgIFJl c3BvbnNlIHRpbWUgICAgICAgIA0KICAgICAgICBBVEEgcmVzcG9uc2UgaW5mb3JtYXRpb24gIHN0 cy9lcnIgIGZsYWdzDQogICAgMTQ0NTgzOTc5MzAwMzczNyAgICAgYzggMDAwMCAwMDA0IDAwMDAw MDAwMmZhOCAxNDQ1ODM5NzkzMDAzODA2ICAgICANCiAgICAgICAgYzggMDAwMCAwMDA0IDAwMDAw MDAwMmZhOCA1MCAwMCAwMDAwMDA3ZA0KICAgIDE0NDU4Mzk3OTMwMDM4NzQgICAgIGM4IDAwMDAg MDAyMCAwMDAwMDAxMTNhYzggMTQ0NTgzOTc5MzAxMTU0MSAgICAgDQogICAgICAgIGM4IDAwMDAg MDAyMCAwMDAwMDAxMTNhYzggNTAgMDAgMDAwMDAwN2QNCiAgICAxNDQ1ODM5NzkzMDExNzk1ICAg ICBjOCAwMDAwIDAwMDggMDAwMDAwMTE4Y2E4IDE0NDU4Mzk3OTMwMTc3MDIgICAgIA0KICAgICAg ICBjOCAwMDAwIDAwMDggMDAwMDAwMTE4Y2E4IDUwIDAwIDAwMDAwMDdkDQogICAgMTQ0NTgzOTc5 MzAxNzgwOCAgICAgYzggMDAwMCAwMDgwIDAwMDAwMDExNzYyOCAxNDQ1ODM5NzkzMDE4OTc1ICAg ICANCiAgICAgICAgYzggMDAwMCAwMDgwIDAwMDAwMDExNzYyOCA1MCAwMCAwMDAwMDA3ZA0KICAg IDE0NDU4Mzk3OTMwMTkwNzkgICAgIGM4IDAwMDAgMDAyMCAwMDAwMDAxMTc3YTggMTQ0NTgzOTc5 MzAxOTY4NiAgICAgDQogICAgICAgIGM4IDAwMDAgMDAyMCAwMDAwMDAxMTc3YTggNTAgMDAgMDAw MDAwN2QNCg0KICAgICMgSHVtYW4tcmVhZGFibGUNCiAgICBGTEFHUyAgICAgICBSRVFVRVNUIFRJ TUUgICAgICAgICBSRVNQT05TRSBUSU1FICAgICAgICBFTEFQU0VEIFRJTUUgICAgICAgICANCiAg ICAgICAgUkVRVUVTVCBDT01NQU5EICAgICAgICAgICAgICAgICAgICAgICAgICBTVEFUVVMgICBF UlJPUiAgICANCiAgICAgICAgUkVTUE9OU0UgQ09NTUFORCAgICAgICAgICAgICAgICAgICAgICAg IA0KICAgIC0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0t LS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tIC0tLS0tLS0tIA0KICAgICAgICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgX19fX0MuLi4uX1YgMTQ0NTgzOTc5 MzAwMzczNyAgICAgMTQ0NTgzOTc5MzAwMzgwNiAgICAgNjkgICAgICAgICAgICAgICAgICAgDQog ICAgICAgIFJFQUQgRE1BIChMQkEgMTIyMDAgKyA0IHNlY3RvcnMpICAgICAgICAgX1JfU19fX18g X19fX19fX18gDQogICAgICAgIC0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICBfX19fQy4uLi5fViAxNDQ1ODM5NzkzMDAzODc0ICAgICAxNDQ1ODM5NzkzMDExNTQx ICAgICA3NjY3ICAgICAgICAgICAgICAgICANCiAgICAgICAgUkVBRCBETUEgKExCQSAxMTI5MTYw ICsgMzIgc2VjdG9ycykgICAgICBfUl9TX19fXyBfX19fX19fXyANCiAgICAgICAgLS0tLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgIF9fX19DLi4uLl9WIDE0NDU4Mzk3 OTMwMTE3OTUgICAgIDE0NDU4Mzk3OTMwMTc3MDIgICAgIDU5MDcgICAgICAgICAgICAgICAgIA0K ICAgICAgICBSRUFEIERNQSAoTEJBIDExNTAxMjAgKyA4IHNlY3RvcnMpICAgICAgIF9SX1NfX19f IF9fX19fX19fIA0KICAgICAgICAtLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgX19fX0MuLi4uX1YgMTQ0NTgzOTc5MzAxNzgwOCAgICAgMTQ0NTgzOTc5MzAxODk3 NSAgICAgMTE2NyAgICAgICAgICAgICAgICAgDQogICAgICAgIFJFQUQgRE1BIChMQkEgMTE0NDM2 MCArIDEyOCBzZWN0b3JzKSAgICAgX1JfU19fX18gX19fX19fX18gDQogICAgICAgIC0tLS0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICBfX19fQy4uLi5fViAxNDQ1ODM5 NzkzMDE5MDc5ICAgICAxNDQ1ODM5NzkzMDE5Njg2ICAgICA2MDcgICAgICAgICAgICAgICAgICAN CiAgICAgICAgUkVBRCBETUEgKExCQSAxMTQ0NzQ0ICsgMzIgc2VjdG9ycykgICAgICBfUl9TX19f XyBfX19fX19fXyANCiAgICAgICAgLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQpUaGUgb2J2aW91cyBwbGFjZSB0byBwdXQgdGhpcyBzb3J0IG9mIHRyYWNpbmcgd291 bGQgYmUgaW4gR0VPTSwgYnV0IHRoYXQgYWN0dWFsbHkgaXNuJ3Qgd2hhdCBJIHdhbnQsIGZvciBh IGZldyByZWFzb25zLiBGaXJzdCBvZiBhbGwsIEknbSBwcmltYXJpbHkgaW50ZXJlc3RlZCBpbiB0 aGUgZXhhY3QgcmVnaXN0ZXIgLyB0YXNrZmlsZSAvIENEQiB2YWx1ZXMgc2VudCB0byB0aGUgZHJp dmUgLSBvcGNvZGUsIGZlYXR1cmUgY29kZXMsIExCQXMsIGV0Yy4gU2Vjb25kLCBJJ20gaW50ZXJl c3RlZCBpbiBoYXJkd2FyZS1sZXZlbCBsYXRlbmN5IC0gaG93IGxvbmcgZG9lcyBhIHJlcXVlc3Qg c3RheSBpbiB0aGUgY29udHJvbGxlciBhbmQgZGV2aWNlLiBCb3RoIG9mIHRob3NlIHByZXR0eSBt dWNoIHJlcXVpcmUgd29ya2luZyBiZWxvdyBHRU9NLg0KDQpUaGVyZWZvcmUsIEkgdGhpbmsgSSB3 YW50IHRvIGRvIGl0IGluIHRoZSBDQU0gc3RhY2s7IGlkZWFsbHksIEknZCBwdXQgdGhlIGhvb2tz IGluIHRoZSBTSU0gZHJpdmVycywgdG8gZ2V0IGFzIGNsb3NlIHRvIHRoZSBtZXRhbCBhcyBwb3Nz aWJsZSwgdG8gZ2V0IHRoZSBtb3N0IGFjY3VyYXRlIGxhdGVuY3kuIEhvd2V2ZXIsIGV2ZW4gYSBs aWdodCB0b3VjaCB0byBldmVyeSBTSU0gZHJpdmVyIGlzIGdvaW5nIHRvIGJlIHBhaW5mdWwsIGFu ZCBzaW5jZSBJIGRvbid0IGhhdmUgYWNjZXNzIHRvIGV2ZXJ5IGNvbnRyb2xsZXIgaW4gdGhlIHdv cmxkLCB0ZXN0aW5nIHdvdWxkIGJlIGRpZmZpY3VsdC4gQWRkaW5nIHRoZSBob29rcyB0byBkYSg0 KSBhbmQgYWRhKDQpIHdvdWxkIHN0aWxsIGJlIHByZXR0eSBjbG9zZSB0byB0aGUgbWV0YWwsIGFu ZCB3b3VsZCByZXF1aXJlIG11Y2ggc21hbGxlciBjaGFuZ2VzLiBPciBtYXliZSB0aGV5IGJlbG9u ZyBpbiB0aGUgWFBUIGxheWVyPyAoSSBkb24ndCBrbm93IG5lYXJseSBhcyBtdWNoIGFib3V0IENB TSBhcyBJIHNob3VsZC4gOi0vKQ0KDQotLS0tLS0tLQ0KTk9URTogV2hlbiBJIG1lbnRpb25lZCB0 aGlzIGlkZWEgYXQgYSAoU2FuIEZyYW5jaXNjbykgQmF5IEFyZWEgRnJlZUJTRCBVc2VyIEdyb3Vw IChCQUZVRykgbWVldGluZywgdGhlcmUgd2VyZSBzdWdnZXN0aW9ucyBhYm91dCBpbnRlZ3JhdGlu ZyB0aGlzIHdpdGggRFRyYWNlIG9yIEtUcmFjZSBpbnN0ZWFkLiBJJ20gaGFwcHkgdG8gY29uc2lk ZXIgZWl0aGVyIG9mIHRob3NlLCBidXQgSSBrbm93IGV2ZW4gbGVzcyBhYm91dCB0aG9zZSB0aGFu IEkgZG8gYWJvdXQgQ0FNLiBJZiB0aGF0J3MgcmVhbGx5IHRoZSBiZXN0IHdheSB0byBkbyB0aGlz IHNvcnQgb2YgdGhpbmcsIEknbSBoYXBweSB0byBsZWFybiwgaWYgc29tZW9uZSBpcyB3aWxsaW5n IHRvIHRlYWNoLg0KLS0tLS0tLS0NCg0KSSB0b29rIHRoZSBQYW5hc2FzIC8gNy54IGltcGxlbWVu dGF0aW9uLCBhbmQgcHNldWRvLWNvZGVkIHdoYXQgaXQgbWlnaHQgbG9vayBsaWtlIGluIENBTS4g KEkgY291bGQgcHJvYmFibHkgbWFrZSBkaWZmcyBhZ2FpbnN0IHRoZSBvbGQgQVRBIHN0YWNrIGF2 YWlsYWJsZSBmb3IgY29tcGFyaXNvbiwgYnV0IEkgZmlndXJlZCBubyBvbmUgd291bGQgY2FyZSBh bnltb3JlLikgQSBodWdlIGNhdmVhdCBpcyB0aGF0IEkndmUgbmV2ZXIgcmVhbGx5IHBva2VkIGlu IENBTSBiZWZvcmUsIHNvIEkgZnVsbHkgZXhwZWN0IEknbSBkb2luZyBzZXZlcmFsIHRoaW5ncyB3 cm9uZy4gUGxlYXNlIGVkdWNhdGUgbWUuIDotKQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQpDcmVhdGUgYSBjaXJjdWxhciBidWZmZXIgb2YgdHJhY2UgcmVjb3JkcyBmb3Ig ZWFjaCBDQU0gUEVSSVBILiBFYWNoIHJlY29yZCB3aWxsIGNvbnRhaW4gdGhlIGZ1bGwgQ0RCIGZv ciB0aGUgcmVxdWVzdCBhcyBzZW50IHRvIHRoZSBkZXZpY2UsIHRoZSB0aW1lc3RhbXAgKGluIHVz ZWMpIG9mIHRoZSByZXF1ZXN0LCB0aGUgQ0RCIGFzIHJldHVybmVkIGJ5IHRoZSBkZXZpY2UsIHRo ZSB0aW1lc3RhbXAgb2YgdGhlIHJlc3BvbnNlLCBhbmQgdGhlIHN0YXR1cyBhbmQgZXJyb3IgY29k ZS4gQWRkaXRpb25hbGx5LCBmbGFncyBhcmUgcHJvdmlkZWQgdG8gdHJhY2sgdGhlIHN0YXRlIG9m IHRoZSB0cmFjZSByZWNvcmQsIGFuZCB0byBpbmRpY2F0ZSB3aGljaCB0eXBlIG9mIHBlcmlwaCB0 aGUgcmVjb3JkIGlzIGFzc29jaWF0ZWQgd2l0aC4NCg0KLS0tLS0tLS0NCg0KdHlwZWRlZiBzdHJ1 Y3Qgew0KCXVfaW50MzJfdAlmbGFnczsNCiNkZWZpbmUgQ0FNX1RSQUNFX0ZfVkFMSUQJMHgwMDAw MDAwMQkvKiB2YWxpZCByZWNvcmQgKi8NCiNkZWZpbmUgQ0FNX1RSQUNFX0ZfSU5QUk9HUkVTUwkw eDAwMDAwMDAyCS8qIHJlcXVlc3QgaW4gcHJvZ3Jlc3MgKi8NCiNkZWZpbmUgQ0FNX1RSQUNFX0Zf UkVRX1ZBTElECTB4MDAwMDAwMDQJLyogcmVxdWVzdCBkYXRhIHZhbGlkICovDQojZGVmaW5lIENB TV9UUkFDRV9GX1JFU1BfVkFMSUQJMHgwMDAwMDAwOAkvKiByZXNwb25zZSBkYXRhIHZhbGlkICov DQojZGVmaW5lIENBTV9UUkFDRV9GX0NPTVBMRVRFCTB4MDAwMDAwMTAJLyogcmVzcG9uc2UgZ2F0 aGVyZWQgKi8NCiNkZWZpbmUgQ0FNX1RSQUNFX0ZfVElNRURPVVQJMHgwMDAwMDAyMAkvKiByZXF1 ZXN0IHRpbWVkIG91dCAqLw0KI2RlZmluZSBDQU1fVFJBQ0VfRl9BQkFORE9ORUQJMHgwMDAwMDA0 MAkvKiBjYW5jZWxsZWQsIGV0Yy4gKi8NCiNkZWZpbmUgQ0FNX1RSQUNFX0ZfUkVUUklFRAkweDAw MDAwMDgwCS8qIHJldHJ5IGluIGxhdGVyIHJlY29yZCAqLw0KI2RlZmluZSBDQU1fVFJBQ0VfRl9J U19SRVRSWQkweDAwMDAwMTAwCS8qIHJldHJ5IG9mIGVhcmxpZXIgcmVxLiAqLw0KI2RlZmluZSBD QU1fVFJBQ0VfRl9QRVJJUEhfTUFTSwkweGYwMDAwMDAwCS8qIHVwIHRvIDE2IFBFUklQSCB0eXBl cyAqLw0KI2RlZmluZSBDQU1fVFJBQ0VfRl9QRVJJUEhfREEJMHgwDQojZGVmaW5lIENBTV9UUkFD RV9GX1BFUklQSF9BREEJMHgxDQojZGVmaW5lIENBTV9UUkFDRV9GX1BFUklQSF9OVkQJMHgyDQoJ dV9pbnQ2NF90CXJlcV91c2VjOw0KCWNkYl90CQlyZXFfY2RiOw0KCXVfaW50NjRfdAlyZXNwX3Vz ZWM7DQoJY2RiX3QJCXJlc3BfY2RiOw0KCXVfaW50OF90CXJlc3Bfc3RhdHVzOw0KCXVfaW50OF90 CXJlc3BfZXJyb3I7DQoJdV9pbnQ4X3QJcmVzcF9hc2M7CS8qIE5lZWRlZCBmb3IgU0NTST8gKi8N Cgl1X2ludDhfdAlyZXNwX2FzcTsJLyogTmVlZGVkIGZvciBTQ1NJPyAqLw0KCXVfaW50OF90CXBh ZGRpbmdbOF07CS8qIFBhZCB0byA2NCBieXRlcyAqLw0KLyogVGhlcmUncyBnb2luZyB0byBiZSBh IGxhcmdlLWlzaCBhcnJheSBvZiB0aGVzZSBpbiB0aGUga2VybmVsOyBtYWtlIHN1cmUNCiAqIHRo ZXkncmUgcGFja2VkIHRvIG1pbmltaXplIHNwYWNlIHVzYWdlLCBhbmQga2VlcCB0aGluZ3MgYWxp Z25lZC4gSXQgbWF5DQogKiBtYWtlIHNlbnNlIHRvIHJlLW9yZGVyIHRoZSBmaWVsZHMgZm9yIGFs aWdubWVudCBhcyB3ZWxsLg0KICovDQp9IGNhbV90cmFjZV9yZWNvcmRfdCBfX2F0dHJpYnV0ZV9f KChwYWNrZWQsIGFsaWduZWQoOCkpKTsNCg0KdHlwZWRlZiBzdHJ1Y3Qgew0KCXVfaW50MzJfdAkJ dHJhY2VfYnVmX3JlY29yZF9jb3VudDsNCgljYW1fdHJhY2VfcmVjb3JkX3QJKnRyYWNlX2J1ZjsN Cn0gY2FtX3RyYWNlX2J1ZmZlcl90Ow0KDQovKiBUaGlzIGlzIHNldHRhYmxlIHZpYSBhIHR1bmFi bGU7IGZvciBQYW5hc2FzJyBwdXJwb3NlcywgMTAwSyBlbnRyaWVzIHdhcw0KICogZW5vdWdoIHRv IHByb3ZpZGUgYSBnb29kIGFtb3VudCBvZiBoaXN0b3J5IGV2ZW4gb24gYSBidXN5IHN5c3RlbSwg d2hpbGUNCiAqIG5vdCB0YWtpbmcgdXAgbXVjaCBzcGFjZSAoPCA1TUIvZHJpdmUpLg0KICovDQoj ZGVmaW5lIENBTV9UUkFDRV9CVUZGRVJfREVGQVVMVF9DT1VOVCAxMDAwMDANCg0KLS0tLS0tLS0t LS0tLS0tLQ0KDQppb2N0bCBpbnRlcmZhY2VzIGFyZSB1c2VkIHRvIGdldCB0aGUgdHJhY2UgYnVm ZmVyIHNpemUsIHRvIHJldHJpZXZlIHRoZSBidWZmZXIgY29udGVudHMsIG9yIHRvIGNsZWFyIHRo ZSBidWZmZXIuIFRoZSBidWZmZXIgY2FuIHRoZW4gYmUgYW5hbHl6ZWQgZnJvbSB1c2Vyc3BhY2Us IG9yIHdyaXR0ZW4gdG8gYSBmaWxlIGZvciBwb3N0LXByb2Nlc3NpbmcuDQoNCi0tLS0tLS0tDQoN CiNkZWZpbmUgQ0FNX0dFVF9UUkFDRV9SRUNPUkRfQ09VTlQJX0lPUig/Pz8sID8/PywgdV9pbnQz Ml90KQ0KI2RlZmluZSBDQU1fR0VUX1RSQUNFX0JVRkZFUgkJX0lPV1IoPz8/LCA/Pz8sIGNhbV90 cmFjZV9idWZmZXJfdCkNCiNkZWZpbmUgQ0FNX0NMRUFSX1RSQUNFX0JVRkZFUgkJX0lPVyg/Pz8s ID8/PywgdV9pbnQzMl90KQ0KDQotLS0tLS0tLS0tLS0tLS0tDQoNClRvIGdldCB0aGUgYnVmZmVy Og0KDQotLS0tLS0tLQ0KDQoJY2FtX3RyYWNlX2J1ZmZlcl90IHRyYWNlID0gTlVMTDsNCglmZCA9 IG9wZW4ocGVyaXBoX25hbWUsIE9fUkRPTkxZKTsNCgllcnJvciA9IGlvY3RsKGZkLCBDQU1fR0VU X1RSQUNFX1JFQ09SRF9DT1VOVCwNCgkgICAgJnRyYWNlLnRyYWNlX2J1Zl9yZWNvcmRfY291bnQp Ow0KCXRyYWNlLnRyYWNlX2J1ZiA9IG1hbGxvYyh0cmFjZS50cmFjZV9idWZfcmVjb3JkX2NvdW50 ICoNCgkgICAgc2l6ZW9mKGNhbV90cmFjZV9yZWNvcmRfdCkpOw0KCWVycm9yID0gaW9jdGwoZmQs IENBTV9HRVRfVFJBQ0VfQlVGRkVSLCAmdHJhY2UpOw0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCkJ5 IGluY2x1ZGluZyB0aGUgZnVsbCBDREIsIHRoZSBlbnRpcmUgY29tbWFuZCBjYW4gYmUgZGVjb2Rl ZCBieSBhbmFseXNpcyB0b29scy4gVG9vbHMgY2FuIGJlIHdyaXR0ZW4gdG8gcGFyc2UgdGhlIGJ1 ZmZlciBhbmQgdHJhbnNsYXRlIGNvbW1hbmQgZGF0YSBpbnRvIGh1bWFuLXJlYWRhYmxlIGRlc2Ny aXB0aW9ucywgY2FsY3VsYXRlIGVsYXBzZWQgdGltZXMgZm9yIHJlcXVlc3RzLCBwZXJmb3JtIHN0 YXRpc3RpY2FsIGFuYWx5c2lzIGJhc2VkIG9uIG9wY29kZSwgY29tbWFuZCB0eXBlLCB0cmFuc2Zl ciBzaXplLCBldGMuIENvbW1hbmQgZGVjb2RlcnMgd291bGQgbmVlZCB0byBiZSB3cml0dGVuIGZv ciBlYWNoIFBFUklQSCB0eXBlIChpLmUuIG9uZSBmb3IgQVRBLCBvbmUgZm9yIFNDU0ksIG9uZSBm b3IgTlZNZSwgZXRjLikuDQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KRWFjaCBQRVJJUEgncyBzb2Z0 YyBuZWVkcyB0byBpbmNsdWRlIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBlci1kZXZpY2UN CmJ1ZmZlci4NCg0KLS0tLS0tLS0NCg0KCXVfaW50MzJfdAkJdHJhY2VfYnVmX3JlY29yZF9jb3Vu dDsNCgl1X2ludDY0X3QJCXRyYWNlX2J1Zl9yZXF1ZXN0X2NvdW50Ow0KCWNhbV90cmFjZV9yZWNv cmRfdAkqdHJhY2VfYnVmOw0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCkluIGVhY2ggU0lNLCB0aGVy ZSBzaG91bGQgYWxyZWFkeSBiZSBzb21lIHNvcnQgb2YgcmVxdWVzdCBzdHJ1Y3R1cmUsIHdoaWNo IGFzc29jaWF0ZXMgdGhlIHNvZnRjIGFuZCB0aGUgQ0RCIG9mIHRoZSByZXF1ZXN0LiBUbyB0aGF0 IHN0cnVjdHVyZSwgYWRkIGEgcG9pbnRlciB0byB0aGUgdHJhY2UgcmVjb3JkIGFzc29jaWF0ZWQg d2l0aCB0aGUgcmVxdWVzdC4NCg0KLS0tLS0tLS0NCg0KcmVxdWVzdCBzdHJ1Y3R1cmU6DQoJY2Ft X3RyYWNlX3JlY29yZF90CSp0cmFjZV9yZWM7DQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KV2hlbiBp bml0aWFsaXppbmcgdGhlIHBlci1kZXZpY2Ugc29mdGMsIGFsbG9jYXRlIGEgdHJhY2UgYnVmZmVy LiBUaGUgbnVtYmVyIG9mIHJlY29yZHMgY2FuIGJlIGhhcmQtY29kZWQsIG9yIHNldHRhYmxlIHZp YSBhIHR1bmFibGUuDQoNClRoZSBleGFtcGxlIGJlbG93IGhhcyBhIGdsb2JhbCBzaXplIGZvciBl dmVyeXRoaW5nLCBidXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIGl0IG9uIGEgcGVyLWRl dmljZSBvciBwZXItUEVSSVBIIGJhc2lzLg0KDQotLS0tLS0tLQ0KDQoJLyoqIEluaXRpYWxpemUg cGVyLWRyaXZlIGNvbW1hbmQgdHJhY2luZyBidWZmZXIuICoqLw0KCS8qIEdldCB0aGUgYnVmZmVy IHNpemUgZnJvbSB0aGUgdHVuYWJsZS4gU2FuaXR5IGNoZWNrIGl0LiAqLw0KCXNjLT50cmFjZV9i dWZfcmVjb3JkX2NvdW50ID0gQ0FNX1RSQUNFX0JVRkZFUl9ERUZBVUxUX0NPVU5UOw0KCVRVTkFC TEVfVUxPTkdfRkVUQ0goImNhbS50cmFjZV9idWZfcmVjb3JkX2NvdW50IiwNCgkgICAgJnRyYWNl X2J1Zl9yZWNvcmRfY291bnRfdHVuYWJsZSk7DQoJaWYgKHRyYWNlX2J1Zl9yZWNvcmRfY291bnRf dHVuYWJsZSkgew0KCQkvKiBMZXNzIHRoYW4gMUsgcmVjb3JkcyBpcyB1bnVzYWJseSBmZXc7IG1v cmUgdGhhbiAxTQ0KCQkgKiByZWNvcmRzIGlzIHVudXNhYmx5IG1hbnkuDQoJCSAqLw0KCQlpZiAo KHRyYWNlX2J1Zl9yZWNvcmRfY291bnRfdHVuYWJsZSA8ICgxIDw8IDEwKSkgfHwNCgkJICAgICh0 cmFjZV9idWZfcmVjb3JkX2NvdW50X3R1bmFibGUgPiAoMSA8PCAyMCkpKSB7DQoJCQlkZXZpY2Vf cHJpbnRmKGRldiwgImNhbS50cmFjZV9idWZfcmVjb3JkX2NvdW50PSVsdSINCgkJCSAgICAiIG91 dCBvZiByYW5nZTsgc2hvdWxkIGJlIGJldHdlZW4gJXUgYW5kICV1XG4iLA0KCQkJICAgIHRyYWNl X2J1Zl9yZWNvcmRfY291bnRfdHVuYWJsZSwgKDEgPDwgMTApLA0KCQkJICAgICgxIDw8IDIwKSk7 DQoJCX0gZWxzZSB7DQoJCQlzYy0+dHJhY2VfYnVmX3JlY29yZF9jb3VudCA9ICh1X2ludDMyX3Qp DQoJCQkgICAgdHJhY2VfYnVmX3JlY29yZF9jb3VudF90dW5hYmxlOw0KCQl9DQoJfQ0KCS8qIEFs bG9jYXRlIHRoZSBidWZmZXIuICovDQoJdHJhY2VfYnVmX2J5dGVzID0gc2MtPnRyYWNlX2J1Zl9y ZWNvcmRfY291bnQgKg0KCSAgICBzaXplb2YoY2FtX3RyYWNlX3JlY29yZF90KTsNCglzYy0+dHJh Y2VfYnVmID0gbWFsbG9jKHRyYWNlX2J1Zl9ieXRlcywgTV9BRCwgTV9OT1dBSVQgfCBNX1pFUk8p Ow0KCWlmIChzYy0+dHJhY2VfYnVmID09IE5VTEwpIHsNCgkJZGV2aWNlX3ByaW50ZihkZXYsICJ1 bmFibGUgdG8gYWxsb2NhdGUgJXpkIGZvciB0cmFjZV9idWZcbiIsDQoJCSAgICB0cmFjZV9idWZf Ynl0ZXMpOw0KCQlzYy0+dHJhY2VfYnVmX3JlY29yZF9jb3VudCA9IDA7DQoJfSBlbHNlIHsNCgkJ ZGV2aWNlX3ByaW50ZihkZXYsICJhbGxvY2F0ZWQgJXpkIEAgJXAgZm9yIHRyYWNlX2J1ZlxuIiwN CgkJICAgIHRyYWNlX2J1Zl9ieXRlcywgc2MtPnRyYWNlX2J1Zik7DQoJfQ0KCS8qIFJlcXVlc3Qg Y291bnRlciwgdXNlZCBmb3IgaW5kZXhpbmcgKi8NCglzYy0+dHJhY2VfYnVmX3JlcXVlc3RfY291 bnQgPSAwOw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUg dHJhY2UgcmVjb3JkIGZvciBhIG5ldyByZXF1ZXN0Lg0KICoNCiAqICBMb2NhdGUgdGhlIGNpcmN1 bGFyIHBlci1kZXZpY2UgdHJhY2UgYnVmZmVyIGluIHRoZSBkcml2ZSdzIHNvZnRjLg0KICogIFBv cHVsYXRlIHRoZSBwb2ludGVyIHRvIHRoZSBuZXh0IHJlY29yZCBpbiB0aGUgdHJhY2UgYnVmZmVy OyB0aGlzIGlzDQogKiAgZG9uZSBhdG9taWNhbGx5IHRvIHByZXZlbnQgY29uY3VycmVudCByZXF1 ZXN0cyBmcm9tIGdldHRpbmcgdGhlIHNhbWUNCiAqICBpbmRleC4gVGhhdCBjb3VsZCBnZXQgYSBi aXQgd2VpcmQgaWYvd2hlbiAndHJhY2VfYnVmX3JlcXVlc3RfY291bnQnDQogKiAgcm9sbHMgb3Zl ciwgaWYgdGhlIG1heGltdW0gY291bnRlciB2YWx1ZSBpcyBub3QgYSBtdWx0aXBsZSBvZg0KICog ICd0cmFjZV9idWZfcmVjb3JkX2NvdW50JyAoaS5lLiB0aGUgcmVxdWVzdCBjb3VudGVyIHJlY3lj bGVzIGluIHRoZQ0KICogIG1pZGRsZSBvZiB0aGUgYnVmZmVyKS4gQnkgdXNpbmcgYSA2NC1iaXQg cmVxdWVzdCBjb3VudGVyLCB3ZSdyZSBwcmV0dHkNCiAqICBzYWZlIC0gZXZlbiBhdCBvbmUgdHJh bnNhY3Rpb24gcGVyIG5hbm9zZWNvbmQsIHRoYXQgd2lsbCBzdGlsbCBsYXN0DQogKiAgYWJvdXQg NTg1IHllYXJzLg0KICoNCiAqICBJbml0aWFsaXplIHRoZSByZWNvcmQgYnkgemVyb2luZyBpdCBh bmQgdGhlbiBzZXR0aW5nIHRoZSBWQUxJRCBmbGFnLg0KICoNCiAqICBUaGlzIGNvdWxkIGJlIGRv bmUgYXQgYW55IHBvaW50IGJlZm9yZSBzZW5kaW5nIHRoZSByZXF1ZXN0IHRvIHRoZQ0KICogIGhh cmR3YXJlOyBuZWl0aGVyIHRoZSBDREIgZGF0YSBub3IgdGhlIHRpbWVzdGFtcHMgYXJlIGludm9s dmVkIHlldC4NCiAqLw0Kdm9pZA0KdHJhY2VfcmVjX2luaXQoY2FtX3JlcXVlc3RfdCByZXEpIHsN CglhZGFfc29mdGMgKnNjID0gKHJlcXVlc3QtPi4uLi0+c29mdGMpDQoJdV9pbnQ2NF90IHRtcCA9 IDA7DQoJaWYgKHNjICYmIHNjLT50cmFjZV9idWYpIHsNCgkJdG1wID0gYXRvbWljX2ZldGNoYWRk X2xvZygmc2MtPnRyYWNlX2J1Zl9yZXF1ZXN0X2NvdW50LCAxKTsNCgkJcmVxLT50cmFjZV9yZWMg PSAmc2MtPnRyYWNlX2J1Zlt0bXAgJQ0KCQkgICAgc2MtPnRyYWNlX2J1Zl9yZWNvcmRfY291bnRd Ow0KCQliemVybyhyZXEtPnRyYWNlX3JlYywgc2l6ZW9mKCpyZXEtPnRyYWNlX3JlYykpOw0KCQly ZXEtPnRyYWNlX3JlYy0+ZmxhZ3MgPSAoQ0FNX1RSQUNFX0ZfUEVSSVBIX1hYWCA8PCAyOCk7DQoJ CXJlcS0+dHJhY2VfcmVjLT5mbGFncyB8PSBDQU1fVFJBQ0VfRl9WQUxJRDsNCgl9IGVsc2Ugew0K CQlyZXEtPnRyYWNlX3JlYyA9IE5VTEw7DQoJfQ0KfQ0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCi8q IFN0dWZmIHRoZSByZXF1ZXN0IGRhdGEgaW50byB0aGUgdHJhY2UgcmVjb3JkLg0KICoNCiAqICBJ ZiB0aGUgdHJhY2UgcmVjb3JkIGlzIHByZXNlbnQgYW5kIHZhbGlkLCBjb3B5IHRoZSBDREIgaW50 byB0aGUNCiAqICByZWNvcmQuIFNldCBDQU1fVFJBQ0VfRl9SRVFfVkFMSUQgdG8gaW5kaWNhdGUg dGhhdCB0aGUgcmVxdWVzdCBkYXRhIGlzDQogKiAgdmFsaWQsIGFuZCBJTlBST0dSRVNTIHRvIHNo b3cgdGhhdCB0aGUgcmVxdWVzdCBpcyBpbi1wcm9ncmVzcy4NCiAqDQogKiAgVGhpcyBzaG91bGQg YmUgZG9uZSBqdXN0IGJlZm9yZSBzZW5kaW5nIHRoZSByZXF1ZXN0IHRvIHRoZSBoYXJkd2FyZS4N CiAqICBUaGlzIHNob3VsZCAqbm90KiBiZSBmdXNlZCBpbnRvIHRyYWNlX3JlY19pbml0KCksIGJl Y2F1c2UNCiAqICB0cmFjZV9yZWNfaW5pdCgpIGlzIGFsc28gdXNlZCBpbiB0aGUgcmV0cnkgY2Fz ZSwgd2hlcmUgaXQgaXMgbm90DQogKiBjb3JyZWN0IHRvIGltbWVkaWF0ZWx5IHN0YXJ0IHRoZSB0 aW1lci4NCiAqLw0Kdm9pZA0KdHJhY2VfcmVjX3JlcShjYW1fcmVxdWVzdF90IHJlcSkgew0KCXN0 cnVjdCB0aW1ldmFsIHR2Ow0KCWlmIChyZXEtPnRyYWNlX3JlYyAmJiAocmVxLT50cmFjZV9yZWMt PmZsYWdzICYgQ0FNX1RSQUNFX0ZfVkFMSUQpKSB7DQoJCWJjb3B5KHJlcS0+Y2RiLCByZXEtPnRy YWNlX3JlYy0+cmVxX2NkYiwgc2l6ZW9mKHJlcS0+Y2RiKSk7DQoJCW1pY3JvdXB0aW1lKCZ0dik7 DQoJCXJlcS0+dHJhY2VfcmVjLT5yZXFfdXNlYyA9ICgodWludDY0X3QpIHR2LT50dl9zZWMgKiAx MDAwMDAwKQ0KCQkgICAgKyB0di0+dHZfdXNlYzsNCgkJcmVxLT50cmFjZV9yZWMtPmZsYWdzIHw9 DQoJCSAgICAoQ0FNX1RSQUNFX0ZfUkVRX1ZBTElEIHwgQ0FNX1RSQUNFX0ZfSU5QUk9HUkVTUyk7 DQoJfQ0KfQ0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCi8qIFN0dWZmIHRoZSByZXNwb25zZSBkYXRh IGludG8gdGhlIHRyYWNlIHJlY29yZC4NCiAqDQogKiAgSWYgdGhlIHRyYWNlIHJlY29yZCBpcyBw cmVzZW50IGFuZCB2YWxpZCwgY29weSB0aGUgQ0RCICoqYXMgcmV0dXJuZWQgYnkNCiAqICB0aGUg ZHJpdmUqKiBpbnRvIHRoZSByZWNvcmQuIEF0IHRoaXMgcG9pbnQsIHdlIGFsc28gaGF2ZSB0aGUg cmVzdWx0IGZyb20NCiAqICB0aGUgY29tbWFuZCAoc3RhdHVzLCBlcnJvciwgKGFzYz8gYXNjcT8p KSwgc28gc2F2ZSB0aGVtIHRvby4gU2V0DQogKiAgQ0FNX1RSQUNFX0ZfUkVTUF9WQUxJRCB0byBp bmRpY2F0ZSB0aGF0IHRoZSByZXNwb25zZSBkYXRhIGlzIHZhbGlkLg0KICogIENsZWFyIElOUFJP R1JFU1MgYW5kIHNldCBDT01QTEVURSBpbnN0ZWFkLg0KICoNCiAqICBUaGlzIHNob3VsZCBiZSBk b25lIGp1c3QgYWZ0ZXIgZ2V0dGluZyB0aGUgcmVzcG9uc2UgaW5mb3JtYXRpb24gZnJvbSB0aGUN CiAqICBoYXJkd2FyZS4NCiAqLw0Kdm9pZA0KdHJhY2VfcmVjX3Jlc3AoY2FtX3JlcXVlc3RfdCBy ZXEpIHsNCglzdHJ1Y3QgdGltZXZhbCB0djsNCglpZiAocmVxLT50cmFjZV9yZWMgJiYgKHJlcS0+ dHJhY2VfcmVjLT5mbGFncyAmIENBTV9UUkFDRV9GX1ZBTElEKSkgew0KCQltaWNyb3VwdGltZSgm dHYpOw0KCQliY29weShyZXEtPmNkYiwgcmVxLT50cmFjZV9yZWMtPnJlc3BfY2RiLCBzaXplb2Yo cmVxLT5jZGIpKTsNCgkJcmVxLT50cmFjZV9yZWMtPnJlc3BfdXNlYyA9ICgodWludDY0X3QpIHR2 LT50dl9zZWMgKg0KCQkgICAgMTAwMDAwMCkgKyB0di0+dHZfdXNlYzsNCgkJcmVxLT50cmFjZV9y ZWMtPmZsYWdzIHw9DQoJCSAgICAoQ0FNX1RSQUNFX0ZfUkVTUF9WQUxJRCB8IENBTV9UUkFDRV9G X0NPTVBMRVRFKTsNCgkJcmVxLT50cmFjZV9yZWMtPmZsYWdzICY9IH5DQU1fVFJBQ0VfRl9JTlBS T0dSRVNTOw0KCX0NCn0NCg0KLS0tLS0tLS0tLS0tLS0tLQ0KDQovKiBVcGRhdGUgdGhlIHRyYWNl IHJlY29yZCBpZiB0aGVyZSB3YXMgYSB0aW1lb3V0Lg0KICoNCiAqICBJZiB0aGUgdHJhY2UgcmVj b3JkIGlzIHByZXNlbnQgYW5kIHZhbGlkLCBzZXQgVElNRURPVVQgdG8gaW5kaWNhdGUNCiAqICB0 aGF0IHRoZSByZXF1ZXN0IGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVjb3JkIGV4Y2VlZGVkIGl0cyB0 aW1lb3V0Lg0KICogIFNpbmNlIHRoaXMgYXR0ZW1wdCBpcyBjb21wbGV0ZSwgY2xlYXIgSU5QUk9H UkVTUyBhbmQgc2V0IENPTVBMRVRFLg0KICoNCiAqICBUaGlzIHNob3VsZCBiZSBkb25lIGFsb25n IHdpdGggb3RoZXIgdGltZW91dCBoYW5kbGluZy4NCiAqLw0Kdm9pZA0KdHJhY2VfcmVjX3RpbWVv dXQoY2FtX3JlcXVlc3RfdCByZXEpIHsNCglpZiAocmVxLT50cmFjZV9yZWMgJiYgKHJlcS0+dHJh Y2VfcmVjLT5mbGFncyAmIENBTV9UUkFDRV9GX1ZBTElEKSkgew0KCQlyZXEtPnRyYWNlX3JlYy0+ ZmxhZ3MgfD0NCgkJICAgIChDQU1fVFJBQ0VfRl9USU1FRE9VVCB8IENBTV9UUkFDRV9GX0NPTVBM RVRFKTsNCgkJcmVxLT50cmFjZV9yZWMtPmZsYWdzICY9IH5DQU1fVFJBQ0VfRl9JTlBST0dSRVNT Ow0KCX0NCn0NCg0KLS0tLS0tLS0tLS0tLS0tLQ0KDQovKiBVcGRhdGUgdGhlIHRyYWNlIHJlY29y ZCBpZiB0aGUgcmVxdWVzdCBpcyBiZWluZyByZXRyaWVkLg0KICogIA0KICogIElmIHRoZSB0cmFj ZSByZWNvcmQgaXMgcHJlc2VudCBhbmQgdmFsaWQsIHNldCBSRVRSSUVEIHRvIGluZGljYXRlDQog KiAgdGhhdCB0aGUgcmVxdWVzdCBhc3NvY2lhdGVkIHdpdGggdGhlIHJlY29yZCBpcyBnb2luZyB0 byBiZSByZXRyaWVkLg0KICogIFNpbmNlIHRoaXMgYXR0ZW1wdCBpcyBjb21wbGV0ZSwgY2xlYXIg SU5QUk9HUkVTUyBhbmQgc2V0IENPTVBMRVRFLg0KICogIFRoZW4gZ2V0IGEgbmV3IHRyYWNlIHJl Y29yZCBmb3IgdGhlIG5ldyBhdHRlbXB0LCBjb3B5IHRoZSByZXF1ZXN0DQogKiAgY29tbWFuZCBk YXRhIHRvIHRoZSBuZXcgcmVjb3JkLCBhbmQgc2V0IElTX1JFVFJZIHRvIHNob3cgdGhhdCB0aGlz DQogKiAgaXMgYSByZXRyeSBvZiBhbiBlYXJsaWVyIHJlcXVlc3QuDQogKg0KICogIFRoaXMgc2hv dWxkIGJlIGRvbmUgYXQgdGhlIHRpbWUgdGhlIHJldHJ5IGlzIHF1ZXVlZC4NCiAqLw0Kdm9pZA0K dHJhY2VfcmVjX3JldHJ5KGNhbV9yZXF1ZXN0X3QgcmVxKSB7DQoJaWYgKHJlcS0+dHJhY2VfcmVj ICYmIChyZXEtPnRyYWNlX3JlYy0+ZmxhZ3MgJiBDQU1fVFJBQ0VfRl9WQUxJRCkpIHsNCgkJLyog Rmlyc3QsIG1hcmsgdGhlIG9yaWdpbmFsIHJlcXVlc3QgYXMgYmVpbmcgcmVxdWV1ZWQuICovDQoJ CXJlcS0+dHJhY2VfcmVjLT5mbGFncyB8PQ0KCQkgICAgKENBTV9UUkFDRV9GX1JFVFJJRUQgfCBD QU1fVFJBQ0VfRl9DT01QTEVURSk7DQoJCXJlcS0+dHJhY2VfcmVjLT5mbGFncyAmPSB+Q0FNX1RS QUNFX0ZfSU5QUk9HUkVTUzsNCgkJLyogR2V0IGEgbmV3IHJlY29yZCBmb3IgdGhlIHJldHJ5LiAq Lw0KCQl0cmFjZV9yZWNfaW5pdChyZXEpOw0KCQkvKiBNYXJrIHRoZSBuZXcgcmVjb3JkIGFzIGJl aW5nIGEgcmV0cnkuICovDQoJCXJlcS0+dHJhY2VfcmVjLT5mbGFncyB8PSBDQU1fVFJBQ0VfRl9J U19SRVRSWTsNCgl9DQp9DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkkn ZCBhcHByZWNpYXRlIGZlZWRiYWNrLCBib3RoIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxz IGFuZCBvbiB0aGUgaWRlYSBhcyBhIHdob2xlLiBTb21lIG9wZW4gcXVlc3Rpb25zIGFyZToNCg0K LSBNeSBhc3N1bXB0aW9uIGlzIHRoYXQgZWFjaCBTSU0gaGFzIGEgc3RydWN0dXJlIHRoYXQgYXNz b2NpYXRlcyBhIFBFUklQSCdzIHNvZnRjIHdpdGggdGhlIENEQiB0aGF0J3MgYmVpbmcgcHJvY2Vz c2VkLiBJdCBtaWdodCByZXF1aXJlIGRlcmVmZXJlbmNpbmcgYSBjaGFpbiBvZiBwb2ludGVycywg YnV0IGl0IHNob3VsZCBiZSB0aGVyZSBpbiBzb21lIGZhc2hpb24uDQoNCi0gVGhlIGN1cnJlbnQg aW1wbGVtZW50YXRpb24gYWRkcyBhIGZldyBpb2N0bHMgdG8gdGhlIG9sZCBhZCg0KSBkaXNrLWRl dmljZSBkcml2ZXIuIEkgd291bGQgZXhwZWN0IHRvIGFkZCB0aGUgbmV3IGlvY3RscyB0byBkYSg0 KSBhbmQgYWRhKDQpOyBpcyB0aGF0IHRoZSByaWdodCB0aGluZyB0byBkbz8NCg0KQWdhaW4sIGFu eSBmZWVkYmFjayB3b3VsZCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLiBJJ2xsIGJlIGF0IHRoZSBE ZXYvVmVuZG9yIFN1bW1pdCBuZXh0IHdlZWssIGlmIGFueW9uZSB3YW50cyB0byBkaXNjdXNzIHRo aXMgd2l0aCBtZSBpbiBwZXJzb24uDQoNClRoYW5rcywNCg0KUmF2aQ0K From owner-freebsd-hackers@freebsd.org Tue Oct 27 02:52:26 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2737BA1D637; Tue, 27 Oct 2015 02:52:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E750D1ED1; Tue, 27 Oct 2015 02:52:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbdj2 with SMTP id dj2so69954862igb.1; Mon, 26 Oct 2015 19:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0N04urbmjDcKXag4ODP61wNFTI9J0m9FSkmzdfrVxE=; b=th4YS+SukWTb9+Pl+hATNh020/GWHaKkl8C7mS+b7gdtjIXX3MA3JTthh54sTkiTI9 xhzG5Mev06XJOvVpDMi7tNPYdm9QXd9s1PYprZYScCl0+L1H9eMIbvo6v/TsREW5pu5i /sIPOd2/0UCVT4PyU85wusBhJbyr6pcVgaq1u4UIm2t9q/S6EISH2oWXRJKjiMGMasKH 1qEURqDYIrOyBAiziqEndhJ3Azhea/n+vOkMtF+mVW8jtd34Jf6E/1+LDOUUCRKErqKy nKdASewgkyG+0Z+pNdJ9SQlCtjG7lYVM2NdNiy0XL1mACn+BnTHbuuS9RdJYhAlBQLJ6 UUqA== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr21220057igb.61.1445914345393; Mon, 26 Oct 2015 19:52:25 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Mon, 26 Oct 2015 19:52:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2015 21:52:25 -0500 Message-ID: Subject: Re: Low-level trace-buffers in CAM From: Adrian Chadd To: "Pokala, Ravi" Cc: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Tue, 27 Oct 2015 02:59:47 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 02:52:26 -0000 Hi, ok. So this is where I create work for people. :-) Something I've been tossing up for quite some time is a generic version of this that exposes a ring-buffer of entries back to userland. For things like this, things like ALQ/KTR, etc, it's all just a producer-consumer ring based thing. You don't even care about multiple readers; that's a userland thing. So, I'm a big fan of this. I did this for the ath driver to debug descriptors and register accesses and it was a big help. I'd really like to see a more generic way we can expose this data in an efficient manner! -a From owner-freebsd-hackers@freebsd.org Tue Oct 27 03:15:47 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9315A1E4A0 for ; Tue, 27 Oct 2015 03:15:47 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm30-vm8.bullet.mail.gq1.yahoo.com (nm30-vm8.bullet.mail.gq1.yahoo.com [98.136.216.199]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C3551F68 for ; Tue, 27 Oct 2015 03:15:47 +0000 (UTC) (envelope-from scott4long@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1445915324; bh=EQOsczGewNEODH9UYzy6zp7RenazxJBTgd8Xi9dCsyA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=AGViYa2Cy3pWx1CnEU9yQsSgP4pm6dzPKMKz/zY0yLlidB03WVxt9TECMqpPBK4GBhT+fxh7jN75S/b25BRJmba5tXF155m8uhEgF0PRVNeTmt3OGxwy+5K3enzcQq9iyt/FYCGkI0hYfDCn5BE4zxs5jqCdcDzZo1LiV8Yfqm/n/qNAtBUwa8wssT7p5uCfkW2JdafPsvyNlhRGOTV9ZHLSVqSiIoT0ElfJJ3HzFCqo3tjLeKgghZjyyIiiPz5kqcMaGCruQwpKPPjKnut3aXN47kWDE/3t2he9a3I/KVYEpqNPaFrPeSDr6dujhKxh3OGS9SocY8cGc6oNPQv6hQ== Received: from [98.137.12.55] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 03:08:44 -0000 Received: from [208.71.42.198] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 03:08:44 -0000 Received: from [127.0.0.1] by smtp209.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 03:08:44 -0000 X-Yahoo-Newman-Id: 651161.7604.bm@smtp209.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CO37JK4VM1nFIy7Qa8nbeXEOF9VtrnHzSFncdrpMNP8Tgdg YQ8keMmIC2Nz5Oc3t8jQ4oiN2et05cQ7QWwwpu9pSR01PHJINhqR9WZAaAq9 aFjWMLa5_wcxTmTBzFwULDRemrxPawOzexZa.PROmjSv3NjdhQMrgXuaMPK3 EIbgcmAPnxcBIinCP6nlo_Eb5zmcJg5rES56fDqFPsLl7ADvHTvcTWrE2bBP zSbIItr86dPnmIaBNBnvwTJ49pSCVp9dm1sd57g5OMhS7FyCKcrVQAE6S60b GSM5M5bi3AVgyxWWwGF8U96Om08tFo3e0eMf2yuX_zbv1vzxB.Pr71qh4G5p p.lZfvMMtFpruoY2xe4cXQ8HjJZJACn_VqwZsekcvNDogt2mMamHRd7eXbX8 oWOtTUuvywFgSNR3SuVZhOxqTa0vGKsWv5s0ZY0zSDLRtToEwHwsHeJ0BYps 0a_j2OIHNdfObetFyhwfE3FdMCJGN2kRllio3oodVbHnJS5GoWQeO.Se3Gnt sfSpXfvPJaNxpyTR7mHOucq4V0LFEwsnDPcIBXeY- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Low-level trace-buffers in CAM From: Scott Long X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Mon, 26 Oct 2015 21:08:42 -0600 Cc: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2C9653BA-CC10-497B-ACEF-0C76AAE2FF44@yahoo.com> References: To: "Pokala, Ravi" X-Mailman-Approved-At: Tue, 27 Oct 2015 03:32:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 03:15:47 -0000 Hi Ravi, Yes I was one of the people who never followed up. I'll be at the vendor su= mmit next week, let's chat some more. Scott Sent from my iPhone > On Oct 26, 2015, at 8:22 PM, Pokala, Ravi wrote: >=20 > Hi folks, >=20 > ---------------------------------------------------------------- > This is an updated re-send of a message I originally sent about a year ago= , during MeetBSD 2014. A few people expressed interest in person, but no one= ever followed up on the lists. I'm bringing this up again, in the hopes tha= t I can get some feedback before / during next week's Dev/Vendor Summit. I'm= CCing some folks who expressed interest at that time, and some folks that I= was told would be interested. > ---------------------------------------------------------------- >=20 > At Panasas, we found it useful to have a trace buffer for each ATA drive i= n the system, for gathering information about command sequences and latency.= I implemented that functionality for our old 7-ish ATA driver, and it works= quite well, with fairly low overhead. (I ran our usual suite of performance= tests, and any differences were lost in the noise.) These traces allowed us= to capture and replay access patterns (though obviously not with the same d= ata), analyze and compare latency, etc. >=20 > As Panasas moves toward a more modern base, we want to re-implement this f= unctionality for ATA, SCSI, NVMe, etc. And push it upstream, of course! :-) >=20 > First, some example output; I wrote code for three different formats: > - The binary trace buffer dump > Useful for manipulating in C; the other two formats are post-processed o= ut of this, and I also wrote a replay utility and a basic stats analyzer whi= ch operated on the binary dump. > - Tabular hex > Useful for parsing with scripts; I never actually used this format, but= it was trivial so I just went ahead and wrote it. > - Human-readable > Useful for eyeballing; on more than one occasion, I was able to see tha= t I had mis-assembled a command in userspace, etc. >=20 > These examples are actually really long lines; I've broken them up and ind= ented for the sake of email: >=20 > # Tabular hex format, for use w/ scripts > # Request time ATA request information Response time =20 > ATA response information sts/err flags > 1445839793003737 c8 0000 0004 000000002fa8 1445839793003806 =20 > c8 0000 0004 000000002fa8 50 00 0000007d > 1445839793003874 c8 0000 0020 000000113ac8 1445839793011541 =20 > c8 0000 0020 000000113ac8 50 00 0000007d > 1445839793011795 c8 0000 0008 000000118ca8 1445839793017702 =20 > c8 0000 0008 000000118ca8 50 00 0000007d > 1445839793017808 c8 0000 0080 000000117628 1445839793018975 =20 > c8 0000 0080 000000117628 50 00 0000007d > 1445839793019079 c8 0000 0020 0000001177a8 1445839793019686 =20 > c8 0000 0020 0000001177a8 50 00 0000007d >=20 > # Human-readable > FLAGS REQUEST TIME RESPONSE TIME ELAPSED TIME = =20 > REQUEST COMMAND STATUS ERROR =20 > RESPONSE COMMAND =20 > ----------- -------------------- -------------------- -----------------= ---=20 > ---------------------------------------- -------- --------=20 > ---------------------------------------- > ____C...._V 1445839793003737 1445839793003806 69 = =20 > READ DMA (LBA 12200 + 4 sectors) _R_S____ ________=20 > ---- =20 > ____C...._V 1445839793003874 1445839793011541 7667 = =20 > READ DMA (LBA 1129160 + 32 sectors) _R_S____ ________=20 > ---- =20 > ____C...._V 1445839793011795 1445839793017702 5907 = =20 > READ DMA (LBA 1150120 + 8 sectors) _R_S____ ________=20 > ---- =20 > ____C...._V 1445839793017808 1445839793018975 1167 = =20 > READ DMA (LBA 1144360 + 128 sectors) _R_S____ ________=20 > ---- =20 > ____C...._V 1445839793019079 1445839793019686 607 = =20 > READ DMA (LBA 1144744 + 32 sectors) _R_S____ ________=20 > ---- =20 >=20 > The obvious place to put this sort of tracing would be in GEOM, but that a= ctually isn't what I want, for a few reasons. First of all, I'm primarily in= terested in the exact register / taskfile / CDB values sent to the drive - o= pcode, feature codes, LBAs, etc. Second, I'm interested in hardware-level la= tency - how long does a request stay in the controller and device. Both of t= hose pretty much require working below GEOM. >=20 > Therefore, I think I want to do it in the CAM stack; ideally, I'd put the h= ooks in the SIM drivers, to get as close to the metal as possible, to get th= e most accurate latency. However, even a light touch to every SIM driver is g= oing to be painful, and since I don't have access to every controller in the= world, testing would be difficult. Adding the hooks to da(4) and ada(4) wou= ld still be pretty close to the metal, and would require much smaller change= s. Or maybe they belong in the XPT layer? (I don't know nearly as much about= CAM as I should. :-/) >=20 > -------- > NOTE: When I mentioned this idea at a (San Francisco) Bay Area FreeBSD Use= r Group (BAFUG) meeting, there were suggestions about integrating this with D= Trace or KTrace instead. I'm happy to consider either of those, but I know e= ven less about those than I do about CAM. If that's really the best way to d= o this sort of thing, I'm happy to learn, if someone is willing to teach. > -------- >=20 > I took the Panasas / 7.x implementation, and pseudo-coded what it might lo= ok like in CAM. (I could probably make diffs against the old ATA stack avail= able for comparison, but I figured no one would care anymore.) A huge caveat= is that I've never really poked in CAM before, so I fully expect I'm doing s= everal things wrong. Please educate me. :-) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Create a circular buffer of trace records for each CAM PERIPH. Each record= will contain the full CDB for the request as sent to the device, the timest= amp (in usec) of the request, the CDB as returned by the device, the timesta= mp of the response, and the status and error code. Additionally, flags are p= rovided to track the state of the trace record, and to indicate which type o= f periph the record is associated with. >=20 > -------- >=20 > typedef struct { > u_int32_t flags; > #define CAM_TRACE_F_VALID 0x00000001 /* valid record */ > #define CAM_TRACE_F_INPROGRESS 0x00000002 /* request in progress */ > #define CAM_TRACE_F_REQ_VALID 0x00000004 /* request data valid */ > #define CAM_TRACE_F_RESP_VALID 0x00000008 /* response data valid */ > #define CAM_TRACE_F_COMPLETE 0x00000010 /* response gathered */ > #define CAM_TRACE_F_TIMEDOUT 0x00000020 /* request timed out */ > #define CAM_TRACE_F_ABANDONED 0x00000040 /* cancelled, etc. */ > #define CAM_TRACE_F_RETRIED 0x00000080 /* retry in later record */ > #define CAM_TRACE_F_IS_RETRY 0x00000100 /* retry of earlier req. */ > #define CAM_TRACE_F_PERIPH_MASK 0xf0000000 /* up to 16 PERIPH types *= / > #define CAM_TRACE_F_PERIPH_DA 0x0 > #define CAM_TRACE_F_PERIPH_ADA 0x1 > #define CAM_TRACE_F_PERIPH_NVD 0x2 > u_int64_t req_usec; > cdb_t req_cdb; > u_int64_t resp_usec; > cdb_t resp_cdb; > u_int8_t resp_status; > u_int8_t resp_error; > u_int8_t resp_asc; /* Needed for SCSI? */ > u_int8_t resp_asq; /* Needed for SCSI? */ > u_int8_t padding[8]; /* Pad to 64 bytes */ > /* There's going to be a large-ish array of these in the kernel; make sure= > * they're packed to minimize space usage, and keep things aligned. It may > * make sense to re-order the fields for alignment as well. > */ > } cam_trace_record_t __attribute__((packed, aligned(8))); >=20 > typedef struct { > u_int32_t trace_buf_record_count; > cam_trace_record_t *trace_buf; > } cam_trace_buffer_t; >=20 > /* This is settable via a tunable; for Panasas' purposes, 100K entries was= > * enough to provide a good amount of history even on a busy system, while > * not taking up much space (< 5MB/drive). > */ > #define CAM_TRACE_BUFFER_DEFAULT_COUNT 100000 >=20 > ---------------- >=20 > ioctl interfaces are used to get the trace buffer size, to retrieve the bu= ffer contents, or to clear the buffer. The buffer can then be analyzed from u= serspace, or written to a file for post-processing. >=20 > -------- >=20 > #define CAM_GET_TRACE_RECORD_COUNT _IOR(???, ???, u_int32_t) > #define CAM_GET_TRACE_BUFFER _IOWR(???, ???, cam_trace_buffer_t) > #define CAM_CLEAR_TRACE_BUFFER _IOW(???, ???, u_int32_t) >=20 > ---------------- >=20 > To get the buffer: >=20 > -------- >=20 > cam_trace_buffer_t trace =3D NULL; > fd =3D open(periph_name, O_RDONLY); > error =3D ioctl(fd, CAM_GET_TRACE_RECORD_COUNT, > &trace.trace_buf_record_count); > trace.trace_buf =3D malloc(trace.trace_buf_record_count * > sizeof(cam_trace_record_t)); > error =3D ioctl(fd, CAM_GET_TRACE_BUFFER, &trace); >=20 > ---------------- >=20 > By including the full CDB, the entire command can be decoded by analysis t= ools. Tools can be written to parse the buffer and translate command data in= to human-readable descriptions, calculate elapsed times for requests, perfor= m statistical analysis based on opcode, command type, transfer size, etc. Co= mmand decoders would need to be written for each PERIPH type (i.e. one for A= TA, one for SCSI, one for NVMe, etc.). >=20 > ---------------- >=20 > Each PERIPH's softc needs to include some information about the per-device= > buffer. >=20 > -------- >=20 > u_int32_t trace_buf_record_count; > u_int64_t trace_buf_request_count; > cam_trace_record_t *trace_buf; >=20 > ---------------- >=20 > In each SIM, there should already be some sort of request structure, which= associates the softc and the CDB of the request. To that structure, add a p= ointer to the trace record associated with the request. >=20 > -------- >=20 > request structure: > cam_trace_record_t *trace_rec; >=20 > ---------------- >=20 > When initializing the per-device softc, allocate a trace buffer. The numbe= r of records can be hard-coded, or settable via a tunable. >=20 > The example below has a global size for everything, but it should be possi= ble to do it on a per-device or per-PERIPH basis. >=20 > -------- >=20 > /** Initialize per-drive command tracing buffer. **/ > /* Get the buffer size from the tunable. Sanity check it. */ > sc->trace_buf_record_count =3D CAM_TRACE_BUFFER_DEFAULT_COUNT; > TUNABLE_ULONG_FETCH("cam.trace_buf_record_count", > &trace_buf_record_count_tunable); > if (trace_buf_record_count_tunable) { > /* Less than 1K records is unusably few; more than 1M > * records is unusably many. > */ > if ((trace_buf_record_count_tunable < (1 << 10)) || > (trace_buf_record_count_tunable > (1 << 20))) { > device_printf(dev, "cam.trace_buf_record_count=3D%lu" > " out of range; should be between %u and %u\n", > trace_buf_record_count_tunable, (1 << 10), > (1 << 20)); > } else { > sc->trace_buf_record_count =3D (u_int32_t) > trace_buf_record_count_tunable; > } > } > /* Allocate the buffer. */ > trace_buf_bytes =3D sc->trace_buf_record_count * > sizeof(cam_trace_record_t); > sc->trace_buf =3D malloc(trace_buf_bytes, M_AD, M_NOWAIT | M_ZERO); > if (sc->trace_buf =3D=3D NULL) { > device_printf(dev, "unable to allocate %zd for trace_buf\n", > trace_buf_bytes); > sc->trace_buf_record_count =3D 0; > } else { > device_printf(dev, "allocated %zd @ %p for trace_buf\n", > trace_buf_bytes, sc->trace_buf); > } > /* Request counter, used for indexing */ > sc->trace_buf_request_count =3D 0; >=20 >=20 > ---------------- >=20 > /* Initial setup of the trace record for a new request. > * > * Locate the circular per-device trace buffer in the drive's softc. > * Populate the pointer to the next record in the trace buffer; this is > * done atomically to prevent concurrent requests from getting the same > * index. That could get a bit weird if/when 'trace_buf_request_count' > * rolls over, if the maximum counter value is not a multiple of > * 'trace_buf_record_count' (i.e. the request counter recycles in the > * middle of the buffer). By using a 64-bit request counter, we're pretty > * safe - even at one transaction per nanosecond, that will still last > * about 585 years. > * > * Initialize the record by zeroing it and then setting the VALID flag. > * > * This could be done at any point before sending the request to the > * hardware; neither the CDB data nor the timestamps are involved yet. > */ > void > trace_rec_init(cam_request_t req) { > ada_softc *sc =3D (request->...->softc) > u_int64_t tmp =3D 0; > if (sc && sc->trace_buf) { > tmp =3D atomic_fetchadd_log(&sc->trace_buf_request_count, 1); > req->trace_rec =3D &sc->trace_buf[tmp % > sc->trace_buf_record_count]; > bzero(req->trace_rec, sizeof(*req->trace_rec)); > req->trace_rec->flags =3D (CAM_TRACE_F_PERIPH_XXX << 28); > req->trace_rec->flags |=3D CAM_TRACE_F_VALID; > } else { > req->trace_rec =3D NULL; > } > } >=20 > ---------------- >=20 > /* Stuff the request data into the trace record. > * > * If the trace record is present and valid, copy the CDB into the > * record. Set CAM_TRACE_F_REQ_VALID to indicate that the request data is > * valid, and INPROGRESS to show that the request is in-progress. > * > * This should be done just before sending the request to the hardware. > * This should *not* be fused into trace_rec_init(), because > * trace_rec_init() is also used in the retry case, where it is not > * correct to immediately start the timer. > */ > void > trace_rec_req(cam_request_t req) { > struct timeval tv; > if (req->trace_rec && (req->trace_rec->flags & CAM_TRACE_F_VALID)) { > bcopy(req->cdb, req->trace_rec->req_cdb, sizeof(req->cdb)); > microuptime(&tv); > req->trace_rec->req_usec =3D ((uint64_t) tv->tv_sec * 1000000) > + tv->tv_usec; > req->trace_rec->flags |=3D > (CAM_TRACE_F_REQ_VALID | CAM_TRACE_F_INPROGRESS); > } > } >=20 > ---------------- >=20 > /* Stuff the response data into the trace record. > * > * If the trace record is present and valid, copy the CDB **as returned by= > * the drive** into the record. At this point, we also have the result fro= m > * the command (status, error, (asc? ascq?)), so save them too. Set > * CAM_TRACE_F_RESP_VALID to indicate that the response data is valid. > * Clear INPROGRESS and set COMPLETE instead. > * > * This should be done just after getting the response information from th= e > * hardware. > */ > void > trace_rec_resp(cam_request_t req) { > struct timeval tv; > if (req->trace_rec && (req->trace_rec->flags & CAM_TRACE_F_VALID)) { > microuptime(&tv); > bcopy(req->cdb, req->trace_rec->resp_cdb, sizeof(req->cdb)); > req->trace_rec->resp_usec =3D ((uint64_t) tv->tv_sec * > 1000000) + tv->tv_usec; > req->trace_rec->flags |=3D > (CAM_TRACE_F_RESP_VALID | CAM_TRACE_F_COMPLETE); > req->trace_rec->flags &=3D ~CAM_TRACE_F_INPROGRESS; > } > } >=20 > ---------------- >=20 > /* Update the trace record if there was a timeout. > * > * If the trace record is present and valid, set TIMEDOUT to indicate > * that the request associated with the record exceeded its timeout. > * Since this attempt is complete, clear INPROGRESS and set COMPLETE. > * > * This should be done along with other timeout handling. > */ > void > trace_rec_timeout(cam_request_t req) { > if (req->trace_rec && (req->trace_rec->flags & CAM_TRACE_F_VALID)) { > req->trace_rec->flags |=3D > (CAM_TRACE_F_TIMEDOUT | CAM_TRACE_F_COMPLETE); > req->trace_rec->flags &=3D ~CAM_TRACE_F_INPROGRESS; > } > } >=20 > ---------------- >=20 > /* Update the trace record if the request is being retried. > * =20 > * If the trace record is present and valid, set RETRIED to indicate > * that the request associated with the record is going to be retried. > * Since this attempt is complete, clear INPROGRESS and set COMPLETE. > * Then get a new trace record for the new attempt, copy the request > * command data to the new record, and set IS_RETRY to show that this > * is a retry of an earlier request. > * > * This should be done at the time the retry is queued. > */ > void > trace_rec_retry(cam_request_t req) { > if (req->trace_rec && (req->trace_rec->flags & CAM_TRACE_F_VALID)) { > /* First, mark the original request as being requeued. */ > req->trace_rec->flags |=3D > (CAM_TRACE_F_RETRIED | CAM_TRACE_F_COMPLETE); > req->trace_rec->flags &=3D ~CAM_TRACE_F_INPROGRESS; > /* Get a new record for the retry. */ > trace_rec_init(req); > /* Mark the new record as being a retry. */ > req->trace_rec->flags |=3D CAM_TRACE_F_IS_RETRY; > } > } >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > I'd appreciate feedback, both on the implementation details and on the ide= a as a whole. Some open questions are: >=20 > - My assumption is that each SIM has a structure that associates a PERIPH'= s softc with the CDB that's being processed. It might require dereferencing a= chain of pointers, but it should be there in some fashion. >=20 > - The current implementation adds a few ioctls to the old ad(4) disk-devic= e driver. I would expect to add the new ioctls to da(4) and ada(4); is that t= he right thing to do? >=20 > Again, any feedback would be greatly appreciated. I'll be at the Dev/Vendo= r Summit next week, if anyone wants to discuss this with me in person. >=20 > Thanks, >=20 > Ravi > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Oct 27 04:22:52 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA863A066CE; Tue, 27 Oct 2015 04:22:52 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0084.outbound.protection.outlook.com [207.46.100.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23EBE1E16; Tue, 27 Oct 2015 04:22:51 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1801.namprd08.prod.outlook.com (10.162.218.23) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 04:22:49 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 04:22:49 +0000 From: "Pokala, Ravi" To: Scott Long CC: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Subject: Re: Low-level trace-buffers in CAM Thread-Topic: Low-level trace-buffers in CAM Thread-Index: AQHREF5W2DCPOIdjUUGMRg6fRJs3w55+qNQA//+fWoA= Date: Tue, 27 Oct 2015 04:22:49 +0000 Message-ID: <12D1A6F3-2C2B-4912-B752-7DDF9EB09CD9@panasas.com> References: <2C9653BA-CC10-497B-ACEF-0C76AAE2FF44@yahoo.com> In-Reply-To: <2C9653BA-CC10-497B-ACEF-0C76AAE2FF44@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.6.178.251] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1801; 5:4djtNbEwtU6shvp5hZnmyquE8kbmrx8oA9lb48KOHqa1dm6AF2+y19rHFwkJeqCLp2UWH7acWCYOtt81masGdyrDw5Wq3ljLXNpHrf7xzHs6ibAaZByfcnRIrIscnLoWcwm6whVK3/gMkiot7KEZJA==; 24:7JWPSg0Mj80J+9v9M/IpbEUw27vtAmBzd7U9YFbsJOGmcbIflNaKiUSH1fVz8CmalsUVhy5hVPwTu6w3/YznbTKho7Du66XelIVvOzetd18=; 20:EU/c1mX/qDZ5BKIpDSBfANGdb9ItBFFqsFH265+GtBakPyHkZkx44kUjs+QX7v8O64CJHTZvCS4Rg1vGu7tbpg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1801; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(201166117486090)(239227872634102); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:CY1PR08MB1801; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1801; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377424004)(199003)(189002)(189998001)(66066001)(5004730100002)(33656002)(11100500001)(5007970100001)(2900100001)(5008740100001)(5001960100002)(10400500002)(102836002)(77096005)(110136002)(2950100001)(92566002)(5002640100001)(4001150100001)(19580405001)(81156007)(97736004)(19580395003)(83506001)(82746002)(106116001)(87936001)(40100003)(122556002)(105586002)(2521001)(36756003)(86362001)(99286002)(4001350100001)(50986999)(106356001)(101416001)(76176999)(54356999)(83716003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1801; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7674820A88048243B3C70D2E851DBE35@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 04:22:49.2661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1801 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 04:22:53 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KDQpGcm9tOiBTY290dCBMb25nIDxzY290dDRs b25nQHlhaG9vLmNvbT4NCkRhdGU6IDIwMTUtMTAtMjYsIE1vbmRheSBhdCAyMDowOA0KVG86IFJh dmkgUG9rYWxhIDxycG9rYWxhQHBhbmFzYXMuY29tPg0KQ2M6ICJmcmVlYnNkLWdlb21AZnJlZWJz ZC5vcmciIDxmcmVlYnNkLWdlb21AZnJlZWJzZC5vcmc+LCAiZnJlZWJzZC1zY3NpQGZyZWVic2Qu b3JnIiA8ZnJlZWJzZC1zY3NpQGZyZWVic2Qub3JnPiwgImZyZWVic2QtaGFja2Vyc0BmcmVlYnNk Lm9yZyIgPGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZz4sICJrZW5AZnJlZWJzZC5vcmciIDxr ZW5AZnJlZWJzZC5vcmc+LCAiaW1wQGZyZWVic2Qub3JnIiA8aW1wQGZyZWVic2Qub3JnPiwgInNj b3R0bEBmcmVlYnNkLm9yZyIgPHNjb3R0bEBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJlOiBMb3ct bGV2ZWwgdHJhY2UtYnVmZmVycyBpbiBDQU0NCg0KPkhpIFJhdmksDQo+DQo+WWVzIEkgd2FzIG9u ZSBvZiB0aGUgcGVvcGxlIHdobyBuZXZlciBmb2xsb3dlZCB1cC4NCg0KTm8gd29ycmllcy4gSSdt IGp1c3Qgbm93IGNpcmNsaW5nIGJhY2sgYXJvdW5kIHRvIGl0IG15c2VsZi4NCg0KPkknbGwgYmUg YXQgdGhlIHZlbmRvciBzdW1taXQgbmV4dCB3ZWVrLCBsZXQncyBjaGF0IHNvbWUgbW9yZS4NCg0K TG9va2luZyBmb3J3YXJkIHRvIGl0LiBTZWUgeW91IHRoZW4uDQoNCi1SYXZpDQoNCj5TY290dA0K From owner-freebsd-hackers@freebsd.org Tue Oct 27 04:56:34 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81786A06CC6; Tue, 27 Oct 2015 04:56:34 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bn0100.outbound.protection.outlook.com [157.56.110.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FC7018AB; Tue, 27 Oct 2015 04:56:33 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1801.namprd08.prod.outlook.com (10.162.218.23) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 04:21:58 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 04:21:58 +0000 From: "Pokala, Ravi" To: Adrian Chadd CC: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Subject: Re: Low-level trace-buffers in CAM Thread-Topic: Low-level trace-buffers in CAM Thread-Index: AQHREF5W2DCPOIdjUUGMRg6fRJs3w55+pEiA//+jqQA= Date: Tue, 27 Oct 2015 04:21:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.6.178.251] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1801; 5:US3Ailkrpkb9jcOEy1WylEDtrYnQS67nzRpt/ILe9Xg92Tgo0yIh7cMUWI0e1SpZgwff+x8/WufAIQmXydlaAI8rc27LZMwQ9lva7hLW108g69OF5pst7kF3pvqJv2t2/YSeBSZW7pbRbi71nYQQjQ==; 24:5ziYBHVUzSIPwL+JEAKXKMe86GFDhbcEofIOJ225d2tY5ehJUFeg7H2uavSzqyGJsw+j41QPnJET9jmO38hFSmrM5DGdwCo7DuLv93Vkrxo=; 20:MaU9/bUsYZ83xEYB3IY9HLgjOG0Z4ThlotUIgZGcyxY0C62ToDlUVb4jpkeWXJ7lV9MIUwxPPoQ/eEun7DjbiQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1801; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(239227872634102); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:CY1PR08MB1801; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1801; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(377424004)(199003)(189002)(189998001)(66066001)(5004730100002)(33656002)(11100500001)(5007970100001)(2900100001)(5008740100001)(5001960100002)(10400500002)(102836002)(77096005)(110136002)(2950100001)(92566002)(5002640100001)(4001150100001)(19580405001)(81156007)(97736004)(19580395003)(83506001)(82746002)(106116001)(87936001)(40100003)(122556002)(105586002)(36756003)(86362001)(99286002)(4001350100001)(50986999)(106356001)(101416001)(76176999)(54356999)(83716003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1801; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <977EA068F5C318448D0D73F79294A6FB@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 04:21:58.2318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1801 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 04:56:34 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KDQpGcm9tOiBBZHJpYW4gQ2hhZGQgPGFkcmlh bi5jaGFkZEBnbWFpbC5jb20+DQpEYXRlOiAyMDE1LTEwLTI2LCBNb25kYXkgYXQgMTk6NTINClRv OiBSYXZpIFBva2FsYSA8cnBva2FsYUBwYW5hc2FzLmNvbT4NCkNjOiAiZnJlZWJzZC1nZW9tQGZy ZWVic2Qub3JnIiA8ZnJlZWJzZC1nZW9tQGZyZWVic2Qub3JnPiwgImZyZWVic2Qtc2NzaUBmcmVl YnNkLm9yZyIgPGZyZWVic2Qtc2NzaUBmcmVlYnNkLm9yZz4sICJmcmVlYnNkLWhhY2tlcnNAZnJl ZWJzZC5vcmciIDxmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmc+LCAia2VuQGZyZWVic2Qub3Jn IiA8a2VuQGZyZWVic2Qub3JnPiwgImltcEBmcmVlYnNkLm9yZyIgPGltcEBmcmVlYnNkLm9yZz4s ICJzY290dGxAZnJlZWJzZC5vcmciIDxzY290dGxAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTog TG93LWxldmVsIHRyYWNlLWJ1ZmZlcnMgaW4gQ0FNDQoNCj5IaSwNCj4NCj5vay4gU28gdGhpcyBp cyB3aGVyZSBJIGNyZWF0ZSB3b3JrIGZvciBwZW9wbGUuIDotKQ0KDQpUc2ssIHRzayEgKkkqIHdv dWxkIG5ldmVyIGRvIHN1Y2ggYSB0aGluZyEgOy0pDQoNCj5Tb21ldGhpbmcgSSd2ZSBiZWVuIHRv c3NpbmcgdXAgZm9yIHF1aXRlIHNvbWUgdGltZSBpcyBhIGdlbmVyaWMgdmVyc2lvbiBvZiB0aGlz IHRoYXQgZXhwb3NlcyBhIHJpbmctYnVmZmVyIG9mIGVudHJpZXMgYmFjayB0byB1c2VybGFuZC4g Rm9yIHRoaW5ncyBsaWtlIHRoaXMsIHRoaW5ncyBsaWtlIEFMUS9LVFIsIGV0YywgaXQncyBhbGwg anVzdCBhIHByb2R1Y2VyLWNvbnN1bWVyIHJpbmcgYmFzZWQgdGhpbmcuIFlvdSBkb24ndCBldmVu IGNhcmUgYWJvdXQgbXVsdGlwbGUgcmVhZGVyczsgdGhhdCdzIGEgdXNlcmxhbmQgdGhpbmcuDQo+ DQo+U28sIEknbSBhIGJpZyBmYW4gb2YgdGhpcy4gSSBkaWQgdGhpcyBmb3IgdGhlIGF0aCBkcml2 ZXIgdG8gZGVidWcgZGVzY3JpcHRvcnMgYW5kIHJlZ2lzdGVyIGFjY2Vzc2VzIGFuZCBpdCB3YXMg YSBiaWcgaGVscC4gSSdkIHJlYWxseSBsaWtlIHRvIHNlZSBhIG1vcmUgZ2VuZXJpYyB3YXkgd2Ug Y2FuIGV4cG9zZSB0aGlzIGRhdGEgaW4gYW4gZWZmaWNpZW50IG1hbm5lciENCg0KSSdtIGhhdmlu ZyB0cm91YmxlIHBhcnNpbmcgdGhhdCAtIGl0J3MgYmVlbiBhIGxvbmcgZGF5LiBZb3UncmUgdGFs a2luZyBhYm91dCBjcmVhdGluZyBhIGdlbmVyaWMgaW4ta2VybmVsIHJpbmctYnVmZmVyIGltcGxl bWVudGF0aW9uLCB0aGF0IHdlIGNvdWxkIGxldmVyYWdlIGZvciAoQ0FNIHRyYWNpbmcgfCBLVFIg fCB3aGF0ZXZlcik/IExpa2Ugd2UgZGlkIGZvciB2YXJpb3VzIGxpc3QgYW5kIHF1ZXVlIHR5cGVz IGluIDxzeXMvcXVldWUuaD4/IFRoYXQncyBhIGdvb2QgaWRlYSwgYnV0IEkgZ28gY3Jvc3MtZXll ZCBhbnkgdGltZSBJIGxvb2sgdG9vIGNsb3NlbHkgYXQgYWxsIHRoZSBwcmVwcm9jZXNzb3ItZnUg aW4gdGhlcmUuIDotKQ0KDQotUmF2aQ0KDQo+LWENCg== From owner-freebsd-hackers@freebsd.org Tue Oct 27 09:05:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4988A8246 for ; Tue, 27 Oct 2015 09:05:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 58D9419F1; Tue, 27 Oct 2015 09:05:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA16928; Tue, 27 Oct 2015 11:05:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Zr0CM-000GsT-U7; Tue, 27 Oct 2015 11:05:42 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <562F3E2F.2010100@FreeBSD.org> Date: Tue, 27 Oct 2015 11:04:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151021184850.GX2257@kib.kiev.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 09:05:46 -0000 On 21/10/2015 21:48, Konstantin Belousov wrote: > Am I right that the tsc synchronization test passes on your machine ? Yes. > If yes, you probably cannot read 'slightly behind' timecounter after IPI > on other core. Right. But please note that my hypothesis does not require that the following is true: CPU_A reads TSC value X, CPU_A sends an IPI to CPU_B, CPU_B gets the IPI, CPU_B reads TSC value Y, Y < X. In my configuration there is one master CPU and 3 slaves. Also, it could be possible that the IPI is delayed for so long that there is an interaction between handling of 2 consecutive hardclock IPIs. > Might be, try to change CPUID instruction in the test to > MFENCE and see if the test still able to pass. > Does the symptom disappear if you switch the eventtimer to LAPIC ? And now another observation. I have C1E option enabled in BIOS. It means that if all cores enter C1 state, then the whole processor is magically placed into a deep C-state (C3, I think). LAPIC timer on this CPU model does not run in the deep C-state. So, I had to disable C1E option to test the LAPIC timer in a useful way. But before actually testing it I first tried to reproduce the problem. As you might have already guessed the problem is gone with that option disabled. Scratching my head to understand the implications of this observation. > What happens if you turn off usermode gettimeofday() > by setting kern.timercounter.fast_gettime to 0 ? -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Oct 27 11:58:21 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B176A1FAF0 for ; Tue, 27 Oct 2015 11:58:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED3FD15CC; Tue, 27 Oct 2015 11:58:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9RBwAda032337 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Oct 2015 13:58:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9RBwAda032337 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9RBwAWT032332; Tue, 27 Oct 2015 13:58:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Oct 2015 13:58:10 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim Subject: Re: instability of timekeeping Message-ID: <20151027115810.GU2257@kib.kiev.ua> References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562F3E2F.2010100@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 11:58:21 -0000 On Tue, Oct 27, 2015 at 11:04:47AM +0200, Andriy Gapon wrote: > And now another observation. I have C1E option enabled in BIOS. It > means that if all cores enter C1 state, then the whole processor > is magically placed into a deep C-state (C3, I think). LAPIC timer > on this CPU model does not run in the deep C-state. So, I had to > disable C1E option to test the LAPIC timer in a useful way. But > before actually testing it I first tried to reproduce the problem. As > you might have already guessed the problem is gone with that option > disabled. Scratching my head to understand the implications of this > observation. Most obvious explanation would be that the latency of wakeup is very large. What is the HPET frequency when the jitter occur ? From owner-freebsd-hackers@freebsd.org Tue Oct 27 13:51:08 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DA2A1E7A2 for ; Tue, 27 Oct 2015 13:51:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D0AF01369; Tue, 27 Oct 2015 13:51:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA20802; Tue, 27 Oct 2015 15:50:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Zr4eQ-000HBQ-Qd; Tue, 27 Oct 2015 15:50:58 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon Message-ID: <562F8109.4050203@FreeBSD.org> Date: Tue, 27 Oct 2015 15:50:01 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151027115810.GU2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 13:51:08 -0000 On 27/10/2015 13:58, Konstantin Belousov wrote: > On Tue, Oct 27, 2015 at 11:04:47AM +0200, Andriy Gapon wrote: >> And now another observation. I have C1E option enabled in BIOS. It >> means that if all cores enter C1 state, then the whole processor >> is magically placed into a deep C-state (C3, I think). LAPIC timer >> on this CPU model does not run in the deep C-state. So, I had to >> disable C1E option to test the LAPIC timer in a useful way. But >> before actually testing it I first tried to reproduce the problem. As >> you might have already guessed the problem is gone with that option >> disabled. Scratching my head to understand the implications of this >> observation. > > Most obvious explanation would be that the latency of wakeup is very large. > What is the HPET frequency when the jitter occur ? > kern.timecounter.tc.TSC-low.frequency: 1607351869 kern.eventtimer.et.HPET.frequency: 14318180 Or did you mean the actual rate of timer interrupts? -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Oct 27 14:00:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADBE7A1E9FB for ; Tue, 27 Oct 2015 14:00:39 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B5311A8F for ; Tue, 27 Oct 2015 14:00:38 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id t9RDu86h051159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 27 Oct 2015 14:56:09 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.15.2/8.15.2) with ESMTP id t9RLxeG7000699 for ; Tue, 27 Oct 2015 22:59:40 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.15.2/8.15.2/Submit) with ESMTP id t9RLxZ8a000696 for ; Tue, 27 Oct 2015 22:59:35 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Tue, 27 Oct 2015 22:59:35 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: freebsd-hackers@freebsd.org Subject: Z36xxx Graphics & display Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Tue, 27 Oct 2015 14:56:09 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:00:39 -0000 vgapci0@pci0:0:2:0: class=0x030000 card=0x390517aa chip=0x0f318086 rev=0x0e hdr=0x00 vendor = 'Intel Corporation' device = 'Atom Processor Z36xxx/Z37xxx Series Graphics & Display' class = display subclass = VGA is it supported in newer i915kms? i run FreeBSD 10.2 and seems like i815kms doesn't know this device. Xorg runs with vesa driver...slowly. From owner-freebsd-hackers@freebsd.org Tue Oct 27 14:04:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68665A1EC4D for ; Tue, 27 Oct 2015 14:04:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4B50107B; Tue, 27 Oct 2015 14:04:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9RE43Pi069729 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Oct 2015 16:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9RE43Pi069729 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9RE434G069728; Tue, 27 Oct 2015 16:04:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Oct 2015 16:04:03 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim Subject: Re: instability of timekeeping Message-ID: <20151027140403.GB2257@kib.kiev.ua> References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562F8109.4050203@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:04:12 -0000 On Tue, Oct 27, 2015 at 03:50:01PM +0200, Andriy Gapon wrote: > On 27/10/2015 13:58, Konstantin Belousov wrote: > > On Tue, Oct 27, 2015 at 11:04:47AM +0200, Andriy Gapon wrote: > >> And now another observation. I have C1E option enabled in BIOS. It > >> means that if all cores enter C1 state, then the whole processor > >> is magically placed into a deep C-state (C3, I think). LAPIC timer > >> on this CPU model does not run in the deep C-state. So, I had to > >> disable C1E option to test the LAPIC timer in a useful way. But > >> before actually testing it I first tried to reproduce the problem. As > >> you might have already guessed the problem is gone with that option > >> disabled. Scratching my head to understand the implications of this > >> observation. > > > > Most obvious explanation would be that the latency of wakeup is very large. > > What is the HPET frequency when the jitter occur ? > > > > kern.timecounter.tc.TSC-low.frequency: 1607351869 > kern.eventtimer.et.HPET.frequency: 14318180 > > Or did you mean the actual rate of timer interrupts? Actual rate, and I used the wrong word. Since most likely your eventtimer is not periodic, I mean the next timer interrupt deadline. From owner-freebsd-hackers@freebsd.org Tue Oct 27 18:31:07 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B22CBA1F9F8 for ; Tue, 27 Oct 2015 18:31:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 288C8118A for ; Tue, 27 Oct 2015 18:31:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id f64bc910 for ; Tue, 27 Oct 2015 19:24:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :subject:message-id; s=mail; bh=Q2pdb/ZRMfaudiNhHH2Uk/J0m0k=; b= WritF0zTztcqH/2dXd+1cqmnt2aSP7flLBCAz5U7uh8mjlfTjfyYjOwGIOkU4pRm JeL/Y7fP01G3YqVw4TyOled4YcT38p616a1uFySwy13PKPn6ZEZML75NG/XVXFBu QE8JLycFymBQDa0LEMPH9agXCiYRQtUIS7D0m+KW9cA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :subject:message-id; q=dns; s=mail; b=pCobrJEQLLsaYWIARzfmcojA/Q GK+FckruEt8q6MHujoZxwwyhaQ8F4Avt2gKG189DGdUqKbI1c2fzeALFdRKgKHmO zzeV3hrEme4fyq8Z3eu4nmTL9vOn1/5j8WxmtF3rdNtqmIJ/43qbiOBM0aKscvWV oMLQHNExiie6ebUw8= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id d481102e for ; Tue, 27 Oct 2015 19:24:23 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 Oct 2015 19:24:23 +0100 From: Emmanuel Vadot To: freebsd-hackers Subject: EFI Variables Organization: Bidouilliste Message-ID: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 18:31:07 -0000 Hello all, I'm currently hacking around the loader.efi I've added the possibility to change background/foreground colors (not very useful I know). I've also added the list and get command to the not working "nvram" command. CUrrently the variables are printed in the form "${var}-${guid}" (Result of a nvram list command : https://pbs.twimg.com/media/CSVxdzMW0AEEVo4.jpg) The "get" subcommand print the content of the variable (passed without the guid) as if it is a unicode string even if a variable can contain any data possible. For the "set" subcommand I think that the best way to handle it is : "nvram set myvar data" -> This will set the variable myvar to data with the freebsd guid (if there is any) and "nvram set myvar guid data" -> This will force the guid to I'll look tomorrow how to access efivars once the kernel is booted so we can set some from some userland tool (especially the boot related one). Is any of you guys uses efivars for something not boot-releated ? I'm interested in any usage of efi variables. You can see my change on my github branch : https://github.com/evadot/freebsd/tree/loader_efi Cheers, -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Tue Oct 27 21:06:52 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E94C2A1C67E for ; Tue, 27 Oct 2015 21:06:52 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 B0D9B1FA7 for ; Tue, 27 Oct 2015 21:06:52 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: by obctp1 with SMTP id tp1so154412289obc.2 for ; Tue, 27 Oct 2015 14:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CZOxizTvo/ScmbCuRZkwcIeKjA+Gv2PCsS2mKC0vz7I=; b=FNj5uKOFhgTs6vY6+nZcuzXbGYf/wlocrBYWaccAiOIlExncOtpW8FTDi9GYHQcF7C b73jpkAD230VnIZc7FY5C4rj+KLxdvtXw0J5JEnKKSBhj/cyXXnQix3PBWS4QfHoCl7q FQMvL881hqUJiLv3gJij2DwkghO9CDtP42AmTS3wfGhkHtl7b+4tK1OMNBYXRqcyXiZ4 pygvNC9k2hhKUTg453toSLRrqxqHiDOZgFbWw4mbY7NmWKISC8H/MvZ3isNvhVaTTPcJ SX6cdHWA/jUHtZklYxpjWFNzxiUWSudYaXMDOOrTG5LfHl+7HhODrip52lKuYspkKgOf /heA== X-Received: by 10.182.22.198 with SMTP id g6mr4796205obf.50.1445980012186; Tue, 27 Oct 2015 14:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.231 with HTTP; Tue, 27 Oct 2015 14:06:32 -0700 (PDT) From: Gabor Radnai Date: Tue, 27 Oct 2015 22:06:32 +0100 Message-ID: Subject: Re: EFI/ZFS Update: successful tests, need more complex vdevs To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Tue, 27 Oct 2015 21:15:32 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 21:06:53 -0000 Hi, Sorry for the most likely stupid question but I fail to get the patched current tree compiled, as "boot_module.h" is added to boot1.c but that header is missing from my tree for some reason. I did svn up just before starting making process. Could you please advise where this header is/should be? Thanks. From owner-freebsd-hackers@freebsd.org Tue Oct 27 22:26:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB431A1F360; Tue, 27 Oct 2015 22:26:04 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0058.outbound.protection.outlook.com [157.56.110.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C657510A4; Tue, 27 Oct 2015 22:26:02 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1801.namprd08.prod.outlook.com (10.162.218.23) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 22:25:54 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 22:25:53 +0000 From: "Pokala, Ravi" To: Adrian Chadd CC: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Subject: Re: Low-level trace-buffers in CAM Thread-Topic: Low-level trace-buffers in CAM Thread-Index: AQHREF5W2DCPOIdjUUGMRg6fRJs3w55+pEiA//+jqQCAAS7bgA== Date: Tue, 27 Oct 2015 22:25:53 +0000 Message-ID: <18A15118-7860-4912-B2D4-1EA51054D3FD@panasas.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1801; 5:KHiVyCODBCiTNx0/E/c4u1fmCed68iAL9ujFl8wy5c6mlrT2F/m0XhNwpR31lmoWxLy/hEC3ZxY4Pdg4k2K/UqPongnC+9Sfi3DLvGY6g67GErSijr3GCNCltoC8MFAp92gNq6BQQPjUNX8AyWzlTA==; 24:yKDK2S78dwuY8YGVqTDC/9OWHGu14hCPk9tDqR/dwVgf6V32cTPQVW5wtVdwWBR1cbOgCycwhUqKA+7GejgepYiO2IARa1kIISyI15i8EPY=; 20:yRgnrEhK382Sqsjf/ODY2IK0lWPX7TVY8GoK2yBxFv5JCx4981fNIP6mTWCUqxcFSclWEhxG+i+f8l/pEQg/iw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1801; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(239227872634102); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501037)(3002001)(102215026); SRVR:CY1PR08MB1801; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1801; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(13464003)(199003)(377424004)(5002640100001)(82746002)(122556002)(106356001)(87936001)(83506001)(19580395003)(81156007)(105586002)(19580405001)(4001150100001)(36756003)(40100003)(106116001)(54356999)(83716003)(86362001)(50986999)(4001350100001)(76176999)(101416001)(99286002)(97736004)(66066001)(5004730100002)(33656002)(189998001)(92566002)(5001920100001)(77096005)(110136002)(102836002)(2900100001)(5008740100001)(2950100001)(10400500002)(5007970100001)(5001960100002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1801; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 22:25:53.4472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1801 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 22:26:05 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KDQpGcm9tOiBSYXZpIFBva2FsYSA8cnBva2Fs YUBwYW5hc2FzLmNvbT4NCkRhdGU6IDIwMTUtMTAtMjYsIE1vbmRheSBhdCAyMToyMQ0KVG86IEFk cmlhbiBDaGFkZCA8YWRyaWFuLmNoYWRkQGdtYWlsLmNvbT4NCkNjOiAiZnJlZWJzZC1nZW9tQGZy ZWVic2Qub3JnIiA8ZnJlZWJzZC1nZW9tQGZyZWVic2Qub3JnPiwgImZyZWVic2Qtc2NzaUBmcmVl YnNkLm9yZyIgPGZyZWVic2Qtc2NzaUBmcmVlYnNkLm9yZz4sICJmcmVlYnNkLWhhY2tlcnNAZnJl ZWJzZC5vcmciIDxmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmc+LCAia2VuQGZyZWVic2Qub3Jn IiA8a2VuQGZyZWVic2Qub3JnPiwgImltcEBmcmVlYnNkLm9yZyIgPGltcEBmcmVlYnNkLm9yZz4s ICJzY290dGxAZnJlZWJzZC5vcmciIDxzY290dGxAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTog TG93LWxldmVsIHRyYWNlLWJ1ZmZlcnMgaW4gQ0FNDQoNCj5JJ20gaGF2aW5nIHRyb3VibGUgcGFy c2luZyB0aGF0IC0gaXQncyBiZWVuIGEgbG9uZyBkYXkuIFlvdSdyZSB0YWxraW5nIGFib3V0IGNy ZWF0aW5nIGEgZ2VuZXJpYyBpbi1rZXJuZWwgcmluZy1idWZmZXIgaW1wbGVtZW50YXRpb24sIHRo YXQgd2UgY291bGQgbGV2ZXJhZ2UgZm9yIChDQU0gdHJhY2luZyB8IEtUUiB8IHdoYXRldmVyKT8g TGlrZSB3ZSBkaWQgZm9yIHZhcmlvdXMgbGlzdCBhbmQgcXVldWUgdHlwZXMgaW4gPHN5cy9xdWV1 ZS5oPj8gVGhhdCdzIGEgZ29vZCBpZGVhLCBidXQgSSBnbyBjcm9zcy1leWVkIGFueSB0aW1lIEkg bG9vayB0b28gY2xvc2VseSBhdCBhbGwgdGhlIHByZXByb2Nlc3Nvci1mdSBpbiB0aGVyZS4gOi0p DQoNCkxvb2tpbmcgYXQgaXQgYWdhaW4gdG9kYXksIEkgdGhpbmsgSSBtaXMtcGFyc2VkIGl0LiBZ b3Ugd2VyZSAqYWN0dWFsbHkqIHRhbGtpbmcgYWJvdXQgYSBnZW5lcmljICppbnRlcmZhY2UqIGZv ciBwYXNzaW5nIGEgcmluZyBvdXQgb2YgdGhlIGtlcm5lbCwgcmlnaHQ/IFRoZSBrZXJuZWwganVz dCBkdW1wcyBvbnRvIGl0LCBhbmQgdXNlcmxhbmQgZGVhbHMgd2l0aCB3YWxraW5nIGl0LCBmaWd1 cmluZyBvdXQgaWYgaXQncyB0aGUgcmVjb3JkIGlzIHNvbWV0aGluZyB3ZSdyZSBpbnRlcmVzdGVk IGluLCBldGMuDQoNCk9yIGRpZCB5b3UgbWVhbiBhIDNyZCB0aGluZz8gOi0pDQoNCi1SYXZpDQo= From owner-freebsd-hackers@freebsd.org Wed Oct 28 04:52:40 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51F9FA1F693 for ; Wed, 28 Oct 2015 04:52:40 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 165A9179C for ; Wed, 28 Oct 2015 04:52:39 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1446007543; bh=a78juyGYovwYPmPm/bA3/OASOL53LMCMJDwtfR1dPbU=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=tNltGsTEmXpvGApQKsPU5bTuELnDc4sdroPJ766KiHQ6Jv15IFX+x6WPl9FLGKNDtH/YZqxzxy7aUfAJs4/Um47fvPK2L4j67DgfJje2xXhZivXtRgDKsLvwkBuhwRGXKb28NkSufgGBzL4LZnFi7BqRBsKl6uGW8al0cjBcohjj8VR/fYUMfJCHzSf2fkkAiR2vjKVl/AnsdaSv6FTlbqYjzsj0SsHYxTXLx6KxCWNNkzIlWD2xKksHDq0DKCmNzkGaBfVYdj0SYn+traLNz23C0UD2UdxFCqZoCW8pBcS+IFHBtddYrAdLX63OoeK2FTW3Dimo/ksiq5JaOmRgIw== Received: from [98.138.226.180] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2015 04:45:43 -0000 Received: from [98.138.226.161] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 28 Oct 2015 04:45:43 -0000 Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 28 Oct 2015 04:45:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 503545.67310.bm@omp1062.mail.ne1.yahoo.com X-YMail-OSG: vr2fETQVM1m3BIIyJZgmSsoFxt2adoBVXly4rrkAUTP.nTrJ1xIQ_GwyhJpA5Dm qP7iQTH3ywlWGmCBSooCBWDLkQMBNv2AqMgXsFfNGX.ofsx0J47Qhu2s7laMr8B6shishDoYUpkf es8Q8EC0kQw8oPA5uYcU3t7nmsbznkgk00CRO1nvWr9d7Yj3ZI19o0SC5gsQw86r5wDxHKVVDyj_ h0n2jNX.hyMAah8ojl1W.rbxfIDq1_WWCVfxcwk5UakB.zx317nvydEuShU3BIbiDCjuu7r.eFtk unj1qpG9lyCNAoOKTzrLGbJ4pf9BiRHwMbP0zSti9_V9Vz5iKarvj3wNNSn0ytUV6mSH9yjFMHvf In.9YrzQoHX8hDxHezwnjaSt_xCA5sgRxtfkW00SkLISc6IIK3ESAuXBY5biBVbjocpGkZJtYNp1 uGWURbTX2gYGEbl5JrcKG33DTSeNuukG7zPhLvoXc_ObEEPNTO0Im31fy4HVYQoRe1C76TClqOXH 7J78V5g.nTawOegwBfZw- Received: by 98.138.101.167; Wed, 28 Oct 2015 04:45:43 +0000 Date: Wed, 28 Oct 2015 04:45:42 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "drivers@freebsd.org" , Freebsd Hackers List Message-ID: <1919029817.753677.1446007542768.JavaMail.yahoo@mail.yahoo.com> Subject: Anyone from China here MIME-Version: 1.0 References: <1919029817.753677.1446007542768.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 04:52:40 -0000 Hi list, is anyone from China here ? From owner-freebsd-hackers@freebsd.org Wed Oct 28 06:34:05 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFC84A20BAC for ; Wed, 28 Oct 2015 06:34:05 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from mo175.mail-out.ovh.net (mo175.mail-out.ovh.net [178.32.228.175]) (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 971B71F40 for ; Wed, 28 Oct 2015 06:34:04 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from EX3.OVH.local (corp.ovh.com [5.196.251.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mo175.mail-out.ovh.net (Postfix) with ESMTPS id B9E9DFF8270; Wed, 28 Oct 2015 07:27:24 +0100 (CET) Received: from desk533202.ovh.net (5.196.2.34) by EX3.OVH.local (172.16.7.3) with Microsoft SMTP Server (TLS) id 15.1.225.42; Wed, 28 Oct 2015 07:27:19 +0100 From: Ganael Laplanche Organization: OVH To: Emmanuel Vadot Subject: Re: EFI Variables Date: Wed, 28 Oct 2015 07:27:19 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) CC: References: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> In-Reply-To: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <201510280727.19357.ganael.laplanche@corp.ovh.com> X-Originating-IP: [5.196.2.34] X-ClientProxiedBy: cas02.OVH.local (172.16.1.2) To EX3.OVH.local (172.16.7.3) X-Ovh-Tracer-Id: 7695525864503032455 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrudegucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 06:34:05 -0000 On Tuesday, October 27, 2015 07:24:23 PM Emmanuel Vadot wrote: Hi Emmanuel, > I'm currently hacking around the loader.efi Great :) > I've also added the list and get command to the not working "nvram" > command. I had myself posted a PR to fix that command as well as add a verbose switc= h=20 and the ability to specify a variable name, see : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202614 > For the "set" subcommand I think that the best way to handle it is : > "nvram set myvar data" -> This will set the variable myvar to data with > the freebsd guid (if there is any) >=20 > and >=20 > "nvram set myvar guid data" -> This will force the guid to It can be useful to set variables containing *strings*, but will hardly han= dle=20 binary stuff :/ I am not sure whether it should be the loader's job to set variables... I c= an=20 think of changing the boot order, but it may be difficult to get it right b= y=20 hand and would probably require an upper-level tool, such as efibootmgr on= =20 Linux. > I'll look tomorrow how to access efivars once the kernel is booted so > we can set some from some userland tool (especially the boot related > one). Yes, this is interesting as the current kernel (amd64) does not provide acc= ess=20 to EFI variables at all. 10.x/ia64 provided access to EFI variables through libefi(3) and io(4). It= =20 should be possible to import that code to other archs too, but you'll have = to=20 save the entry point to the Runtime Services Tables and maybe set a Virtual= =20 Address Map too (not sure about that point). Best regards, =2D-=20 Gana=EBl LAPLANCHE From owner-freebsd-hackers@freebsd.org Wed Oct 28 08:33:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47F38A2050A for ; Wed, 28 Oct 2015 08:33:04 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 0600B1E3F for ; Wed, 28 Oct 2015 08:33:04 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZrMAH-000ApR-9T for freebsd-hackers@freebsd.org; Wed, 28 Oct 2015 09:33:01 +0100 Subject: Re: Z36xxx Graphics & display To: freebsd-hackers@freebsd.org References: From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Message-ID: <56308838.7090601@dumbbell.fr> Date: Wed, 28 Oct 2015 09:32:56 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PPGoR9g8eGN31gXo1xK2f1BrWbqOif23h" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 08:33:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PPGoR9g8eGN31gXo1xK2f1BrWbqOif23h Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27.10.2015 22:59, Wojciech Puchar wrote: > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x390517aa chip=3D0x0f3= 18086 > rev=3D0x0e hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Atom Processor Z36xxx/Z37xxx Series Graphics & Disp= lay' > class =3D display > subclass =3D VGA >=20 > is it supported in newer i915kms? Hi! This is a Valleyview, so unfortunately no, it's not currently supported and will have experimental support in the upcoming update. Hopefully further updates will follow in the coming months, including better support for this family. --=20 Jean-S=E9bastien P=E9dron --PPGoR9g8eGN31gXo1xK2f1BrWbqOif23h 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 iQJ8BAEBCgBmBQJWMIg8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTM83sP/030oVDJje63H9gPR/7FXk7t avjR0ESNUjcA6Oq67O2KgU0+wYpTG8aa/9SQrupf/yIpRIdRzG7uXTnMvrNs6tVu oufa6uDxxmh2CsYdbifHLg52pVR28UhYpse+32V0/+kQ0hkk6vuyGOgKqaUrGsiF Xg24jGVzLPKpuOnoI6XSKXc8029AGwa3vbzKlAbPUfdvxMUQ+vL7//kKVgzLyNGo eJVpF8la9vcLe7N0rD2RJ1uDzpFJeldTM4+gbC7vQvNWMGDhIgzaemQ1ATr1cZFF yglmoP/XGDw1RxH7KU4OM84yuch8T67edgPiFkuXXy23imCGZUSjAQgo5CFkAcgs pFfwLPtb17kzdRQ52Hjh+g63Ji20Yr+9l3M/lfDwjTa9pO06GpNX1Mq+c3J2ua3E Khu7/nwX+EfTa41AN20TuhzqJ7IkML97vOF4hZBhd6cLjg+oxRkT9m0J1qcr1gq0 QHfnAUte6yhadx2wn1asiUfCQpIOJEdLLaDHdGFvgTw+QHr10Fcc0I0NUym7TR/3 ZcFf0JPIzasS5DvRr8lyD+zo5RT/woQyp+awq6rJiyvsg5yyjyufKIZzOPDQ+Qyk FBdwuOSZ6HZ/0+9Besl4utcvC0pAcWJ27T67LC+xrhSqs+DmDew8OR9CQYVTxWSh Tm0onxQf7rC+8po9sweg =9Ojw -----END PGP SIGNATURE----- --PPGoR9g8eGN31gXo1xK2f1BrWbqOif23h-- From owner-freebsd-hackers@freebsd.org Wed Oct 28 09:00:02 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BB7CA20C1F for ; Wed, 28 Oct 2015 09:00:02 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5274A163B for ; Wed, 28 Oct 2015 09:00:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA05145; Wed, 28 Oct 2015 10:59:57 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZrMaL-000IPN-8S; Wed, 28 Oct 2015 10:59:57 +0200 Subject: Re: EFI Variables To: Emmanuel Vadot , freebsd-hackers References: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <56308E54.6000202@FreeBSD.org> Date: Wed, 28 Oct 2015 10:59:00 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 09:00:02 -0000 On 27/10/2015 20:24, Emmanuel Vadot wrote: > Is any of you guys uses efivars for something not boot-releated ? > I'm interested in any usage of efi variables. I am not using EFI yet, but I am going to and I would like to use EFI's built-in mechanism for the nextboot-ish kind of things (BootOrder, BootNext variables). -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Oct 28 09:33:31 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3F79A1F4AB for ; Wed, 28 Oct 2015 09:33:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 570451646 for ; Wed, 28 Oct 2015 09:33:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id t9S9XNac086806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Oct 2015 10:33:24 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.15.2/8.15.2) with ESMTP id t9S9XK7H003981; Wed, 28 Oct 2015 10:33:20 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.15.2/8.15.2/Submit) with ESMTP id t9S9XFxe003978; Wed, 28 Oct 2015 10:33:15 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Wed, 28 Oct 2015 10:33:15 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: =?ISO-8859-15?Q?Jean-S=E9bastien_P=E9dron?= cc: freebsd-hackers@freebsd.org Subject: Re: Z36xxx Graphics & display In-Reply-To: <56308838.7090601@dumbbell.fr> Message-ID: References: <56308838.7090601@dumbbell.fr> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 28 Oct 2015 10:33:24 +0100 (CET) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 09:33:31 -0000 > > Hi! > > This is a Valleyview, so unfortunately no, it's not currently supported > and will have experimental support in the upcoming update. so it WILL be supported? If so, i will not give my new laptop back (i can within a week). It runs now but with VESA mode. slow. > > Hopefully further updates will follow in the coming months, including > better support for this family. > > -- > Jean-Sébastien Pédron > > From owner-freebsd-hackers@freebsd.org Wed Oct 28 09:53:42 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B359A1FAA9 for ; Wed, 28 Oct 2015 09:53:42 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 523201F4C for ; Wed, 28 Oct 2015 09:53:42 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZrNQK-000BS1-Dh for freebsd-hackers@freebsd.org; Wed, 28 Oct 2015 10:53:40 +0100 Subject: Re: Z36xxx Graphics & display To: freebsd-hackers@freebsd.org References: <56308838.7090601@dumbbell.fr> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Message-ID: <56309B1E.20801@dumbbell.fr> Date: Wed, 28 Oct 2015 10:53:34 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f87n89Vf0e9NblafXXR8XpFeaeJO3X9jF" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 09:53:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f87n89Vf0e9NblafXXR8XpFeaeJO3X9jF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28.10.2015 10:33, Wojciech Puchar wrote: > so it WILL be supported? If so, i will not give my new laptop back (i > can within a week). It runs now but with VESA mode. slow. It will be supported in the sense that the PCI ID will be listed. However, support for Valleyview is disabled by default in the patch because it's considered unstable (it's not my call, it's like this in the original Linux 3.8 driver). --=20 Jean-S=E9bastien P=E9dron --f87n89Vf0e9NblafXXR8XpFeaeJO3X9jF 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 iQJ8BAEBCgBmBQJWMJsfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMCRUP/RO2fUTeLj4nLP9muYbiTy+a 0n3wiDQ+TX6rA6ReAm3TmC3e+1yhWbCu3Ct7JUWo8XE5c5WsmCiZcW17iJEoGmcs 1Hi6yzSTCwq8p1zsN0wUDbeDBVT0KUS+UwPkIpsqnnTE8KvHj1HwFkVzxamQbyhJ uPqCJfFdjDzsmv4F19hiK8wR942nNTRsndPDgg/OleGFb2SWEQDaTlLEvn8JSR9C lRYIcqlowxSJ72ln9orrgI5toO2a+phPcgxCSEACMFwm1en/jHD3DBPJ4xMkko0S PBgPGvBa6upyYunt7Vzzy/Sj1SqvNFLhLrIN7sRXdFIVZpZ+tk2BtnetHD2Y42GO 9l6j1UI+L2UNYKA6yRTpWZtBT1MtAurSyG9eaTIZkattWEfV/HfAn+BFSoVyjUMe iRoXsK8kzohULmsGhuPUanT359XNb9lLd+rNcZyV3BhZ/Ka7Zd2Hc/D0/u3qRmGq 67fC6dIztsYLLZRfyUL9Ote06Ggyz1FwbKJjsoso0KiRaiWLm1/T6yh4pasQ0H1G fZYlhVQhmGy+5hMAkAVBhSbJkZ6z6mk9hFiOnpKJ02yJ6CKtktXhCnTl+AGIgEl0 5ZSYeL7XhEjM8W3LXcXok0xFxI8QZGAFhLtnUw5Pk44bBk1SB+Sl87GZ89+Oi8ty R/vmN/gTdElt5WD/luoJ =w0AK -----END PGP SIGNATURE----- --f87n89Vf0e9NblafXXR8XpFeaeJO3X9jF-- From owner-freebsd-hackers@freebsd.org Wed Oct 28 09:44:10 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05B70A1F764 for ; Wed, 28 Oct 2015 09:44:10 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6F5B1B67 for ; Wed, 28 Oct 2015 09:44:08 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 5C0F66DF91B; Wed, 28 Oct 2015 10:44:05 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t9S9i4lZ030341; Wed, 28 Oct 2015 10:44:04 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t9S9i4ou030083; Wed, 28 Oct 2015 10:44:04 +0100 (CET) (envelope-from lars) Date: Wed, 28 Oct 2015 10:44:04 +0100 From: Lars Engels To: Wojciech Puchar Cc: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= , freebsd-hackers@freebsd.org Subject: Re: Z36xxx Graphics & display Message-ID: <20151028094403.GT66179@e-new.0x20.net> References: <56308838.7090601@dumbbell.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J9YdZykiGPT3Jhx7" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Wed, 28 Oct 2015 11:26:39 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 09:44:10 -0000 --J9YdZykiGPT3Jhx7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 28, 2015 at 10:33:15AM +0100, Wojciech Puchar wrote: > > > > Hi! > > > > This is a Valleyview, so unfortunately no, it's not currently supported > > and will have experimental support in the upcoming update. >=20 > so it WILL be supported? If so, i will not give my new laptop back (i can= =20 > within a week). It runs now but with VESA mode. slow. Have you tried xf86-video-scfb instead? --J9YdZykiGPT3Jhx7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJWMJjjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tXkgH/3SvJy61OUT412k6XZYrElTE nV3Egutpho071a/jR4J35Pa0ptXIb911kg0Of3YFsWUThFv+Ftmb/gVjrP3lsYtV yDjrNwayWf39R/X3ouIseEyKiJXmIX5Kryj5JHmDOhiRJFIYhuAIwPYAOa/HDR6e FCgo3zTgJL7/LSndn/e4CGpqGXd34qnI7lgEqEXUF4vrz4Zpbs5a7DCSYtHbS8BU xng2PSYrbdDMJNq6lPSq8IqRlofDE+A322M6ExOc/LeAJVX8pOtxlOpe2sU79aDn VILZq4z2a7yKXkNZXQWYyvRIIBITwsPydLDYNjwaTu73vRKCfKxOgMvs9cirxqE= =87z1 -----END PGP SIGNATURE----- --J9YdZykiGPT3Jhx7-- From owner-freebsd-hackers@freebsd.org Wed Oct 28 14:03:33 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2984DA1F7E5; Wed, 28 Oct 2015 14:03:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8A9714FF; Wed, 28 Oct 2015 14:03:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZrRJy-000Fhj-Ed; Wed, 28 Oct 2015 17:03:22 +0300 Date: Wed, 28 Oct 2015 17:03:22 +0300 From: Slawa Olhovchenkov To: "Pokala, Ravi" Cc: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Subject: Re: Low-level trace-buffers in CAM Message-ID: <20151028140322.GK6469@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 14:03:33 -0000 On Tue, Oct 27, 2015 at 02:22:33AM +0000, Pokala, Ravi wrote: > Hi folks, > > ---------------------------------------------------------------- > This is an updated re-send of a message I originally sent about a year ago, during MeetBSD 2014. A few people expressed interest in person, but no one ever followed up on the lists. I'm bringing this up again, in the hopes that I can get some feedback before / during next week's Dev/Vendor Summit. I'm CCing some folks who expressed interest at that time, and some folks that I was told would be interested. > ---------------------------------------------------------------- What about also export average queue length? May be request wait time in queue. From owner-freebsd-hackers@freebsd.org Wed Oct 28 16:50:13 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A38D1A1FFE0 for ; Wed, 28 Oct 2015 16:50:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8A11B5E; Wed, 28 Oct 2015 16:50:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10967; Wed, 28 Oct 2015 18:50:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZrTvI-000IvY-18; Wed, 28 Oct 2015 18:50:04 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov , Alexander Motin References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <5630FC3B.2070908@FreeBSD.org> Date: Wed, 28 Oct 2015 18:47:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151027140403.GB2257@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 16:50:13 -0000 On 27/10/2015 16:04, Konstantin Belousov wrote: > On Tue, Oct 27, 2015 at 03:50:01PM +0200, Andriy Gapon wrote: >> On 27/10/2015 13:58, Konstantin Belousov wrote: >>> On Tue, Oct 27, 2015 at 11:04:47AM +0200, Andriy Gapon wrote: >>>> And now another observation. I have C1E option enabled in BIOS. It >>>> means that if all cores enter C1 state, then the whole processor >>>> is magically placed into a deep C-state (C3, I think). LAPIC timer >>>> on this CPU model does not run in the deep C-state. So, I had to >>>> disable C1E option to test the LAPIC timer in a useful way. But >>>> before actually testing it I first tried to reproduce the problem. As >>>> you might have already guessed the problem is gone with that option >>>> disabled. Scratching my head to understand the implications of this >>>> observation. >>> >>> Most obvious explanation would be that the latency of wakeup is very large. >>> What is the HPET frequency when the jitter occur ? >>> >> >> kern.timecounter.tc.TSC-low.frequency: 1607351869 >> kern.eventtimer.et.HPET.frequency: 14318180 >> >> Or did you mean the actual rate of timer interrupts? > > Actual rate, and I used the wrong word. Since most likely your eventtimer > is not periodic, I mean the next timer interrupt deadline. > I wasn't sure how to answer your question, so I went ahead and obtained a little bit of debugging information using KTR. For a start, here is a patch that adds couple more trace points: https://people.freebsd.org/~avg/timekeeping-ktr.patch Please note that the patch has a small bug in hardclock_cnt(): + CTR1(KTR_SPARE2, "hardclock_cnt at %d: newticks=%d", + newticks); Two format specifiers but only one argument. I mention this, so that the trace is not misinterpreted. Then, here is a snippet of the trace that seems to be of interest: https://people.freebsd.org/~avg/timekeeping.ktrdump.txt I must admit that I have a hard time interpreting what that trace says. As I understand the KTR timestamps are raw TSC values. So, there is a huge gap between entries #999543 and #999544. It's larger than 2 * 2^32, so even after applying tsc_shift it's still larger that 2^32. I am not sure how the HPET timer could get programmed for such a long delay. Or maybe there is some lower level problem that caused the interrupt to be delayed by (16450821032024 - 16442184278422) / 2 / 1607351869 ≈ 2.687 seconds. That's quite a long time. One thing that I can tell is that my earlier hypothesis seems to be wrong as all raw TSC values are increasing. Grepping for lines where the timer gets reprogrammed I was surprised to see the following: 999543 1 16442184278422 load at 1: next 5042.d25692b3 eq 0 999507 3 16442183843960 load at 3: next 5042.d23e2146 eq 0 999503 2 16442183825488 load at 2: next 5042.d25692b3 eq 0 999472 0 16442183792870 load at 0: next 5042.d23e2146 eq 0 This looks like the next event time has flipped between those two values somehow. Also, the following seemed a little bit strange: 999508 3 16442183860624 ipi at 3: now 5042.d2301033 999467 3 16442183787851 active at 3: now 5042.d2306108 The later even reports a value of 'now' that is smaller. I think that that can be explained by the fact that in one case the value is obtained via sbinuptime() while in the other case it's taken from state->now, which is set when an actual timer interrupt is received (before sending a hardclock IPI). In either case I am going to add a few more trace points in et_start and the HPET timer code and see if I can catch anything interesting there. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Oct 28 20:29:23 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 810D0A205B8; Wed, 28 Oct 2015 20:29:23 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0059.outbound.protection.outlook.com [157.56.110.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 419AB115A; Wed, 28 Oct 2015 20:29:21 +0000 (UTC) (envelope-from rpokala@panasas.com) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (10.162.218.25) by CY1PR08MB1804.namprd08.prod.outlook.com (10.162.218.26) with Microsoft SMTP Server (TLS) id 15.1.306.13; Wed, 28 Oct 2015 20:29:13 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([10.162.218.25]) with mapi id 15.01.0306.003; Wed, 28 Oct 2015 20:29:12 +0000 From: "Pokala, Ravi" To: Slawa Olhovchenkov CC: "freebsd-geom@freebsd.org" , "freebsd-scsi@freebsd.org" , "freebsd-hackers@freebsd.org" , "ken@freebsd.org" , "imp@freebsd.org" , "scottl@freebsd.org" Subject: Re: Low-level trace-buffers in CAM Thread-Topic: Low-level trace-buffers in CAM Thread-Index: AQHREF5W2DCPOIdjUUGMRg6fRJs3w56A8hIA///2c4A= Date: Wed, 28 Oct 2015 20:29:12 +0000 Message-ID: <76951B36-ADA9-45AC-BC20-2A8340DEC6B8@panasas.com> References: <20151028140322.GK6469@zxy.spb.ru> In-Reply-To: <20151028140322.GK6469@zxy.spb.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-exchange-diagnostics: 1; CY1PR08MB1804; 5:c6qRbEpEfVaJuKUkHbjuhg07MxfN6rrlcQ6qoLmbEz6bSLAiG3H5V/gqX0fOeaU+qF+6mklYcoEYVBKpLBwNxtt5BviQRN9Td8OXl0f5Tdk1TnUjSe0y5q3GWQ0LqZFs2S2ZPgK7VC05kYXs4OG+gg==; 24:EprJwT9EfvBgScJTLO7KxPffk9Qny1i/nNC/0wBwhjHP5uSH8m3eRkZYB/Xyklu9rXNlkqkfTvEqGyjjtm3uzn/8gtojz8j9kbZYRdxRntk=; 20:G2x4I/r9jPvTqz7/OvXEY8HbgmlKXujvHPJMYNgjentWf2p88gVbqGva0RKWqzKlZPChBfTWU1EetitA9+JGfg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR08MB1804; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(239227872634102); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001)(102215026); SRVR:CY1PR08MB1804; BCL:0; PCL:0; RULEID:; SRVR:CY1PR08MB1804; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(199003)(13464003)(189002)(377424004)(106356001)(19580395003)(33656002)(106116001)(2900100001)(19580405001)(4477795004)(66066001)(5007970100001)(105586002)(4001350100001)(92566002)(83716003)(5004730100002)(50986999)(81156007)(99286002)(102836002)(77096005)(4001150100001)(10400500002)(5002640100001)(5008740100001)(101416001)(36756003)(2950100001)(86362001)(189998001)(97736004)(83506001)(110136002)(40100003)(87936001)(5001960100002)(76176999)(54356999)(122556002)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR08MB1804; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <86E42B15E4EF4D4098A0ADEA231CE97C@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2015 20:29:12.6307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR08MB1804 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 20:29:23 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KDQpGcm9tOiBTbGF3YSBPbGhvdmNoZW5rb3Yg PHNsd0B6eHkuc3BiLnJ1Pg0KRGF0ZTogMjAxNS0xMC0yOCwgV2VkbmVzZGF5IGF0IDA3OjAzDQpU bzogUmF2aSBQb2thbGEgPHJwb2thbGFAcGFuYXNhcy5jb20+DQpDYzogImZyZWVic2QtZ2VvbUBm cmVlYnNkLm9yZyIgPGZyZWVic2QtZ2VvbUBmcmVlYnNkLm9yZz4sICJmcmVlYnNkLXNjc2lAZnJl ZWJzZC5vcmciIDxmcmVlYnNkLXNjc2lAZnJlZWJzZC5vcmc+LCAiZnJlZWJzZC1oYWNrZXJzQGZy ZWVic2Qub3JnIiA8ZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPiwgImtlbkBmcmVlYnNkLm9y ZyIgPGtlbkBmcmVlYnNkLm9yZz4sICJpbXBAZnJlZWJzZC5vcmciIDxpbXBAZnJlZWJzZC5vcmc+ LCAic2NvdHRsQGZyZWVic2Qub3JnIiA8c2NvdHRsQGZyZWVic2Qub3JnPg0KU3ViamVjdDogUmU6 IExvdy1sZXZlbCB0cmFjZS1idWZmZXJzIGluIENBTQ0KDQo+T24gVHVlLCBPY3QgMjcsIDIwMTUg YXQgMDI6MjI6MzNBTSArMDAwMCwgUG9rYWxhLCBSYXZpIHdyb3RlOg0KPg0KPj4gSGkgZm9sa3Ms DQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+IFRoaXMgaXMgYW4gdXBkYXRlZCByZS1zZW5kIG9mIGEgbWVz c2FnZSBJIG9yaWdpbmFsbHkgc2VudCBhYm91dCBhIHllYXIgYWdvLCBkdXJpbmcgTWVldEJTRCAy MDE0LiBBIGZldyBwZW9wbGUgZXhwcmVzc2VkIGludGVyZXN0IGluIHBlcnNvbiwgYnV0IG5vIG9u ZSBldmVyIGZvbGxvd2VkIHVwIG9uIHRoZSBsaXN0cy4gSSdtIGJyaW5naW5nIHRoaXMgdXAgYWdh aW4sIGluIHRoZSBob3BlcyB0aGF0IEkgY2FuIGdldCBzb21lIGZlZWRiYWNrIGJlZm9yZSAvIGR1 cmluZyBuZXh0IHdlZWsncyBEZXYvVmVuZG9yIFN1bW1pdC4gSSdtIENDaW5nIHNvbWUgZm9sa3Mg d2hvIGV4cHJlc3NlZCBpbnRlcmVzdCBhdCB0aGF0IHRpbWUsIGFuZCBzb21lIGZvbGtzIHRoYXQg SSB3YXMgdG9sZCB3b3VsZCBiZSBpbnRlcmVzdGVkLg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPldoYXQgYWJv dXQgYWxzbyBleHBvcnQgYXZlcmFnZSBxdWV1ZSBsZW5ndGg/IE1heSBiZSByZXF1ZXN0IHdhaXQg dGltZSBpbiBxdWV1ZS4NCg0KVGhvc2UgYXJlIGNlcnRhaW5seSBnb29kIHRvIGhhdmUsIGJ1dCBh cmUgYXQgYSBoaWdoZXIgbGF5ZXIgdGhhbiB3aGF0IEknbSB0cnlpbmcgdG8gY2FwdHVyZS4gSSdt IHJlYWxseSBpbnRlcmVzdGVkIGluIHdoYXQncyBnb2luZyBpbnRvIGFuZCBvdXQgb2YgdGhlIGhh cmR3YXJlIC0gdGhlIHZhbHVlcyBvZiB0aGUgQ0RCIGZpZWxkcyBqdXN0IGJlZm9yZSB0aGV5IGdl dCBzZW50IHRvIHRoZSBoYXJkd2FyZSwgYW5kIHRoZSBlbGFwc2VkIHRpbWUgYW5kIHJldHVybi1D REIgZmllbGRzIHdoZW4gdGhlIFNJTSBkcml2ZXIncyBpbnRlcnJ1cHQgaGFuZGxlciBmaXJlcyBh dCBjb21tYW5kIGNvbXBsZXRpb24uIEFkbWl0dGVkbHksIG1vc3QgcGVvcGxlIGRvbid0IG5lZWQg dGhhdCBsZXZlbCBvZiBkZXRhaWwsIGJ1dCBJIHdvcmsgZm9yIGEgc3RvcmFnZSBjb21wYW55LCBz byAuLi4gOy0pDQoNCi1SYXZpDQo= From owner-freebsd-hackers@freebsd.org Wed Oct 28 21:38:35 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEDC5A20640 for ; Wed, 28 Oct 2015 21:38:35 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C75BF1637 for ; Wed, 28 Oct 2015 21:38:35 +0000 (UTC) (envelope-from rpaulo@me.com) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from akita.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NWY00NOT6O4JV10@mr11p00im-asmtp004.me.com> for freebsd-hackers@freebsd.org; Wed, 28 Oct 2015 20:38:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-10-28_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510090000 definitions=main-1510280351 Message-id: <1446064708.28809.77.camel@me.com> Subject: Re: EFI Variables From: Rui Paulo To: Ganael Laplanche , Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Date: Wed, 28 Oct 2015 13:38:28 -0700 In-reply-to: <201510280727.19357.ganael.laplanche@corp.ovh.com> References: <6ce779725aab266bc85e92f0ee2186b6@megadrive.org> <201510280727.19357.ganael.laplanche@corp.ovh.com> X-Mailer: Evolution 3.18.0-2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 21:38:36 -0000 On Wed, 2015-10-28 at 07:27 +0100, Ganael Laplanche wrote: > On Tuesday, October 27, 2015 07:24:23 PM Emmanuel Vadot wrote: > > Hi Emmanuel, > > >   I'm currently hacking around the loader.efi > > Great :) > > >   I've also added the list and get command to the not working > > "nvram" > > command. > > I had myself posted a PR to fix that command as well as add a verbose > switch > and the ability to specify a variable name, see : > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202614 > > >   For the "set" subcommand I think that the best way to handle it > > is : > >   "nvram set myvar data" -> This will set the variable myvar to > > data with > > the freebsd guid (if there is any) > > > >   and > > > >   "nvram set myvar guid data" -> This will force the guid to > > It can be useful to set variables containing *strings*, but will > hardly handle > binary stuff :/ > > I am not sure whether it should be the loader's job to set > variables... I can > think of changing the boot order, but it may be difficult to get it > right by > hand and would probably require an upper-level tool, such as > efibootmgr on > Linux. > > >   I'll look tomorrow how to access efivars once the kernel is > > booted so > > we can set some from some userland tool (especially the boot > > related > > one). > > Yes, this is interesting as the current kernel (amd64) does not > provide access > to EFI variables at all. > > 10.x/ia64 provided access to EFI variables through libefi(3) and > io(4). It > should be possible to import that code to other archs too, but you'll > have to > save the entry point to the Runtime Services Tables and maybe set a > Virtual > Address Map too (not sure about that point). > It would be nice to set some EFI variables in the loader, but you can't expect to handle binary data from the loader.  Like you said, we need a special tool to change EFI variables on a system already running FreeBSD. -- Rui Paulo From owner-freebsd-hackers@freebsd.org Wed Oct 28 22:45:40 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DD57A203AA for ; Wed, 28 Oct 2015 22:45:40 +0000 (UTC) (envelope-from koert.xls@gmail.com) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 BF51914C8 for ; Wed, 28 Oct 2015 22:45:39 +0000 (UTC) (envelope-from koert.xls@gmail.com) Received: by lbbec13 with SMTP id ec13so16679598lbb.0 for ; Wed, 28 Oct 2015 15:45:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=8gHmAD4RTSBshNQCCwlCckhii7SjHybuvAfrRsZqsPY=; b=J2AFsO28Q9JDSq0ysggnCVU1a67qL8IXiH3Jo4eDXtiI3ZbxIuxIGzu3ITwtQ0jWyh siV0h0wocep0i9SzjRa760T2s45wrLcFE3Q8efqk1Z6p+3II8q9JHj+CvcV0mSQk7UjJ XHEzYO1t2+p0AufxB9VwruwRLMDA/+LDzSZfTz5XM2/4Ko5NWQ2RsQ1xy5RbK5QTNvs0 zRzbHwu5UlHSbLGu+vYvkVvUQv+RNBt7+OZ9/rA9LuF2s2t2J7fb/j6Qy70f92hrYIq0 h0rhV5M13o94EzFa3vOSsa9/XhzKepjR/YyYOL26MgDyziRDiYdjWLmmR4oFo+pqw3Tw J/+w== X-Received: by 10.112.199.100 with SMTP id jj4mr24861593lbc.122.1446072332396; Wed, 28 Oct 2015 15:45:32 -0700 (PDT) MIME-Version: 1.0 From: Koert van der Veer Date: Wed, 28 Oct 2015 22:45:22 +0000 Message-ID: Subject: ABI stability for loadable modules To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 28 Oct 2015 23:17:29 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 22:45:40 -0000 TL;DR: Can I safely load a kernel module compiled against a slightly different kernel? I maintain a fleet of FreeBSD machines. We've encountered a problem with one of the modules (iscsi doesn't allow passwords > 16 chars). I've determined that patching the module solves the problem for us, and doesn't affect any other kernel component. I'd like to distribute the patched module and user-space components. My use-case allows me to unload the iscsi module, but doesn't allow me to reboot the machine. However, we're running an array of different kernels (10.0-RELEASE, 10.0-RELEASE-p9, 10.0-STABLE, 10.1-RELEASE, 10.1-RELEASE-p6). I'd like to minimize the number of distinct binaries being distributed, so preferably I'd compile only one or two. My preliminary tests on VMs show me that this does not cause any immediate problems. Is this actually safe, or do I need to make distinct sets of binaries for each minor version and patchlevel of kernel in production? From owner-freebsd-hackers@freebsd.org Wed Oct 28 23:21:28 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 190F5A2096D for ; Wed, 28 Oct 2015 23:21:28 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 B628B13D1 for ; Wed, 28 Oct 2015 23:21:27 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-f79766d000002fec-ec-56315870e858 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.D0.12268.07851365; Wed, 28 Oct 2015 19:21:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t9SNLJ9S025101; Wed, 28 Oct 2015 19:21:19 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9SNLEV0026036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2015 19:21:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9SNLElR028926; Wed, 28 Oct 2015 19:21:14 -0400 (EDT) Date: Wed, 28 Oct 2015 19:21:14 -0400 (EDT) From: Benjamin Kaduk To: Koert van der Veer cc: freebsd-hackers@freebsd.org Subject: Re: ABI stability for loadable modules In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrVsQYRhmMHExl8X2zf8YLQ59jXZg 8nj/cDGTx4xP81kCmKK4bFJSczLLUov07RK4Mh6tvcNa0MJVsez5SZYGxj6OLkYODgkBE4lT 13m6GDmBTDGJC/fWs3UxcnEICSxmkpj6r5kdwtnIKPHgxQYmCOcQk8TGjh8sEE4Do0Tnq3+M IP0sAtoSe9/tZgKx2QRUJGa+2cgGYosAxX+eWwcWZxaQl7iw+RBYvbCAvsTNpufMIDanQKDE 4XvX2UFsXgFHiVtdu8DiQgIBErv332IBsUUFdCRW75/CAlEjKHFy5hMWiJlaEsunb2OZwCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGMGBKsm7g/HdQaVD jAIcjEo8vB4GhmFCrIllxZW5hxglOZiURHmvBACF+JLyUyozEosz4otKc1KLDzFKcDArifBK swDleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeKPDgRoFi1LTUyvS MnNKENJMHJwgw3mAhk8FqeEtLkjMLc5Mh8ifYlSUEue1BUkIgCQySvPgesGJZDeT6itGcaBX hHmPg1TxAJMQXPcroMFMQIPdr+iCDC5JREhJNTC6tefmXa+92ZDfvoCxJU3unMi8ibUq/C7/ 5t2WWMVzVkogMjmspSDYImqNsvgH9Rv3Dp55smZyssjJvW6t3q9VbvotvmrbxDBl9sETmjFP ghIqPnHe+f/KyOpMSUTH5sly4f33E2JOnLS+N10hYDvT4rsPg+bo1f13vvLpev3FlRsbj0d2 OKoqsRRnJBpqMRcVJwIARiZF2f8CAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 23:21:28 -0000 On Wed, 28 Oct 2015, Koert van der Veer wrote: > TL;DR: Can I safely load a kernel module compiled against a slightly > different kernel? > > > I maintain a fleet of FreeBSD machines. We've encountered a problem with > one of the modules (iscsi doesn't allow passwords > 16 chars). I've > determined that patching the module solves the problem for us, and doesn't > affect any other kernel component. I'd like to distribute the patched > module and user-space components. My use-case allows me to unload the iscsi > module, but doesn't allow me to reboot the machine. > > > However, we're running an array of different kernels (10.0-RELEASE, > 10.0-RELEASE-p9, 10.0-STABLE, 10.1-RELEASE, 10.1-RELEASE-p6). I'd like to > minimize the number of distinct binaries being distributed, so preferably > I'd compile only one or two. My preliminary tests on VMs show me that this > does not cause any immediate problems. Is this actually safe, or do I need > to make distinct sets of binaries for each minor version and patchlevel of > kernel in production? Kernel ABI stability is guaranteed(*) within a major release branch. -Ben (*) there are occasional exceptions involving portions of the network stack, but 10.x is probably better than 9.x in this regard From owner-freebsd-hackers@freebsd.org Wed Oct 28 23:54:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E45BA20ED3 for ; Wed, 28 Oct 2015 23:54:14 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 3C5B112DC for ; Wed, 28 Oct 2015 23:54:14 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3nmRZT6cKWz7J for ; Thu, 29 Oct 2015 00:54:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1446076446; x=1448668447; bh=mXK KYJhf4UzBIv9rzaoLiOg1MsxWVXbT6Rh1Uigl9QI=; b=aMrCWnvFyfMxQJytpG0 +swKPvPwcXqaaxCZ4avztyhyV93kktuC8trw0ADjRc0RWEi9OTuDFJOrp9D2Bq3v x0YQbf+w9gLWX1NRELFUDfm8PCF4HbZP0t0gvd7MbXwDoxNERMgKc6W7VrY+q2Ok eU8ZXABenfOhWYW9aSI0d8AI= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id suEQg5alUmNJ for ; Thu, 29 Oct 2015 00:54:06 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3nmRZQ6b2Pz7G for ; Thu, 29 Oct 2015 00:54:06 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3nmRZQ3JF1zyH for ; Thu, 29 Oct 2015 00:54:06 +0100 (CET) Received: from sleepy.ijs.si (2001:1470:ff80:e001::1:1) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Thu, 29 Oct 2015 00:54:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 29 Oct 2015 00:54:06 +0100 From: Mark Martinec To: freebsd-hackers@freebsd.org Subject: Re: ABI stability for loadable modules Organization: Jozef Stefan Institute In-Reply-To: References: Message-ID: <022117707d6196d7d117db0288033996@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 23:54:14 -0000 > Kernel ABI stability is guaranteed(*) within a major release branch. > -Ben > > (*) there are occasional exceptions involving portions of the network > stack, but 10.x is probably better than 9.x in this regard Two ports come to mind which crash the system when built under 10.0 and are attempted to be loaded under 10.2: emulators/virtualbox-ose-kmod x11/nvidia-driver Mark 2015-10-29 00:21, Benjamin Kaduk wrote: > On Wed, 28 Oct 2015, Koert van der Veer wrote: > >> TL;DR: Can I safely load a kernel module compiled against a slightly >> different kernel? >> >> >> I maintain a fleet of FreeBSD machines. We've encountered a problem >> with >> one of the modules (iscsi doesn't allow passwords > 16 chars). I've >> determined that patching the module solves the problem for us, and >> doesn't >> affect any other kernel component. I'd like to distribute the patched >> module and user-space components. My use-case allows me to unload the >> iscsi >> module, but doesn't allow me to reboot the machine. >> >> >> However, we're running an array of different kernels (10.0-RELEASE, >> 10.0-RELEASE-p9, 10.0-STABLE, 10.1-RELEASE, 10.1-RELEASE-p6). I'd like >> to >> minimize the number of distinct binaries being distributed, so >> preferably >> I'd compile only one or two. My preliminary tests on VMs show me that >> this >> does not cause any immediate problems. Is this actually safe, or do I >> need >> to make distinct sets of binaries for each minor version and >> patchlevel of >> kernel in production? > > Kernel ABI stability is guaranteed(*) within a major release branch. > > -Ben > > (*) there are occasional exceptions involving portions of the network > stack, but 10.x is probably better than 9.x in this regard From owner-freebsd-hackers@freebsd.org Thu Oct 29 10:57:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35B77A2032F for ; Thu, 29 Oct 2015 10:57:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC11D1034; Thu, 29 Oct 2015 10:57:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA25729; Thu, 29 Oct 2015 12:57:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Zrkti-000K9w-FT; Thu, 29 Oct 2015 12:57:34 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov , Alexander Motin References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <5631FB66.4000007@FreeBSD.org> Date: Thu, 29 Oct 2015 12:56:38 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5630FC3B.2070908@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 10:57:39 -0000 On 28/10/2015 18:47, Andriy Gapon wrote: > In either case I am going to add a few more trace points in et_start and the > HPET timer code and see if I can catch anything interesting there. Okay, more data: https://people.freebsd.org/~avg/timekeeping-ktr.2.patch https://people.freebsd.org/~avg/timekeeping.2.ktrdump.txt I think that the snippet (amended with some notes of mine) makes it painfully obvious that the timer interrupt got very delayed when all CPUs entered the idle state. I do not see anything that could suggest a FreeBSD bug. There is another sad discovery. Turns out that my CPU model provides two ways of doing C1E magic. The sane one: the north bridge logic in the CPU performs a read of a configured LVL3 register so that C3 is entered. The insane one: the CPU NB performs a write of a configured value to a configured SMI register, so that the SMI is generated and an SMM handler does the job (probably reading from LVL2 or LVL3). Looking at MSR C001_0055 I see that my BIOS has chosen the insane approach[*], quite unfortunately. Bugs in the SMM code are not unheard of, to put it mildly, so that could be an explanation for my problem. So, I guess I'll just disable C1E and end this investigation. [*] $ cpucontrol -m 0xc0010055 /dev/cpuctl0 MSR 0xc0010055: 0x00000000 0x083400b0 SmiOnCmpHalt: SMI on chip multi-processing halt. - write 0x34 to port 0xb0 -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Oct 29 12:33:44 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6F39A123B4 for ; Thu, 29 Oct 2015 12:33:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C00E81BF9; Thu, 29 Oct 2015 12:33:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9TCXcQw049685 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 29 Oct 2015 14:33:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9TCXcQw049685 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9TCXc85049684; Thu, 29 Oct 2015 14:33:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Oct 2015 14:33:38 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: Alexander Motin , freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim Subject: Re: instability of timekeeping Message-ID: <20151029123338.GU2257@kib.kiev.ua> References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> <5631FB66.4000007@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5631FB66.4000007@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 12:33:44 -0000 On Thu, Oct 29, 2015 at 12:56:38PM +0200, Andriy Gapon wrote: > On 28/10/2015 18:47, Andriy Gapon wrote: > > In either case I am going to add a few more trace points in et_start and the > > HPET timer code and see if I can catch anything interesting there. > > Okay, more data: > https://people.freebsd.org/~avg/timekeeping-ktr.2.patch > https://people.freebsd.org/~avg/timekeeping.2.ktrdump.txt > > I think that the snippet (amended with some notes of mine) makes it painfully > obvious that the timer interrupt got very delayed when all CPUs entered the idle > state. > I do not see anything that could suggest a FreeBSD bug. > > There is another sad discovery. Turns out that my CPU model provides two ways > of doing C1E magic. The sane one: the north bridge logic in the CPU performs a > read of a configured LVL3 register so that C3 is entered. The insane one: the > CPU NB performs a write of a configured value to a configured SMI register, so > that the SMI is generated and an SMM handler does the job (probably reading from > LVL2 or LVL3). Looking at MSR C001_0055 I see that my BIOS has chosen the > insane approach[*], quite unfortunately. Bugs in the SMM code are not unheard > of, to put it mildly, so that could be an explanation for my problem. > > So, I guess I'll just disable C1E and end this investigation. > > [*] > $ cpucontrol -m 0xc0010055 /dev/cpuctl0 > > > MSR 0xc0010055: 0x00000000 0x083400b0 > > SmiOnCmpHalt: SMI on chip multi-processing halt. > - write 0x34 to port 0xb0 What if you enable C3 (in OS, and possibly BIOS), but disable C1E ? Does the issue with jitter persist ? From owner-freebsd-hackers@freebsd.org Thu Oct 29 12:36:50 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB5AFA12437 for ; Thu, 29 Oct 2015 12:36:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 81DFB1D3B; Thu, 29 Oct 2015 12:36:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA27120; Thu, 29 Oct 2015 14:36:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZrmRj-000KGu-5m; Thu, 29 Oct 2015 14:36:47 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> <5631FB66.4000007@FreeBSD.org> <20151029123338.GU2257@kib.kiev.ua> Cc: Alexander Motin , freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon Message-ID: <563212BB.9030701@FreeBSD.org> Date: Thu, 29 Oct 2015 14:36:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151029123338.GU2257@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 12:36:51 -0000 On 29/10/2015 14:33, Konstantin Belousov wrote: > What if you enable C3 (in OS, and possibly BIOS), but disable C1E ? > Does the issue with jitter persist ? There is no such option in BIOS. ACPI tables advertise only C1 state regardless of C1E option. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Oct 29 22:31:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC015A216CB for ; Thu, 29 Oct 2015 22:31:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F28351294; Thu, 29 Oct 2015 22:31:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA04100; Fri, 30 Oct 2015 00:31:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Zrvj3-000KuV-Ov; Fri, 30 Oct 2015 00:31:17 +0200 Subject: Re: instability of timekeeping To: Konstantin Belousov , Alexander Motin References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> <5631FB66.4000007@FreeBSD.org> Cc: freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <56329E11.1070102@FreeBSD.org> Date: Fri, 30 Oct 2015 00:30:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5631FB66.4000007@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 22:31:27 -0000 On 29/10/2015 12:56, Andriy Gapon wrote: > Okay, more data: > https://people.freebsd.org/~avg/timekeeping-ktr.2.patch > https://people.freebsd.org/~avg/timekeeping.2.ktrdump.txt > > I think that the snippet (amended with some notes of mine) makes it painfully > obvious that the timer interrupt got very delayed when all CPUs entered the idle > state. > I do not see anything that could suggest a FreeBSD bug. > > There is another sad discovery. Turns out that my CPU model provides two ways > of doing C1E magic. The sane one: the north bridge logic in the CPU performs a > read of a configured LVL3 register so that C3 is entered. The insane one: the > CPU NB performs a write of a configured value to a configured SMI register, so > that the SMI is generated and an SMM handler does the job (probably reading from > LVL2 or LVL3). Looking at MSR C001_0055 I see that my BIOS has chosen the > insane approach[*], quite unfortunately. Bugs in the SMM code are not unheard > of, to put it mildly, so that could be an explanation for my problem. > > So, I guess I'll just disable C1E and end this investigation. Just in case anyone is still interested in this, I have found that a newer BIOS version is available for my motherboard and it includes a newer version of AGESA. So, I upgraded the BIOS and the new version does C1E in the sane way: $ cpucontrol -m 0xc0010055 /dev/cpuctl0 MSR 0xc0010055: 0x00000000 0x14c14015 C1eOnCmpHalt: C1E on chip multi-processing halt. - read from 0x4015 Also, after a few hours of testing I do not see any problems with the timekeeping. So, either the problem was indeed in the SMM code in the older BIOS or the older BIOS incorrectly configured the sleep break events. Unfortunately, the newer BIOS has a regression in a different area: it fails to access HDD LBAs greater than INT32_MAX (offsets beyond 1TB on my HDDs with 512-byte native sector sizes). But that's a different story. > [*] > $ cpucontrol -m 0xc0010055 /dev/cpuctl0 > > > MSR 0xc0010055: 0x00000000 0x083400b0 > > SmiOnCmpHalt: SMI on chip multi-processing halt. > - write 0x34 to port 0xb0 > -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Oct 30 11:43:54 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B1F5A20E15 for ; Fri, 30 Oct 2015 11:43:54 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 C9ADF1A26 for ; Fri, 30 Oct 2015 11:43:53 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by lbjm5 with SMTP id m5so48554013lbj.3 for ; Fri, 30 Oct 2015 04:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rCJ2SUUPWWGWorub0v8r9fGuTgfWLZMsT5GmqcusBws=; b=vw96BAyqV2BzhF5l+GyNSzmNONgTd+56GnkPhAOAIIPwL1UeP6ZRjjLnEWZn+VU9Jd ucnwiOX5OoRce73+OtC6ZLP5I/qEJaZgQr4Dn30lhVk+ynt+n16gEraxgoxj/0OMSdBk GT/DBbT1dhSh+VtG55QaAERw8yukflbBWGuZnXCPbWqsx4Dy7VYFn0FiIcn+r6ltTf/I Alfbg0wEXWKFKbMT0lyguwJKG1USi7xli9NsIR9lfgl8C82XDkTiBTxh0vfxhfWAxBz0 zDRRlx21jmlUdDX0LK+iMhxjepYPrZTg+DNMW0+hUZbgpp122DGL9MzWwqsjdplBsaBa LmEw== MIME-Version: 1.0 X-Received: by 10.112.204.67 with SMTP id kw3mr3690791lbc.60.1446205431956; Fri, 30 Oct 2015 04:43:51 -0700 (PDT) Received: by 10.25.144.136 with HTTP; Fri, 30 Oct 2015 04:43:51 -0700 (PDT) In-Reply-To: <3250582195207722079@scdbackup.webframe.org> References: <3250582195207722079@scdbackup.webframe.org> Date: Fri, 30 Oct 2015 12:43:51 +0100 Message-ID: Subject: Re: What to do with triaged Coverity complaints about makefs ? From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: Thomas Schmitt Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 30 Oct 2015 11:52:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 11:43:54 -0000 2015-10-08 20:17 GMT+02:00 Thomas Schmitt : > Hi, > > Alan Somers wrote: >> Filling out the Coverity triage info is good. > > It seems that i am not authorized. The "Apply" button is greyed out > even if i choose menu items and fill fields. Only members of the Project (i.e. people with @freebsd.org addresses) have full access. From owner-freebsd-hackers@freebsd.org Fri Oct 30 11:46:08 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28B24A20EA8 for ; Fri, 30 Oct 2015 11:46:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A66531AD0; Fri, 30 Oct 2015 11:46:07 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by lfbf136 with SMTP id f136so17813467lfb.0; Fri, 30 Oct 2015 04:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bkHA7Bt9RPlNq/plVdJKLSVTHvC1LVbmRk50+sp3TJ8=; b=ElXNEu6w/c89HTGO8ueyyvAQpJ1OeBYtYVZIbCZ0p7wHzG3F4bso9i7ywoTiuOfVR9 YiTK2RZlCrtl5NUToIlmOHwo0rnEc1SNeMa8572vkQdygn930oH9PQiuzP174W/8Ooby owLLk2sKvU1MKqcQ+VfapMhq5537vhKYbVfmur9y1yLahkEHSF7mcZXO45zTAl2i7YZe 9+8U8xb+I/cj/oUGEJS2cCqwlNzmu+w2RWR5iuUp+CJGkj0lf+nmtU0vgTq1xKSiJaRt dwGqMvQYlmDyEaUjae5A0i6Rv1GgbECQ/n80rHN2c2SmBJwchH7NTqTUkcJ1tE1KqwGe waQQ== MIME-Version: 1.0 X-Received: by 10.25.20.158 with SMTP id 30mr2506207lfu.28.1446205565611; Fri, 30 Oct 2015 04:46:05 -0700 (PDT) Received: by 10.25.144.136 with HTTP; Fri, 30 Oct 2015 04:46:05 -0700 (PDT) In-Reply-To: References: <302195821622251047657@scdbackup.webframe.org> Date: Fri, 30 Oct 2015 12:46:05 +0100 Message-ID: Subject: Re: What to do with triaged Coverity complaints about makefs ? From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: Alan Somers Cc: Thomas Schmitt , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 30 Oct 2015 12:17:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 11:46:08 -0000 2015-10-08 17:01 GMT+02:00 Alan Somers : > After your patches are committed, coverity will update the issues > automatically on its next scan. It currently scans once every 2 or 3 > weeks. Umm, yeah, so ... as I stated on a recent thread, this actually broke down. If you don't see a run _every_ week (ideally 2x a week), then yell at me, because something has broken (again) then. Have I mentioned that I'm looking for volunteers to up the bus factor here? :) Cheers, Uli From owner-freebsd-hackers@freebsd.org Fri Oct 30 12:50:33 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B077BA214A6 for ; Fri, 30 Oct 2015 12:50:33 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01CF21E15 for ; Fri, 30 Oct 2015 12:50:32 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from scdbackup.webframe.org ([79.192.89.160]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MgLMU-1a5q0H39Da-00NigE for ; Fri, 30 Oct 2015 13:50:23 +0100 Date: Fri, 30 Oct 2015 13:49:46 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: Re: What to do with triaged Coverity complaints about makefs ? Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit References: In-Reply-To: Message-Id: <1195458027528642405@scdbackup.webframe.org> X-Provags-ID: V03:K0:lIyZIyFgxqhU2NnjHflHDxoWdsIyXB+r+ImnnyzzDMxid1S+5ID 43vRH3EhcVYLW6elF0IPbmeESxKE5YowyCo6voVJhgQJ14HzAKDiBYQf9iRuY/e5Lqk46T1 j/9RuAAqRCr00dgoV7NJ+R0AKyIfLfFOqbN1/v2sRxXqBjMRPbGTcSy8gZvNpKLy43WjjKv 1bCv9Z9I+o87ot3PSoXjQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:snoy78RwdyE=:nhH7Ob9oPiigfFKnJixsBs xWgt+0A7RF9pKSKNjItZOZVxZm8dXkmbTzmjzlsALOY+X7cT5xjNKz08c4p9em0jUeO8YCv1Z qXZV6uDm5wt63X6pKHot0tEyT8qs2sF4yPrMvJCZ531VsDh3O3YAUnu+nYUb7qD9+ad/BUg1i Tl5b7YADjz0CLynl6uatyfpAHT94NMWam4M34Z0egpqlqVsMs2GxswzkvA5lZHba87wkb1ED6 BPD3aIiObfUXcC57aqw7FqHcH70+FYo7Aab99D/SbkqsBiImYThswMad2gKNfkaPDD4BDOrqt 6PROd5MOGWpxxuMBWbfQyS9RxfRyyhtnxX71dl/LXVnnOv4QlTh5lO6juGYo8eTmStPTn1//9 puuvU1Q0jElXNvIzbjhbRZUF7YqtYggOSkLBWtIgQnDvhpMd6jGVz9RIoIgBaY+aTmiWdnCob hc4QVLjbJGDTsDxSCMMXbwk2BvIBQOlkcCxj2xV6wA8JyKz0+25ATMrhxej5m+4iZcNtesc51 Zk5WBsJ8j7f7JPuNOvnQttnYBg13HDRESitUFp5wVWryBPqkPrIzm//9hmGNH5aWPp941knix 4MY5N2BNep8nRHxtpNVME3cP9CYyXILwQzeJvIxg8aVh6Fz7dctdhSx2tnSPf0PCnbmn7AWWV DDHGv6dHVDyrBK+LAvrrMNR/4+WzVELdsAepcbLgXvDaXqRIGy13z3fZwpb48DsWqUcatX5qy m6aZg21QeVNdsLWkl9/CdDdLuXs41SCA26LHNZspEmJz2sy6kBmB+e7fNNXoyd7EpNrMvveE3 dkE9H3h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 12:50:33 -0000 Hi, Alan Somers wrote: > > > Filling out the Coverity triage info is good. i wrote: > > It seems that i am not authorized. Ulrich Spörlein wrote: > Only members of the Project (i.e. people with @freebsd.org addresses) > have full access. I have filed two handful of PRs, which ngie@FreeBSD.org assigned to himself meanwhile. The CIDs are named in their subjects. So it should be possible to triage them in Coverity when they have been processed for FreeBSD. > If you don't see a run _every_ week (ideally 2x a week), then yell at > me, because something has broken (again) then. I got a mail that a rescan happened a few days ago. But since most of the PRs still have to be processed, i did not look for changes there. ------------------------------------------------------------ Overview of PRs: PR 203644 makefs: Coverity CID 974635, 974636: Copying several struct elements by single memcpy(). PR 203938 makefs: Coverity CID 975345, 975346: No provisions for i/o error PR 203937 makefs: Coverity CID 975347, 975348: No provisions for i/o error PR 203923 makefs: Coverity CID 975621: False positive PR 203645 makefs: Coverity CID 976312: SIGSEGV with option -l 3 PR 203940 makefs: Coverity CID 976847: Delayed error with wrong output file type PR 203943 makefs: Coverity CID 977469: False positive PR 203646 makefs: Coverity CID 977470: Writes slightly wrong El Torito Boot Record PR 203647 makefs: Coverity CID 978431: No free() after malloc(). PR 203944 makefs: Coverity CID 979130, 979131: Possibly gone after PR 203938 / CID 975345, 975346 is done PR 203648 makefs: Coverity CID 1008927: sizeof() compared against desired bit count rather than byte count PR 203649 makefs: Coverity CID 1305659: Unclear whether reaction on malloc failure suffices. (Meanwhile it is clear that err() suffices.) ------------------------------------------------------------ Have a nice day :) Thomas From owner-freebsd-hackers@freebsd.org Fri Oct 30 15:50:24 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E7ABA20AEB for ; Fri, 30 Oct 2015 15:50:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 65DE112D9; Fri, 30 Oct 2015 15:50:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA18038; Fri, 30 Oct 2015 17:50:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZsBwZ-000M5w-01; Fri, 30 Oct 2015 17:50:19 +0200 Subject: Re: instability of timekeeping To: Adrian Chadd References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> <5631FB66.4000007@FreeBSD.org> <56329E11.1070102@FreeBSD.org> Cc: Konstantin Belousov , Alexander Motin , freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <56339196.3060304@FreeBSD.org> Date: Fri, 30 Oct 2015 17:49:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 15:50:24 -0000 On 30/10/2015 15:22, Adrian Chadd wrote: > Hm! > > are you able to come up with a sane way to check whether it does C1E > the silly way (eg that MSR on that particular platform) so we can > print/disable it? > > That way noone else has this same problem. Well, even the silly way can work correctly. I believe that this particular BIOS had a bug, but there are many vendors and versions out there. It might still make sense to print a warning. It should be as easy as checking bit AMDK8_SMIONCMPHALT in MSR_AMDK8_IPM, see sys/x86/x86/cpu_machdep.c. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Oct 30 13:22:15 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07EFFA21B9F for ; Fri, 30 Oct 2015 13:22:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 C28DE1D75; Fri, 30 Oct 2015 13:22:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbdj2 with SMTP id dj2so10755908igb.1; Fri, 30 Oct 2015 06:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+jnwcPznB9yGqodQRiqDMvGtBFFGdpevJM3UKGbYSmk=; b=t95MPk99pBKt9tdtPpLLOPUsZFUIdnYsGmEM0tmVMWd4NdqCiDqaD+yAR0aTWwKK06 dbUcgZkhYI7EGU4Rf1D1cfQVSimRF1PeYrwBLGxq9wHQiT8gYRptaGuoJa6F2XV7mQXQ h4nI3ENanZ412CUtO0ikdPvli8I1M/SXt5p1bp87J/mg6k2fjyvGIRQtQ9PbJKeVTGVs XIi7PxREXzkx9bkWGwTMhB4gjEM95CsOfdWgF04pN+anVEhyyp4tq84RJmVddhm2wt7j cKc1EIj4yuojRPMbZNw+brWJwOMcqckdg7V4r7zWvt1FSf7YvcfLuF9nTENpMTugPnB6 3zGQ== MIME-Version: 1.0 X-Received: by 10.50.73.228 with SMTP id o4mr2758121igv.37.1446211334197; Fri, 30 Oct 2015 06:22:14 -0700 (PDT) Received: by 10.36.46.66 with HTTP; Fri, 30 Oct 2015 06:22:14 -0700 (PDT) In-Reply-To: <56329E11.1070102@FreeBSD.org> References: <56261398.60102@FreeBSD.org> <56261FE6.90302@FreeBSD.org> <56274FFC.2000608@FreeBSD.org> <20151021184850.GX2257@kib.kiev.ua> <562F3E2F.2010100@FreeBSD.org> <20151027115810.GU2257@kib.kiev.ua> <562F8109.4050203@FreeBSD.org> <20151027140403.GB2257@kib.kiev.ua> <5630FC3B.2070908@FreeBSD.org> <5631FB66.4000007@FreeBSD.org> <56329E11.1070102@FreeBSD.org> Date: Fri, 30 Oct 2015 06:22:14 -0700 Message-ID: Subject: Re: instability of timekeeping From: Adrian Chadd To: Andriy Gapon Cc: Konstantin Belousov , Alexander Motin , freebsd-hackers , Poul-Henning Kamp , Jung-uk Kim Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 30 Oct 2015 16:43:59 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 13:22:15 -0000 Hm! are you able to come up with a sane way to check whether it does C1E the silly way (eg that MSR on that particular platform) so we can print/disable it? That way noone else has this same problem. -a From owner-freebsd-hackers@freebsd.org Fri Oct 30 18:25:25 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26E17A22BFC for ; Fri, 30 Oct 2015 18:25:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 050331B1E for ; Fri, 30 Oct 2015 18:25:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 19D08B915; Fri, 30 Oct 2015 14:25:24 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: "Matthew D. Fuller" , Kurt Lidl Subject: Re: Missing "Local system status" Date: Fri, 30 Oct 2015 10:42:56 -0700 Message-ID: <1579252.MOChMlxT6g@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150915175222.GG1709@over-yonder.net> References: <20150915080318.GA89697@server.rulingia.com> <55F811F1.7040202@pix.net> <20150915175222.GG1709@over-yonder.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Oct 2015 14:25:24 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 18:25:25 -0000 On Tuesday, September 15, 2015 12:52:22 PM Matthew D. Fuller wrote: > On Tue, Sep 15, 2015 at 08:41:21AM -0400 I heard the voice of > Kurt Lidl, and lo! it spake thus: > > > > So the real argument ought to be if rwhod/ruptime ought to be part of a > > different MK_xxx, > > I think Peter's point is that 430.status-rwho shows uptime(1) info > too, if rwhod isn't writing out data for it to ruptime(1), so it's > still useful even without r*. Which also means it's slightly > misnamed, but... Humm. I'm inclined to just always install it. Having a second script would just duplicate code (and then having rwho in the name would be confusing). -- John Baldwin