From owner-freebsd-hackers@freebsd.org Sun Sep 23 22:19:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5621B109BA5C for ; Sun, 23 Sep 2018 22:19:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id E508B85C38 for ; Sun, 23 Sep 2018 22:19:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 9B538571; Mon, 24 Sep 2018 01:19:31 +0300 (MSK) Date: Mon, 24 Sep 2018 01:19:10 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Message-ID: <971906820.20180924011910@serebryakov.spb.ru> To: FreeBSD Hackers CC: Hans-Joerg Hoexer Subject: Is there support for Intel Trusted Execution Engine? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 22:19:33 -0000 Hello FreeBSD, I have system which contains, among other: none0@pci0:0:26:0: class=0x108000 card=0x72708086 chip=0x22988086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine' class = encrypt/decrypt Looks like, tpm(8) doesn't support it. Is it worth supporting at all? Is it TPM or something else? -- Best regards, Lev mailto:lev@FreeBSD.org From owner-freebsd-hackers@freebsd.org Mon Sep 24 00:57:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B81B109F0E7 for ; Mon, 24 Sep 2018 00:57:12 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9AD5F8A0BB; Mon, 24 Sep 2018 00:57:11 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-217ff7000000432a-af-5ba83533d83e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.20.17194.33538AB5; Sun, 23 Sep 2018 20:52:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w8O0pxgb031072; Sun, 23 Sep 2018 20:52:00 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8O0ptGC020536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Sep 2018 20:51:58 -0400 Date: Sun, 23 Sep 2018 19:51:55 -0500 From: Benjamin Kaduk To: Lev Serebryakov Cc: FreeBSD Hackers , Hans-Joerg Hoexer Subject: Re: Is there support for Intel Trusted Execution Engine? Message-ID: <20180924005155.GF24695@kduck.kaduk.org> References: <971906820.20180924011910@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <971906820.20180924011910@serebryakov.spb.ru> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nomtiuiLaYNl3KYvtm/8xWszd9pHN onfVRlYHZo8Zn+azeMx6uY05gCmKyyYlNSezLLVI3y6BK+Pm6d+MBXNZKx78fsrSwNjO0sXI ySEhYCKx/eMPRhBbSGAxk0TvjoQuRi4geyOjxNZTLxghnKtMEoevzmMHqWIRUJXof9IG1s0m oCLR0H2ZGcQWAYq/+/8erIZZIEvi87sGVhBbWMBRYvuBI2AbeIG23Tv/EqiGA2iopUTrHTWI sKDEyZlPWCBatSRu/HvJBFLCLCAtsfwfB0iYU8BKouHpC7ApogLKEnv7DrFPYBSYhaR7FpLu WQjdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgQFK6ck3w7GSQ3ehxgF OBiVeHhX3F4eLcSaWFZcmXuIUZKDSUmUl/8fUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr9st oBxvSmJlVWpRPkxKmoNFSZx3QsviaCGB9MSS1OzU1ILUIpisDAeHkgTvT+MV0UKCRanpqRVp mTklCGkmDk6Q4TxAwz+B1PAWFyTmFmemQ+RPMSpKifNWmAAlBEASGaV5cL2gZCKRvb/mFaM4 0CvCvAkgVTzARATX/QpoMBPQ4CuzloAMLklESEk1MF5onLthmnR4Th3DBW21M6ln31z4s8Ko ue1vqGq74bP5l+/d2vVtiqqm39czV28qOpbrW+U97FS2lPz587DYjDvndq2qnRyt7syvHLyu ej1z97lnCf+m6cnVKH0KmPRyW9pHj2lfPka8P8B/hSdvr+RLpr3LI8xeKYXnZDwx2sci/Vjn MIdfja0SS3FGoqEWc1FxIgB55qCvAQMAAA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 00:57:12 -0000 On Mon, Sep 24, 2018 at 01:19:10AM +0300, Lev Serebryakov wrote: > Hello FreeBSD, > > I have system which contains, among other: > > none0@pci0:0:26:0: class=0x108000 card=0x72708086 chip=0x22988086 rev=0x35 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine' > class = encrypt/decrypt > > Looks like, tpm(8) doesn't support it. Is it worth supporting at all? Is it > TPM or something else? This is the Intel SGX technology, if I understand correctly. Which is not really the same sort of thing that tpm(8) seems to be doing. -Ben From owner-freebsd-hackers@freebsd.org Mon Sep 24 16:01:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C63510B08F4 for ; Mon, 24 Sep 2018 16:01:46 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 EBAAD86EBB for ; Mon, 24 Sep 2018 16:01:45 +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 w8OG1L6c025214 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Sep 2018 18:01:21 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w8OG1GXX025211; Mon, 24 Sep 2018 18:01:16 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Mon, 24 Sep 2018 18:01:16 +0200 (CEST) From: Wojciech Puchar To: Wojciech Puchar cc: freebsd-hackers@freebsd.org Subject: Re: attempt to make UEFI bootable pendrive In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 16:01:46 -0000 thanks for help. it's all fine. only under qemu it doesn't work. on real computer it works On Fri, 21 Sep 2018, Wojciech Puchar wrote: > i've made pendrive with GPT as for UEFI boot > > gpart da0 shows > > => 40 30998448 da0 GPT (15G) > 40 1600 1 efi (800K) > 1640 24 - free - (12K) > 1664 30996800 2 freebsd-ufs (15G) > 30998464 24 - free - (12K) > > > efi partition filled from /boot/boot1.efifat, partition 2 with FreeBSD > installed, /boot populated etc. > > all done as per > https://wiki.freebsd.org/UEFI > > tried with qemu as in this tutorial > > the result is as follows: > > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: ZFS UFS > Load Path: \EFI\BOOT\BOOTX64.EFI > Load Device: > PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,GPT,2C0157FF-BDC7-11E8-A22C-3C52820D28A6,0x28,0x640) > BootCurrent: 0004 > BootOrder: 0000 0001 0002 0003 0004[*] 0005 0006 0007 > Probing 6 block devices......*.. done > ZFS found no pools > UFS found 1 partition > Failed to start image provided by UFS (9) > !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! > ExceptionData - 0000000000000000 I:0 R:0 U:0 W:0 P:0 PK:0 S:0 > RIP - 0000000007F16F6F, CS - 0000000000000038, RFLAGS - 0000000000000202 > RAX - 0000000000000001, RCX - 0000000000000010, RDX - 0000000007F0A75C > RBX - 000000000000000E, RSP - 0000000007F0A690, RBP - 0000000007F0A75C > RSI - 0000000007F0A75C, RDI - 000000000000000E > R8 - 0000000000000000, R9 - 00000000068A7270, R10 - 000000008010E640 > R11 - 0000000000000000, R12 - 00000000068AF420, R13 - 0000000000000001 > R14 - 0000000007F0A75C, R15 - 0000000000000000 > DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 > GS - 0000000000000030, SS - 0000000000000030 > CR0 - 0000000080010033, CR2 - FFFFFFFFFFFFFFF6, CR3 - 0000000007C01000 > CR4 - 0000000000000668, CR8 - 0000000000000000 > DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 > DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 > GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000 > IDTR - 00000000072BF018 0000000000000FFF, TR - 0000000000000000 > FXSAVE_STATE - 0000000007F0A2F0 > !!!! Find image based on IP(0x7F16F6F) > /home/jenkins/workspace/edk2/rpms/build/edk2-g4423f0bc61/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePk > > > what i am doing wrong? > _______________________________________________ > 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 Sep 25 13:09:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 251A110B1B8B for ; Tue, 25 Sep 2018 13:09:54 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 C3FDD71354 for ; Tue, 25 Sep 2018 13:09:53 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 63FCE21F8E for ; Tue, 25 Sep 2018 09:09:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 25 Sep 2018 09:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=g4ZTzatFDyjI4V7cu 6LBhpocKX6YBA1+i0S7ANdEfX8=; b=mNQBc2zHmqTUHn+ITrFXEaWZaSjLTAojE DFYKha+WhkJeZPQWF+9MbEHCsxgKZkD/a4bi2HwGHQLx+4jG3cowd2GQg9h+ics+ LGqJhs5zPA8t0WVmfXxov85pF+sDqRGFMKlZtON8j2FaHwBkgKjC7NycoXt0itoy k8rYcKJ588cNB2qeFoY5LsehK7zlvEQURFN/8uQBC1l6YGrF8UD9C4Pk6/zskt76 AZGOoGucAenpmYXQ2ABMfibIV6b5fRGUU800Mn7OqsnRkrGpCDevSmjUHlfl8opx ypMk8qOMkMQpiTJ4OgOe3cx3p4QjKA2+RjKTZY9mthiAjTASFLcCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=g4ZTzatFDyjI4V7cu6LBhpocKX6YBA1+i0S7ANdEfX8=; b=JgqnA+r3 pVe+ad9yGjb6QigVhqgUQ0kgm/DwHcYU2nolsg9gClRyw3DDV1h4THqIq6lOqF+q n1oDU1ll20ocA9JytH4kizqs5S16+L09bqX+XizlnfCGEMTE43uWG+3g8AvXxprH Bv6KY/O3X/LJdm7+u8fueC8cqVZX+KCJi1HOOM+orxqPZfirmrpzuhselVUT2/y8 5UzLkspUVPELQ85JUV5fB7H4Qj267NifJMKKjiBQBor2C5khmZyI0pNkBTl96S9u oOVApsmKnKZejl4ytoErtKaTC/S2kycOwem2t56hKSbrLqoh689y44afiZy2JHhU UCoj/CQcs3lCeg== X-ME-Proxy: X-ME-Sender: Received: from thor.yuripv.net (unknown [62.183.127.62]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B2FC102DD for ; Tue, 25 Sep 2018 09:09:52 -0400 (EDT) To: freebsd-hackers@freebsd.org From: Yuri Pankov Subject: allow specifying literal values in MODULE_PNP_INFO(9) Message-ID: <2926f43a-4709-3335-07a4-03248e13675a@yuripv.net> Date: Tue, 25 Sep 2018 16:10:26 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F77BAD18663E3FDB44654300" Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 13:09:54 -0000 This is a multi-part message in MIME format. --------------F77BAD18663E3FDB44654300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Looking at adding the MODULE_PNP_INFO() entry to iwm(4), I came up with the patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231625 adding redundant and useless vendor field to iwm_devices. While it works, it's unfortunate, and I have started looking into possible solutions and the result is a small patch for kldxref(8) allowing specifying literal values in descriptor_string like the following: MODULE_PNP_INFO("U16=8086:vendor;U16:device;P:#", pci, iwm_pci_driver, iwm_devices, sizeof(iwm_devices[0]), nitems(iwm_devices)); ...so that we always have vendor 0x8086 and only consume the device field. If it makes at least some sense, I'll put it for review. --------------F77BAD18663E3FDB44654300 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="kldxref-literal.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kldxref-literal.diff" ZGlmZiAtLWdpdCBhL3Vzci5zYmluL2tsZHhyZWYva2xkeHJlZi5jIGIvdXNyLnNiaW4va2xk eHJlZi9rbGR4cmVmLmMKaW5kZXggZjBkNjk5MzY5ZGJkLi5lNDk0ZThhOWYwMzkgMTAwNjQ0 Ci0tLSBhL3Vzci5zYmluL2tsZHhyZWYva2xkeHJlZi5jCisrKyBiL3Vzci5zYmluL2tsZHhy ZWYva2xkeHJlZi5jCkBAIC0xNjgsNyArMTY4LDcgQEAgcG5wX2Vpc2Fmb3JtYXQodWludDMy X3QgaWQpCiAKIHN0cnVjdCBwbnBfZWx0CiB7Ci0JaW50CXBlX2tpbmQ7CS8qIFdoYXQga2lu ZCBvZiBlbnRyeSAqLworCWludAkJcGVfa2luZDsJLyogV2hhdCBraW5kIG9mIGVudHJ5ICov CiAjZGVmaW5lIFRZUEVfU1pfTUFTSwkweDBmCiAjZGVmaW5lIFRZUEVfRkxBR0dFRAkweDEw CS8qIGFsbCBmJ3MgaXMgYSB3aWxkY2FyZCAqLwogI2RlZmluZQlUWVBFX0lOVAkweDIwCS8q IElzIGEgbnVtYmVyICovCkBAIC0xOTEsOCArMTkxLDkgQEAgc3RydWN0IHBucF9lbHQKICNk ZWZpbmUgVFlQRV9QCQk5CiAjZGVmaW5lIFRZUEVfRQkJMTAKICNkZWZpbmUgVFlQRV9UCQkx MQotCWludAlwZV9vZmZzZXQ7CS8qIE9mZnNldCB3aXRoaW4gdGhlIGVsZW1lbnQgKi8KLQlj aGFyICoJcGVfa2V5OwkJLyogcG5wIGtleSBuYW1lICovCisJaW50CQlwZV9vZmZzZXQ7CS8q IE9mZnNldCB3aXRoaW4gdGhlIGVsZW1lbnQgKi8KKwljaGFyCQkqcGVfa2V5OwkvKiBwbnAg a2V5IG5hbWUgKi8KKwl1aW50MzJfdAlwZV92YWx1ZTsJLyogbGl0ZXJhbCB2YWx1ZSwgaWYg YW55ICovCiAJVEFJTFFfRU5UUlkocG5wX2VsdCkgbmV4dDsgLyogTGluayAqLwogfTsKIHR5 cGVkZWYgVEFJTFFfSEVBRChwbnBfaGVhZCwgcG5wX2VsdCkgcG5wX2xpc3Q7CkBAIC0yMzIs MTAgKzIzMywxMCBAQCBzdGF0aWMgaW50CiBwYXJzZV9wbnBfbGlzdChjb25zdCBjaGFyICpk ZXNjLCBjaGFyICoqbmV3X2Rlc2MsIHBucF9saXN0ICpsaXN0KQogewogCWNvbnN0IGNoYXIg KndhbGtlciwgKmVwOwotCWNvbnN0IGNoYXIgKmNvbG9uLCAqc2VtaTsKKwljb25zdCBjaGFy ICphc3NpZ24sICpjb2xvbiwgKnNlbWk7CiAJc3RydWN0IHBucF9lbHQgKmVsdDsKIAljaGFy ICpuZDsKLQljaGFyIHR5cGVbOF0sIGtleVszMl07CisJY2hhciB0eXBlWzhdLCB2YWx1ZVs5 XSwga2V5WzMyXTsKIAlpbnQgb2ZmOwogCiAJd2Fsa2VyID0gZGVzYzsKQEAgLTI0NSwxNCAr MjQ2LDI4IEBAIHBhcnNlX3BucF9saXN0KGNvbnN0IGNoYXIgKmRlc2MsIGNoYXIgKipuZXdf ZGVzYywgcG5wX2xpc3QgKmxpc3QpCiAJaWYgKHZlcmJvc2UgPiAxKQogCQlwcmludGYoIkNv bnZlcnRpbmcgJXMgaW50byBhIGxpc3RcbiIsIGRlc2MpOwogCXdoaWxlICh3YWxrZXIgPCBl cCkgeworCQlhc3NpZ24gPSBzdHJjaHIod2Fsa2VyLCAnPScpOwogCQljb2xvbiA9IHN0cmNo cih3YWxrZXIsICc6Jyk7CiAJCXNlbWkgPSBzdHJjaHIod2Fsa2VyLCAnOycpOworCQlpZiAo Y29sb24gPT0gTlVMTCkKKwkJCWdvdG8gZXJyOworCQlpZiAoYXNzaWduICE9IE5VTEwgJiYg YXNzaWduID4gY29sb24pCisJCQlhc3NpZ24gPSBOVUxMOwogCQlpZiAoc2VtaSAhPSBOVUxM ICYmIHNlbWkgPCBjb2xvbikKIAkJCWdvdG8gZXJyOwogCQlpZiAoY29sb24gLSB3YWxrZXIg PiBzaXplb2YodHlwZSkpCiAJCQlnb3RvIGVycjsKLQkJc3RybmNweSh0eXBlLCB3YWxrZXIs IGNvbG9uIC0gd2Fsa2VyKTsKLQkJdHlwZVtjb2xvbiAtIHdhbGtlcl0gPSAnXDAnOworCQlp ZiAoYXNzaWduICE9IE5VTEwpIHsKKwkJCXN0cm5jcHkodHlwZSwgd2Fsa2VyLCBhc3NpZ24g LSB3YWxrZXIpOworCQkJdHlwZVthc3NpZ24gLSB3YWxrZXJdID0gJ1wwJzsKKwkJCWlmIChj b2xvbiAtIGFzc2lnbiA+PSBzaXplb2YodmFsdWUpKQorCQkJCWdvdG8gZXJyOworCQkJc3Ry bmNweSh2YWx1ZSwgYXNzaWduICsgMSwgY29sb24gLSBhc3NpZ24gLSAxKTsKKwkJCXZhbHVl W2NvbG9uIC0gYXNzaWduIC0gMV0gPSAnXDAnOworCQl9IGVsc2UgeworCQkJc3RybmNweSh0 eXBlLCB3YWxrZXIsIGNvbG9uIC0gd2Fsa2VyKTsKKwkJCXR5cGVbY29sb24gLSB3YWxrZXJd ID0gJ1wwJzsKKwkJfQogCQlpZiAoc2VtaSAhPSBOVUxMKSB7CiAJCQlpZiAoc2VtaSAtIGNv bG9uID49IHNpemVvZihrZXkpKQogCQkJCWdvdG8gZXJyOwpAQCAtMjY1LDggKzI4MCwxNSBA QCBwYXJzZV9wbnBfbGlzdChjb25zdCBjaGFyICpkZXNjLCBjaGFyICoqbmV3X2Rlc2MsIHBu cF9saXN0ICpsaXN0KQogCQkJc3RyY3B5KGtleSwgY29sb24gKyAxKTsKIAkJCXdhbGtlciA9 IGVwOwogCQl9Ci0JCWlmICh2ZXJib3NlID4gMSkKLQkJCXByaW50ZigiRm91bmQgdHlwZSAl cyBmb3IgbmFtZSAlc1xuIiwgdHlwZSwga2V5KTsKKwkJaWYgKHZlcmJvc2UgPiAxKSB7CisJ CQlpZiAoYXNzaWduICE9IE5VTEwpIHsKKwkJCQlwcmludGYoIkZvdW5kIHR5cGUgJXMgZm9y IG5hbWUgJXMgIgorCQkJCSAgICAid2l0aCB2YWx1ZSAlc1xuIiwgdHlwZSwga2V5LCB2YWx1 ZSk7CisJCQl9IGVsc2UgeworCQkJCXByaW50ZigiRm91bmQgdHlwZSAlcyBmb3IgbmFtZSAl c1xuIiwKKwkJCQkgICAgdHlwZSwga2V5KTsKKwkJCX0KKwkJfQogCQkvKiBTa2lwIHBvaW50 ZXIgcGxhY2UgaG9sZGVycyAqLwogCQlpZiAoc3RyY21wKHR5cGUsICJQIikgPT0gMCkgewog CQkJb2ZmICs9IHNpemVvZih2b2lkICopOwpAQCAtMzE4LDcgKzM0MCwxNCBAQCBwYXJzZV9w bnBfbGlzdChjb25zdCBjaGFyICpkZXNjLCBjaGFyICoqbmV3X2Rlc2MsIHBucF9saXN0ICps aXN0KQogCQkgKiBoYXZlIHNhbmUgb3JkZXJpbmcgb2YgdHlwZXMuCiAJCSAqLwogCQlpZiAo ZWx0LT5wZV9raW5kICYgVFlQRV9JTlQpIHsKLQkJCWVsdC0+cGVfb2Zmc2V0ID0gcm91bmR1 cDIoZWx0LT5wZV9vZmZzZXQsIGVsdC0+cGVfa2luZCAmIFRZUEVfU1pfTUFTSyk7CisJCQkv KgorCQkJICogTGl0ZXJhbCB2YWx1ZXMgKGFzc2lnbiAhPSBOVUxMKSBkb24ndCBjb25zdW1l IHNwYWNlCisJCQkgKiBpbiB0aGUgdGFibGUuCisJCQkgKi8KKwkJCWlmIChhc3NpZ24gPT0g TlVMTCkgeworCQkJCWVsdC0+cGVfb2Zmc2V0ID0gcm91bmR1cDIoZWx0LT5wZV9vZmZzZXQs CisJCQkJICAgIGVsdC0+cGVfa2luZCAmIFRZUEVfU1pfTUFTSyk7CisJCQl9CiAJCQlvZmYg PSBlbHQtPnBlX29mZnNldCArIChlbHQtPnBlX2tpbmQgJiBUWVBFX1NaX01BU0spOwogCQl9 IGVsc2UgaWYgKGVsdC0+cGVfa2luZCA9PSBUWVBFX0UpIHsKIAkJCS8qIFR5cGUgRSBzdG9y ZWQgYXMgSW50LCBkaXNwbGF5cyBhcyBzdHJpbmcgKi8KQEAgLTM0MCw5ICszNjksNyBAQCBw YXJzZV9wbnBfbGlzdChjb25zdCBjaGFyICpkZXNjLCBjaGFyICoqbmV3X2Rlc2MsIHBucF9s aXN0ICpsaXN0KQogCQkJCSAgICB3b3JkKTsKIAkJCQluZCArPSBzdHJsZW4obmQpOwogCQkJ fQotCQkJCi0JCX0KLQkJZWxzZSB7CisJCX0gZWxzZSB7CiAJCQlpZiAoZWx0LT5wZV9raW5k ICYgVFlQRV9GTEFHR0VEKQogCQkJCSpuZCsrID0gJ0onOwogCQkJZWxzZSBpZiAoZWx0LT5w ZV9raW5kICYgVFlQRV9HRSkKQEAgLTM1MSw5ICszNzgsMTggQEAgcGFyc2VfcG5wX2xpc3Qo Y29uc3QgY2hhciAqZGVzYywgY2hhciAqKm5ld19kZXNjLCBwbnBfbGlzdCAqbGlzdCkKIAkJ CQkqbmQrKyA9ICdMJzsKIAkJCWVsc2UgaWYgKGVsdC0+cGVfa2luZCAmIFRZUEVfTUFTSykK IAkJCQkqbmQrKyA9ICdNJzsKLQkJCWVsc2UgaWYgKGVsdC0+cGVfa2luZCAmIFRZUEVfSU5U KQorCQkJZWxzZSBpZiAoZWx0LT5wZV9raW5kICYgVFlQRV9JTlQpIHsKIAkJCQkqbmQrKyA9 ICdJJzsKLQkJCWVsc2UgaWYgKGVsdC0+cGVfa2luZCA9PSBUWVBFX0QpCisJCQkJaWYgKGFz c2lnbiAhPSBOVUxMKSB7CisJCQkJCWNoYXIgKmNlcDsKKworCQkJCQllcnJubyA9IDA7CisJ CQkJCWVsdC0+cGVfdmFsdWUgPSBzdHJ0b3VsKHZhbHVlLCAmY2VwLAorCQkJCQkgICAgMTYp OworCQkJCQlpZiAoZXJybm8gIT0gMCB8fCAqZXAgIT0gJ1wwJykKKwkJCQkJCWdvdG8gZXJy OworCQkJCX0KKwkJCX0gZWxzZSBpZiAoZWx0LT5wZV9raW5kID09IFRZUEVfRCkKIAkJCQkq bmQrKyA9ICdEJzsKIAkJCWVsc2UgaWYgKGVsdC0+cGVfa2luZCA9PSBUWVBFX1ogfHwgZWx0 LT5wZV9raW5kID09IFRZUEVfRSkKIAkJCQkqbmQrKyA9ICdaJzsKQEAgLTQ3MCwyMyArNTA2 LDI3IEBAIHBhcnNlX2VudHJ5KHN0cnVjdCBtb2RfbWV0YWRhdGEgKm1kLCBjb25zdCBjaGFy ICpjdmFsLAogCQkJCQkJaWYgKHZlcmJvc2UgPiAxKQogCQkJCQkJCXByaW50ZigiOiUjeDsi LCB2YWx1ZSk7CiAJCQkJCX0gZWxzZSBpZiAoZWx0LT5wZV9raW5kICYgVFlQRV9JTlQpIHsK KwkJCQkJCWNoYXIgKnZhbCA9IGVsdC0+cGVfdmFsdWUgIT0gMCA/CisJCQkJCQkgICAgKGNo YXIgKikmZWx0LT5wZV92YWx1ZSA6CisJCQkJCQkgICAgd2Fsa2VyICsgZWx0LT5wZV9vZmZz ZXQ7CisKIAkJCQkJCXN3aXRjaCAoZWx0LT5wZV9raW5kICYgVFlQRV9TWl9NQVNLKSB7CiAJ CQkJCQljYXNlIDE6Ci0JCQkJCQkJbWVtY3B5KCZ2MSwgd2Fsa2VyICsgZWx0LT5wZV9vZmZz ZXQsIHNpemVvZih2MSkpOworCQkJCQkJCW1lbWNweSgmdjEsIHZhbCwgc2l6ZW9mKHYxKSk7 CiAJCQkJCQkJaWYgKChlbHQtPnBlX2tpbmQgJiBUWVBFX0ZMQUdHRUQpICYmIHYxID09IDB4 ZmYpCiAJCQkJCQkJCXZhbHVlID0gLTE7CiAJCQkJCQkJZWxzZQogCQkJCQkJCQl2YWx1ZSA9 IHYxOwogCQkJCQkJCWJyZWFrOwogCQkJCQkJY2FzZSAyOgotCQkJCQkJCW1lbWNweSgmdjIs IHdhbGtlciArIGVsdC0+cGVfb2Zmc2V0LCBzaXplb2YodjIpKTsKKwkJCQkJCQltZW1jcHko JnYyLCB2YWwsIHNpemVvZih2MikpOwogCQkJCQkJCWlmICgoZWx0LT5wZV9raW5kICYgVFlQ RV9GTEFHR0VEKSAmJiB2MiA9PSAweGZmZmYpCiAJCQkJCQkJCXZhbHVlID0gLTE7CiAJCQkJ CQkJZWxzZQogCQkJCQkJCQl2YWx1ZSA9IHYyOwogCQkJCQkJCWJyZWFrOwogCQkJCQkJY2Fz ZSA0OgotCQkJCQkJCW1lbWNweSgmdjQsIHdhbGtlciArIGVsdC0+cGVfb2Zmc2V0LCBzaXpl b2YodjQpKTsKKwkJCQkJCQltZW1jcHkoJnY0LCB2YWwsIHNpemVvZih2NCkpOwogCQkJCQkJ CWlmICgoZWx0LT5wZV9raW5kICYgVFlQRV9GTEFHR0VEKSAmJiB2NCA9PSAweGZmZmZmZmZm KQogCQkJCQkJCQl2YWx1ZSA9IC0xOwogCQkJCQkJCWVsc2UK --------------F77BAD18663E3FDB44654300-- From owner-freebsd-hackers@freebsd.org Tue Sep 25 13:20:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BEA510B20ED for ; Tue, 25 Sep 2018 13:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C59371B2A for ; Tue, 25 Sep 2018 13:20:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x12c.google.com with SMTP id h3-v6so15308565ita.2 for ; Tue, 25 Sep 2018 06:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P4pIplyetG9MsxWPY/axfkPkzfld+asXPhr99wmS4Ak=; b=On/g9cCEj/38YUQv3lD1tPHrPSHmuaz4FXb4WmZW1bSP3zRMy7baxestPmXj+kUHt7 sCGT2IhBZL910beUm4Sq2TnerboViOJIsndNaGktRrUAaFoCwVMi4XVWCPMgAgHHqXwm HrN2qui5HIvPAXTMOFd72TF/dCWgX/4CcTt4aZMUDV3SmRKVmB3pCRob3icqDfVTPwlG 6LIt/LbVnv2hEvA6Ca/S1XDmKaIHi9l9IqOnR1Hk9SCzdNBedfWJRvh3k7kdY8PYwBXW J2rA/lVBGy9F1YNhMGOyq5HbW8O/+WNPgIade9Ejufli2Uva+RUJbmXL9Ukto6lLpL5+ gHhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P4pIplyetG9MsxWPY/axfkPkzfld+asXPhr99wmS4Ak=; b=Gak74x1zv4l57MJUWiKUHwwgn26SprjVqc68ezvEhnHdBg3P+QGzfkH93UAkQ+uUXA XupG0enR0iImxjYuKi9iWuIEAg3q9buPDe36Fen86HQc1QtzjBTSrXZFMqTAB9oICec3 bZzwlh+DTOxYb1FVu0tT6qF7Nd2GmANB4YyPuTVWcm1qDFDwbyLKU/gm5TpV6pAu80tS 4P+T9IAylWKT+3ktQbDZX/jvmYXYydpxwmrHABENDDgeRe4LV7V5T148jJo3CrjbO+H9 7JI7Fe7HcOyzsZrvFBf/21Q+pDfX5u5LdiP2CKkIOIjrrQ1NYSs5vEEDDbRIOrhW93pN K5tQ== X-Gm-Message-State: ABuFfoguOLMF+YUHperJcgaCMt++kjPV0B7xkPvX15PsB7j9huv3Z7mo 9VEtiy5IGkxcRGWRaIjfAiByWWSG/t0sA9YElmn/3Q== X-Google-Smtp-Source: ACcGV61GHj197VcimcshW6b+UQ0ZiZ03Cv+b1PT2iDmE9nAoREmCd06L52+b8etoWOtZvRR1C1ym0GzhWYVQXBiV8Sk= X-Received: by 2002:a24:a54c:: with SMTP id w12-v6mr643632iti.75.1537881615943; Tue, 25 Sep 2018 06:20:15 -0700 (PDT) MIME-Version: 1.0 References: <2926f43a-4709-3335-07a4-03248e13675a@yuripv.net> In-Reply-To: <2926f43a-4709-3335-07a4-03248e13675a@yuripv.net> From: Warner Losh Date: Tue, 25 Sep 2018 07:20:04 -0600 Message-ID: Subject: Re: allow specifying literal values in MODULE_PNP_INFO(9) To: Yuri Pankov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 13:20:17 -0000 On Tue, Sep 25, 2018 at 7:12 AM Yuri Pankov wrote: > Hi, > > Looking at adding the MODULE_PNP_INFO() entry to iwm(4), I came up with > the patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231625 > adding redundant and useless vendor field to iwm_devices. While it > works, it's unfortunate, and I have started looking into possible > solutions and the result is a small patch for kldxref(8) allowing > specifying literal values in descriptor_string like the following: > > MODULE_PNP_INFO("U16=8086:vendor;U16:device;P:#", pci, iwm_pci_driver, > iwm_devices, sizeof(iwm_devices[0]), nitems(iwm_devices)); > > ...so that we always have vendor 0x8086 and only consume the device field. > > If it makes at least some sense, I'll put it for review. > So what's wrong with using the T type that's already implemented? T:device=0x8086? Warner From owner-freebsd-hackers@freebsd.org Tue Sep 25 13:28:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E10EE10B2437 for ; Tue, 25 Sep 2018 13:28:32 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 85F2971F86 for ; Tue, 25 Sep 2018 13:28:32 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EA14F21B25; Tue, 25 Sep 2018 09:28:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 25 Sep 2018 09:28:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=cTa9R8HewzcWMygrrG5AlkZ3f9jGo A+V6vns0zyq+JU=; b=UH+kve8OFgSennYb21h5AE5fzvimFlYmClpJ4E1GqjuMN ghXNhmUWtFL+kYJTFtsVR3ErnTqYkQl+p7fGqpv7twuberUUZs6+LIlI06JJkor7 /HkstMNVQhvjfO4Dp0HYSG+DBrfMvHbnsuLMyg6+v27MEGX2xt6DZlfOOsJavF6N pH4dNbyoGAHgfcWHDkPu1zXAJHWPj1VUqKZOxXWIt64Tv61GIFehcEtgsSNetizJ A2vvze/+mGm5ariG7ijjE4CtLgKbrXs3zp/5iKU132NgF/xB56v0SZ51anTxUsxy U9KWRIEyvWkL3Z/aKwXt9vbtE6KQZcKiVyf0l77Yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cTa9R8 HewzcWMygrrG5AlkZ3f9jGoA+V6vns0zyq+JU=; b=so1pfkN4ClhLf2NqT7wd1e puyXPcDBasirXQJtjEma4Hn3IF7WEMqHf6gEvAQpzPvfmZmmWJJM5pObFvuqK+k0 nTIxhWgjsckOQRFktrx6dwGVEXVlRSC9pC7xg1DTyK4tXCWQah4P81TWAbbiy217 ShOKli+hvbXpLyaGPbMqa0Sk1F4SX2qKvs8M/kummGBSYr0qn7j2dqpF4WrJbNin f3IrnbndX5PmU6pA+LlxeFD5mrJr/sgUGIFwHQfXJ4hiMzRO4CcwNhxPtZLaPMai QEYlN+qYk/ylD+Oxt1L6QJlCxvrqPP7nWck0LKEe/2aY/wRC0xZZfxJyKVmUWE5Q == X-ME-Proxy: X-ME-Sender: Received: from thor.yuripv.net (unknown [62.183.127.62]) by mail.messagingengine.com (Postfix) with ESMTPA id EB06F102E4; Tue, 25 Sep 2018 09:28:30 -0400 (EDT) Subject: Re: allow specifying literal values in MODULE_PNP_INFO(9) To: Warner Losh Cc: freebsd-hackers@freebsd.org References: <2926f43a-4709-3335-07a4-03248e13675a@yuripv.net> From: Yuri Pankov Message-ID: <880c1557-6eba-b624-3a0f-73f67a38edc7@yuripv.net> Date: Tue, 25 Sep 2018 16:29:04 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 13:28:33 -0000 Warner Losh wrote: > On Tue, Sep 25, 2018 at 7:12 AM Yuri Pankov wrote: > >> Hi, >> >> Looking at adding the MODULE_PNP_INFO() entry to iwm(4), I came up with >> the patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231625 >> adding redundant and useless vendor field to iwm_devices. While it >> works, it's unfortunate, and I have started looking into possible >> solutions and the result is a small patch for kldxref(8) allowing >> specifying literal values in descriptor_string like the following: >> >> MODULE_PNP_INFO("U16=8086:vendor;U16:device;P:#", pci, iwm_pci_driver, >> iwm_devices, sizeof(iwm_devices[0]), nitems(iwm_devices)); >> >> ...so that we always have vendor 0x8086 and only consume the device field. >> >> If it makes at least some sense, I'll put it for review. >> > > So what's wrong with using the T type that's already implemented? > T:device=0x8086? Nothing other than my inability to read and understand the documentation. I'm actually happy that it already exists. Thanks and sorry for the noise. From owner-freebsd-hackers@freebsd.org Wed Sep 26 02:24:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5636410989D6 for ; Wed, 26 Sep 2018 02:24:37 +0000 (UTC) (envelope-from vas@admin.sibptus.ru) Received: from admin.sibptus.ru (admin.sibptus.ru [IPv6:2001:19f0:5001:21dc:5400:1ff:feaf:6afb]) (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 F0D1F8A5B5 for ; Wed, 26 Sep 2018 02:24:36 +0000 (UTC) (envelope-from vas@admin.sibptus.ru) Received: from vas by admin.sibptus.ru with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g4zVE-0007a5-6o for freebsd-hackers@freebsd.org; Wed, 26 Sep 2018 09:24:36 +0700 Date: Wed, 26 Sep 2018 09:24:36 +0700 From: Victor Sudakov To: freebsd-hackers@freebsd.org Subject: setting SSLKEYLOGFILE (for HTTPS decryption) does not work Message-ID: <20180926022436.GA29135@admin.sibptus.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Victor Sudakov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 02:24:37 -0000 Dear Colleagues, I have noticed that "env SSLKEYLOGFILE=/var/tmp/keylog.txt firefox" does not create keylog.txt on FreeBSD. On Windows, this environment variable works as expected (creates a dump file with SSL keys to be fed to Wireshark for HTTPS decryption). What am I doing wrong? I've tried this on FreeBSD 11.2 with FireFox 62.0 from the FreeBSD default package repository. This is a rather standard recipe, it's odd that it does not work on FreeBSD. Any help is appreciated. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ From owner-freebsd-hackers@freebsd.org Wed Sep 26 17:39:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36AF610B2868 for ; Wed, 26 Sep 2018 17:39:26 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9DE486E38 for ; Wed, 26 Sep 2018 17:39:25 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w8QHdLvE094794 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 26 Sep 2018 10:39:23 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com To: FreeBSD Hackers From: Craig Leres Subject: Supermicro AOC-SLG3-2M2 dual M.2 card only identifies one drive Message-ID: Date: Wed, 26 Sep 2018 10:39:21 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.1 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2107-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 17:39:26 -0000 I picked up one of these and two intel 760p M.2 drives for use with a Supermicro X10SRA-F motherboard under 11.2-RELEASE-p3. The system only identifies drive that is mounted in the top slot. I believe this pci-e x8 card mostly just wires the (m-key) M.2 connectors pins to the pci slot pins. It looks like the top drive goes to the first 4 pci-e lanes and the bottom slot the next 4 pci-e lanes. I suspect the driver is not even looking for the nvme that is connected to the second set of lanes. Can anyone tell me what it takes to support this configuration? Craig From owner-freebsd-hackers@freebsd.org Wed Sep 26 20:04:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A50810B598B for ; Wed, 26 Sep 2018 20:04:13 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57E9C8CBC1; Wed, 26 Sep 2018 20:04:12 +0000 (UTC) (envelope-from michael@fuckner.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1537992250; s=strato-dkim-0002; d=fuckner.net; h=Subject:References:In-Reply-To:Message-ID:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=Snidc3NMbO1o4K0T0xCn/dR8mYJ66IjUxsz57l+Nsuk=; b=bKviwZ692Jw7Upr1LzW/ULq+nIPoEOql5zKgc1z/S3rwFHuAuiZkZzutWJi1TqF+W8 0xIVBVw9SWWSgysSpMu83GMDnQuKvhEjI1r3C43Otlie1CF9/82Aes6ZQ8ivNDLAgrwJ 3HbNs9wGcqhd0iAZWM+NDx9qhItOwLnenEjor35IVIlUrxFZnuB3IIvqr+OIBpwVE1LM ujZnPSOKVMcG4Kv9CqRzTW2yEHxLfkRrHF12s0uaKNvIEq+39rd2E5/K8vpQclzrKYZx anc+Z1KWJBP4UcKDaMtpCDhHUmW6RpLb+Ei7Oo2gNyxSHpR+/xN3NfSxheYCq82J4pFl /umQ== X-RZG-AUTH: ":IWUHfUGtd9+6EujMWHx57N4dWae4bmTbIPWLqRDxdxMSR21kQd9enUjzgkX1WAFIuiJuAyk=" X-RZG-CLASS-ID: mo00 Received: from [100.113.10.15] by smtp.strato.de (RZmta 44.2 DYNA|AUTH) with ESMTPSA id 50a34bu8QK4923S (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate); Wed, 26 Sep 2018 22:04:09 +0200 (CEST) Date: Wed, 26 Sep 2018 22:04:10 +0200 From: michael@fuckner.net To: FreeBSD Hackers , Craig Leres Message-ID: <20e93169-d3b3-469f-8860-81b3c4d6b09c.maildroid@localhost> In-Reply-To: References: Subject: Re: Supermicro AOC-SLG3-2M2 dual M.2 card only identifies one drive MIME-Version: 1.0 X-Mailer: MailDroid/4.92 (Android 8.1.0) User-Agent: MailDroid/4.92 (Android 8.1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 20:04:13 -0000 SGksClBsZWFzZSBoYXZlIGEgbG9vayBpbiB0aGUgYmlvcyB0byBDaGFuZ2UgdGhlIFNsb3QgZnJv bSB4OCB0byB4NCt4NApNaWNoYWVsIQpTZW50IGZyb20gTWFpbERyb2lkCgotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQpGcm9tOiBDcmFpZyBMZXJlcyA8bGVyZXNAZnJlZWJzZC5vcmc+ClRvOiBG cmVlQlNEIEhhY2tlcnMgPGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZz4KU2VudDogTWkuLCAy NiBTZXAuIDIwMTggMTk6NDAKU3ViamVjdDogU3VwZXJtaWNybyBBT0MtU0xHMy0yTTIgZHVhbCBN LjIgY2FyZCBvbmx5IGlkZW50aWZpZXMgb25lIGRyaXZlCgpJIHBpY2tlZCB1cCBvbmUgb2YgdGhl c2UgYW5kIHR3byBpbnRlbCA3NjBwIE0uMiBkcml2ZXMgZm9yIHVzZSB3aXRoIGEgClN1cGVybWlj cm8gWDEwU1JBLUYgbW90aGVyYm9hcmQgdW5kZXIgMTEuMi1SRUxFQVNFLXAzLiBUaGUgc3lzdGVt IG9ubHkgCmlkZW50aWZpZXMgZHJpdmUgdGhhdCBpcyBtb3VudGVkIGluIHRoZSB0b3Agc2xvdC4g SSBiZWxpZXZlIHRoaXMgcGNpLWUgCng4IGNhcmQgbW9zdGx5IGp1c3Qgd2lyZXMgdGhlIChtLWtl eSkgTS4yIGNvbm5lY3RvcnMgcGlucyB0byB0aGUgcGNpIApzbG90IHBpbnMuIEl0IGxvb2tzIGxp a2UgdGhlIHRvcCBkcml2ZSBnb2VzIHRvIHRoZSBmaXJzdCA0IHBjaS1lIGxhbmVzIAphbmQgdGhl IGJvdHRvbSBzbG90IHRoZSBuZXh0IDQgcGNpLWUgbGFuZXMuCgpJIHN1c3BlY3QgdGhlIGRyaXZl ciBpcyBub3QgZXZlbiBsb29raW5nIGZvciB0aGUgbnZtZSB0aGF0IGlzIGNvbm5lY3RlZCAKdG8g dGhlIHNlY29uZCBzZXQgb2YgbGFuZXMuIENhbiBhbnlvbmUgdGVsbCBtZSB3aGF0IGl0IHRha2Vz IHRvIHN1cHBvcnQgCnRoaXMgY29uZmlndXJhdGlvbj8KCgkJQ3JhaWcKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qu b3JnIG1haWxpbmcgbGlzdApodHRwczovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGlu Zm8vZnJlZWJzZC1oYWNrZXJzClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVl YnNkLWhhY2tlcnMtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciCg== From owner-freebsd-hackers@freebsd.org Thu Sep 27 03:30:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66CA910980D4 for ; Thu, 27 Sep 2018 03:30:47 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from xse.com (xse.com [IPv6:2607:f2f8:abb8::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "xse.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8F9D72A81 for ; Thu, 27 Sep 2018 03:30:46 +0000 (UTC) (envelope-from leres@freebsd.org) Received-SPF: pass (dot.xse.com: authenticated connection) receiver=dot.xse.com; client-ip=2001:558:6045:10:9084:9e0:4b6d:eb99; helo=ice.alameda.xse.com; envelope-from=leres@freebsd.org; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; Received: from ice.alameda.xse.com (ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99]) (authenticated bits=0) by dot.xse.com (8.15.2/8.15.2) with ESMTPSA id w8R3UgAt034807 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Sep 2018 20:30:44 -0700 (PDT) (envelope-from leres@freebsd.org) X-Authentication-Warning: dot.xse.com: Host ice.xse.com [IPv6:2001:558:6045:10:9084:9e0:4b6d:eb99] claimed to be ice.alameda.xse.com Subject: Re: Supermicro AOC-SLG3-2M2 dual M.2 card only identifies one drive To: michael@fuckner.net, FreeBSD Hackers References: <20e93169-d3b3-469f-8860-81b3c4d6b09c.maildroid@localhost> From: Craig Leres Message-ID: <992f6d46-9b11-6e4c-f0d3-2fd2fadcbd66@freebsd.org> Date: Wed, 26 Sep 2018 20:30:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0.1 MIME-Version: 1.0 In-Reply-To: <20e93169-d3b3-469f-8860-81b3c4d6b09c.maildroid@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.1 at dot.xse.com X-Virus-Status: Clean X-GBUdb-Analysis: Unknown X-MessageSniffer-Rules: 0-0-0-2674-c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 03:30:47 -0000 On 9/26/18 11:04 AM, michael@fuckner.net wrote: > Please have a look in the bios to Change the Slot from x8 to x4+x4 Perfect, thanks! But also I see there is a linux driver available for download from the Supermicro website. Is it possible to make driver changes and talk to both nvme disks without bifurcating a pci-e slot? For future reference the knob is under: Advanced -> PCIe/PCI/PnP -> CPU SLOT{1,6} PCI-e ... bifurcation I had to do testing with a different motherboard (X10DRW-i) and even after updating the bios wasn't able to find the magic option to boot from a nvme. The manual says: change the Device Option Rom Configure "UEFI mode" from Legacy but this didn't give me any nvme drives to configure to boot from. Craig From owner-freebsd-hackers@freebsd.org Thu Sep 27 23:04:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4F3510BD178 for ; Thu, 27 Sep 2018 23:04:19 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A2C67C539; Thu, 27 Sep 2018 23:04:19 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-pf1-x431.google.com with SMTP id m77-v6so2907692pfi.8; Thu, 27 Sep 2018 16:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KCgzVRGokghuiNouQbJ9CzY64y+5Gxg3oB1fdWT2x14=; b=fxs6iq2782kUPEfZ/Im9cFmNnaQXQtwQHiO64NtI60ATXbr374Bt59lSY9gSeVp+1J a7FHs+quihkdulD2fKezRDdtACY0IFWhxf3zWhMYXY18XYHa+AuA+TUbw23DKgGNFOt0 6vj7dDUw52n0sT54p0h5umiZJEdK7+wlu67ie2Hns6IFj2IIB0Hep2wFigDXD0m2RJ3s AgQibEF5EdMM7rAJOoCSal7bYcAs+aikfCJwTvUyhKpCYxU8mMpS+HSS28BDiYQ1kuYy oRShgM+W2P0p6XspnZotYayZ2O9/+3gDFLn2P83N+mZ5QGETVTAGcgIRJWlxplAm9K9g G9ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KCgzVRGokghuiNouQbJ9CzY64y+5Gxg3oB1fdWT2x14=; b=QfE40+PqXMf2meJU0a9a+c1OZu5oM2yCRdVskncI9/u5KzZpgEZuUVawwefJ4+h+dz grK93RVZl1BYuWbIAA7et4cW7tcevZCklqKGHfBVS6w3lVRHdsrZAECM2Ki9cr5hlxz9 C5aGcEAQINLkjBkRRlBDwSPu5D3wOpg/UNVJ1vwlBHjOlEm6jUTjC3QeK8+F8YNIVh5+ H5/DqCiRrEzkvGj2JXe5B6gpToFqbXmdQw7c889sVYURliRIDVnQIUpbQHMtrGihBFIw XT0wl+tmJZSJvvd4xrCfsiPYm+6Kb3gniS8CGXQ9EhBO+3+Ap32bW65xkfLfweycL6CW Yq1w== X-Gm-Message-State: ABuFfojhiSMwrC17FPqx5wKWuWpsuAHQk23k8HKUIBBDa0GIYKRdoLYw yLSqvaxeY0nO8dYM3nwN2DZCqvM= X-Google-Smtp-Source: ACcGV63UK8ICJuSuXl7NbRDe2zL5we+5ilo+U28qn67QZiflB0jj+iiBjSblu6e0GCW7mGTeFKUGNQ== X-Received: by 2002:a63:d34f:: with SMTP id u15-v6mr12443889pgi.325.1538089457806; Thu, 27 Sep 2018 16:04:17 -0700 (PDT) Received: from [192.168.1.113] (c-73-202-42-181.hsd1.ca.comcast.net. [73.202.42.181]) by smtp.gmail.com with ESMTPSA id z20-v6sm5573912pfd.99.2018.09.27.16.04.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 16:04:16 -0700 (PDT) Subject: Re: Sudden grow of memory in "Laundry" state To: Mark Johnston Cc: freebsd-hackers@freebsd.org References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> <20180911150849.GD92634@raichu> From: Robert Message-ID: <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> Date: Thu, 27 Sep 2018 16:04:15 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180911150849.GD92634@raichu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 23:04:20 -0000 Is there a way to force move pages back from laundry to Free or Inactive? Also, what's the best way to identify addresses of these pages and "look" inside of them? Thanks. On 09/11/18 08:08, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 10:18:31PM -0700, Robert wrote: >> Hi, if I understood correctly, "written back to swap device" means they >> come from swap at some point, but it's not the case (see attached graph). > Sorry, I didn't mean to imply that. Pages containing your application's > shared memory, for instance, would simply be written to the swap device > before being freed and reused for some other purpose. > > Your graph shows a sudden drop in free memory. Does that coincide with > the sudden increase in size of the laundry queue? > >> Swap was 16GB, and slightly reduced when pages rapidly started to move >> from free (or "Inactive"?) into "Laundry" queue. > Right. Specifically, the amount of free swap space decreased right at > the time that the amount of free memory dropped, so what likely happened > is that the system wrote some pages in "Laundry" to the swap device so > that they could be freed, as a response to the drop in free memory. > >> Here is vmstat output: >> >> vmstat -s >> [...] >> 12 clean page reclamation shortfalls > This line basically means that at some point we were writing pages to > the swap device as fast as possible in order to reclaim some memory. > >> What do you think? How pages could be moved into "Laundry" without being >> in Swap? > That's perfectly normal. Pages typically move from "Active" or > "Inactive" to laundry. > >> On 09/10/18 17:54, Mark Johnston wrote: >>> On Mon, Sep 10, 2018 at 11:44:52AM -0700, Robert wrote: >>>> Hi, I have a server with FreeBSD 11.2 and 48 Gigs of RAM where an app >>>> with extensive usage of shared memory (24GB allocation) is running. >>>> >>>> After some random amount of time (usually few days of running), there >>>> happens a sudden increase of "Laundry" memory grow (from zero to 24G in >>>> a few minutes). >>>> >>>> Then slowly it reduces. >>>> >>>> Are described symptoms normal and expected? I've never noticed anything >>>> like that on 11.1. >>> The laundry queue contains dirty inactive pages, which need to be >>> written back to the swap device or a filesystem before they can be >>> reused. When the system is short for free pages, it will scan the >>> inactive queue looking for clean pages, which can be freed cheaply. >>> Dirty pages are moved to the laundry queue. My guess is that the >>> system was running without a page shortage for a long time, and >>> suddenly experienced some memory pressure. This caused lots of >>> pages to move from the inactive queue to the laundry queue. Demand >>> for free pages will then cause pages in the laundry queue to be >>> written back and freed, or requeued if the page was referenced after >>> being placed in the laundry queue. "vmstat -s" and "sysctl vm.stats" >>> output might make things more clear. >>> >>> All this is to say that there's nothing particularly abnormal about what >>> you're observing, though it's not clear what effects this behaviour has >>> on your workload, if any. I can't think of any direct reason this would >>> happen on 11.2 but not 11.1. > From owner-freebsd-hackers@freebsd.org Fri Sep 28 02:21:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A25C109E90F for ; Fri, 28 Sep 2018 02:21:11 +0000 (UTC) (envelope-from ath@heybey.org) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E66A081364 for ; Fri, 28 Sep 2018 02:21:10 +0000 (UTC) (envelope-from ath@heybey.org) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 5hoUgj0KzPUIw5iOwgqz1u; Fri, 28 Sep 2018 02:21:06 +0000 Received: from spaten.heybey.org ([98.237.106.248]) by resomta-ch2-20v.sys.comcast.net with ESMTPA id 5iMzgtuGIi7DZ5iN0g61VL; Fri, 28 Sep 2018 02:19:06 +0000 Received: from [10.1.0.96] (unknown [10.1.0.96]) by spaten.heybey.org (Postfix) with ESMTPSA id D92488039 for ; Thu, 27 Sep 2018 22:19:04 -0400 (EDT) From: Andrew Heybey Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Mostly complete set of 4.3 BSD printed (paper) manuals available Message-Id: <3B02FD31-2BC5-426E-A004-E4CA35FD8A3E@heybey.org> Date: Thu, 27 Sep 2018 22:19:03 -0400 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfL07pui0IDq8Qr7RgeXF6H7POhRaITwxvfMC8of3k3/H8FZalU+/PtaU5fLV5Ka6rlRq6xOrNlZqcn0Lk13i6kkfIGH9WxLkcM1Bor/kRAhYoPCinYhl +NVRJ7kx+irvu6BOa3gm7g7ujO7ML2zuvPtFb8i0SiwNBih5Au0Ve7HaKdNv92lJV7t48Gf4q6vLsQ== X-Mailman-Approved-At: Fri, 28 Sep 2018 10:27:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 02:21:11 -0000 When I was in graduate school, my research group ran 4.2 and then 4.3 = BSD on MicroVAXen. By the time I left we had switched over to = DECstations running Ultrix, and so I took a set of BSD manuals (printed = by USENIX) with me because I thought they were cool to have. I don=E2=80=99t want them any more, but I don=E2=80=99t want to recycle = them while I am haunted by the thought that someone somewhere might want = them. I have URM, PRM, USD, PS2, SMM, and Master Index. Cover page says = =E2=80=9C4.3 Berkeley Software Distribution, Virtual VAX-11 Version, = April 1986=E2=80=9D. Copyright page says (in part) =E2=80=9CPrinted by = the USENIX Association as a service to the UNIX community.=E2=80=9D The = latest date on the copyright page is =E2=80=9C4.3 Edition, Second = Printing June 1987=E2=80=9D. Covers have Beastie on them. Here are URM and PRM: = https://s3.amazonaws.com/ath-public-images/URM-PRM.jpg They are yours for the cost of shipping. andrew From owner-freebsd-hackers@freebsd.org Fri Sep 28 15:25:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CC1C10B3436 for ; Fri, 28 Sep 2018 15:25:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8639077221 for ; Fri, 28 Sep 2018 15:25:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pg1-x52b.google.com with SMTP id y18-v6so4741597pge.0 for ; Fri, 28 Sep 2018 08:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PuRHPvO0sy6iH+spu54+WFWVUjEriTRauiHgd5AvejI=; b=pTPje0lfguOoxH1JhhqKXEDLZ34qGuUCa/HJrP3aBPck1O6s86uOy2JhFxQJJtOc+W VNHT/Z5LexmBMZtNb3e0rj4hnHHuHVJCXFziVJ/OAa7EwiaHf66YiR8q4R8AXcfMYTp2 pUxAgNl0YjZVzFwOVq7+e+J6fhwZDhHhImtQWrr466fWHSP5tALaSWjBwlrjOo/LN2Qz ZY6xP8vYmpj/9uIZ1lZ+yEaOhQWY934o/AEWQ25NhNnXqiFrGWp3GG59UPE/CXEnn65l mGB/H7bmUUI81C4Yy1Rawy4O6RNB4csvJ9qvCMhwnRIabWr8Hb5i/ak6H1ba4GNmlyyI pRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=PuRHPvO0sy6iH+spu54+WFWVUjEriTRauiHgd5AvejI=; b=IG2ww3GniT3ijZoZJqx2tYUMpLO1w6sMltnN5obGFtokscKHmZAXTWXNKB9XtxtbCh plS1QX9SkQoCFlSi2N7rvPUZ7vTckhou+wqCue0r4kXZwj3Td7i5XMdO5/iShVY/heK+ QDpezrtRAYyAfTqTZ4YoejTzF0JxGpvj3N03SdDKAXzcyc5AemgrO/cequOf8O33TSKw RjTYsI/NDb0BN+Y1eLGeYWvHmix+XeZKqDRCxrf3uET33jozWVZRP7LXIIqVd/yoLSb1 EmDIefCcrZ1LH4Q35BZGqJJed82CR89nBrSlGgrcNYV0D3+x13z6ntMeGWsiX9oirnxg +R5A== X-Gm-Message-State: ABuFfoi6ZchPeH/BciFD/Jaz5ddXtB1QnZmzR2iuTkBpPFSpPMLNVM// qHsNoyD3Z/4iBZ7tStDry7s= X-Google-Smtp-Source: ACcGV60yP1KWpmoxFI94aA7LGs/Yd5cmRp07zMIKegM/SgOQ/u29W/SdNkRxWVKrqec4bKty9ixHUQ== X-Received: by 2002:a63:f110:: with SMTP id f16-v6mr15560873pgi.236.1538148357292; Fri, 28 Sep 2018 08:25:57 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-79-38.dsl.bell.ca. [174.88.79.38]) by smtp.gmail.com with ESMTPSA id 89-v6sm13027231pfk.134.2018.09.28.08.25.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 08:25:56 -0700 (PDT) Sender: Mark Johnston Date: Fri, 28 Sep 2018 11:25:50 -0400 From: Mark Johnston To: Robert Cc: freebsd-hackers@freebsd.org Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20180928152550.GA3609@raichu> References: <55b0dd7d-19a3-b566-0602-762b783e8ff3@gmail.com> <20180911005411.GF2849@raichu> <20180911150849.GD92634@raichu> <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 15:25:59 -0000 On Thu, Sep 27, 2018 at 04:04:15PM -0700, Robert wrote: > Is there a way to force move pages back from laundry to Free or Inactive? There's no real way to do that from outside of the application. The application itself can free anonymous memory by unmapping it. It can also force memory to be marked clean (thus moving it back to the inactive queue) using madvise(MADV_FREE). This will cause the memory's contents to be discarded, though. > Also, what's the best way to identify addresses of these pages and > "look" inside of them? There's no convenient way to do that that I'm aware of. On amd64, you could in principle use kgdb to dump individual pages in the queue via the direct map: # kgdb82 -q Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. sched_switch (td=0xfffff8002c560000, newtd=0xfffff800025ca000, flags=) at /home/mark/src/freebsd-dev/sys/kern/sched_ule.c:2112 2112 cpuid = PCPU_GET(cpuid); (kgdb) p vm_dom[0].vmd_pagequeues[2] $1 = { pq_mutex = { lock_object = { lo_name = 0xffffffff80c34c0d "vm laundry pagequeue", lo_flags = 21168128, lo_data = 0, lo_witness = 0xfffff8041ed6cb00 }, mtx_lock = 0 }, pq_pl = { tqh_first = 0xfffff8040f9ef980, tqh_last = 0xfffff8041227f448 }, pq_cnt = 20087, pq_name = 0xffffffff80c34c0d "vm laundry pagequeue", pq_pdpages = 0 } (kgdb) x/512gx vm_dom[0].vmd_pagequeues[2].pq_pl.tqh_first->phys_addr + (vm_offset_t)&dmapbase 0xfffff801aea00000: 0x0000000800000000 0x000000082298c400 0xfffff801aea00010: 0x00000009be801000 0x0000000000000006 ...