From owner-freebsd-current@FreeBSD.ORG Sat Aug 16 19:44:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72BBB7DB for ; Sat, 16 Aug 2014 19:44:02 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 329C120E0 for ; Sat, 16 Aug 2014 19:44:02 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so4563939igd.8 for ; Sat, 16 Aug 2014 12:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:to:subject:importance:date:message-id :content-type; bh=g6IEZjA7YQ67LmgHiYCfCgVHUL47a0c9T5UhUWQt1C4=; b=Q4xgBT5Fso/bo9eQgHtQ8sIBJgviqFEGQDJ4FgK1d1GPxP0OnmcrIYNAxJeXXYbBjf 0MORZ8JMVpI13hztb8zVZZAmkUO9X+Ew0iKu+2DbjRXkElKmtTiTRNU5dfclxFEMcy15 MS5OAbeGyPFmERyu1AX1zegG/W2BNPvjkiirhxkC+lL8yD24aZqS8M2RVNOQ21PXHfE0 t5oXQgpU4/uZ3CyzHG2RIfqq2PxxTQYQSmDuKGZDLR/sfe+uJ0XQKi1p5YBTFZ+otsIe +Ak4Wus812xgbxvp5VEogkEIcVK4U+GblN9+Ix8r+5bjmrVDQMI8icRjlK7hpvq2H0Od JXCQ== X-Received: by 10.50.50.198 with SMTP id e6mr73370180igo.1.1408218241166; Sat, 16 Aug 2014 12:44:01 -0700 (PDT) Received: from Beast (c-107-5-152-233.hsd1.mi.comcast.net. [107.5.152.233]) by mx.google.com with ESMTPSA id qq2sm18519638igb.19.2014.08.16.12.43.56 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 16 Aug 2014 12:43:57 -0700 (PDT) MIME-Version: 1.0 From: To: "=?utf-8?Q?freebsd-current@freebsd.org?=" Subject: =?utf-8?Q?FreeBSD_11.0_CURRENT_Crash_on_UEFI_boot?= Importance: Normal Date: Sat, 16 Aug 2014 19:40:05 +0000 Message-ID: <43fce4afb6c74052a6a989077a14caf8@gmail.com> X-Mailman-Approved-At: Sun, 17 Aug 2014 03:39:40 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 19:44:02 -0000 DQoNCg0KDQpVRUZJIGJvb3RpbmcgdXNpbmcgdGhlIDExLjAgQ1VSUkVOVCBtZW1zdGljay5pbWcg Y2F1c2VzIHRoZSBmb2xsb3dpbmcgZXJyb3IgdG8gb2NjdXI6DQoNCg0KQ09ERTogU0VMRUNUIEFM TEZhdGFsIHRyYXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUNCmNwdWlkID0g MDsgYXBpYyBpZCA9IDAwOw0KZmF1bHQgdmlydHVhbCBhZGRyZXNzID0gMHhlOGINCmZhdWx0IGNv ZGUgPSBzdXBlcnZpc29yIHdyaXRlIGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQNCmluc3RydWN0aW9u IHBvaW50ZXIgPSAweDIwOjB4ZmZmZmZmZmYwMDMwMDAwMg0Kc3RhY2sgcG9pbnRlciA9IDB4MjA6 MHhmZmZmZmZmZjgxNGU1NTcwDQoNClRoaXMgaXMgYWxzbyB3aGF0IGhhcHBlbnMgd2hlbiBJIGJ1 aWxkIC9iYXNlL2hlYWQvIGFuZCBmb2xsb3cgdGhlIGd1aWRlIGZvciBjcmVhdGluZyBhIFVFRkkg bWVtb3J5IHN0aWNrLg0KDQpDbGF5IFNwZW5jZXINCg0KDQoNCg0KU2VudCBmcm9tIFdpbmRvd3Mg TWFpbA== From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 07:47:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A5AB14D; Sun, 17 Aug 2014 07:47:40 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17FA82584; Sun, 17 Aug 2014 07:47:39 +0000 (UTC) Received: from [93.104.25.142] (helo=localhost.my.domain) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XIvBb-0000nI-6f; Sun, 17 Aug 2014 09:47:31 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.7/8.14.3) with ESMTP id s7H7lTdK001528; Sun, 17 Aug 2014 09:47:29 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.14.7/8.14.3/Submit) id s7H7lS4T001527; Sun, 17 Aug 2014 09:47:28 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 17 Aug 2014 09:47:28 +0200 From: Matthias Apitz To: freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: Broadcom BCM4312 802.11b/g in 11-CURRENT r269739 Message-ID: <20140817074728.GA1495@La-Habana> Reply-To: Matthias Apitz References: <20140816152509.GA1529@La-Habana> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140816152509.GA1529@La-Habana> X-Operating-System: FreeBSD 9.0-CURRENT r214444 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.25.142 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 07:47:40 -0000 El día Saturday, August 16, 2014 a las 05:25:09PM +0200, Matthias Apitz escribió: > > Hello, > > I have a 11-CURRENT from August 8, and ports from the day after: > > FreeBSD tiny-r269739 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r269739M: Fri Aug 15 18:07:41 CEST 2014 guru@vm-tiny-r269739:/usr/obj/usr/src/sys/GENERIC i386 > > The configuration used for the Wifi card is: > > rc.conf: > > wlans_bwn0="wlan0" > ifconfig_wlan0="WPA DHCP" > > loader.conf > > if_bwn_load="YES" > bwn_v4_lp_ucode_load="YES" > > The Wifi comes up fine on boot with WPA and DHCP assigns IP addr and > routing: > > wlan0: flags=8843 metric 0 mtu 1500 > ether 90:4c:e5:00:06:ce > inet 192.168.2.100 netmask 0xffffff00 broadcast 192.168.2.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g > status: associated > ssid tarara channel 7 (2442 MHz 11g) bssid 00:13:f7:0d:08:48 > country US authmode WPA2/802.11i privacy ON deftxkey UNDEF > AES-CCM 4:128-bit txpower 30 bmiss 7 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS > wme roaming MANUAL > > I even can do a DNS lookup and transfer some ~10 PING to Internet, but > after this it gets stuck. Below is a 'dmesg | fgrep -i bwn'. Let me know > if someone needs a complete dmesg output. > I have recompiled if_bwn.c with -DBWN_DEBUG and set hw.bwn.debug=15 in /boot/loader.conf; an output of 'dmesg | fgrep bwn' is attached. IP addr gets assigned via DHCP and some 20 IMCP packages can be sent. After this, the traffic gets stuck. If someone (the author of the driver or the port of net/bwn*) is willing to guide my through the debugging, here I am. Thanks matthias Preloaded elf module "/boot/kernel/if_bwn.ko" at 0xc183d8e8. Preloaded elf module "/boot/kernel/siba_bwn.ko" at 0xc183dc6c. Preloaded elf module "/boot/modules/bwn_v4_lp_ucode.ko" at 0xc183e01c. firmware: 'bwn_v4_lp_ucode' version 0: 0 bytes loaded at 0xc1811084 firmware: 'bwn_v4_lp_ucode5' version 0: 22264 bytes loaded at 0xc1811084 firmware: 'bwn_v4_lp_ucode11' version 0: 32776 bytes loaded at 0xc181677c firmware: 'bwn_v4_lp_ucode13' version 0: 31440 bytes loaded at 0xc181e784 firmware: 'bwn_v4_lp_ucode14' version 0: 31000 bytes loaded at 0xc1826254 firmware: 'bwn_v4_lp_ucode15' version 0: 34672 bytes loaded at 0xc182db6c firmware: 'bwn_v4_lp_pcm5' version 0: 1320 bytes loaded at 0xc18362dc firmware: 'bwn_v4_lp_a0g1initvals5' version 0: 1848 bytes loaded at 0xc1836804 firmware: 'bwn_v4_lp_a0g0initvals5' version 0: 1848 bytes loaded at 0xc1836f3c firmware: 'bwn_v4_lp_b0g0initvals5' version 0: 1848 bytes loaded at 0xc1837674 firmware: 'bwn_v4_lp_b0g0initvals13' version 0: 2126 bytes loaded at 0xc1837dac firmware: 'bwn_v4_lp_a0g1bsinitvals5' version 0: 178 bytes loaded at 0xc18385fa firmware: 'bwn_v4_lp_a0g0bsinitvals5' version 0: 178 bytes loaded at 0xc18386ac firmware: 'bwn_v4_lp_b0g0bsinitvals5' version 0: 178 bytes loaded at 0xc183875e firmware: 'bwn_v4_lp_lp0initvals13' version 0: 3664 bytes loaded at 0xc1838810 firmware: 'bwn_v4_lp_lp0initvals14' version 0: 2110 bytes loaded at 0xc1839660 firmware: 'bwn_v4_lp_lp0initvals15' version 0: 2282 bytes loaded at 0xc1839e9e firmware: 'bwn_v4_lp_lp0bsinitvals13' version 0: 178 bytes loaded at 0xc183a788 firmware: 'bwn_v4_lp_lp0bsinitvals14' version 0: 178 bytes loaded at 0xc183a83a firmware: 'bwn_v4_lp_lp0bsinitvals15' version 0: 178 bytes loaded at 0xc183a8ec firmware: 'bwn_v4_lp_n0bsinitvals11' version 0: 178 bytes loaded at 0xc183a99e siba_bwn0: mem 0x57100000-0x57103fff irq 16 at device 0.0 on pci1 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4312 rev 15) PHY (analog 6 type 5 rev 1) RADIO (manuf 0x17f ver 0x2062 rev 2) bwn0: DMA (64 bits) bwn0: MSI count : 1 siba_bwn0: attempting to allocate 1 MSI vectors (1 supported) siba_bwn0: using IRQ 257 for MSI bwn0: Using 1 MSI messages bwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps bwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps bwn_init: if_flags 0x8803 bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) bwn_newstate: INIT -> SCAN bwn_newstate: SCAN -> AUTH bwn_newstate: AUTH -> ASSOC bwn_newstate: ASSOC -> RUN bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: need multicast update callback bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) bwn0: RX decryption attempted (old 0 keyidx 0x2) -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 10:44:34 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57FF3513; Sun, 17 Aug 2014 10:44:34 +0000 (UTC) Received: from mail.beastielabs.net (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (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 B0C0D25AB; Sun, 17 Aug 2014 10:44:33 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by mail.beastielabs.net (8.14.7/8.14.7) with ESMTP id s7HAiUnN059437; Sun, 17 Aug 2014 12:44:30 +0200 (CEST) (envelope-from hans@beastielabs.net) Message-ID: <53F0878E.3000401@beastielabs.net> Date: Sun, 17 Aug 2014 12:44:30 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= Subject: Re: [CFT] Autofs. References: <20140730071933.GA20122@pc5.home> In-Reply-To: <20140730071933.GA20122@pc5.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 10:44:34 -0000 On 07/30/14 09:19, Edward Tomasz Napierała wrote: > At the link below you will find a patch that adds the new automounter. > The patch is against yesterdays 11.0-CURRENT. > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > Slides that explain the project scope and deliverables are here: > > http://people.freebsd.org/~trasz/autofs.pdf > > Testing is welcome. Please start with manual pages, eg. automount(8). > Note that you need not only to rebuild both kernel and world, but also > to run mergemaster, to install required /etc files. To run at startup, > add 'autofs_enable="YES"' to /etc/rc.conf. > > This project is being sponsored by FreeBSD Foundation. > Hi! Great to see a real autofs finally coming to FreeBSD. I already did some very cursory testing on a recent 11-CURRENT system that I still happened to have and things with at least the /net map look quite OK. I could do some more extensive testing if I could use some of my 10-STABLE systems. I already checked that the patch applies cleanly to a recent 10-STABLE (modulo a few offsets) and that both buildworld and buildkernel succeed. Should I expect difficulties actually running your autofs on 10-STABLE? And do you plan support for NIS? I know NIS is quite dead and has been so for at least 20 years, but I still see it being used occasionally (probably most out of habit) and it is (still ?) available in the base-system. Kind regards, Hans From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 13:10:20 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB27F33 for ; Sun, 17 Aug 2014 13:10:20 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F26AC26C7 for ; Sun, 17 Aug 2014 13:10:19 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,879,1400050800"; d="asc'?scan'208";a="140608759" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 17 Aug 2014 06:10:18 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 17 Aug 2014 06:09:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 17 Aug 2014 06:09:28 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Sun, 17 Aug 2014 06:09:10 -0700 From: "Eggert, Lars" To: "current@freebsd.org" Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPt7KjJmpD94JuA0qgbFukGy7xyJvVPwmA Date: Sun, 17 Aug 2014 13:09:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_DCD44659-36F9-4D82-87D4-CB733A076A02"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:10:20 -0000 --Apple-Mail=_DCD44659-36F9-4D82-87D4-CB733A076A02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Nobody using nscd? Really? On 2014-8-14, at 13:26, Eggert, Lars wrote: > [Resending to current@, since I can't get it to work on -CURRENT = either.] >=20 > Hi, >=20 > anyone have an idea why nscd would not be caching NIS lookups? >=20 > My nsswitch.conf looks as follows: >=20 > group: cache files nis > hosts: cache files dns > networks: cache files > passwd: cache files nis > shells: files > services: cache files nis > protocols: cache files > rpc: cache files >=20 > nisdomain is set and ypbind is started, and I see lots of NIS traffic = going in and out. >=20 > But nothing is cached; running nscd with -t just prints this and then = then nothing, ever: >=20 > M1 from main: successfully daemonized > M1 from main: request agents registered successfully > M2 from cache: cache was successfully initialized > M2 from runtime environment: using socket /var/run/nscd > M2 from runtime environment: successfully initialized > M1 from main: thread #0 was successfully created > M1 from main: thread #1 was successfully created > M1 from main: thread #2 was successfully created > M1 from main: thread #3 was successfully created > M1 from main: thread #4 was successfully created > M1 from main: thread #5 was successfully created > M1 from main: thread #6 was successfully created > M1 from main: thread #7 was successfully created >=20 > Lars >=20 --Apple-Mail=_DCD44659-36F9-4D82-87D4-CB733A076A02 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU/CppdZcnpRveo1xAQJJZgP/eDuiQ+ROnsZhGMLgiJTMEcWFIKsUoyD8 Py+nKSunVFRHzmTA3iMoEZhLvk2rADeKcqJTa7Y2Jf/AL3fzQ6AlrO5gTVC9d27N RJelmZX0JoXnwFQZHQL3tDpXAahnJ2pUZNnTFUhz8wuzQqw9nadCs8qmLxyPrvLh Qi/jbEsrQfQ= =Besx -----END PGP SIGNATURE----- --Apple-Mail=_DCD44659-36F9-4D82-87D4-CB733A076A02-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 13:22:58 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16F24A7D; Sun, 17 Aug 2014 13:22:58 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A5E4327FF; Sun, 17 Aug 2014 13:22:57 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XJ0QB-000LJR-7e>; Sun, 17 Aug 2014 15:22:55 +0200 Received: from g229053128.adsl.alicedsl.de ([92.229.53.128] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XJ0QB-002tJx-3u>; Sun, 17 Aug 2014 15:22:55 +0200 Date: Sun, 17 Aug 2014 15:22:54 +0200 From: "O. Hartmann" To: Hans Ottevanger Subject: Re: [CFT] Autofs. Message-ID: <20140817152254.1e2786db.ohartman@zedat.fu-berlin.de> In-Reply-To: <53F0878E.3000401@beastielabs.net> References: <20140730071933.GA20122@pc5.home> <53F0878E.3000401@beastielabs.net> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_//tezXkiRzb233=u3GdmP179"; protocol="application/pgp-signature" X-Originating-IP: 92.229.53.128 X-ZEDAT-Hint: A Cc: freebsd-current@FreeBSD.org, Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:22:58 -0000 --Sig_//tezXkiRzb233=u3GdmP179 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Sun, 17 Aug 2014 12:44:30 +0200 Hans Ottevanger schrieb: > On 07/30/14 09:19, Edward Tomasz Napiera=C5=82a wrote: > > At the link below you will find a patch that adds the new automounter. > > The patch is against yesterdays 11.0-CURRENT. > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > Slides that explain the project scope and deliverables are here: > > > > http://people.freebsd.org/~trasz/autofs.pdf > > > > Testing is welcome. Please start with manual pages, eg. automount(8). > > Note that you need not only to rebuild both kernel and world, but also > > to run mergemaster, to install required /etc files. To run at startup, > > add 'autofs_enable=3D"YES"' to /etc/rc.conf. > > > > This project is being sponsored by FreeBSD Foundation. > > >=20 > Hi! >=20 > Great to see a real autofs finally coming to FreeBSD. >=20 > I already did some very cursory testing on a recent 11-CURRENT system=20 > that I still happened to have and things with at least the /net map look= =20 > quite OK. >=20 > I could do some more extensive testing if I could use some of my=20 > 10-STABLE systems. I already checked that the patch applies cleanly to a= =20 > recent 10-STABLE (modulo a few offsets) and that both buildworld and=20 > buildkernel succeed. Should I expect difficulties actually running your=20 > autofs on 10-STABLE? >=20 > And do you plan support for NIS? I know NIS is quite dead and has been=20 > so for at least 20 years, but I still see it being used occasionally=20 > (probably most out of habit) and it is (still ?) available in the=20 > base-system. >=20 > Kind regards, >=20 > Hans >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Is this "new" autofs of the same type and concept as the autofs used in Lin= ux for more than a decade now? --Sig_//tezXkiRzb233=u3GdmP179 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT8KyuAAoJEOgBcD7A/5N8wUcIALO/3aHJq2q2udeRrHvvX552 0LTB1pRdaNzFYWP8obX6D0eMmpc6qkBAYQ3FjVWfDI3bBctMJQOM3949jIpBJ6ET 0UGyDsdx0wCkxDL69vf7AJ1G4ECZuckpgIzhczXMrUaz7oEPL8cSoJdtYhbARayU Mv7/YqFvoYvBuWI80g3dLmXTxOKXTZcC9SWPeJNC/njrJOtCxn8cevz6gMBp3fLS /uqt3jLXYbkK+cDxhE5Rm7CNdjdkJfsFbX1a/4mUXM+3yX0onMeL5fVahEtyiye/ d4RokjF2VVNgUyMt4RyRshLKI48O7JfQ57AK+IO0xM+HAg/s1vFybzSTjVVhxVU= =cZaN -----END PGP SIGNATURE----- --Sig_//tezXkiRzb233=u3GdmP179-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 13:25:32 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B986CAC for ; Sun, 17 Aug 2014 13:25:32 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 0BB51281F for ; Sun, 17 Aug 2014 13:25:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XJ0PT-000LDn-IL>; Sun, 17 Aug 2014 15:22:11 +0200 Received: from g229053128.adsl.alicedsl.de ([92.229.53.128] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XJ0PT-002tIx-EZ>; Sun, 17 Aug 2014 15:22:11 +0200 Date: Sun, 17 Aug 2014 15:22:02 +0200 From: "O. Hartmann" To: "Eggert, Lars" Subject: Re: nscd not caching Message-ID: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> In-Reply-To: References: Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/QQj.UnoqZQ/vsLmjjaWO+O4"; protocol="application/pgp-signature" X-Originating-IP: 92.229.53.128 X-ZEDAT-Hint: A Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:25:32 -0000 --Sig_/QQj.UnoqZQ/vsLmjjaWO+O4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 17 Aug 2014 13:09:10 +0000 "Eggert, Lars" schrieb: > Nobody using nscd? Really? I can only speak for myself and I stopped using nscd since the support is c= rap. A while ago (t > 1 1/2 years) I realised within a OpenLDAP environment, tha= t when nscd is running, sometimes the system simple "forgets" about root - this is painful= while installing/updating ports and getting interrupted with a weird error "unkno= wn user root". nscd is supposed to be used in large environments where the cost for a user= lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in that large envir= onments with OpenLDAP and I'm wondering what the purpose of nscd is. >=20 > On 2014-8-14, at 13:26, Eggert, Lars wrote: >=20 > > [Resending to current@, since I can't get it to work on -CURRENT either= .] > >=20 > > Hi, > >=20 > > anyone have an idea why nscd would not be caching NIS lookups? > >=20 > > My nsswitch.conf looks as follows: > >=20 > > group: cache files nis > > hosts: cache files dns > > networks: cache files > > passwd: cache files nis > > shells: files > > services: cache files nis > > protocols: cache files > > rpc: cache files > >=20 > > nisdomain is set and ypbind is started, and I see lots of NIS traffic g= oing in and > > out. > >=20 > > But nothing is cached; running nscd with -t just prints this and then t= hen nothing, > > ever: > >=20 > > M1 from main: successfully daemonized > > M1 from main: request agents registered successfully > > M2 from cache: cache was successfully initialized > > M2 from runtime environment: using socket /var/run/nscd > > M2 from runtime environment: successfully initialized > > M1 from main: thread #0 was successfully created > > M1 from main: thread #1 was successfully created > > M1 from main: thread #2 was successfully created > > M1 from main: thread #3 was successfully created > > M1 from main: thread #4 was successfully created > > M1 from main: thread #5 was successfully created > > M1 from main: thread #6 was successfully created > > M1 from main: thread #7 was successfully created > >=20 > > Lars > >=20 >=20 --Sig_/QQj.UnoqZQ/vsLmjjaWO+O4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT8KyCAAoJEOgBcD7A/5N8x2sH/0RM0Ehu9vMt3O8qLyAxJi5M 6iyNoldRsM5PWKXl5TkvxpLVGUe7tQSXbKOETu0jaSBJ+CcHIEynEWNVdJ0jlYKu gpp6Yse0f0tpZ1o+007TQlvmoIcT9XQ97jhpIVI89ne94vqImmKvh3eJl7iLcT27 eVWE0oNpK0fbTfZQyT/H9mBF3qopQ1aWBka6SgkCJ7a2el5tZt9CK67eQmDeV+Wh NEYHuSnBqrk0nN7AWPee/w1o88kMrRHNUuf98vAski6fqWe3hgo61mkQhMBrgtXV pQZwtgUMVKoSbSevbAJG8K5qgbrmU6FKXdumm/nq/5XfAeEW+JqQiuk1QBYQF3w= =G1Kf -----END PGP SIGNATURE----- --Sig_/QQj.UnoqZQ/vsLmjjaWO+O4-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 14:51:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 862F73ED; Sun, 17 Aug 2014 14:51:02 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D32C2205D; Sun, 17 Aug 2014 14:51:01 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id gl10so3778899lab.12 for ; Sun, 17 Aug 2014 07:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=MuyiV+EyhnLHm8Dvo+77CunOnSeiifyyhLrf7a/5Jgg=; b=ttR4imc4RpEzf6NY6OlPFFeVXIIGB+WEa7zyF/ctmIMEVRfj/HXOCozQdP23cjEDbj t6RQ3YFIybUV+BW72V2eLXrm9IlOM6FCDkRZEPZE3WMIQ3tXy5XaqwlHnxlBJNmf2j2Z G36qTMTyD2Hk552cReuFhbjxhtqdNyRmQVfi7NuJ61u8moaf/wYJ5/19XA9ALrb1fjwv FZpIwJdHhwRMfgc84PjNEddAQruJneeVHCm9VV79BNJBoRfNysPQNq3+WmEWGVEceJk6 3EI/LfS1ClXt/ZY6XcqkySEZZBe6BaN+aICrffrF68zw3paqhbTo4rbn7rCnFluHjnUx jMvw== X-Received: by 10.152.164.70 with SMTP id yo6mr23792407lab.2.1408287059767; Sun, 17 Aug 2014 07:50:59 -0700 (PDT) Received: from pc5.home (abpi45.neoplus.adsl.tpnet.pl. [83.8.50.45]) by mx.google.com with ESMTPSA id h3sm8741756lah.20.2014.08.17.07.50.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 07:50:59 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 17 Aug 2014 16:50:59 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Hans Ottevanger Subject: Re: [CFT] Autofs. Message-ID: <20140817145059.GA5497@pc5.home> Mail-Followup-To: Hans Ottevanger , freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <53F0878E.3000401@beastielabs.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53F0878E.3000401@beastielabs.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 14:51:02 -0000 On 0817T1244, Hans Ottevanger wrote: > On 07/30/14 09:19, Edward Tomasz Napierała wrote: > >At the link below you will find a patch that adds the new automounter. > >The patch is against yesterdays 11.0-CURRENT. > > > >http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > >Slides that explain the project scope and deliverables are here: > > > >http://people.freebsd.org/~trasz/autofs.pdf > > > >Testing is welcome. Please start with manual pages, eg. automount(8). > >Note that you need not only to rebuild both kernel and world, but also > >to run mergemaster, to install required /etc files. To run at startup, > >add 'autofs_enable="YES"' to /etc/rc.conf. > > > >This project is being sponsored by FreeBSD Foundation. > > > > Hi! > > Great to see a real autofs finally coming to FreeBSD. > > I already did some very cursory testing on a recent 11-CURRENT system > that I still happened to have and things with at least the /net map > look quite OK. > > I could do some more extensive testing if I could use some of my > 10-STABLE systems. I already checked that the patch applies cleanly > to a recent 10-STABLE (modulo a few offsets) and that both buildworld > and buildkernel succeed. Should I expect difficulties actually > running your autofs on 10-STABLE? No, it should be fine. Plan is to MFC this to 10 soon, btw. > And do you plan support for NIS? I know NIS is quite dead and has > been so for at least 20 years, but I still see it being used > occasionally (probably most out of habit) and it is (still ?) > available in the base-system. It should be trivial to add, I just need someone with such setup (autofs maps in NIS) to test it against. From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 14:52:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D917C66B; Sun, 17 Aug 2014 14:52:20 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2097B20E6; Sun, 17 Aug 2014 14:52:19 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id s7so3359793lbd.0 for ; Sun, 17 Aug 2014 07:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=KgsSmmtsQW129B+GOjTcU5ln0byYKGpxFwQg3XansU8=; b=ZK77mR/i3rd1yiATY76LdZ2Cm2ZOlcmSGyic1KcsWO5AAIQNKLYs+e2xk1cB3zreIi 3ClAMLuC2nZi9AaZbLsJyakZ0vP6mxy51d9ZQqL6m2qFPCqhLV8WRW5Z5JYYtUmssKBI Bco0GcuMpJF6CxFnOspHlj/WffWNQxdYZohTZcngQLIt/RT0lydaCWEVbd41Pv96Iy02 P/8z7Ov1BFs7LiA62KRx2FdqJ7hZxu936u9M/lCaioSPRYDPwSAuCcf7EjUIcrkr5MrF mckGsvQcGl9OTebNgUnu2dPuPKHfPmzesr1C2tDUl7yzoE77QHWgzasjVpkfYWwmbPGg 3h8Q== X-Received: by 10.112.52.225 with SMTP id w1mr23001264lbo.44.1408287137869; Sun, 17 Aug 2014 07:52:17 -0700 (PDT) Received: from pc5.home (abpi45.neoplus.adsl.tpnet.pl. [83.8.50.45]) by mx.google.com with ESMTPSA id yn1sm22592200lbb.25.2014.08.17.07.52.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 07:52:17 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 17 Aug 2014 16:52:17 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "O. Hartmann" Subject: Re: [CFT] Autofs. Message-ID: <20140817145217.GB5497@pc5.home> Mail-Followup-To: "O. Hartmann" , Hans Ottevanger , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <53F0878E.3000401@beastielabs.net> <20140817152254.1e2786db.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140817152254.1e2786db.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, Hans Ottevanger , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 14:52:21 -0000 On 0817T1522, O. Hartmann wrote: > Am Sun, 17 Aug 2014 12:44:30 +0200 > Hans Ottevanger schrieb: > > > On 07/30/14 09:19, Edward Tomasz Napierała wrote: > > > At the link below you will find a patch that adds the new automounter. > > > The patch is against yesterdays 11.0-CURRENT. > > > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > > > Slides that explain the project scope and deliverables are here: > > > > > > http://people.freebsd.org/~trasz/autofs.pdf > > > > > > Testing is welcome. Please start with manual pages, eg. automount(8). > > > Note that you need not only to rebuild both kernel and world, but also > > > to run mergemaster, to install required /etc files. To run at startup, > > > add 'autofs_enable="YES"' to /etc/rc.conf. > > > > > > This project is being sponsored by FreeBSD Foundation. > > > > > > > Hi! > > > > Great to see a real autofs finally coming to FreeBSD. > > > > I already did some very cursory testing on a recent 11-CURRENT system > > that I still happened to have and things with at least the /net map look > > quite OK. > > > > I could do some more extensive testing if I could use some of my > > 10-STABLE systems. I already checked that the patch applies cleanly to a > > recent 10-STABLE (modulo a few offsets) and that both buildworld and > > buildkernel succeed. Should I expect difficulties actually running your > > autofs on 10-STABLE? > > > > And do you plan support for NIS? I know NIS is quite dead and has been > > so for at least 20 years, but I still see it being used occasionally > > (probably most out of habit) and it is (still ?) available in the > > base-system. > > > > Kind regards, > > > > Hans > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Is this "new" autofs of the same type and concept as the autofs used in Linux for more > than a decade now? Yes. From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 16:10:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57B5DF41 for ; Sun, 17 Aug 2014 16:10:36 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2FEBD2830 for ; Sun, 17 Aug 2014 16:10:35 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 20D5E46644 for ; Sun, 17 Aug 2014 12:10:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YR1eRkKygiW for ; Sun, 17 Aug 2014 12:10:27 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <53F0D3F3.4030804@egr.msu.edu> Date: Sun, 17 Aug 2014 12:10:27 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: nscd not caching References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 16:10:36 -0000 On 08/17/2014 09:09, Eggert, Lars wrote: > Nobody using nscd? Really? > I would test for you, but we retired our NIS infrastructure at least a year ago. I did have it working on a test client at some point, but I didn't push it into production because I found a couple issues (below). We were using +::::::::: type entries in the local password and group tables and I believe we used an unmodified /etc/nsswitch.conf (excluding cache lines while testing nscd): group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files The two main problems I recall were nscd making java crash, and nscd holding on to negative cache lookups too long, causing failures while installing ports that depend on adding users/groups for a following file permission change. I can't remember if the latter issue was fixed at some point. I also can't remember if I was receiving perfectly accurate results from the cache either. At our site, we never had enough load to outright require nscd on FreeBSD, although there were some areas where caching had a usability benefit. top was slow to open since it would load the whole passwd table first, but top -u was a workaround. Our Samba servers allowed users to connect a few seconds quicker if it didn't have to pull down the entire group table to check group membership of the connecting user. As a workaround until we retired NIS, I wrote a hack of a script to merge NIS groups into my local /etc/group files periodically from cron. Aside from bugs in my script, that worked well. I dabbled with nscd a bit after we switched from NIS to LDAP. I think I recall lookups being slightly slower WITH the cache, plus I would get some duplicated group entries returned on all but the first getent group. The short version is we in no way seem to benefit or require a cache of LDAP with our site size, so I'm just not using nscd. I didn't make bug reports for these issues, I had to prioritize towards more pressing issues. I'm trying to do better about reporting bugs. From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 17:18:26 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E0D4149; Sun, 17 Aug 2014 17:18:26 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E45FD2031; Sun, 17 Aug 2014 17:18:25 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 3CF2579B; Sun, 17 Aug 2014 10:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1408295899; bh=HONwKAqGTn2Nr+bmBn4HuvBF8HxbM5JY2qAwn4ThmoI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YK8iZF0gbsuPx1DnXLuhb/aKK5YTe+VYC35sJfA/zt1u1A6zyqv3russ8MvDqtWPT pzGtb8If3oW2XXLx7Z0FLMWHWHLh8bLHu3DtruZ1O2igmiVg887AumIXGkMwiwesBq g/UKkn5B6LOuAk3dSWFv4JRgHf1WqKuja4KHmAC8= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: nscd not caching Date: Sun, 17 Aug 2014 10:18:13 -0700 Message-ID: <2295097.hWnAh3kd1o@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> References: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2400597.UVvrdKI6Fg"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: "Eggert, Lars" , "O. Hartmann" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 17:18:26 -0000 --nextPart2400597.UVvrdKI6Fg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: > Am Sun, 17 Aug 2014 13:09:10 +0000 >=20 > "Eggert, Lars" schrieb: > > Nobody using nscd? Really? >=20 > I can only speak for myself and I stopped using nscd since the suppor= t is > crap. >=20 > A while ago (t > 1 1/2 years) I realised within a OpenLDAP environmen= t, that > when nscd is running, sometimes the system simple "forgets" about roo= t - > this is painful while installing/updating ports and getting interrupt= ed > with a weird error "unknown user root". >=20 > nscd is supposed to be used in large environments where the cost for = a user > lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used = in > that large environments with OpenLDAP and I'm wondering what the purp= ose of > nscd is. The other problem is that net/nss_ldap and security/pam_ldap have kind = of been=20 left behind for performance and robustness. People who use this seriou= sy tend=20 to discover net/nss-pam-ldapd fairly quickly which has its own caching = proxy=20 and eliminates the need for nscd. With nss_ldap and pam_ldap, the openldap client libraries and startup c= ost is=20 linked into every single binary that uses it. WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred=20 authentication) and no heavy-weight libraries in the consumers. The pro= xy on=20 the other end of the socket keeps a ldap connection open (with an idle=20= timeout). The whole thing was vastly more robust and efficient. At least that's what we found in the freebsd.org cluster. nss-pam-ldap= d was=20 two or three orders of magnitude more usable and got rid of nscd in the= =20 process. For us, nscd "worked", but it just didn't save much effort because it w= as a=20 per-uid cache. ie: if "jkh" had just caused a ldap search, and "peter"= =20 repeated it, it had to be done again from scratch. The downside for nss-pam-ldapd was that it uses a non-extensible wire p= rotocol=20 and didn't have room for bsd-style login classes. > > On 2014-8-14, at 13:26, Eggert, Lars wrote: > > > [Resending to current@, since I can't get it to work on -CURRENT > > > either.] > > >=20 > > > Hi, > > >=20 > > > anyone have an idea why nscd would not be caching NIS lookups? > > >=20 > > > My nsswitch.conf looks as follows: > > >=20 > > > group: cache files nis > > > hosts: cache files dns > > > networks: cache files > > > passwd: cache files nis > > > shells: files > > > services: cache files nis > > > protocols: cache files > > > rpc: cache files > > >=20 > > > nisdomain is set and ypbind is started, and I see lots of NIS tra= ffic > > > going in and out. > > >=20 > > > But nothing is cached; running nscd with -t just prints this and = then > > > then nothing, ever: > > >=20 > > > M1 from main: successfully daemonized > > > M1 from main: request agents registered successfully > > > M2 from cache: cache was successfully initialized > > > M2 from runtime environment: using socket /var/run/nscd > > > M2 from runtime environment: successfully initialized > > > M1 from main: thread #0 was successfully created > > > M1 from main: thread #1 was successfully created > > > M1 from main: thread #2 was successfully created > > > M1 from main: thread #3 was successfully created > > > M1 from main: thread #4 was successfully created > > > M1 from main: thread #5 was successfully created > > > M1 from main: thread #6 was successfully created > > > M1 from main: thread #7 was successfully created > > >=20 > > > Lars =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2400597.UVvrdKI6Fg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT8OPZAAoJEDXWlwnsgJ4EO4MH/0XpEIY+3weHVVX89iDGo+TV KsVPBqpuaXYjJSA5w9VsYlvTVc3R63lXeiNwFrffDKbIUKswEaJqCn9+j+uViYVJ aFF5CruKLHIxkcptdZvO4RD4bSnVkWSSwz5I5vjNbRfuVhoQz131XpG5wUXi60m7 rmbavKOGkyAqr6AWkLCJuYWGHl1L4G0KWMuFrhzj4xNIPnq95qhX0DCsKaC/EzDB tjpR2cH5zJpFTMsHPRRd40pG/1Soz6oG2SHBKrY1tVm09oNEA17frx6H3kmQOFtz w0UzXES8WGlmjVD2maOOm+odEPgFsxMFLNDjijcmBdQSxxkQtc0BDpweQl/RXKU= =3qF/ -----END PGP SIGNATURE----- --nextPart2400597.UVvrdKI6Fg-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 07:43:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84DF3FBE for ; Mon, 18 Aug 2014 07:43:36 +0000 (UTC) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 436D93675 for ; Mon, 18 Aug 2014 07:43:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,884,1400050800"; d="asc'?scan'208";a="100570602" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx2-out.netapp.com with ESMTP; 18 Aug 2014 00:43:31 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 18 Aug 2014 00:42:40 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 18 Aug 2014 00:42:39 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Mon, 18 Aug 2014 00:42:39 -0700 From: "Eggert, Lars" To: Adam McDougall Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPt7KjJmpD94JuA0qgbFukGy7xyJvVPwmAgAAyboCAAQSvAA== Date: Mon, 18 Aug 2014 07:42:38 +0000 Message-ID: <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> References: <53F0D3F3.4030804@egr.msu.edu> In-Reply-To: <53F0D3F3.4030804@egr.msu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_9AE9E1F9-0578-4535-AABB-9708E3D27C22"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 07:43:36 -0000 --Apple-Mail=_9AE9E1F9-0578-4535-AABB-9708E3D27C22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-8-17, at 18:10, Adam McDougall wrote: > We were using +::::::::: type entries in the local password and group > tables and I believe we used an unmodified /etc/nsswitch.conf = (excluding > cache lines while testing nscd): I tried that setup too, and it doesn't seem to be caching any NIS = lookups either. The current NIS server is 25ms away, which is a pain. I'm trying to get = a local slave set up, which will make the need for nscd go away, but it = would sure be nice if it worked in the meantime. > At our site, we never had enough load to outright require nscd on > FreeBSD, although there were some areas where caching had a usability > benefit. Load is not an issue, latency is (see above). > top was slow to open since it would load the whole passwd > table first, but top -u was a workaround. Right, I see that issue too. > As a workaround until we retired NIS, I wrote a hack of a script to > merge NIS groups into my local /etc/group files periodically from = cron. > Aside from bugs in my script, that worked well. I may end up doing this, too. Given all this, maybe it's time to retire nscd? Lars --Apple-Mail=_9AE9E1F9-0578-4535-AABB-9708E3D27C22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU/GuoNZcnpRveo1xAQI2CQQAheHMbkMzu/OwA6L0Vmk9ksLH4hTPGQ/6 ViB3Iwp9g6CFtlX2K4C6wNx9u5lPsTRNyTrB2cquo7vGS8AmXsNJpfNNGCfxEMHk dfNFxy0UJVJFQaj2lIRIO5BvbLkjDqCSVimnyY8PgqAyTuTP92FWZn+Cua92LlFn YI+6F9XReHw= =bcjW -----END PGP SIGNATURE----- --Apple-Mail=_9AE9E1F9-0578-4535-AABB-9708E3D27C22-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 07:52:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA911D5; Mon, 18 Aug 2014 07:52:53 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F62D3741; Mon, 18 Aug 2014 07:52:53 +0000 (UTC) Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de [172.20.26.241]) by mailout04.t-online.de (Postfix) with SMTP id DB80422BA4; Mon, 18 Aug 2014 09:52:49 +0200 (CEST) Received: from [192.168.119.33] (bVaIvaZHQh19teurRP6rLg8u5p9iKnhY36a4ic6a-WF0sykzFZ3pCmS1DOGBoMVQiU@[84.154.101.219]) by fwd12.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XJHkD-1fJzLU0; Mon, 18 Aug 2014 09:52:45 +0200 Message-ID: <53F1B0C9.8040303@freebsd.org> Date: Mon, 18 Aug 2014 09:52:41 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Adam McDougall , freebsd-current@freebsd.org Subject: Re: nscd not caching References: <53F0D3F3.4030804@egr.msu.edu> In-Reply-To: <53F0D3F3.4030804@egr.msu.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: bVaIvaZHQh19teurRP6rLg8u5p9iKnhY36a4ic6a-WF0sykzFZ3pCmS1DOGBoMVQiU X-TOI-MSGID: 310b06ac-fdd4-4fb4-a166-ddc90cd90c22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 07:52:53 -0000 Am 17.08.2014 um 18:10 schrieb Adam McDougall: > On 08/17/2014 09:09, Eggert, Lars wrote: >> Nobody using nscd? Really? > > I would test for you, but we retired our NIS infrastructure at least a > year ago. I did have it working on a test client at some point, but I > didn't push it into production because I found a couple issues (below). [...] > The two main problems I recall were nscd making java crash, and nscd > holding on to negative cache lookups too long, causing failures while > installing ports that depend on adding users/groups for a following file > permission change. I can't remember if the latter issue was fixed at > some point. I also can't remember if I was receiving perfectly accurate > results from the cache either. I added the "negative-confidence-threshold" option to nscd, a few years ago. If set to a number > 1 (the default), then that number of failures are required to cause a negative cache entry. Setting this value to 3 should allow for 2 probes for the presence of a UID or username, before the cache returns a failure without bothering to re-check the source. The value should be low enough to prevent flooding of a remote source with requests, if an entry really does not exist. The default was left unchanged - you need to increase the value to see any effect of this threshold. 3 might be a reasonable default for the user database. But I never bothered to suggest and discuss an increased default value on the mail-lists ... [...] > I dabbled with nscd a bit after we switched from NIS to LDAP. I think I > recall lookups being slightly slower WITH the cache, plus I would get > some duplicated group entries returned on all but the first getent > group. The short version is we in no way seem to benefit or require a > cache of LDAP with our site size, so I'm just not using nscd. I didn't > make bug reports for these issues, I had to prioritize towards more > pressing issues. I'm trying to do better about reporting bugs. I also found that there were glitches, when I tested the extension to cache only the nth negative reply. The code is not easy to read and change (IMHO), and I did not succeed when I tried to reproduce and debug these glitches. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 08:41:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA23714C; Mon, 18 Aug 2014 08:41:52 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78B443BB9; Mon, 18 Aug 2014 08:41:52 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7I8fhgJ083812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2014 11:41:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7I8fhgJ083812 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7I8fg4F083811; Mon, 18 Aug 2014 11:41:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Aug 2014 11:41:42 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: panic: pmap active 0xfffff8002d2ae9f8 Message-ID: <20140818084142.GM2737@kib.kiev.ua> References: <53EB868A.1060406@FreeBSD.org> <295b3f285bffb20608153322d259224a@shatow.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I2AcQh+/kfs26T/w" Content-Disposition: inline In-Reply-To: <295b3f285bffb20608153322d259224a@shatow.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:41:53 -0000 --I2AcQh+/kfs26T/w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 15, 2014 at 10:38:25PM -0500, Bryan Drewery wrote: > On 2014-08-13 10:38, Bryan Drewery wrote: > > On 6/24/2014 4:28 PM, Craig Rodrigues wrote: > >> Hi, > >>=20 > >> I have a system running CURRENT at r266925 from May 31. > >>=20 > >> While doing some software builds using poudriere, the system > >> panicked. Unfortunately this system was not configured with > >> swap space, so I cannot do a kernel dump. > >>=20 > >> The system is currently at the ddb prompt. > >> Here is the backtrace: > >>=20 > >>=20 > >> Here is the backtrace from ddb: > >>=20 > >> panic: pmap active 0xfffff8002d2ae9f8 > >> cpuid =3D 5 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfffffe183958a7d0 > >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe183958a880 > >> vpanic() at vpanic+0x126/frame 0xfffffe183958a8c0 > >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe183958a930 > >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe183958aa20 > >> vmspace_exit() at vmspace_exit+0xa1/frame 0xfffffe183958aa60 > >> exit1() at exit1+0x541/frame 0xfffffe183958aad0 > >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe183958aae0 > >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe183958abf0 > >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe183958abf0 > >> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - > >> 0x7ffffffe3e8, rbp =3D 0x7ffffffffe400 > >> KDB: enter: panic > >> [ thread pid 94762 tid 101570 ] > >> Stopped at kdb_enter+0x3e: movq $0.kdb_why > >> db> > >>=20 > >>=20 > >> Is this a known problem? > >> Are there other commands I should type at the ddb prompt? > >> -- > >> Craig > >=20 > > I have run into this as well on r269147: > >=20 > >> panic: pmap active 0xfffff80035f422f8 > >> cpuid =3D 10 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame=20 > >> 0xfffffe124852b7d0 > >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124852b880 > >> vpanic() at vpanic+0x126/frame 0xfffffe124852b8c0 > >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe124852b930 > >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe124852ba20 > >> vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe124852ba60 > >> exit1() at exit1+0x541/frame 0xfffffe124852bad0 > >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe124852bae0 > >> ia32_syscall() at ia32_syscall+0x270/frame 0xfffffe124852bbf0 > >> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfffffe124852bbf0 > >> --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip =3D 0x297e386f, rsp = =3D=20 > >> 0xffffd7ac, rbp =3D 0xffffd7b8 --- > >> KDB: enter: panic > >> [ thread pid 85335 tid 101517 ] > >> Stopped at kdb_enter+0x3e: movq $0,kdb_why > >> db> call doadump > >>=20 > >> Dump failed. Partition too small. > >> =3D 0 >=20 > Got it again on recent r269950 while building with poudriere: >=20 > panic: pmap active 0xfffff8113c3c6d78 > cpuid =3D 10 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame=20 > 0xfffffe1248acc7d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1248acc880 > vpanic() at vpanic+0x126/frame 0xfffffe1248acc8c0 > kassert_panic() at kassert_panic+0x139/frame 0xfffffe1248acc930 > pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe1248acca20 > vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe1248acca60 > exit1() at exit1+0x541/frame 0xfffffe1248accad0 > sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe1248accae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1248accbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1248accbf0 > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip =3D 0x80387fadc, rsp = =3D=20 > 0x7fffffffd4e8, rbp =3D 0x7fffffffd5a0 --- > KDB: enter: panic > [ thread pid 84433 tid 101503 ] > Stopped at kdb_enter+0x3e: movq $0,kdb_why > db> call doadump >=20 > Dump failed. Partition too small. > =3D 0 The interesting information is pmap->pm_active, for pmap address reported by the panic. Easiest way to get the active mask is using kgdb on vmcore. --I2AcQh+/kfs26T/w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT8bxGAAoJEJDCuSvBvK1BTe8P/iczyBq1Zz1zUYFXjW8Yybs7 keVhqz7lvDpxNKxYQ6n1IuXeNIUnercYpZbVqB+TkacysSVGYEqg6hPUgEDE/iKO 9rXmqwl/p4Q1//MqyImEtRK97cwU4bc2KSF8boPs4F8+ylUNTjgqVlHggw17++5U 5hOkGJDDGB3gUDaCG5/FYHC80JVy8ZgSBeu+IkRQ3dEfqe/sDudHTYv96X6fHURV yXqZYDemdbvHY72H1vP7tajr73SeuhIUDco1RMv4loM0wlzolbTx4UvEp1janJCy HEoVQZx7Qv2uDh+byAOOEj8yOx3i8pu4COdKSjxiU+oVPcShV8gJae7Fru2C5WuF SIzMMfg7JGc/jbwe7P6qFN8X97DYegVz5OMF5Vvw8xswlaeT0rf49cG9EQSKsGKv rTSX9VpLDMv2Y9gFv1QVscV/wLhcX3BYYSuEKUzZ0SHKPqb/OACx0Bjg7tzi+tby dBJn8NoRE59bHKpsP8uEbl4jlcEZjcAE7n7g5ajGoo0n1iZqwkmGK1BvpoDYBymf GwKVpr64mBbTlViNDvqwn+q++CVgmVZhzP373xTVMOc4p7oBI9gszToZ+YcPv9z7 7+8BITUYqUa//97Vyiy4VwJDxnaXlFJbvOfS880EaofBjyuTS/cNEx4kZ16iI9qm 8CJwaqXjw66YpU0EedhE =+1pQ -----END PGP SIGNATURE----- --I2AcQh+/kfs26T/w-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 15:21:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 873C6557 for ; Mon, 18 Aug 2014 15:21:54 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57FEF3400 for ; Mon, 18 Aug 2014 15:21:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=MZ5i/Vjt9F1oFvGg68aBBbl/twPugA2xzqTbOL+GOeQ=; b=rSdIs2ijv4Wm/76RVO/QjVth+UH+QVIsErquwTKqo2oga+RTH8iS5RqDg5q8hG3bvTPlWmVnwD62kttPi/VLHTbx9p+BDR0nxqxgGbWePdgv6mmLMGIj7puE55WjkQa4Hln6JYzrbpaCz9k1dtG0L9X3CPQG/ZZ1PKhBsnN+YRA=; Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]:23967 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XJOkp-000Fd8-Fr for freebsd-current@freebsd.org; Mon, 18 Aug 2014 10:21:53 -0500 Date: Mon, 18 Aug 2014 10:21:40 -0500 From: Larry Rosenman To: freebsd-current@freebsd.org Subject: DEADLKRES crash Message-ID: <20140818152138.GA3481@borg.lerctr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, TVD_RCVD_IP=0.001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:21:54 -0000 I got the following: borg.lerctr.org dumped core - see /var/crash/vmcore.8 Mon Aug 18 07:30:42 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 r269784M: Sun Aug 10 12:33:07 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, blocked for 1800926 ticks GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, blocked for 1800926 ticks cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100bff1a10 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100bff1ac0 vpanic() at vpanic+0x126/frame 0xfffffe100bff1b00 panic() at panic+0x43/frame 0xfffffe100bff1b60 deadlkres() at deadlkres+0x35c/frame 0xfffffe100bff1bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe100bff1bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100bff1bf0 --- trap 0, rip = 0, rsp = 0xfffffe100bff1cb0, rbp = 0 --- Uptime: 7d14h14m38s Dumping 9124 out of 64463 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/cyclic.ko.symbols...done. Loaded symbols for /boot/kernel/cyclic.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/lockstat.ko.symbols...done. Loaded symbols for /boot/kernel/lockstat.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonkmsfw_R100_cp.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkmsfw_R100_cp.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/uhid.ko.symbols...done. Loaded symbols for /boot/kernel/uhid.ko.symbols Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ether.ko.symbols Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff80a072b7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff80a077f5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0xffffffff80a07843 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:675 #4 0xffffffff809b754c in deadlkres () at /usr/src/sys/kern/kern_clock.c:286 #5 0xffffffff809d5ac4 in fork_exit (callout=0xffffffff809b71f0 , arg=0x0, frame=0xfffffe100bff1c00) at /usr/src/sys/kern/kern_fork.c:977 #6 0xffffffff80df785e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 #7 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) What info do folks need? Might have been NFS related. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 18:01:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7302A4A for ; Mon, 18 Aug 2014 18:01:30 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 863F03257 for ; Mon, 18 Aug 2014 18:01:30 +0000 (UTC) X-AuditID: 1209190c-f79ef6d000005dd6-3e-53f23e4570c3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 00.F6.24022.54E32F35; Mon, 18 Aug 2014 13:56:21 -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 s7IHuJFT003508; Mon, 18 Aug 2014 13:56:20 -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 s7IHuHOs003135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 13:56:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7IHuHcF016451; Mon, 18 Aug 2014 13:56:17 -0400 (EDT) Date: Mon, 18 Aug 2014 13:56:17 -0400 (EDT) From: Benjamin Kaduk To: Larry Rosenman Subject: Re: DEADLKRES crash In-Reply-To: <20140818152138.GA3481@borg.lerctr.org> Message-ID: References: <20140818152138.GA3481@borg.lerctr.org> 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+NgFvrBIsWRmVeSWpSXmKPExsUixCmqretq9ynY4N99Xos5bz4wWSx/MIvV gcljxqf5LB77925lCWCK4rJJSc3JLEst0rdL4MqY++snU8ETtopdXbeYGhj3s3YxcnJICJhI LNx4hQXCFpO4cG89WxcjF4eQwGwmiQ0vzrBDOBsZJebvnASVOcQkce1/O5TTwCjxorcBaBYH B4uAtsTGXakgo9gEVCRmvtnIBmKLCChLrJn6hxnEZhaQl/h/5TITiC0sICPRsmAzO0grJ9AZ h1/XgoR5BRwlPj94yQhiCwkYS7ye1Q52naiAjsTq/VNYIGoEJU7OfMICMVJLYvn0bSwTGAVn IUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQLzezRC81pXQTIzhQJXl2ML45qHSI UYCDUYmH98THj8FCrIllxZW5hxglOZiURHmn2XwKFuJLyk+pzEgszogvKs1JLT7EKMHBrCTC m2AKlONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgtgsnKcHAoSfD+BBkqWJSanlqR lplTgpBm4uAEGc4DNHwZSA1vcUFibnFmOkT+FKMuR0vT214mIZa8/LxUKXFeA1ugIgGQoozS PLg5sATzilEc6C1h3k8go3iAyQlu0iugJUxAS7Yu/giypCQRISXVwLj0ooPQ/s+TJoZGbXDb uu/oogUXGd+GluU7bJcNXZGx6IRNef8tz9S0CXeXit5YW8n+W2fCpf6FptPqjMy0OljWanBY Tdjkm1VXPkc8tnCto4nD20md0htOC7Mc1REKYrvH3q93mTv9av/75XcZ7htV8S0RvaovvLv+ GEe6spB/X33rQimez0osxRmJhlrMRcWJAB1c60kLAwAA Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:01:31 -0000 On Mon, 18 Aug 2014, Larry Rosenman wrote: > I got the following: > > borg.lerctr.org dumped core - see /var/crash/vmcore.8 > > Mon Aug 18 07:30:42 CDT 2014 > > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 r269784M: Sun Aug 10 12:33:07 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > > panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, > blocked for 1800926 ticks [...] > Current language: auto; currently minimal > (kgdb) > > What info do folks need? Most useful would be the "show alllocks" from DDB. Getting the lock information from kgdb is rather more annoying, though jhb has some gdb scripts which help. (http://people.freebsd.org/~jhb/gdb/) I guess the 'allchains' command from gdb6 is the one in question, but it's been a while since I tried to use these scripts. -Ben From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 18:05:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D3B4D2A; Mon, 18 Aug 2014 18:05:45 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF2C0334D; Mon, 18 Aug 2014 18:05:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=SV5PboMeQjhOfwEeQaM6PsgV6v28c3wK2y0c5z92GDs=; b=XWnX619QXa5vJsczjkQdrwxChvI4GCd9YQTOoD4K+TRfzcopby/ARHLdKmEXhOQl61bIIZGfSDVulikWvA7zT4dFuSbyvidkah0pfuUqUMNrqdnNvp6BKMDiwKxeexpqRbmkca7H+Nre8HIvtY0O1s8TEpShWtfsWtCkNzMmwxE=; Received: from localhost.lerctr.org ([127.0.0.1]:20439 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XJRJO-000Hom-8Z; Mon, 18 Aug 2014 13:05:43 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Mon, 18 Aug 2014 13:05:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 Aug 2014 13:05:42 -0500 From: Larry Rosenman To: Benjamin Kaduk Subject: Re: DEADLKRES crash In-Reply-To: References: <20140818152138.GA3481@borg.lerctr.org> Message-ID: <68bfaf46e716f5fa317896b4bb89b40b@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.6 (---) X-LERCTR-Spam-Score: -3.6 (---) X-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 X-LERCTR-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:05:45 -0000 On 2014-08-18 12:56, Benjamin Kaduk wrote: > On Mon, 18 Aug 2014, Larry Rosenman wrote: > >> I got the following: >> >> borg.lerctr.org dumped core - see /var/crash/vmcore.8 >> >> Mon Aug 18 07:30:42 CDT 2014 >> >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 >> r269784M: Sun Aug 10 12:33:07 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> >> panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, >> blocked for 1800926 ticks > [...] >> Current language: auto; currently minimal >> (kgdb) >> >> What info do folks need? > > Most useful would be the "show alllocks" from DDB. Getting the lock > information from kgdb is rather more annoying, though jhb has some gdb > scripts which help. (http://people.freebsd.org/~jhb/gdb/) I guess the > 'allchains' command from gdb6 is the one in question, but it's been a > while since I tried to use these scripts. > > -Ben > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" after source'ing the above, and typing allchains, it sits and spins, but no output... :( Ideas? I **CAN** give SSH access.... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 18:23:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02F57540 for ; Mon, 18 Aug 2014 18:23:44 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C74363528 for ; Mon, 18 Aug 2014 18:23:43 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7IINe6x065958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2014 11:23:40 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7IINcob065957; Mon, 18 Aug 2014 11:23:38 -0700 (PDT) (envelope-from jmg) Date: Mon, 18 Aug 2014 11:23:38 -0700 From: John-Mark Gurney To: "Eggert, Lars" Subject: Re: nscd not caching Message-ID: <20140818182338.GE83475@funkthat.com> Mail-Followup-To: "Eggert, Lars" , Adam McDougall , "freebsd-current@freebsd.org" References: <53F0D3F3.4030804@egr.msu.edu> <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 18 Aug 2014 11:23:40 -0700 (PDT) Cc: Adam McDougall , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:23:44 -0000 Eggert, Lars wrote this message on Mon, Aug 18, 2014 at 07:42 +0000: > The current NIS server is 25ms away, which is a pain. I'm trying to get a local slave set up, which will make the need for nscd go away, but it would sure be nice if it worked in the meantime. Why not run a local slave on your server? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 19:01:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54AE7C04; Mon, 18 Aug 2014 19:01:13 +0000 (UTC) Received: from kefka.worrbase.com (unknown [IPv6:2620:8d:8000:e49:f084:3e1b:e7f2:1c33]) (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 D8F453959; Mon, 18 Aug 2014 19:01:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]); by kefka.worrbase.com (OpenSMTPD) with ESMTP id b747f247; Mon, 18 Aug 2014 12:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=worrbase.com; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=mail; t=1408388454; x=1410202855; bh=kIdOkiTyFcvMLx OErts3HgtvFpHcbWfbczuMQ5EPCEk=; b=z4MbkU1dOrbVhwfikULH6E3aqhmwOL ahHkLzj2Mf6bW5KI6CP04d7jrE/nS/7h0f0fgaeUS/vRUV9idaB4e+iF03p3kz99 b2oE9otzgSY6CQVU58iPDJ0++hV4FfZ9hoYTk2QOXitgqlTHQe/cEePH1K0zqp8C bCTUTe34maQ9APGl4rZXAZg91LbZOe5ItufdHEuoBt93m+04WNdbTUTuiMIOxPaZ rOEM9h0KPBqVyDDFB3K3lKvvf1FQgkOgVqcDMpZPrmudJdoLNkeGh5/nUYqLm+gv UViGSwPGMMHpwNPN9n9CbJ/nWdU3Kmg7iud0Mld4i8tGgXUfTijEV8xkPWbFrQav i5ggyN/KaK0g4BHO2XnPU9yrlxs1nmm2ZhN+YZam21QuDP8sPo5+7U/6LwNcz/jJ Bv7OZ/aOsHt/2PUlDGOzWpuvexE2/VR+iUS+8uPDWyKgfDP0vHGG0xmUh6uImfdm MjloPGZT6oj7bgdUBOozVe4+e4yrl7YOIkXdGtxRAEB2iGXBjLrzaaqf5pJWRNSA qgVTNmOAcBAyzPkA6K0X0eg6caPcxGoYCdSrmKNHKEvWY7EO1kp34dXSCkcEP2oG J6lt8HuTM2xGc7XttwVwGMKnz1CsSphwE3DZ1sgDyTxtofncAIIer0N+46JCU7/s 1dtTX+Anzpdb4= X-Virus-Scanned: amavisd-new at worrbase.com Received: from kefka.worrbase.com ([IPv6:::1]) by localhost (kefka.worrbase.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id OXSfsCTrzevU; Mon, 18 Aug 2014 12:00:54 -0700 (PDT) Received: from [172.22.206.59] (216.3.18.37 [216.3.18.37]); by kefka.worrbase.com (OpenSMTPD) with ESMTPSA id 55f2f0f8; TLS version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 18 Aug 2014 12:00:54 -0700 (PDT) Message-ID: <53F24D60.4080107@worrbase.com> Date: Mon, 18 Aug 2014 12:00:48 -0700 From: William Orr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alan Somers , FreeBSD CURRENT Subject: Re: Inconsistent behavior with dd(1) References: <3C86F281-D618-4B93-BBA3-2DA33AC407EC@worrbase.com> <20140816173439.GZ83475@funkthat.com> In-Reply-To: <20140816173439.GZ83475@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8p3vhNA8fQQDtgrGDuLkFO9Fp8BHBDDdn" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 19:01:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8p3vhNA8fQQDtgrGDuLkFO9Fp8BHBDDdn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reply inline. On 08/16/2014 10:34 AM, John-Mark Gurney wrote: > Alan Somers wrote this message on Fri, Aug 15, 2014 at 10:42 -0600: >> On Thu, Aug 14, 2014 at 11:55 PM, William Orr wrot= e: >>> Hey, >>> >>> I found some inconsistent behavior with dd(1) when it comes to specif= ying arguments in -CURRENT. >>> >>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D1= 8446744073709551616 >>> dd: count: Result too large >>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D1= 8446744073709551617 >>> dd: count: Result too large >>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D1= 8446744073709551615 >>> dd: count cannot be negative >>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D-= 18446744073709551615 >>> 1+0 records in >>> 1+0 records out >>> 512 bytes transferred in 0.000373 secs (1373071 bytes/sec) >>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D-= 1 >>> dd: count cannot be negative >>> >>> ??? >>> >>> Any chance someone has the time and could take a look? https://bugs.f= reebsd.org/bugzilla/show_bug.cgi?id=3D191263 >>> >>> Thanks, >>> William Orr >>> >>> ??? >> >> >> IMHO, this is a bug in strtouq(3), not in dd(1). Why should it parse >> negative numbers at all, when there is stroq(3) for that purpose? The= >> standard is clear that it must, though. Oddly enough, stroq would >> probably not accept -18446744073709551615, even though strtouq does. >> Specific comments on your patch below: >> >> >>> >>> Here???s the patch: >>> >>> Index: bin/dd/args.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- bin/dd/args.c (revision 267712) >>> +++ bin/dd/args.c (working copy) >>> @@ -186,46 +186,31 @@ >>> static void >>> f_bs(char *arg) >>> { >>> - uintmax_t res; >>> - >>> - res =3D get_num(arg); >>> - if (res < 1 || res > SSIZE_MAX) >>> - errx(1, "bs must be between 1 and %jd", (intmax_t)SSI= ZE_MAX); >>> - in.dbsz =3D out.dbsz =3D (size_t)res; >>> + in.dbsz =3D out.dbsz =3D get_num(arg); >>> + if (in.dbsz < 1 || out.dbsz < 1) >> >> Why do you need to check both in and out? Aren't they the same? >> Also, you eliminated the check for overflowing SSIZE_MAX. That's not >> ok, because these values get passed to places that expect signed >> numbers, for example in dd.c:303. >=20 > The type of dbsz is size_t, so really: >=20 >>> + errx(1, "bs must be between 1 and %ju", (uintmax_t)-1= ); >=20 > This should be SIZE_MAX, except there isn't a define for this? So mayb= e > the code really should be: > (uintmax_t)(size_t)-1 >=20 > to get the correct value for SIZE_MAX... >=20 > Otherwise on systems that uintmax_t is >32bits and size_t is 32bits, > the error message will be wrong... Yes, this should probably be SIZE_MAX rather than that cast. Same with the others >=20 >>> } >>> >>> static void >>> f_cbs(char *arg) >>> { >>> - uintmax_t res; >>> - >>> - res =3D get_num(arg); >>> - if (res < 1 || res > SSIZE_MAX) >>> - errx(1, "cbs must be between 1 and %jd", (intmax_t)SS= IZE_MAX); >>> - cbsz =3D (size_t)res; >>> + cbsz =3D get_num(arg); >>> + if (cbsz < 1) >>> + errx(1, "cbs must be between 1 and %ju", (uintmax_t)-= 1); >>> } >> >> Again, you eliminated the check for SSIZE_MAX, but cbsz must be signed= =2E >=20 > What do you mean by this? cbsz is size_t which is unsigned... I believe he's referring to this use of cbsz/in.dbsz/out.dbsz: https://svnweb.freebsd.org/base/head/bin/dd/dd.c?revision=3D265698&view=3D= markup#l171 Really, this is more wrong since there is math inside of a malloc(3) call without any overflow handling. By virtue of making this max out at a ssize_t, it becomes more unlikely that you'll have overflow. This math should probably be done ahead of time with proper overflow handling. I'll include that in my next patch, if there's no objection. I don't see any other reason why in.dbsz, out.dbsz or cbsz should be signed, but it's very possible that I didn't look hard enough. > Again, the cast above is wrong... Maybe we should add a SIZE_MAX > define so we don't have to see the double cast... >=20 >>> static void >>> f_count(char *arg) >>> { >>> - intmax_t res; >>> - >>> - res =3D (intmax_t)get_num(arg); >>> - if (res < 0) >>> - errx(1, "count cannot be negative"); >>> - if (res =3D=3D 0) >>> - cpy_cnt =3D (uintmax_t)-1; >> >> This is a special case. See dd_in(). I think that eliminating this >> special case will have the unintended effect of breaking count=3D0. >> >>> - else >>> - cpy_cnt =3D (uintmax_t)res; >>> + cpy_cnt =3D get_num(arg); >>> } >>> >>> static void >>> f_files(char *arg) >>> { >>> - >=20 > Don't eliminate these blank lines.. they are intentional per style(9): > /* Insert an empty line if the function has no local varia= bles. */ >=20 >>> files_cnt =3D get_num(arg); >>> if (files_cnt < 1) >>> - errx(1, "files must be between 1 and %jd", (uintmax_t= )-1); >>> + errx(1, "files must be between 1 and %ju", (uintmax_t= )-1); >> >> Good catch. >> >>> } >>> >>> static void >>> @@ -241,14 +226,10 @@ >>> static void >>> f_ibs(char *arg) >>> { >>> - uintmax_t res; >>> - >>> if (!(ddflags & C_BS)) { >>> - res =3D get_num(arg); >>> - if (res < 1 || res > SSIZE_MAX) >>> - errx(1, "ibs must be between 1 and %jd", >>> - (intmax_t)SSIZE_MAX); >>> - in.dbsz =3D (size_t)res; >>> + in.dbsz =3D get_num(arg); >>> + if (in.dbsz < 1) >>> + errx(1, "ibs must be between 1 and %ju", (uin= tmax_t)-1); >> >> Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed= =2E >=20 > If dbsz must be signed, we should change it's definition to ssize_t > instead of size_t... Can you point to the line that says this? >=20 > In investigating this, it looks like we may have a bug in ftruncate in > that out.offset * out.dbsz may overflow and return incorrect results...= > We should probably check that the output (cast to off_t) is greater tha= n > both the inputs before calling ftruncate... This is safe as both are > unsigned... Yeah, there probably ought to be integer overflow handling here as well. >=20 >>> } >>> } >>> >>> @@ -262,14 +243,10 @@ >>> static void >>> f_obs(char *arg) >>> { >>> - uintmax_t res; >>> - >>> if (!(ddflags & C_BS)) { >>> - res =3D get_num(arg); >>> - if (res < 1 || res > SSIZE_MAX) >>> - errx(1, "obs must be between 1 and %jd", >>> - (intmax_t)SSIZE_MAX); >>> - out.dbsz =3D (size_t)res; >>> + out.dbsz =3D get_num(arg); >>> + if (out.dbsz < 1) >>> + errx(1, "obs must be between 1 and %ju", (uin= tmax_t)-1); >>> } >>> } >> >> Again, you eliminated the check for SSIZE_MAX, but dbsz must be signed= =2E >> >>> >>> @@ -378,11 +355,14 @@ >>> uintmax_t num, mult, prevnum; >>> char *expr; >>> >>> + if (val[0] =3D=3D '-') >>> + errx(1, "%s: cannot be negative", oper); >>> + >> >> In general, I like this part of the diff. Every user of get_num >> checks for negative values, so why not move the check into get_num >> itself? But you changed it from a numeric check to a text check, and >> writing text parsers makes me nervous. I can't see any problems, >> though. Funnily enough this part of the diff was wrong. I didn't account for spaces, so I'll add that in my upcoming diff. >> >>> errno =3D 0; >>> num =3D strtouq(val, &expr, 0); >>> if (errno !=3D 0) /* Overflow or unde= rflow. */ >>> err(1, "%s", oper); >>> - >>> + >>> if (expr =3D=3D val) /* No valid digit= s. */ >>> errx(1, "%s: illegal numeric value", oper); >>> >>> Index: bin/dd/dd.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- bin/dd/dd.c (revision 267712) >>> +++ bin/dd/dd.c (working copy) >>> @@ -284,8 +284,6 @@ >>> >>> for (;;) { >>> switch (cpy_cnt) { >>> - case -1: /* count=3D0 was spec= ified */ >>> - return; >> >> Again, I don't think this will do what you want it to do. Previously,= >> leaving count unspecified resulted in cpy_cnt being 0, and specifying >> count=3D0 set cpy_cnt to -1. With your patch, setting count=3D0 will = have >> the same effect as leaving it unspecified. Nope. It didn't do what I wanted. I'll submit an updated diff with this fixed as well as the other things I mentioned, provided there's no objection to my direction. >>> case 0: >>> break; >>> default: >>> >>> >=20 --8p3vhNA8fQQDtgrGDuLkFO9Fp8BHBDDdn 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.14 (GNU/Linux) iQIcBAEBAgAGBQJT8k1lAAoJEOWIWopNkblkBkEP/1o+GE8yL5x/yiFUlx/drGvy p/rbLpvWMALru93/WIbUcLpktT1shOxbT/+uCwFImmrq+AU2nohiHM9zobRDOZgE Iqj6KpJKqhVRpGuG7iwO24Lnv/SKyxYr8Tje/SqLrEwUek49mNsRHcyNvp8M9rii 6tLZV8yYwEs9FnvGH2WH+hiWUFLHt6Ato4l2L50cWbrJrEBJrDuIXqajOFdRlofb O2EQms8XaXnl5toSKVYQOgdy4ORkOXg1Tdp9my6Oph0t8W+cIaIh8XRrEA6UMMos P1CrRib2NQT10Y7ybrWFOff/jz+5FZ0C0PxQXV0gqewA3l9Wp2o4J/5nuKiQSY11 LVq8jgzxtQHSlDKyvXwzOHfTl78Gr/UhE7SJwBpvCgoBgptYZG8P7hQhIYhlXU5W DtlRSrnv7n69MmTWxeB6dC1MmVo3E0eb5J0YvEVjkQKp7E71LAwDPd/hz3VBSQDt 2KU6zSuooSydzrvXcF0qT0aGp4ttYYXly66O2qPQgT7umLlTjpzLU8Rcn1uwbpDB WRTR6anc3urknBu3EuDnOa10eiowDhtlC8x8bkY8MSzbd8EuVFeIjJSD61qWVtKM 5u8DoybOy8M3bD9wcApYILdarwmAlVsELgjMf8r5459GabndAL7QWdRbLLPzLcoj 2iusnBvxbecJTz4oLon4 =CtY/ -----END PGP SIGNATURE----- --8p3vhNA8fQQDtgrGDuLkFO9Fp8BHBDDdn-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 20:45:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05832F1D for ; Mon, 18 Aug 2014 20:45:05 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C60383562 for ; Mon, 18 Aug 2014 20:45:04 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j17so4489407oag.14 for ; Mon, 18 Aug 2014 13:45:04 -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=qcTpnh6O8FtjoV6gMUGjekHnk374we5955a8De1SF5g=; b=iUMgjTUp/ytdPX85zxWFk2dxcqjxu4sp+a8mPfKwunH+eaAVfSArEsFR0PQKRyQkBp U4tN/YiPuVQPhPzBwsXECpg9Xi2V326zh+MyiYekwR2vuaWk+UUvDg6iYRczozdriHth 0ARSQrwJeHlgVpaNgohkIrVSdXJ+tsqW0pLElLuv0ycB3bhYUplnwcuyqVQyNYdtex3k xwpNDCY7iy5C/5VKEBwQ/41QqkcUPCW7BmNci+MUSnmI2m3hhbBLT3sZo8dVcnPqvXd2 FRmiERjmtk9CCZe8X5WUMOaS7WcHxSLcen87JftzsZal8N+Za0xbRHc2earr/HuOS3I1 paEw== MIME-Version: 1.0 X-Received: by 10.182.114.169 with SMTP id jh9mr38983276obb.25.1408394704135; Mon, 18 Aug 2014 13:45:04 -0700 (PDT) Received: by 10.76.187.39 with HTTP; Mon, 18 Aug 2014 13:45:04 -0700 (PDT) In-Reply-To: <20140818152138.GA3481@borg.lerctr.org> References: <20140818152138.GA3481@borg.lerctr.org> Date: Mon, 18 Aug 2014 16:45:04 -0400 Message-ID: Subject: Re: DEADLKRES crash From: Ryan Stone To: Larry Rosenman Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:45:05 -0000 On Mon, Aug 18, 2014 at 11:21 AM, Larry Rosenman wrote: > I got the following: > > borg.lerctr.org dumped core - see /var/crash/vmcore.8 > > Mon Aug 18 07:30:42 CDT 2014 > > FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 r269784M: Sun Aug 10 12:33:07 CDT 2014 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > > panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, blocked for 1800926 ticks > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, blocked for 1800926 ticks > > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe100bff1a10 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100bff1ac0 > vpanic() at vpanic+0x126/frame 0xfffffe100bff1b00 > panic() at panic+0x43/frame 0xfffffe100bff1b60 > deadlkres() at deadlkres+0x35c/frame 0xfffffe100bff1bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe100bff1bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100bff1bf0 > --- trap 0, rip = 0, rsp = 0xfffffe100bff1cb0, rbp = 0 --- > Uptime: 7d14h14m38s The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xfffff8002abeb000 tid $td->td_tid bt That will show us the backtrace of the thread that was blocked for so long. From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 20:47:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8456B234 for ; Mon, 18 Aug 2014 20:47:40 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 507063592 for ; Mon, 18 Aug 2014 20:47:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=8i3aLsFoUbUkWU+nAlhpraqSTDm2RqWV0FhkVJZW7Sw=; b=Fd/xQBifRJusr8ZGUV/NrvwrTtf3RGkw+kdbtbbSw97s8QYtqf/0XsVbiSDs7ZZEzhq5aW7CuGI7uQl1v5dmxiNu1zLUkbrfwiW8A49AapJFBqbon54tYkNLlqnFCeamNnLdPBw6Vqe/yM0XpUpeKCHO5Wyrapb7NrsQRfbKH68=; Received: from localhost.lerctr.org ([127.0.0.1]:18736 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XJTq5-000K6L-8N; Mon, 18 Aug 2014 15:47:39 -0500 Received: from host.alcatel.com ([198.205.55.139]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Mon, 18 Aug 2014 15:47:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 18 Aug 2014 15:47:37 -0500 From: Larry Rosenman To: Ryan Stone Subject: Re: DEADLKRES crash In-Reply-To: References: <20140818152138.GA3481@borg.lerctr.org> Message-ID: <0915cd35b52b70eb2fb20765223fc7f1@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.6 (---) X-LERCTR-Spam-Score: -3.6 (---) X-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 X-LERCTR-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 20:47:40 -0000 On 2014-08-18 15:45, Ryan Stone wrote: > On Mon, Aug 18, 2014 at 11:21 AM, Larry Rosenman > wrote: >> I got the following: >> >> borg.lerctr.org dumped core - see /var/crash/vmcore.8 >> >> Mon Aug 18 07:30:42 CDT 2014 >> >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 >> r269784M: Sun Aug 10 12:33:07 CDT 2014 >> root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> >> panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, >> blocked for 1800926 ticks >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> panic: deadlkres: possible deadlock detected for 0xfffff8002abeb000, >> blocked for 1800926 ticks >> >> cpuid = 3 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe100bff1a10 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe100bff1ac0 >> vpanic() at vpanic+0x126/frame 0xfffffe100bff1b00 >> panic() at panic+0x43/frame 0xfffffe100bff1b60 >> deadlkres() at deadlkres+0x35c/frame 0xfffffe100bff1bb0 >> fork_exit() at fork_exit+0x84/frame 0xfffffe100bff1bf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe100bff1bf0 >> --- trap 0, rip = 0, rsp = 0xfffffe100bff1cb0, rbp = 0 --- >> Uptime: 7d14h14m38s > > The first thing that I'd like to see is (in kgdb): > > set $td=(struct thread)0xfffff8002abeb000 > tid $td->td_tid > bt > > That will show us the backtrace of the thread that was blocked for so > long. 0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) set $td=(struct thread)0xfffff8002abeb000 Invalid cast. (kgdb) set $td=(struct thread*)0xfffff8002abeb000 Current language: auto; currently minimal (kgdb) tid $td->td_tid [Switching to thread 469 (Thread 100681)]#0 sched_switch ( td=0xfffff8002abeb000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1931 1931 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xfffff8002abeb000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1931 #1 0xffffffff80a107d9 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:493 #2 0xffffffff80a4c442 in sleepq_switch (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:552 #3 0xffffffff80a4c2a3 in sleepq_wait (wchan=0xfffff80070a4dd50, pri=96) at /usr/src/sys/kern/subr_sleepqueue.c:631 #4 0xffffffff809eb1fa in sleeplk (lk=, flags=, ilk=, wmesg=, pri=, timo=) at /usr/src/sys/kern/kern_lock.c:225 #5 0xffffffff809eaa06 in __lockmgr_args (lk=0xfffff80070a4dd50, flags=, ilk=0xfffff80070a4dd80, wmesg=, pri=, timo=) at /usr/src/sys/kern/kern_lock.c:931 #6 0xffffffff8092e092 in nfs_lock1 (ap=) at lockmgr.h:97 #7 0xffffffff80f2d57c in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2082 #8 0xffffffff80abd22a in _vn_lock (vp=0xfffff80070a4dce8, flags=, file=0xffffffff8110db88 "/usr/src/sys/kern/vfs_subr.c", line=2137) at vnode_if.h:859 #9 0xffffffff80aad4e7 in vget (vp=0xfffff80070a4dce8, flags=524544, ---Type to continue, or q to quit--- td=0xfffff8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137 #10 0xffffffff80aa1491 in vfs_hash_get (mp=0xfffff8002aa1e990, hash=1741450670, flags=, td=0xfffff8002abeb000, vpp=0xfffffe100c75c670, fn=0xffffffff80935820 ) at /usr/src/sys/kern/vfs_hash.c:88 #11 0xffffffff809314bd in ncl_nget (mntp=0xfffff8002aa1e990, fhp=0xfffff80070ccf4a4 "\001", fhsize=12, npp=0xfffffe100c75c6e0, lkflags=) at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114 #12 0xffffffff809340fd in nfs_statfs (mp=0xfffff8002aa1e990, sbp=0xfffff8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:288 #13 0xffffffff80aa7ade in __vfs_statfs (mp=0x0, sbp=0xfffff8002aa1ea48) at /usr/src/sys/kern/vfs_mount.c:1706 #14 0xffffffff80ab4f5e in kern_getfsstat (td=0xfffff8002abeb000, buf=, bufsize=, bufseg=UIO_USERSPACE, flags=) at /usr/src/sys/kern/vfs_syscalls.c:511 #15 0xffffffff80e1625a in amd64_syscall (td=0xfffff8002abeb000, traced=0) at subr_syscall.c:133 #16 0xffffffff80df760b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #17 0x00000008010fc83a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 08:42:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3D95B73 for ; Tue, 19 Aug 2014 08:42:29 +0000 (UTC) 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 955B430FD for ; Tue, 19 Aug 2014 08:42:29 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XJezr-000Izm-AE for freebsd-current@freebsd.org; Tue, 19 Aug 2014 10:42:27 +0200 Message-ID: <53F30DF3.1090301@dumbbell.fr> Date: Tue, 19 Aug 2014 10:42:27 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> In-Reply-To: <53EE9CFF.4080607@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jO7gijdjV6n3SdkbJXm0OQKua7W0MQ0lv" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 08:42:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jO7gijdjV6n3SdkbJXm0OQKua7W0MQ0lv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16.08.2014 01:51, Nathan Whitehorn wrote: > It also has bad effects on boot time. My desktop takes something like 3= > times as long to boot after r269471. If it can't be fixed quickly, it > needs to be reverted. Just a quick note: I'm working on an update to vt_vga. The current patch already fixes the draw speed problem, but I'm not finished yet (the mouse cursor is broken as well as some other small annoyances). --=20 Jean-S=E9bastien P=E9dron --jO7gijdjV6n3SdkbJXm0OQKua7W0MQ0lv 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 iQIcBAEBAgAGBQJT8w3zAAoJEDnpl2Gl/ZTMZBQQALfKlImCAiwbdD7zHT6GiYOg BDoQJXyIM0gnl+6tGPwKolR+3sMQ4SW0mMC1SfWj5kJK1bMZ4fPCIpTKchJHNt7J 9NQOXlA+mGy6HqOZhj3jG5ocDkji/lfBirN112LDC7R0vdlENy5W02Hppw65iU+R MsKxYVq1BLKc/nMliYsiIGiEuETL9/7prVnkLaHjSey64pJhZ9Ga1/OpLj43IDnP GLx3A5MBaGT6vt7TxfcsFX6RhNge9ZedxEVUX8MVdG4OV4MUob8xGpg4LsrrIwda c4s7XFgCZEX6JffES5HOBLcTmKKADWvJeT/WgnA7wxpJvyJOEuh2oziTPNxgJdon Th0frBH9OCc3uSheErdImOrAODO1ingEVRwf+MemsrQ6IvJKIj3WG3CXkZ0yoCWg KcJI1heIKkgl48B/SJso1rO6ekPAhLtoGSBusroubru/z/RSCiYpRUDodA2z6OQz aiC89jiw3n6aP4Vl+eIiDLHCKxsoWoV/PSCBPD2aPE3ULKtWOz7LQVrUA8nG5g4M pmvx0q95/AfEBKtzZv5kN2G+dRrTG/CssCqNvWsS6gKBk46rNMZ0SzqE/90T+TFZ ZlOo+Qh3zn1cFYvXG7NdF0NBY1Y0SxZTTDNMptrJtI71bsdtuHuHaKuSIZI4BNpx PyD8jnAVnGuJDBMJ8FlM =BqRj -----END PGP SIGNATURE----- --jO7gijdjV6n3SdkbJXm0OQKua7W0MQ0lv-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 11:55:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3362772C for ; Tue, 19 Aug 2014 11:55:00 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9D173516 for ; Tue, 19 Aug 2014 11:54:59 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XJhzz-000N36-SV; Tue, 19 Aug 2014 14:54:47 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: nscd not caching From: Daniel Braniss In-Reply-To: <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> Date: Tue, 19 Aug 2014 14:54:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3B285476-A7ED-4C88-A2CB-9BD7E93C0E69@cs.huji.ac.il> References: <53F0D3F3.4030804@egr.msu.edu> <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1878.6) Cc: Adam McDougall , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 11:55:00 -0000 On Aug 18, 2014, at 10:42 AM, Eggert, Lars wrote: > Hi, >=20 > On 2014-8-17, at 18:10, Adam McDougall wrote: >> We were using +::::::::: type entries in the local password and group >> tables and I believe we used an unmodified /etc/nsswitch.conf = (excluding >> cache lines while testing nscd): >=20 > I tried that setup too, and it doesn't seem to be caching any NIS = lookups either. >=20 > The current NIS server is 25ms away, which is a pain. I'm trying to = get a local slave set up, which will make the need for nscd go away, but = it would sure be nice if it worked in the meantime. >=20 >> At our site, we never had enough load to outright require nscd on >> FreeBSD, although there were some areas where caching had a usability >> benefit. >=20 > Load is not an issue, latency is (see above). I know that this a bit late but have you ever considered Hesiod? it uses = DNS/txt. we have been using it since the days when BSDi had no NIS support and = haven=92t seen a ypserver not responding since :-) danny From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:14:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 488D8E26; Tue, 19 Aug 2014 13:14:43 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 BCB723D1F; Tue, 19 Aug 2014 13:14:42 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s7JDEa8h099576; Tue, 19 Aug 2014 15:14:36 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3F4103721; Tue, 19 Aug 2014 15:14:36 +0200 (CEST) Message-ID: <53F34DA3.70609@omnilan.de> Date: Tue, 19 Aug 2014 15:14:11 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Peter Wemm Subject: Re: nscd not caching References: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> <2295097.hWnAh3kd1o@overcee.wemm.org> In-Reply-To: <2295097.hWnAh3kd1o@overcee.wemm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE7E1CB56669F1BB3277EFBDA" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 19 Aug 2014 15:14:39 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "O. Hartmann" , freebsd-current@freebsd.org, "Eggert, Lars" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:14:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7E1CB56669F1BB3277EFBDA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): > On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: >> Am Sun, 17 Aug 2014 13:09:10 +0000 >> >> "Eggert, Lars" schrieb: >>> Nobody using nscd? Really? >> I can only speak for myself and I stopped using nscd since the support= is >> crap. >> >> A while ago (t > 1 1/2 years) I realised within a OpenLDAP environment= , that >> when nscd is running, sometimes the system simple "forgets" about root= - >> this is painful while installing/updating ports and getting interrupte= d >> with a weird error "unknown user root". >> >> nscd is supposed to be used in large environments where the cost for a= user >> lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used i= n >> that large environments with OpenLDAP and I'm wondering what the purpo= se of >> nscd is. > The other problem is that net/nss_ldap and security/pam_ldap have kind = of been=20 > left behind for performance and robustness. People who use this seriou= sy tend=20 > to discover net/nss-pam-ldapd fairly quickly which has its own caching = proxy=20 > and eliminates the need for nscd. > > With nss_ldap and pam_ldap, the openldap client libraries and startup c= ost is=20 > linked into every single binary that uses it. > > WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred=20 > authentication) and no heavy-weight libraries in the consumers. The pro= xy on=20 > the other end of the socket keeps a ldap connection open (with an idle = > timeout). The whole thing was vastly more robust and efficient. > > At least that's what we found in the freebsd.org cluster. nss-pam-ldap= d was=20 > two or three orders of magnitude more usable and got rid of nscd in the= =20 > process. > > For us, nscd "worked", but it just didn't save much effort because it w= as a=20 > per-uid cache. ie: if "jkh" had just caused a ldap search, and "peter"= =20 > repeated it, it had to be done again from scratch. > > The downside for nss-pam-ldapd was that it uses a non-extensible wire p= rotocol=20 > and didn't have room for bsd-style login classes. This exactly refelcts my experiences too, which is why I'm wondering if net/nss-pam-ldapd is a serious base candidate. When nscd showed up (arround 7.0-Release if I remember correctly), it was a big and highly appreciated improovement for me, reducing interactivity lags of gnome e.g. by at least a factor of 4 for usual desktop user tasks when user database was LDAP driven. At that time there were rumors that FreeBSD needs LDAP user-database support, but with the glitches of net/nss_ldap, it seemed that there's no ready-to-implement solution at that time. Things changed completely with net/nss-pam-ldapd. Haven't had any negative experiences with single-LDAP backend networks. Haven't had big environments yet either, but I think it's time to think about base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess it won't get into base, but it was a great template, is it? -Harry --------------enigE7E1CB56669F1BB3277EFBDA 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.18 (FreeBSD) iEYEARECAAYFAlPzTakACgkQLDqVQ9VXb8i0JwCfUfiyTU004LZSbl88QSwOsjNy 9vgAoKwtVqIdEMdnMVWDlMrHsmqdUyna =EDYp -----END PGP SIGNATURE----- --------------enigE7E1CB56669F1BB3277EFBDA-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:31:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0ACC25A for ; Tue, 19 Aug 2014 13:31:40 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A70C23F3A for ; Tue, 19 Aug 2014 13:31:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,894,1400050800"; d="asc'?scan'208";a="140956294" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 19 Aug 2014 06:31:32 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Aug 2014 06:30:35 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 19 Aug 2014 06:30:34 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Tue, 19 Aug 2014 06:30:34 -0700 From: "Eggert, Lars" To: John-Mark Gurney Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPt7KjJmpD94JuA0qgbFukGy7xyJvVPwmAgAAyboCAAQSvAIAAstwAgAFAtAA= Date: Tue, 19 Aug 2014 13:30:34 +0000 Message-ID: References: <53F0D3F3.4030804@egr.msu.edu> <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> <20140818182338.GE83475@funkthat.com> In-Reply-To: <20140818182338.GE83475@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_20DC2BBB-5692-4200-B662-21C193E30AE8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Adam McDougall , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:31:40 -0000 --Apple-Mail=_20DC2BBB-5692-4200-B662-21C193E30AE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-8-18, at 20:23, John-Mark Gurney wrote: > Why not run a local slave on your server? I am trying to get one set up. It requires a change request to our = organization's IT, which is, ahem, not always lightning fast. Lars --Apple-Mail=_20DC2BBB-5692-4200-B662-21C193E30AE8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU/NRsNZcnpRveo1xAQJTogP/b3zTZvcz7icfPu/l61RF8okQpVjfL//V REDt2+tB5Oqq+7EjCaxNoQjXH0Gg550cUYUJxktz0+JDnK26ynxg7sKxZ8aZwCMw fkFwuKI6ppuHCvx2QS9YhUnbblvMSCT/zPDQa9bEnq/h2x7d+ZPIecP61FAV2Ayx 9ABjKqfdpjg= =VnJ/ -----END PGP SIGNATURE----- --Apple-Mail=_20DC2BBB-5692-4200-B662-21C193E30AE8-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:33:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8FE3B9 for ; Tue, 19 Aug 2014 13:33:51 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5EBC3F60 for ; Tue, 19 Aug 2014 13:33:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,894,1400050800"; d="asc'?scan'208";a="140956918" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 19 Aug 2014 06:33:52 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Aug 2014 06:32:55 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 19 Aug 2014 06:32:54 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Tue, 19 Aug 2014 06:32:54 -0700 From: "Eggert, Lars" To: Daniel Braniss Subject: Re: nscd not caching Thread-Topic: nscd not caching Thread-Index: AQHPt7KjJmpD94JuA0qgbFukGy7xyJvVPwmAgAAyboCAAQSvAIAB2IQAgAAbsAA= Date: Tue, 19 Aug 2014 13:32:54 +0000 Message-ID: References: <53F0D3F3.4030804@egr.msu.edu> <9C985132-212F-4F2D-BEBF-CFEAC0097CC9@netapp.com> <3B285476-A7ED-4C88-A2CB-9BD7E93C0E69@cs.huji.ac.il> In-Reply-To: <3B285476-A7ED-4C88-A2CB-9BD7E93C0E69@cs.huji.ac.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_717AE105-06BD-4287-BDE5-F3D98725FB0E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Adam McDougall , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:33:51 -0000 --Apple-Mail=_717AE105-06BD-4287-BDE5-F3D98725FB0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2014-8-19, at 13:54, Daniel Braniss wrote: >=20 > I know that this a bit late but have you ever considered Hesiod? it = uses DNS/txt. > we have been using it since the days when BSDi had no NIS support and = haven=92t > seen a ypserver not responding since :-) I don't control the master NIS infrastructure, I just want to use it = (with a server that is unfortunately 25ms away). We will move to LDAP at = some time, but in the meantime, a functioning nscd would be nice. Lars --Apple-Mail=_717AE105-06BD-4287-BDE5-F3D98725FB0E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU/NSOtZcnpRveo1xAQKARgP+KRlL+6cK7RGE7ZYPHiP2yURQF0o4fao4 Hi/J4REc7HQq3pnrxOOdKzspkfaFrnWQYQaYVzndGxXizaZjv+t36iACxFTmNBOj lMf5YBmbnBmyRKUMNzrofSckRdCwOS29lET5VZlHy3QU3Q3J3H8t7R1OMaNT5RRK YNO6aQkAG4w= =yDbt -----END PGP SIGNATURE----- --Apple-Mail=_717AE105-06BD-4287-BDE5-F3D98725FB0E-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:39:31 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F7CB55C; Tue, 19 Aug 2014 13:39:31 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id CFF8D3FA0; Tue, 19 Aug 2014 13:39:30 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id B5AB456436; Tue, 19 Aug 2014 08:39:29 -0500 (CDT) Message-ID: <53F35390.2060503@vangyzen.net> Date: Tue, 19 Aug 2014 09:39:28 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Harald Schmalzbauer , Peter Wemm Subject: Re: nscd not caching References: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> <2295097.hWnAh3kd1o@overcee.wemm.org> <53F34DA3.70609@omnilan.de> In-Reply-To: <53F34DA3.70609@omnilan.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Eggert, Lars" , freebsd-current@freebsd.org, "O. Hartmann" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:39:31 -0000 On 08/19/2014 09:14, Harald Schmalzbauer wrote: > Bezglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): >> On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: >>> Am Sun, 17 Aug 2014 13:09:10 +0000 >>> >>> "Eggert, Lars" schrieb: >>>> Nobody using nscd? Really? >>> I can only speak for myself and I stopped using nscd since the support is >>> crap. >>> >>> A while ago (t > 1 1/2 years) I realised within a OpenLDAP environment, that >>> when nscd is running, sometimes the system simple "forgets" about root - >>> this is painful while installing/updating ports and getting interrupted >>> with a weird error "unknown user root". >>> >>> nscd is supposed to be used in large environments where the cost for a user >>> lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in >>> that large environments with OpenLDAP and I'm wondering what the purpose of >>> nscd is. >> The other problem is that net/nss_ldap and security/pam_ldap have kind of been >> left behind for performance and robustness. People who use this seriousy tend >> to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy >> and eliminates the need for nscd. >> >> With nss_ldap and pam_ldap, the openldap client libraries and startup cost is >> linked into every single binary that uses it. >> >> WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred >> authentication) and no heavy-weight libraries in the consumers. The proxy on >> the other end of the socket keeps a ldap connection open (with an idle >> timeout). The whole thing was vastly more robust and efficient. >> >> At least that's what we found in the freebsd.org cluster. nss-pam-ldapd was >> two or three orders of magnitude more usable and got rid of nscd in the >> process. >> >> For us, nscd "worked", but it just didn't save much effort because it was a >> per-uid cache. ie: if "jkh" had just caused a ldap search, and "peter" >> repeated it, it had to be done again from scratch. >> >> The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol >> and didn't have room for bsd-style login classes. > This exactly refelcts my experiences too, which is why I'm wondering if > net/nss-pam-ldapd is a serious base candidate. > When nscd showed up (arround 7.0-Release if I remember correctly), it > was a big and highly appreciated improovement for me, reducing > interactivity lags of gnome e.g. by at least a factor of 4 for usual > desktop user tasks when user database was LDAP driven. > At that time there were rumors that FreeBSD needs LDAP user-database > support, but with the glitches of net/nss_ldap, it seemed that there's > no ready-to-implement solution at that time. > Things changed completely with net/nss-pam-ldapd. Haven't had any > negative experiences with single-LDAP backend networks. Haven't had big > environments yet either, but I think it's time to think about > base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess > it won't get into base, but it was a great template, is it? +1 for nss-pam-ldapd. We were using nss_ldap+pam_ldap, but switched to nss-pam-ldapd. It's much faster and very reliable. We have several multi-user FreeBSD systems (build servers, doing lots of lookups), dozens of concurrent users and hundreds of total users, and Active Directory servers. The way nss_ldap links the LDAP libraries into every process is not just inefficient: it can be fatal. Thunderbird includes (or formerly included?) its own private LDAP libraries. These conflicted with those used by nss_ldap, so that Thunderbird would often crash. I don't know if this is still a problem, but it's not /my/ problem anymore. As for the base system, "pkg install nss-pam-ldapd" is embarrassingly easy and /much/ easier than adding to the base system. Eric From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:42:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66503820 for ; Tue, 19 Aug 2014 13:42:35 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 475713059 for ; Tue, 19 Aug 2014 13:42:35 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C03655643D; Tue, 19 Aug 2014 08:42:34 -0500 (CDT) Message-ID: <53F35449.9050608@vangyzen.net> Date: Tue, 19 Aug 2014 09:42:33 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ryan Stone , Larry Rosenman Subject: Re: DEADLKRES crash References: <20140818152138.GA3481@borg.lerctr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:42:35 -0000 On 08/18/2014 16:45, Ryan Stone wrote: > The first thing that I'd like to see is (in kgdb): > > set $td=(struct thread)0xfffff8002abeb000 > tid $td->td_tid > bt > > That will show us the backtrace of the thread that was blocked for so long. Make that: set $td=(struct thread *)0xfffff8002abeb000 tid $td->td_tid bt Eric From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 13:53:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79BD2D55 for ; Tue, 19 Aug 2014 13:53:56 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 464EE31B3 for ; Tue, 19 Aug 2014 13:53:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=+M/qoHfnEqnZZQHCMLi+c32aF+BKp9yD8m/SFUehnKo=; b=D6xwO1bWCov+7MBLu88qpu7pinOR3Hw28boUr+46Q8vvH9a0NQm5ErjhIhrQSr3DMKc59GnjfoAZkm0pq2K0XRMWC9Ox+Yb1AYgFibCoaWn0oUk6zxyfF/Q6BXp/9cqyK6uUqZQqNontX1dXopxbbWzY8wcN/gelRsa97kraWwg=; Received: from localhost.lerctr.org ([127.0.0.1]:51740 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XJjrE-000397-Qz; Tue, 19 Aug 2014 08:53:54 -0500 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 19 Aug 2014 08:53:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 Aug 2014 08:53:52 -0500 From: Larry Rosenman To: Eric van Gyzen Subject: Re: DEADLKRES crash In-Reply-To: <53F35449.9050608@vangyzen.net> References: <20140818152138.GA3481@borg.lerctr.org> <53F35449.9050608@vangyzen.net> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.6 (---) X-LERCTR-Spam-Score: -3.6 (---) X-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 X-LERCTR-Spam-Report: SpamScore (-3.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668 Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:53:56 -0000 On 2014-08-19 08:42, Eric van Gyzen wrote: > On 08/18/2014 16:45, Ryan Stone wrote: >> The first thing that I'd like to see is (in kgdb): >> >> set $td=(struct thread)0xfffff8002abeb000 >> tid $td->td_tid >> bt >> >> That will show us the backtrace of the thread that was blocked for so >> long. > > Make that: > > set $td=(struct thread *)0xfffff8002abeb000 > tid $td->td_tid > bt > > > Eric #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) set $td=(struct thread *)0xfffff8002abeb000 Current language: auto; currently minimal (kgdb) tid $td->td_tid [Switching to thread 469 (Thread 100681)]#0 sched_switch ( td=0xfffff8002abeb000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1931 1931 cpuid = PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=0xfffff8002abeb000, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1931 #1 0xffffffff80a107d9 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:493 #2 0xffffffff80a4c442 in sleepq_switch (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:552 #3 0xffffffff80a4c2a3 in sleepq_wait (wchan=0xfffff80070a4dd50, pri=96) at /usr/src/sys/kern/subr_sleepqueue.c:631 #4 0xffffffff809eb1fa in sleeplk (lk=, flags=, ilk=, wmesg=, pri=, timo=) at /usr/src/sys/kern/kern_lock.c:225 #5 0xffffffff809eaa06 in __lockmgr_args (lk=0xfffff80070a4dd50, flags=, ilk=0xfffff80070a4dd80, wmesg=, pri=, timo=) at /usr/src/sys/kern/kern_lock.c:931 #6 0xffffffff8092e092 in nfs_lock1 (ap=) at lockmgr.h:97 #7 0xffffffff80f2d57c in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2082 #8 0xffffffff80abd22a in _vn_lock (vp=0xfffff80070a4dce8, flags=, file=0xffffffff8110db88 "/usr/src/sys/kern/vfs_subr.c", line=2137) at vnode_if.h:859 #9 0xffffffff80aad4e7 in vget (vp=0xfffff80070a4dce8, flags=524544, ---Type to continue, or q to quit--- td=0xfffff8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137 #10 0xffffffff80aa1491 in vfs_hash_get (mp=0xfffff8002aa1e990, hash=1741450670, flags=, td=0xfffff8002abeb000, vpp=0xfffffe100c75c670, fn=0xffffffff80935820 ) at /usr/src/sys/kern/vfs_hash.c:88 #11 0xffffffff809314bd in ncl_nget (mntp=0xfffff8002aa1e990, fhp=0xfffff80070ccf4a4 "\001", fhsize=12, npp=0xfffffe100c75c6e0, lkflags=) at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114 #12 0xffffffff809340fd in nfs_statfs (mp=0xfffff8002aa1e990, sbp=0xfffff8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops.c:288 #13 0xffffffff80aa7ade in __vfs_statfs (mp=0x0, sbp=0xfffff8002aa1ea48) at /usr/src/sys/kern/vfs_mount.c:1706 #14 0xffffffff80ab4f5e in kern_getfsstat (td=0xfffff8002abeb000, buf=, bufsize=, bufseg=UIO_USERSPACE, flags=) at /usr/src/sys/kern/vfs_syscalls.c:511 #15 0xffffffff80e1625a in amd64_syscall (td=0xfffff8002abeb000, traced=0) at subr_syscall.c:133 #16 0xffffffff80df760b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #17 0x00000008010fc83a in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 14:15:08 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D28D22E; Tue, 19 Aug 2014 14:15:08 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 C944933D8; Tue, 19 Aug 2014 14:15:07 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s7JEF3Dk000211; Tue, 19 Aug 2014 16:15:03 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 111EF374D; Tue, 19 Aug 2014 16:15:03 +0200 (CEST) Message-ID: <53F35BE6.9010905@omnilan.de> Date: Tue, 19 Aug 2014 16:15:02 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Eric van Gyzen Subject: Re: nscd not caching References: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> <2295097.hWnAh3kd1o@overcee.wemm.org> <53F34DA3.70609@omnilan.de> <53F35390.2060503@vangyzen.net> In-Reply-To: <53F35390.2060503@vangyzen.net> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig948005350160D269C1B3BD93" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 19 Aug 2014 16:15:05 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "O. Hartmann" , freebsd-current@freebsd.org, "Eggert, Lars" , "current@freebsd.org" , Peter Wemm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:15:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig948005350160D269C1B3BD93 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Eric van Gyzen's Nachricht vom 19.08.2014 15:39 (localtime):= > On 08/19/2014 09:14, Harald Schmalzbauer wrote: >> =85 >>> At least that's what we found in the freebsd.org cluster. nss-pam-ld= apd was=20 >>> two or three orders of magnitude more usable and got rid of nscd in t= he=20 >>> process. >>> >>> For us, nscd "worked", but it just didn't save much effort because it= was a=20 >>> per-uid cache. ie: if "jkh" had just caused a ldap search, and "pete= r"=20 >>> repeated it, it had to be done again from scratch. >>> >>> The downside for nss-pam-ldapd was that it uses a non-extensible wire= protocol=20 >>> and didn't have room for bsd-style login classes. >> This exactly refelcts my experiences too, which is why I'm wondering i= f >> net/nss-pam-ldapd is a serious base candidate. >> When nscd showed up (arround 7.0-Release if I remember correctly), it >> was a big and highly appreciated improovement for me, reducing >> interactivity lags of gnome e.g. by at least a factor of 4 for usual >> desktop user tasks when user database was LDAP driven. >> At that time there were rumors that FreeBSD needs LDAP user-database >> support, but with the glitches of net/nss_ldap, it seemed that there's= >> no ready-to-implement solution at that time. >> Things changed completely with net/nss-pam-ldapd. Haven't had any >> negative experiences with single-LDAP backend networks. Haven't had bi= g >> environments yet either, but I think it's time to think about >> base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess= >> it won't get into base, but it was a great template, is it? > +1 for nss-pam-ldapd. We were using nss_ldap+pam_ldap, but switched to= > nss-pam-ldapd. It's much faster and very reliable. We have several > multi-user FreeBSD systems (build servers, doing lots of lookups), > dozens of concurrent users and hundreds of total users, and Active > Directory servers. > > The way nss_ldap links the LDAP libraries into every process is not jus= t > inefficient: it can be fatal. Thunderbird includes (or formerly > included?) its own private LDAP libraries. These conflicted with those= > used by nss_ldap, so that Thunderbird would often crash. I don't know > if this is still a problem, but it's not /my/ problem anymore. > > As for the base system, "pkg install nss-pam-ldapd" is embarrassingly > easy and /much/ easier than adding to the base system. 'pkg install' is incredibly convenient these days, for sure, but in my world, hosts that don't need internet acces don't have internet access (4 out of 5). To make things worse, nfs exports aren't root-mapped (other than the default nobody:nobody), so I quiet often have the case that I have to provide net/nss-pam-ldapd via ISO-9660 image (for VMguests) or CD-media. That's not so convenient. Another limitation of 'pkg install' is that I can't influence what to install. Sometimes I want nss_ldap without pam_ldap. Therefore I'd need a compiler (somthing my production machines don't have) and ports, which in my case can't be fetched from internet nor from the NFS server (the latter has to be entered as LDAP user=85) That's why I'd love to see base system LDAP support =96 I think it's very= important to be able to setup a network computer in networks, which aren't interconnected with other networks/internet; these days more important ever since possible=85 -Harry --------------enig948005350160D269C1B3BD93 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.18 (FreeBSD) iEYEARECAAYFAlPzW+YACgkQLDqVQ9VXb8iwSQCbBNenmFrJ9ukNGGqYCkqu4Mkx sT0AoJ8rPIEvmHQc4XpF63EtBQmN4/eJ =Cq/L -----END PGP SIGNATURE----- --------------enig948005350160D269C1B3BD93-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 14:34:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D7D2623 for ; Tue, 19 Aug 2014 14:34:56 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 1AC1A35BF for ; Tue, 19 Aug 2014 14:34:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7JEYtKD049011 for ; Tue, 19 Aug 2014 14:34:55 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7JEYtrW049010 for freebsd-current@freebsd.org; Tue, 19 Aug 2014 14:34:55 GMT (envelope-from bdrewery) Received: (qmail 9440 invoked from network); 19 Aug 2014 09:34:51 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Aug 2014 09:34:51 -0500 Message-ID: <53F36089.3060102@FreeBSD.org> Date: Tue, 19 Aug 2014 09:34:49 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Larry Rosenman , Eric van Gyzen Subject: Re: DEADLKRES crash References: <20140818152138.GA3481@borg.lerctr.org> <53F35449.9050608@vangyzen.net> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf" Cc: FreeBSD Current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:34:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/19/2014 8:53 AM, Larry Rosenman wrote: > On 2014-08-19 08:42, Eric van Gyzen wrote: >> On 08/18/2014 16:45, Ryan Stone wrote: >>> The first thing that I'd like to see is (in kgdb): >>> >>> set $td=3D(struct thread)0xfffff8002abeb000 >>> tid $td->td_tid >>> bt >>> >>> That will show us the backtrace of the thread that was blocked for so= >>> long. >> >> Make that: >> >> set $td=3D(struct thread *)0xfffff8002abeb000 >> tid $td->td_tid >> bt >> >> >> Eric > #0 doadump (textdump=3D1) at pcpu.h:219 > 219 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) set $td=3D(struct thread *)0xfffff8002abeb000 > Current language: auto; currently minimal > (kgdb) tid $td->td_tid > [Switching to thread 469 (Thread 100681)]#0 sched_switch ( > td=3D0xfffff8002abeb000, newtd=3D, > flags=3D) at /usr/src/sys/kern/sched_ule.c:193= 1 > 1931 cpuid =3D PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=3D0xfffff8002abeb000, newtd=3D, > flags=3D) at /usr/src/sys/kern/sched_ule.c:193= 1 > #1 0xffffffff80a107d9 in mi_switch (flags=3D260, newtd=3D0x0) > at /usr/src/sys/kern/kern_synch.c:493 > #2 0xffffffff80a4c442 in sleepq_switch (wchan=3D,= > pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c= :552 > #3 0xffffffff80a4c2a3 in sleepq_wait (wchan=3D0xfffff80070a4dd50, pri=3D= 96) > at /usr/src/sys/kern/subr_sleepqueue.c:631 > #4 0xffffffff809eb1fa in sleeplk (lk=3D, > flags=3D, ilk=3D, > wmesg=3D, pri=3D, > timo=3D) at /usr/src/sys/kern/kern_lock.c:225 > #5 0xffffffff809eaa06 in __lockmgr_args (lk=3D0xfffff80070a4dd50, > flags=3D, ilk=3D0xfffff80070a4dd80, > wmesg=3D, pri=3D, > timo=3D) at /usr/src/sys/kern/kern_lock.c:931 > #6 0xffffffff8092e092 in nfs_lock1 (ap=3D) at > lockmgr.h:97 > #7 0xffffffff80f2d57c in VOP_LOCK1_APV (vop=3D, > a=3D) at vnode_if.c:2082 > #8 0xffffffff80abd22a in _vn_lock (vp=3D0xfffff80070a4dce8, > flags=3D, > file=3D0xffffffff8110db88 "/usr/src/sys/kern/vfs_subr.c", line=3D21= 37) > at vnode_if.h:859 > #9 0xffffffff80aad4e7 in vget (vp=3D0xfffff80070a4dce8, flags=3D524544= , > ---Type to continue, or q to quit--- > td=3D0xfffff8002abeb000) at /usr/src/sys/kern/vfs_subr.c:2137 > #10 0xffffffff80aa1491 in vfs_hash_get (mp=3D0xfffff8002aa1e990, > hash=3D1741450670, flags=3D, td=3D0xfffff8002a= beb000, > vpp=3D0xfffffe100c75c670, fn=3D0xffffffff80935820 ) > at /usr/src/sys/kern/vfs_hash.c:88 > #11 0xffffffff809314bd in ncl_nget (mntp=3D0xfffff8002aa1e990, > fhp=3D0xfffff80070ccf4a4 "\001", fhsize=3D12, npp=3D0xfffffe100c75c= 6e0, > lkflags=3D) > at /usr/src/sys/fs/nfsclient/nfs_clnode.c:114 > #12 0xffffffff809340fd in nfs_statfs (mp=3D0xfffff8002aa1e990, > sbp=3D0xfffff8002aa1ea48) at /usr/src/sys/fs/nfsclient/nfs_clvfsops= =2Ec:288 > #13 0xffffffff80aa7ade in __vfs_statfs (mp=3D0x0, sbp=3D0xfffff8002aa1e= a48) > at /usr/src/sys/kern/vfs_mount.c:1706 > #14 0xffffffff80ab4f5e in kern_getfsstat (td=3D0xfffff8002abeb000, > buf=3D, bufsize=3D, > bufseg=3DUIO_USERSPACE, flags=3D) > at /usr/src/sys/kern/vfs_syscalls.c:511 > #15 0xffffffff80e1625a in amd64_syscall (td=3D0xfffff8002abeb000, trace= d=3D0) > at subr_syscall.c:133 > #16 0xffffffff80df760b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:390 > #17 0x00000008010fc83a in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Looks like the one I hit recently as well: http://lists.freebsd.org/pipermail/freebsd-fs/2014-July/019843.html This lock should probably be excluded from the DEADLKRES. I have not had time to follow-up on it, but it's a trivial thing to add it to the list. --=20 Regards, Bryan Drewery --hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT82CJAAoJEDXXcbtuRpfP1TUH/1I6fn3LoaGLzKJil0y0BHfl /sf2Eh3HLD4uyPK5FKlhCuFbPOtEutI4/Wrt4HaBDdsvVb9ER0HYRaCabCBsamMI siH2Vp44bcYGh2J0UX2r6pkAyvvIx6UfGxEf41rCWyh0h1h+IslHrht79ag/CQW8 C3e0u9askIVkh8t/1eVJnI8bEEVZ9xL+DTET0OGQa4E39Ess689hjIaVeyLyNJTH 0+kDPUXz2JewpLwsRt0hGTBQI4nW+cdG/64Pv/WHrYq8rpEy0kASryNPIL7xFzFc FxPrdthXz5Yb1iFv/B6gf1TuJe3vthfMvRFsQ0kveClBlF4267p3AMSsofb8dZE= =NdnZ -----END PGP SIGNATURE----- --hdBSpUIBSRdCnQnwsbc6bvL1lC6uTbWqf-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 15:43:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 545EF759 for ; Tue, 19 Aug 2014 15:43:28 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 319993D37 for ; Tue, 19 Aug 2014 15:43:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7JFhSTx071297 for ; Tue, 19 Aug 2014 15:43:28 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7JFhRdN071296 for freebsd-current@freebsd.org; Tue, 19 Aug 2014 15:43:27 GMT (envelope-from bdrewery) Received: (qmail 5134 invoked from network); 19 Aug 2014 10:43:25 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Aug 2014 10:43:25 -0500 Message-ID: <53F3709B.6080608@FreeBSD.org> Date: Tue, 19 Aug 2014 10:43:23 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: panic: pmap active 0xfffff8002d2ae9f8 References: <53EB868A.1060406@FreeBSD.org> <295b3f285bffb20608153322d259224a@shatow.net> <20140818084142.GM2737@kib.kiev.ua> In-Reply-To: <20140818084142.GM2737@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tR9PbQRtktNbjG49S8x8k4kPxIR37p42d" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:43:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tR9PbQRtktNbjG49S8x8k4kPxIR37p42d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/18/2014 3:41 AM, Konstantin Belousov wrote: > On Fri, Aug 15, 2014 at 10:38:25PM -0500, Bryan Drewery wrote: >> On 2014-08-13 10:38, Bryan Drewery wrote: >>> On 6/24/2014 4:28 PM, Craig Rodrigues wrote: >>>> Hi, >>>> >>>> I have a system running CURRENT at r266925 from May 31. >>>> >>>> While doing some software builds using poudriere, the system >>>> panicked. Unfortunately this system was not configured with >>>> swap space, so I cannot do a kernel dump. >>>> >>>> The system is currently at the ddb prompt. >>>> Here is the backtrace: >>>> >>>> >>>> Here is the backtrace from ddb: >>>> >>>> panic: pmap active 0xfffff8002d2ae9f8 >>>> cpuid =3D 5 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfffffe183958a7d0 >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe183958a880 >>>> vpanic() at vpanic+0x126/frame 0xfffffe183958a8c0 >>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe183958a930 >>>> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe183958aa= 20 >>>> vmspace_exit() at vmspace_exit+0xa1/frame 0xfffffe183958aa60 >>>> exit1() at exit1+0x541/frame 0xfffffe183958aad0 >>>> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe183958aae0 >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe183958abf0 >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe183958abf0 >>>> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp= - >>>> 0x7ffffffe3e8, rbp =3D 0x7ffffffffe400 >>>> KDB: enter: panic >>>> [ thread pid 94762 tid 101570 ] >>>> Stopped at kdb_enter+0x3e: movq $0.kdb_why >>>> db> >>>> >>>> >>>> Is this a known problem? >>>> Are there other commands I should type at the ddb prompt? >>>> -- >>>> Craig >>> >>> I have run into this as well on r269147: >>> >>>> panic: pmap active 0xfffff80035f422f8 >>>> cpuid =3D 10 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame=20 >>>> 0xfffffe124852b7d0 >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124852b880 >>>> vpanic() at vpanic+0x126/frame 0xfffffe124852b8c0 >>>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe124852b930 >>>> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe124852ba= 20 >>>> vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe124852ba60 >>>> exit1() at exit1+0x541/frame 0xfffffe124852bad0 >>>> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe124852bae0 >>>> ia32_syscall() at ia32_syscall+0x270/frame 0xfffffe124852bbf0 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfffffe124852bbf0= >>>> --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip =3D 0x297e386f, rs= p =3D=20 >>>> 0xffffd7ac, rbp =3D 0xffffd7b8 --- >>>> KDB: enter: panic >>>> [ thread pid 85335 tid 101517 ] >>>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >>>> db> call doadump >>>> >>>> Dump failed. Partition too small. >>>> =3D 0 >> >> Got it again on recent r269950 while building with poudriere: >> >> panic: pmap active 0xfffff8113c3c6d78 >> cpuid =3D 10 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame=20 >> 0xfffffe1248acc7d0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1248acc880 >> vpanic() at vpanic+0x126/frame 0xfffffe1248acc8c0 >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1248acc930 >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe1248acca20= >> vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe1248acca60 >> exit1() at exit1+0x541/frame 0xfffffe1248accad0 >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe1248accae0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1248accbf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1248accbf0 >> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip =3D 0x80387fadc, rsp= =3D=20 >> 0x7fffffffd4e8, rbp =3D 0x7fffffffd5a0 --- >> KDB: enter: panic >> [ thread pid 84433 tid 101503 ] >> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> db> call doadump >> >> Dump failed. Partition too small. >> =3D 0 >=20 > The interesting information is pmap->pm_active, for pmap address report= ed > by the panic. Easiest way to get the active mask is using kgdb on vmco= re. >=20 Ok. I'll add in a larger dedicated dump device to cover the memory size blocking debugging my recent panics. --=20 Regards, Bryan Drewery --tR9PbQRtktNbjG49S8x8k4kPxIR37p42d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT83CbAAoJEDXXcbtuRpfPASEH/05cdr4zIWMCdj+aBf+zHSBT 9rxQ9ti1BM7Sys4xN0dG2K0PXHv5XM6ZueYPoxX/ZOBANr7RLmykVMDz5djrFrLz AGBH+XDrNCGF6idN7Gt4L4ORGV0Z58lmYabZQ3cvdu5TDVQmpgjXTBWFmQUt+aeT pjVuht+ATKDTpP7/EvJpWt85qNecINOUOZ5CNZWMi8k+4viowanUoivp84omwYW3 P9qkL/v2sw7t0A45kGu0pe89kJ0J4j8oe0wdj8/R9GUFS5Mh/bUBBVHhZwIFUDjN alpERm3oNJu/U1RgA5afJ9g1tIGusTZwe6RQ7FeqXULVPPP/44hAOXk6q4plqUI= =4TiN -----END PGP SIGNATURE----- --tR9PbQRtktNbjG49S8x8k4kPxIR37p42d-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 16:28:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6A9CB9B; Tue, 19 Aug 2014 16:28:48 +0000 (UTC) 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 84D8932AC; Tue, 19 Aug 2014 16:28:48 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XJmH8-000OPr-8h; Tue, 19 Aug 2014 18:28:46 +0200 Message-ID: <53F37B2D.3070807@FreeBSD.org> Date: Tue, 19 Aug 2014 18:28:29 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> In-Reply-To: <53F30DF3.1090301@dumbbell.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="puodK99i3luKTF3wpENEnasbW8lGc7WlE" Cc: Aleksandr Rybalko , Ed Maste , Nathan Whitehorn , Adrian Chadd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:28:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --puodK99i3luKTF3wpENEnasbW8lGc7WlE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19.08.2014 10:42, Jean-S=E9bastien P=E9dron wrote: > On 16.08.2014 01:51, Nathan Whitehorn wrote: >> It also has bad effects on boot time. My desktop takes something like = 3 >> times as long to boot after r269471. If it can't be fixed quickly, it >> needs to be reverted. >=20 > Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an "if (bitblt_text !=3D NULL)" check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? --=20 Jean-S=E9bastien P=E9dron --puodK99i3luKTF3wpENEnasbW8lGc7WlE 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 iQIcBAEBAgAGBQJT83s9AAoJEDnpl2Gl/ZTMokUQANVY9pDdQpi1MYtdWa17IC9A XoaFRdcywQal/UiEpwTzt6eNEHPpVfM6X+mfe8eNNlKjCS8RYlUlOTqOPQuBOc33 kqnLta2k8dp4KGjHFSlwah5JJpA0CHW04CHz38pxSX1XzDd4/wox7wchoJAcNYf9 3pW9kQTWTg6kM9f1jhMDZAueLOXer1/rLjW4dq2gc/O+NGQeEGWDeQ1PVLS9uyfJ xRYwiRi6Z7Zj5BgNemnLWXgdPXN6bjw0CbyxalFhQ51y0/D5m5UCeCbD79zgcfN4 9MgcLHCj1EdLT8Puh3IWPeUOunZ03nWIEIIs06ESPc+6dWu6VZowb4E9VG4eL5al nTYD+egJ5JxYIU57JBP+oUk4gtISpdnxbmhq89/rBvcXuhlcWLLQovEbcLULtA37 rQ76zTIM9HAfr/M9wua7s+gaiOFlxdMYd+rBXtJyjjVpiUlHGui/Am/clorRLq9c XQSXkJC1DwVxMg9V0cKtbXLUp/edsTs+oM+UbEbx8CWJ1JcqzgSoAyB7Om6d8CZ+ FfsVGi9mP7jE2z0uYWQMW0oqUmtlolU0O5sd7IsENb3bEBSlTJHXHUDVF3uJilqH jkXGW9sg4KhUdmLaQUjayZOlaRcJvaEGGUUnq1gCFtWYKqg97boueovv+8kR7YvF 8IUsu98T0JFqHH9KPc1m =f8y7 -----END PGP SIGNATURE----- --puodK99i3luKTF3wpENEnasbW8lGc7WlE-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 17:47:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34BAF1F1 for ; Tue, 19 Aug 2014 17:47:04 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 1890A3BC7 for ; Tue, 19 Aug 2014 17:47:03 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7JHksZp003834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Aug 2014 10:46:55 -0700 Message-ID: <53F38D8E.8090605@freebsd.org> Date: Tue, 19 Aug 2014 10:46:54 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> In-Reply-To: <53F37B2D.3070807@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVamYQjmcu1OTrxF8JSaermBn8T59JipWURxXoVSKtV3nZw+s6MbgssjjLXhU6OMj6LYh2uxV0OPqy7Udkk4FVtY877B/iXnGDk= X-Sonic-ID: C;np2/zsgn5BGIes2354E5FQ== M;MkAkz8gn5BGIes2354E5FQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:47:04 -0000 On 08/19/14 09:28, Jean-Sbastien Pdron wrote: > On 19.08.2014 10:42, Jean-Sbastien Pdron wrote: >> On 16.08.2014 01:51, Nathan Whitehorn wrote: >>> It also has bad effects on boot time. My desktop takes something like 3 >>> times as long to boot after r269471. If it can't be fixed quickly, it >>> needs to be reverted. >> Just a quick note: I'm working on an update to vt_vga. > Hello! > > Here's a first version of the patch I was talking about: > https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch Thanks! > What's new/fixed: > > o vt_vga introduces a new callback, vd_bitblt_text_t, which takes > as argument the text buffer, the dirty area, the font and the > cursor (position, map, colors). With all this information at > hand, it can redraw the dirty area with almost no read from the > video memory. This greatly improves the performance. The > implementation is quite naive and I put a lot of comments. This > could probably be simplfied/improved. > > The cursor is drawn at the same time than the text: this avoids > flickering of the mouse pointer. > > The patch reads from the video memory only when the byte to > write uses more than 2 colors (fg/bg). But this only happens > with colored text around the cursor or with fonts who's width > isn't a multiple of 8. Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. -Nathan > o In vt_flush(), handle the cursor position before getting the > dirty area. This fixes a bug where, if we move the cursor too > fast, its new location is outside the marked area and it > disappears from the screen. > > While here, mark the new position of the cursor as dirty, not > only the old one. > > For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* > VDF_MOUSECURSOR must be set! Before, only the former was checked > when deciding if the cursor position should be marked as dirty. > > Finally, if the cursor didn't move, don't mark its position as > dirty. > > Before, these two problems caused major redraw of a large part > of the screen for nothing, due to a mouse pointer location of > [0;0] (even if disabled) and its position always marked as dirty. > > o When the mouse state is changed, mark its position as dirty. > > o The flush timer is paused during a window switch. In the case of > vt_vga, vga_initialize() is called and it messes with VGA > registers and the video memory. If vt_flush() is triggered at > the same time, unexpected data are displayed. This is fixed, > though, there's still a annoying flickering, because the sync > signal is temporarily stopped during vga_initialize(). > > o The patch includes another non-related patch, which tries to > stabilize the refresh rate. Currently, we schedule the next > redraw in 40 ms (25 Hz), but that doesn't count for the time > taken to redraw. > > o Change how the mouse is enabled/disabled/shown/hidden. Now, the > GETLEVEL and GETMODE ioctls don't touch this. Everything goes > through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. > > Known issues: > > o Instead of having an "if (bitblt_text != NULL)" check in > vt_flush(), I'll add a generic bitblt_text callback which > implements the old code, so that other drivers can be changed > incrementally. > > o In vt_vga, the screen flickers during a window switch, because > it stops the sync signal and zeroes the memory. It would be nice > to avoid that. > > o Several issues when the font is changed: > 1. The offset to center the text area is global, not per > window. Therefore other window are not centered anymore. > 2. There's a bug with my patch, where other windows have the > top-left letter wrongly shifted. > 3. When the text area changes (compared to the whole screen), > there's garbage in the borders. > 4. The text cursor (the square) may be broken on other windows. > > o The mouse pointer is somtimes not erased during a move. > > o The text square cursor handling in vt_vga could be improved: > colors are just reversed, we shouldn't change the fg/bg colors, > just write a 0x00 pattern instead. > > o The vt_flush() timer could maybe be stopped when there's nothing > to draw. No need to wakeup a core for that. > > Any comments? > From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 19:02:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B0EFBE for ; Tue, 19 Aug 2014 19:02:30 +0000 (UTC) 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 BEBD2346E for ; Tue, 19 Aug 2014 19:02:29 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XJofr-0000LR-S0 for freebsd-current@freebsd.org; Tue, 19 Aug 2014 21:02:28 +0200 Message-ID: <53F39F3D.9010104@FreeBSD.org> Date: Tue, 19 Aug 2014 21:02:21 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> In-Reply-To: <53F38D8E.8090605@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0fIubDe0HAdUSj8MTWbQH5HohUs4Q8MbP" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:02:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0fIubDe0HAdUSj8MTWbQH5HohUs4Q8MbP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 19.08.2014 19:46, Nathan Whitehorn wrote: > On 08/19/14 09:28, Jean-S=E9bastien P=E9dron wrote: >> o vt_vga introduces a new callback, vd_bitblt_text_t, which take= s >> as argument the text buffer, the dirty area, the font and the >> cursor (position, map, colors). > > Why is this necessary? I'd really prefer to avoid complicating this API= =2E > One of the great things about writing newcons drivers is that there is > basically only one function you need to implement. If the current API > does not provide enough information to do this efficiently, I'd much > rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several "blocks" of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. --=20 Jean-S=E9bastien P=E9dron --0fIubDe0HAdUSj8MTWbQH5HohUs4Q8MbP 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 iQJ8BAEBCgBmBQJT859DXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMgw8QAIWZf3jQwF3/MI4aR3V3jwlD nCXjftGehdZOStr/hju0a5dAMtNkgfuPSCBR7A/RfMGp2S/Kq8jue/p2a77fWrE5 UjtgwnIS3TWxbek1p8+KaVz+zTCAaVRYoMTlOs8HNERzUuV1xi625R2V0VIoeDNA 0uIqg62N9waBVpFqTmWXXfmWdSU12G7sHDZkWHzuE7/I1vtom707KOgYAIdqJ/l+ adxmkizkSGUSmWP7Vm3k+GTl3l7zg+kqgBy0ov7N3v8YX/jy4UIrBCYSdJlnEK9W 4SBiktEopu0BIfUuFTeBu+L5GmJgfI7hOPkFCm4GHhdbH9s2GsQJESjNARwp/+fZ u5ju+qluaanxYiNS4Qy9Lacxkd0iq4hxgtSlofXvXIaRpgzAlrnktW3MQU6Ur8iL XBXx9rqf8u1QXD3HNyXxILfQnIpxsFLgRfkgpN7GeXK+pvAsNp6P5CLThy21Offs l2dJmb3jtkeWJuWM7u3z9GdVSf1AttUQcQI03ZonqKdspnmxI3delIGzyQq+XZza z8QcoWr1pjOm9ZThTp2W/0/b1NqEqrU6Gj+a1acdLnLwncBy4DfikDLNWNC9aXxU BxNoH5VdjhHbyW4ZUdB3G9Ds4SMuNXh1d9Meo6sds10doUaWduYD19H5WhHzw/eO P1wSk2P+MXdxVEJ0JAc7 =OCUa -----END PGP SIGNATURE----- --0fIubDe0HAdUSj8MTWbQH5HohUs4Q8MbP-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 19:20:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 478F8852; Tue, 19 Aug 2014 19:20:02 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA78735B0; Tue, 19 Aug 2014 19:20:01 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id z107so2985755qgd.9 for ; Tue, 19 Aug 2014 12:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l5s3AthSuA8T2boYrR4JbRs84nkszsFlj7cAflTXXPc=; b=KxeS1F6rDqZK0G/e2CHzSYRMfgcujfN3729UV3XdqS3r00wTclqgYU+qP0qpIVUHhZ fAu3V8bAC/RT1L8q1eSjJyW5ZI8N91kO4UoQSVoip9WKbMMr3Om/xPmLZ+PF7wsBr31R p/fmTZHo+D5HQBbMRCtHf/c6y5GdeFvGnczf4qywH7v1QZvmFGZk3N2bWCY+E8vtDTHx ictAC/H/DuYAgVK51lQKpXCsh3QnFIz8GcpbNfjyEsy28G0HHeZF0GOGtwGBChhXuOnN Ol3diTAqmtstMdB++FJ27/sc7T14CIOqoxAQzYYwTRWvcn1mC1H1Rm02L+0zWxbNBk8X IBNw== MIME-Version: 1.0 X-Received: by 10.140.27.144 with SMTP id 16mr65314014qgx.18.1408476000135; Tue, 19 Aug 2014 12:20:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 19 Aug 2014 12:20:00 -0700 (PDT) In-Reply-To: <53F39F3D.9010104@FreeBSD.org> References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> <53F39F3D.9010104@FreeBSD.org> Date: Tue, 19 Aug 2014 12:20:00 -0700 X-Google-Sender-Auth: CQN-1WkoinELlK7_pwEirzn7Cus Message-ID: Subject: Re: r269471 make unusable VT console From: Adrian Chadd To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:20:02 -0000 Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? -a From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 19:40:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC84FFC8; Tue, 19 Aug 2014 19:40:36 +0000 (UTC) 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 9ACC637A1; Tue, 19 Aug 2014 19:40:36 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XJpGk-0000nF-Nm; Tue, 19 Aug 2014 21:40:34 +0200 Message-ID: <53F3A82D.4090000@FreeBSD.org> Date: Tue, 19 Aug 2014 21:40:29 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> <53F39F3D.9010104@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2gcbH8W3nQwj7m1e4BunfJCxnQ3KvkPrV" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:40:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2gcbH8W3nQwj7m1e4BunfJCxnQ3KvkPrV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19.08.2014 21:20, Adrian Chadd wrote: > Hey, this is cool! >=20 > So hm, why are you still doing any reading? Don't you now have all the > information you need to write out the font and cursor information for > each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. 2. Stay in Write Mode 3, do a read/write for each colors. The first solution has a constant time of execution. The second one depends on the number of colors. In the end, I guess both solutions are expensive, but hopefully are rarely used. --=20 Jean-S=C3=A9bastien P=C3=A9dron --2gcbH8W3nQwj7m1e4BunfJCxnQ3KvkPrV 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 iQJ8BAEBCgBmBQJT86gyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTM5LAP/AqyzDdkOXVIDe0jAhiUi3Fr kevuXsLWu/N+0mhqznsryO4pqgohkexcUdwI/qDJ/YIU7k1kn8lvub6wFndTh5H5 fiZoZoXFLTAl33XoJbOpu+pQ4vnmY4gf/HKYmcJ/MOiGcQof9GI4g/GG6BLZDZi0 JVcvL3X0DJWNKKI+GILsY9xQ+FxglJefU3tc/TJ/oJAs+UjyYNs557zGeF0BGDEQ KI37RBQea0pwF+mrdXiJ/xUzL9l5LQ888t4Qqp+rQRNSQRh8ATwWzlj368RtynMq /NgICzV9BWOGKlQ9JaVCyDTMCipQFBjhx1ZuiCk/NHQzkg2b1zdIOxV1rxBctVh0 lCMUKizRW9ur2uZnfakMUqP80a1nfYBRPUm4LoYHaMKXyw+ceDNbXCR6CMLKSSj0 BsPAnSz37fLzX9bVgtG7cmxlZ0kPmSFe2ItJbcEx6QP4MnWoYtYuFUw0C35Ypdtp /npUImSwQojCq2/T8eFexh9AYRxmc06esB9FGYfnpAmcaKLWEZ6Ki77C9kbZJxud j3owIilqPV0+un+V7ElZs7GYreipjOZVTZTejFuO5E8IGAcWnUJG6bYOeem65cny uQYYDmeGBpYkTFnG36mf4YVLRbTh5X9tIjwwIO0jvfoei4/6xhHlClG8JM6Bu6QX Bwyl9dcg9/9GjPbTWTdP =Vx0q -----END PGP SIGNATURE----- --2gcbH8W3nQwj7m1e4BunfJCxnQ3KvkPrV-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 21:18:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6A11986 for ; Tue, 19 Aug 2014 21:18:19 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 A05E930FF for ; Tue, 19 Aug 2014 21:18:19 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7JLIBHO021109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Aug 2014 14:18:11 -0700 Message-ID: <53F3BF13.7040208@freebsd.org> Date: Tue, 19 Aug 2014 14:18:11 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> <53F39F3D.9010104@FreeBSD.org> In-Reply-To: <53F39F3D.9010104@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVagRxhN2Cv8pUPYNu1gN9PI8/1m2ZcF3PoCkeyOCdISLPNm6Bp0A5vsbyBChUnWlFW1UMLBLoFq8FA3gUH4aZhDiFMlv2HGhDs= X-Sonic-ID: C;3LK7UuYn5BGYoPofoK8kYw== M;2MIJU+Yn5BGYoPofoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:18:19 -0000 On 08/19/14 12:02, Jean-Sbastien Pdron wrote: > On 19.08.2014 19:46, Nathan Whitehorn wrote: >> On 08/19/14 09:28, Jean-Sbastien Pdron wrote: >>> o vt_vga introduces a new callback, vd_bitblt_text_t, which takes >>> as argument the text buffer, the dirty area, the font and the >>> cursor (position, map, colors). >> Why is this necessary? I'd really prefer to avoid complicating this API. >> One of the great things about writing newcons drivers is that there is >> basically only one function you need to implement. If the current API >> does not provide enough information to do this efficiently, I'd much >> rather change it than add new callbacks. > I don't want to have two callbacks for the same feature either, and I'd > like to transition other drivers to this new one. > > The current bitbltchr callback only knows about one character. In the > case of vt_vga, if this character (or the cursor) isn't aligned on > 8-pixels boundaries, it needs to redraw several "blocks" of pixels. With > this character-centric approach, if a block needs a redraw, it'll be > refreshed for the character on its left side, then refreshed again for > the character on its right side. > > The advantage of giving the callback the whole text/area is that it > allows the driver to manipulate the pixels block by block, instead of > character by character. > > The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I > made (especially the cursor handling in vt_flush()). But eventually, the > plan is to convert all drivers to this new callback, if you find the new > API sensible. > That sounds great. There are only a few (3?) discrete implementations of bitbltchr in the tree right now, so the conversion should be easy. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Aug 19 22:36:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34172A43; Tue, 19 Aug 2014 22:36:45 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5216385E; Tue, 19 Aug 2014 22:36:44 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id l6so6922488qcy.5 for ; Tue, 19 Aug 2014 15:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1BUhFBva5G1qWu3A8/KZt9nZJ0J242+2JmJfC9C7cYA=; b=hUE98b01XDKMvCoDXzr3qT5hVIv33IWIOOLWm2h8UB8tsup5t5EjRIIGMcNf/LZuF7 JU+reCa/LlW4SApWGLXL5Wq5qTg4twiPrDO0rxMq5rtkOOV08lnZ3C35iQiTlYbp1uVN AU4qFtBKmwIWD6rC2xhRIlyYiJhgb+uY3Z6c33VosNHlkIzDvMMoPY6Vu4xSM1J8UMzc 1J8+5NqsmQOcaHE/6y014AAJggHSnQVRr82xFHYlnCt2/4GfLh1LMYJJ1QI21E1zmeLm WmtM559g98iV8fN8IkRsLScXZjBHJSLfgxjtngIVAqZ75eD4C4hoiagJnlB99Kry/cmS X5Qw== MIME-Version: 1.0 X-Received: by 10.229.38.3 with SMTP id z3mr71884366qcd.17.1408487804036; Tue, 19 Aug 2014 15:36:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 19 Aug 2014 15:36:43 -0700 (PDT) In-Reply-To: <53F3A82D.4090000@FreeBSD.org> References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F38D8E.8090605@freebsd.org> <53F39F3D.9010104@FreeBSD.org> <53F3A82D.4090000@FreeBSD.org> Date: Tue, 19 Aug 2014 15:36:43 -0700 X-Google-Sender-Auth: eZZpAx8eHQBIQAYzTIUj3xlPnZY Message-ID: Subject: Re: r269471 make unusable VT console From: Adrian Chadd To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 22:36:45 -0000 Hi, On 19 August 2014 12:40, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 19.08.2014 21:20, Adrian Chadd wrote: >> Hey, this is cool! >> >> So hm, why are you still doing any reading? Don't you now have all the >> information you need to write out the font and cursor information for >> each given set of 8 pixels? > > I read a lot about VGA in the past days but I'm new to this interface, > so my reasonning may be wrong. Anyway, here it is: > > To write a group of 8 pixels with only 2 colors, I write a byte using > background color in an offscreen memory, read it back to load it in the > latches, put the foreground color in the Set/Reset register, then write > the character/cursor to its final location in video memory. Because the > background color almost never changes, only one read is made the first > time we load the background color, and then only writes. This is fast. > > If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 > alone. I see two possibilities: > 1. Set Write Mode 0, then for each plane, compute the byte to write > (1 bit out of 4 of each pixel's color), activate one plane, write > the byte (repeat for each plane), restore Write Mode 3 and the > relevant registers. Yup. That's how I've done it in the past. There's no read required and computing that stuff on modern CPUs is really cheap. -a From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 07:34:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F250392; Wed, 20 Aug 2014 07:34:28 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17C67390A; Wed, 20 Aug 2014 07:34:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 373B51FE027; Wed, 20 Aug 2014 09:34:26 +0200 (CEST) Message-ID: <53F44F91.2060006@selasky.org> Date: Wed, 20 Aug 2014 09:34:41 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, FreeBSD Current Subject: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> In-Reply-To: <20140709163146.GA21731@ox> Content-Type: multipart/mixed; boundary="------------080406030702000505070708" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:34:28 -0000 This is a multi-part message in MIME format. --------------080406030702000505070708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware transmit rings has been made independent of the TCP stack. This allows firewall applications to forward traffic into hardware transmit rings aswell, and not only native TCP applications. This should be one more reason to get the feature into the kernel. - A hardware transmit ring basically can have two modes: FIXED-RATE or AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed bytes per second rate. In the automatic mode you can configure a time after which the TX queue must be empty. The hardware driver uses this to configure the actual rate. In automatic mode you can also set an upper and lower transmit rate limit. - The MBUF has got a new field in the packet header: "txringid" - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of the "txringid" field in the mbuf. The current patch [see attachment] should be much simpler and less intrusive than the previous one. Any comments ? --HPS --------------080406030702000505070708 Content-Type: text/x-diff; name="net_ratectl.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="net_ratectl.diff" === sys/net/if.h ================================================================== --- sys/net/if.h (revision 270138) +++ sys/net/if.h (local) @@ -239,6 +239,7 @@ #define IFCAP_RXCSUM_IPV6 0x200000 /* can offload checksum on IPv6 RX */ #define IFCAP_TXCSUM_IPV6 0x400000 /* can offload checksum on IPv6 TX */ #define IFCAP_HWSTATS 0x800000 /* manages counters internally */ +#define IFCAP_HWTXRINGS 0x1000000 /* hardware supports TX rings */ #define IFCAP_HWCSUM_IPV6 (IFCAP_RXCSUM_IPV6 | IFCAP_TXCSUM_IPV6) === sys/netinet/in.c ================================================================== --- sys/netinet/in.c (revision 270138) +++ sys/netinet/in.c (local) @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include @@ -201,9 +202,23 @@ struct in_ifaddr *ia; int error; - if (ifp == NULL) - return (EADDRNOTAVAIL); + if (ifp == NULL) { + struct inpcb *inp; + switch (cmd) { + case SIOCSTXRINGID: + inp = sotoinpcb(so); + if (inp == NULL) + return (EINVAL); + INP_WLOCK(inp); + inp->inp_txringid = *(unsigned *)data; + INP_WUNLOCK(inp); + return (0); + default: + return (EADDRNOTAVAIL); + } + } + /* * Filter out 4 ioctls we implement directly. Forward the rest * to specific functions and ifp->if_ioctl(). === sys/netinet/in_pcb.h ================================================================== --- sys/netinet/in_pcb.h (revision 270138) +++ sys/netinet/in_pcb.h (local) @@ -46,6 +46,7 @@ #ifdef _KERNEL #include #include +#include #include #include #endif @@ -177,7 +178,8 @@ u_char inp_ip_ttl; /* (i) time to live proto */ u_char inp_ip_p; /* (c) protocol proto */ u_char inp_ip_minttl; /* (i) minimum TTL or drop */ - uint32_t inp_flowid; /* (x) flow id / queue id */ + m_flowid_t inp_flowid; /* (x) flow ID */ + m_txringid_t inp_txringid; /* (x) transmit ring ID */ u_int inp_refcount; /* (i) refcount */ void *inp_pspare[5]; /* (x) route caching / general use */ uint32_t inp_flowtype; /* (x) M_HASHTYPE value */ === sys/netinet/in_var.h ================================================================== --- sys/netinet/in_var.h (revision 270138) +++ sys/netinet/in_var.h (local) @@ -33,6 +33,7 @@ #ifndef _NETINET_IN_VAR_H_ #define _NETINET_IN_VAR_H_ +#include #include #include #include @@ -81,6 +82,18 @@ struct sockaddr_in ifra_mask; int ifra_vhid; }; + +struct in_ratectlreq { + char ifreq_name[IFNAMSIZ]; + m_txringid_t tx_ring_id; + uint32_t min_bytes_per_interval; + uint32_t max_bytes_per_interval; + uint32_t micros_per_interval; + uint32_t mode; +#define IN_RATECTLREQ_MODE_FIXED 0 /* min rate = max rate */ +#define IN_RATECTLREQ_MODE_AUTOMATIC 1 /* bounded by min/max */ +}; + /* * Given a pointer to an in_ifaddr (ifaddr), * return a pointer to the addr as a sockaddr_in. === sys/netinet/ip_output.c ================================================================== --- sys/netinet/ip_output.c (revision 270138) +++ sys/netinet/ip_output.c (local) @@ -145,6 +145,7 @@ if (inp != NULL) { INP_LOCK_ASSERT(inp); M_SETFIB(m, inp->inp_inc.inc_fibnum); + m->m_pkthdr.txringid = inp->inp_txringid; if (inp->inp_flags & (INP_HW_FLOWID|INP_SW_FLOWID)) { m->m_pkthdr.flowid = inp->inp_flowid; M_HASHTYPE_SET(m, inp->inp_flowtype); === sys/netinet6/in6.c ================================================================== --- sys/netinet6/in6.c (revision 270138) +++ sys/netinet6/in6.c (local) @@ -235,6 +235,23 @@ int error; u_long ocmd = cmd; + if (ifp == NULL) { + struct inpcb *inp; + + switch (cmd) { + case SIOCSTXRINGID: + inp = sotoinpcb(so); + if (inp == NULL) + return (EINVAL); + INP_WLOCK(inp); + inp->inp_txringid = *(unsigned *)data; + INP_WUNLOCK(inp); + return (0); + default: + break; + } + } + /* * Compat to make pre-10.x ifconfig(8) operable. */ === sys/sys/mbuf.h ================================================================== --- sys/sys/mbuf.h (revision 270138) +++ sys/sys/mbuf.h (local) @@ -114,6 +114,10 @@ void (*m_tag_free)(struct m_tag *); }; +typedef uint32_t m_flowid_t; +typedef uint32_t m_txringid_t; +#define M_TXRINGID_UNDEFINED 0 + /* * Record/packet header in first mbuf of chain; valid only if M_PKTHDR is set. * Size ILP32: 48 @@ -125,7 +129,8 @@ int32_t len; /* total packet length */ /* Layer crossing persistent information. */ - uint32_t flowid; /* packet's 4-tuple system */ + m_flowid_t flowid; /* packet's 4-tuple system */ + m_txringid_t txringid; /* transmit ring ID */ uint64_t csum_flags; /* checksum and offload features */ uint16_t fibnum; /* this packet should use this fib */ uint8_t cosqos; /* class/quality of service */ === sys/sys/sockio.h ================================================================== --- sys/sys/sockio.h (revision 270138) +++ sys/sys/sockio.h (local) @@ -43,6 +43,7 @@ #define SIOCATMARK _IOR('s', 7, int) /* at oob mark? */ #define SIOCSPGRP _IOW('s', 8, int) /* set process group */ #define SIOCGPGRP _IOR('s', 9, int) /* get process group */ +#define SIOCSTXRINGID _IOW('s', 10, unsigned) /* set transmit ring ID */ /* SIOCADDRT _IOW('r', 10, struct ortentry) 4.3BSD */ /* SIOCDELRT _IOW('r', 11, struct ortentry) 4.3BSD */ @@ -128,4 +129,9 @@ #define SIOCDIFGROUP _IOW('i', 137, struct ifgroupreq) /* delete ifgroup */ #define SIOCGIFGMEMB _IOWR('i', 138, struct ifgroupreq) /* get members */ +#define SIOCARATECTL _IOWR('i', 139, struct in_ratectlreq) /* add new new rate control HW ring */ +#define SIOCSRATECTL _IOWR('i', 140, struct in_ratectlreq) /* set parameters for existing HW ring */ +#define SIOCGRATECTL _IOWR('i', 141, struct in_ratectlreq) /* get parameters for existing HW ring */ +#define SIOCDRATECTL _IOW('i', 142, struct in_ratectlreq) /* delete existing HW ring */ + #endif /* !_SYS_SOCKIO_H_ */ --------------080406030702000505070708-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 07:50:36 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17E5DAB4; Wed, 20 Aug 2014 07:50:36 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) (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 A8DFE3A34; Wed, 20 Aug 2014 07:50:35 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s7K7YtIu086196; Wed, 20 Aug 2014 08:34:55 +0100 (BST) (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id s7K7Ysmm086195; Wed, 20 Aug 2014 08:34:54 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201408200734.s7K7Ysmm086195@dyslexicfish.net> Date: Wed, 20 Aug 2014 08:34:54 +0100 To: jhs@berklix.com, FreeBSD@ShaneWare.Biz, current@freebsd.org Subject: Re: android bsd connectivity tools etc ? References: <201408132347.s7DNlcHU013055@fire.js.berklix.net> <53EC3930.6060604@ShaneWare.Biz> In-Reply-To: <53EC3930.6060604@ShaneWare.Biz> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [91.109.5.35]); Wed, 20 Aug 2014 08:34:55 +0100 (BST) Cc: gj@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:50:36 -0000 Shane Ambler wrote: > da0 at umass-sim1 bus 1 scbus5 target 0 lun 0 > da0: < Android Adapter 0100> Removable Direct Access SCSI-2 device > cd1 at umass-sim1 bus 1 scbus5 target 0 lun 1 > cd1: < Android Adapter 0100> Removable CD-ROM SCSI-2 device > da1 at umass-sim1 bus 1 scbus5 target 0 lun 2 > da1: < Android Adapter 0100> Removable Direct Access SCSI-2 device > > On the phone I get a message to turn on usb mass storage after which I > can mount_msdosfs /dev/da0s1 and get access to the sdcard in the phone. > > It looks like mass storage was hidden in 4.0 and maybe removed after 4.2. > Try searching the android app store for usb mass storage. With Android 4.0.4: | umass3: on usbus1 | umass3: SCSI over Bulk-Only; quirks = 0x4000 | umass3:6:3:-1: Attached to scbus6 | da2 at umass-sim3 bus 3 scbus6 target 0 lun 0 | da2: Removable Direct Access SCSI-2 device | da2: 40.000MB/s transfers | da3 at umass-sim3 bus 3 scbus6 target 0 lun 1 | da3: Removable Direct Access SCSI-2 device | da3: 40.000MB/s transfers .... which correspond to the 'internal sdcard' and external sdcard. cheers, Jamie From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 07:55:25 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A909C39; Wed, 20 Aug 2014 07:55:25 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) (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 172E33AF5; Wed, 20 Aug 2014 07:55:24 +0000 (UTC) Received: from dyslexicfish.net (dyslexicfish.net [91.109.5.35]) by dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s7K7tL0C088415; Wed, 20 Aug 2014 08:55:22 +0100 (BST) (envelope-from jamie@dyslexicfish.net) Received: (from jamie@localhost) by dyslexicfish.net (8.14.5/8.14.5/Submit) id s7K7tLXA088414; Wed, 20 Aug 2014 08:55:21 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201408200755.s7K7tLXA088414@dyslexicfish.net> Date: Wed, 20 Aug 2014 08:55:20 +0100 To: jhs@berklix.com, current@freebsd.org Subject: Re: android bsd connectivity tools etc ? References: <201408132347.s7DNlcHU013055@fire.js.berklix.net> In-Reply-To: <201408132347.s7DNlcHU013055@fire.js.berklix.net> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (dyslexicfish.net [91.109.5.35]); Wed, 20 Aug 2014 08:55:23 +0100 (BST) Cc: gj@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:55:25 -0000 "Julian H. Stacey" wrote: > Hi, > Any tips for Android / FreeBSD BSD tools for connectivity etc ? I mainly use nfs / ssh (dropbear) / scp for connectivity over IPv6 to my local FreeBSD server. It works quite well - I even have automated cron rsync deduped backups! NFS is used for mounting my media onto /sdcard/Videos /sdcard/Music /sdcard/Pictures Not all androids come with nfs in the kernel though, Cheers, Jamie From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 09:32:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E69F88B5; Wed, 20 Aug 2014 09:32:28 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 305B8344F; Wed, 20 Aug 2014 09:32:28 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id v6so6483974lbi.38 for ; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5eT3lTm3TgjugthKLkDN25vxrfbSC4ZBgOuL9WpTP8o=; b=bWwUfIg3cCXlDeaTNK17k2iiIufLXDD2O5jzcZaBvEOWukrRbP6Ay2mnTWqHCpgcRh fe2RcLjjsXFSEPRcL1BVQ4aCdeKLr5fHhjYvuDxlnzQlsmiU6gNtLWyDhCoSQyLf9/qr I4vcvlahaTuVRPFHg2RqjQOIkh6MdFsSAD4VkO7/plUhmH+hTyhm83YjVu6+gcPfL6tu QtOI+6W+EL16fXYNN/Ss69XfJ21rJZUbT4oR2NkhuHVmpO/C4YRaJlg13hpi5PK61Tqd w98pXNfD7z0GkVLSiiww3w2UwQosKZxSsVlkB2tjr+juJzIiq/nQVewQ2AkfIFKpRdq2 Kiew== MIME-Version: 1.0 X-Received: by 10.112.35.44 with SMTP id e12mr38763111lbj.13.1408527146067; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) In-Reply-To: <53F44F91.2060006@selasky.org> References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> Date: Wed, 20 Aug 2014 11:32:26 +0200 X-Google-Sender-Auth: KXSBRY2Umn7HUstkEjYX2X6Xqnk Message-ID: Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] From: Luigi Rizzo To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 09:32:29 -0000 On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky wrote: > Hi, > > A month has passed since the last e-mail on this topic, and in the > meanwhile some new patches have been created and tested: > > Basically the approach has been changed a little bit: > > - The creation of hardware transmit rings has been made independent of th= e > TCP stack. This allows firewall applications to forward traffic into > hardware transmit rings aswell, and not only native TCP applications. Thi= s > should be one more reason to get the feature into the kernel. > > - A hardware transmit ring basically can have two modes: FIXED-RATE or > AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed byt= es > per second rate. In the automatic mode you can configure a time after whi= ch > the TX queue must be empty. The hardware driver uses this to configure th= e > actual rate. In automatic mode you can also set an upper and lower transm= it > rate limit. > > - The MBUF has got a new field in the packet header: "txringid" > > - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of > the "txringid" field in the mbuf. > > The current patch [see attachment] should be much simpler and less > intrusive than the previous one. > =E2=80=8Bthe patch seems to include only part of the generic code (ie no io= ctls for manipulating the rates, no backend code). Do i miss something ? I have a few comments/concerns: + looks like flowid and txringid are overlapped in scope, both will be used (in the backend) to select a specific tx queue. I don't have a solution but would like to know how do you plan to address this -- does one have priority over the other, etc. + related to the above, a (possibly unavoidable) side effect of this type of changes is that mbufs explode with custom fields, so if we could perhaps make one between flowid and txringid, that would be useful. + is there a way to =E2=80=8Bavoid the replicated code for SIOCSTXRINGID (the ioctl handler, i suppose). Maybe make one function and call it from both ipv4 and ipv6, assuming there aren't other places like this. + i am not particularly happy about the explosion of ioctls for setting and getting rates. Next we'll want to add scheduling, and intervals, and queue sizes and so on. For these commands outside the critical path it would be preferable a single command with an extensible structure. Bikeshed material i am sure. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 13:29:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7D73C0B; Wed, 20 Aug 2014 13:29:10 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59A743EF1; Wed, 20 Aug 2014 13:29:10 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2A3F01FE027; Wed, 20 Aug 2014 15:29:04 +0200 (CEST) Message-ID: <53F4A2AF.6080102@selasky.org> Date: Wed, 20 Aug 2014 15:29:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 13:29:11 -0000 Hi Luigi, On 08/20/14 11:32, Luigi Rizzo wrote: > On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky > wrote: > >> Hi, >> >> A month has passed since the last e-mail on this topic, and in the >> meanwhile some new patches have been created and tested: >> >> Basically the approach has been changed a little bit: >> >> - The creation of hardware transmit rings has been made independent of the >> TCP stack. This allows firewall applications to forward traffic into >> hardware transmit rings aswell, and not only native TCP applications. This >> should be one more reason to get the feature into the kernel. >> >> - A hardware transmit ring basically can have two modes: FIXED-RATE or >> AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed bytes >> per second rate. In the automatic mode you can configure a time after which >> the TX queue must be empty. The hardware driver uses this to configure the >> actual rate. In automatic mode you can also set an upper and lower transmit >> rate limit. >> >> - The MBUF has got a new field in the packet header: "txringid" >> >> - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of >> the "txringid" field in the mbuf. >> >> The current patch [see attachment] should be much simpler and less >> intrusive than the previous one. >> > > ​the patch seems to include only part of the generic code (ie no ioctls > for manipulating the rates, no backend code). Do i miss something ? The IOCTLs for managing the rates are: SIOCARATECTL, SIOCSRATECTL, SIOCGRATECTL and SIOCDRATECTL And they go to the if_ioctl callback. > > I have a few comments/concerns: > > + looks like flowid and txringid are overlapped in scope, > both will be used (in the backend) to select a specific > tx queue. I don't have a solution but would like to know > how do you plan to address this -- does one have priority > over the other, etc. Not 100% . In some cases the flowID is used differently than the txringid, though it might be possible to join the two. Would need to investigate current users of the flow ID. > + related to the above, a (possibly unavoidable) side effect > of this type of changes is that mbufs explode with custom fields, > so if we could perhaps make one between flowid and txringid, > that would be useful. Right, but ratecontrol is an in-general useful feature, especially for high throughput networks, or do you think otherwise? > > + is there a way to ​avoid the replicated code for SIOCSTXRINGID > (the ioctl handler, i suppose). Maybe make one function and > call it from both ipv4 and ipv6, assuming there aren't other > places like this. Yes, could do that. > > + i am not particularly happy about the explosion of ioctls for > setting and getting rates. Next we'll want to add scheduling, > and intervals, and queue sizes and so on. > For these commands outside the critical path it would be > preferable a single command with an extensible structure. > Bikeshed material i am sure. There is only one IOCTL in the critical path and that is the IOCTL to change or update the TX ring ID. The other IOCTLs are in the non-critical path towards the if_ioctl() callback. If we can merge the flowID and the txringid into one field, would it be acceptable to add an IOCTL to read/write this value for all sockets? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 14:41:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61FD589F; Wed, 20 Aug 2014 14:41:29 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96ADD36C4; Wed, 20 Aug 2014 14:41:28 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so7390085lam.14 for ; Wed, 20 Aug 2014 07:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/cEvyJg2v1esY+eJ4fpvO3kbpP3t7VTjrLqwzxVHAyQ=; b=iVQ4PHBNtiS+6uN752S4ynKUyHkm4Q8Bk0SAzD77TXFUr/E9G7u7aICWZ7gZdszeF1 w+3pi92gXn5j/uRcf9z2uqxGAbPUe7BEbKg/9/ueRijWKMbG5vrvqT6ZkE8BC9kCxxOV amzXZdRHGxaN71Zqde7JPXdiz/voM5N3MiAtI11WfccKuByMXjUsKJ+R0rdxrycLJkyj e/zOda44X0wirwTira38HFuepLVXZXufxFKpygyza8gcm1BeZCJ17gqRBAlfWCbycePR p93o2O0g6LhuU3T1MOfJ0vhohui5+7gudlHlGah/4oAvwgZOAnCELylyQ8b5wXqkcjyH qMzQ== MIME-Version: 1.0 X-Received: by 10.152.243.43 with SMTP id wv11mr43884437lac.52.1408545686343; Wed, 20 Aug 2014 07:41:26 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Wed, 20 Aug 2014 07:41:26 -0700 (PDT) In-Reply-To: <53F4A2AF.6080102@selasky.org> References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> <53F4A2AF.6080102@selasky.org> Date: Wed, 20 Aug 2014 16:41:26 +0200 X-Google-Sender-Auth: nsckhSo8zl9qPRFJY6BwzoD4CF4 Message-ID: Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] From: Luigi Rizzo To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 14:41:29 -0000 On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky wrote: > Hi Luigi, > > > On 08/20/14 11:32, Luigi Rizzo wrote: > >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky >> wrote: >> >> Hi, >>> >>> A month has passed since the last e-mail on this topic, and in the >>> meanwhile some new patches have been created and tested: >>> >>> Basically the approach has been changed a little bit: >>> >>> - The creation of hardware transmit rings has been made independent of >>> the >>> TCP stack. This allows firewall applications to forward traffic into >>> hardware transmit rings aswell, and not only native TCP applications. >>> This >>> should be one more reason to get the feature into the kernel. >>> =E2=80=8B... >>> >> =E2=80=8Bthe patch seems to include only part of the generic code (ie no= ioctls >> for manipulating the rates, no backend code). Do i miss something ? >> > > The IOCTLs for managing the rates are: > > SIOCARATECTL, SIOCSRATECTL, SIOCGRATECTL and SIOCDRATECTL > > And they go to the if_ioctl callback.=E2=80=8B =E2=80=8Bi really think these new 'advanced' features should go through some ethtool-like API, not more ioctls. We have a strong need to design and implement such an API also to have a uniform mechanism to manipulate rss, queues and other NIC features. =E2=80=8B...=E2=80=8B > > > >> I have a few comments/concerns: >> >> + looks like flowid and txringid are overlapped in scope, >> both will be used (in the backend) to select a specific >> tx queue. I don't have a solution but would like to know >> how do you plan to address this -- does one have priority >> over the other, etc. >> > > Not 100% . In some cases the flowID is used differently than the txringid= , > though it might be possible to join the two. Would need to investigate > current users of the flow ID. =E2=80=8Bin some 10G drivers i have seen, at the driver level the flowid is used on the tx path to assign packets to a given =E2=80=8Btx queue, generally to improve cpu affinity. Of course some applications may want a true flow classifier so they do not have to re-do the classification multiple times. But then, we have a ton of different classifiers with the same need -- e.g. ipfw dynamic rules, dummynet pipe/queue id, divert ports... Pipes are stored in mtags, which are very expensive so i do see a point in embedding them in the mbufs, it's just that going this path there is no end to the list. > > + related to the above, a (possibly unavoidable) side effect >> of this type of changes is that mbufs explode with custom fields, >> so if we could perhaps make one between flowid and txringid, >> that would be useful. >> > > Right, but ratecontrol is an in-general useful feature, especially for > high throughput networks, or do you think otherwise? of course i think =E2=80=8Bthe feature is useful, but see the previous point. We should find a way to manage it (and others) that does not pollute or require continuous changes to the struct mbuf. > > > >> + i am not particularly happy about the explosion of ioctls for >> setting and getting rates. Next we'll want to add scheduling, >> and intervals, and queue sizes and so on. >> For these commands outside the critical path it would be >> preferable a single command with an extensible structure. >> Bikeshed material i am sure. >> > > There is only one IOCTL in the critical path and that is the IOCTL to > change or update the TX ring ID. The other IOCTLs are in the non-critical > path towards the if_ioctl() callback. > > If we can merge the flowID and the txringid into one field, would it be > acceptable to add an IOCTL to read/write this value for all sockets? =E2=80=8Bsee above. i'd prefer an ethtool-like solution. cheers luigi =E2=80=8B From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 16:21:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECC7618B; Wed, 20 Aug 2014 16:21:40 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9627D342F; Wed, 20 Aug 2014 16:21:40 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id l6so8130128qcy.11 for ; Wed, 20 Aug 2014 09:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MEDBPn7oIvwUjsxh+CZpz1yVxFwbna3Jd9wQC8xQs50=; b=yxWqkXBFW4xL9BZUzLpcOaxil13JY3meOvcOzFIUqJPS0PqGqaCHYDNbqcT8sUC6w8 tshddY1BfrZksKwNvzGpUrez9ye1r05R+PDVCXXrAYfxFGg3tJxRn0zNYY8++HtfLPZG PhZr7NocDnofnh1/AP5Rygy9RiuOmAN9nLUkP2kS0aX9+NrGeTwzmJHRVn7TacGeSSAT K4TMrfrnA842ZogAdOujJq2mYap/tUGKpq/15VPSXw1ePbJq70nIHc03YqbNdy+WZfKS PSNwYbtUZfBYDNRa5K4yXWS7k3doNkRLqKh9vHs/76dIEkUFS4/LPQOQAR4eRddjsbDN BLQQ== MIME-Version: 1.0 X-Received: by 10.224.12.134 with SMTP id x6mr39794633qax.1.1408551699682; Wed, 20 Aug 2014 09:21:39 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.224.17.129 with HTTP; Wed, 20 Aug 2014 09:21:39 -0700 (PDT) In-Reply-To: References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> <53F4A2AF.6080102@selasky.org> Date: Wed, 20 Aug 2014 09:21:39 -0700 X-Google-Sender-Auth: LcH8QDyKws6ZXEPdmZq2F5rVOkI Message-ID: Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] From: "K. Macy" To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , "freebsd-net@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:21:41 -0000 On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo wrote: > On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky > wrote: > > > Hi Luigi, > > > > > > On 08/20/14 11:32, Luigi Rizzo wrote: > > > >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky > >> wrote: > >> > >> Hi, > >>> > >>> A month has passed since the last e-mail on this topic, and in the > >>> meanwhile some new patches have been created and tested: > >>> > >>> Basically the approach has been changed a little bit: > >>> > >>> - The creation of hardware transmit rings has been made independent o= f > >>> the > >>> TCP stack. This allows firewall applications to forward traffic into > >>> hardware transmit rings aswell, and not only native TCP applications. > >>> This > >>> should be one more reason to get the feature into the kernel. > >>> =E2=80=8B... > >>> > >> =E2=80=8Bthe patch seems to include only part of the generic code (ie = no ioctls > >> for manipulating the rates, no backend code). Do i miss something ? > >> > > > > The IOCTLs for managing the rates are: > > > > SIOCARATECTL, SIOCSRATECTL, SIOCGRATECTL and SIOCDRATECTL > > > > And they go to the if_ioctl callback.=E2=80=8B > > > =E2=80=8Bi really think these new 'advanced' features should go > through some ethtool-like API, not more ioctls. > We have a strong need to design and implement such > an API also to have a uniform mechanism to manipulate > rss, queues and other NIC features. > > > There is no ethtool equivalent yet, but exposing them through a sysctl is definitely the place to start before putting it straight in to ifconfig. The ifnet API is already a bit of a mess. > =E2=80=8B...=E2=80=8B > > > > > > > >> I have a few comments/concerns: > >> > >> + looks like flowid and txringid are overlapped in scope, > >> both will be used (in the backend) to select a specific > >> tx queue. I don't have a solution but would like to know > >> how do you plan to address this -- does one have priority > >> over the other, etc. > >> > > > > Not 100% . In some cases the flowID is used differently than the > txringid, > > though it might be possible to join the two. Would need to investigate > > current users of the flow ID. > > > =E2=80=8Bin some 10G drivers i have seen, at the driver > level the flowid is used on the tx path to assign > packets to a given =E2=80=8Btx queue, generally to improve > cpu affinity. Of course some applications > may want a true flow classifier so they do not > have to re-do the classification multiple times. > But then, we have a ton of different classifiers > with the same need -- e.g. ipfw dynamic rules, > dummynet pipe/queue id, divert ports... > Pipes are stored in mtags, which are very expensive > so i do see a point in embedding them in the mbufs, > it's just that going this path there is no end > to the list. > > > The purpose of the flowid was to enforce packet ordering on transmit while being large enough to store a RSS hash, potentially allowing input consumers to use it to semi-uniquely label (srcip, srcport, dstip, dstport) tuples. It seems to that the txringid would be almost entirely redundant. Why not just let users set the flowid? > If we can merge the flowID and the txringid into one field, would it be > > acceptable to add an IOCTL to read/write this value for all sockets? > > That sounds reasonable - although I have not thought through all the implications. -K From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 16:34:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6521496B for ; Wed, 20 Aug 2014 16:34:30 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 45B893576 for ; Wed, 20 Aug 2014 16:34:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7KGYUij074428 for ; Wed, 20 Aug 2014 16:34:30 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7KGYU3Y074425 for freebsd-current@freebsd.org; Wed, 20 Aug 2014 16:34:30 GMT (envelope-from bdrewery) Received: (qmail 23391 invoked from network); 20 Aug 2014 11:34:26 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 20 Aug 2014 11:34:26 -0500 Message-ID: <53F4CE0E.8040106@FreeBSD.org> Date: Wed, 20 Aug 2014 11:34:22 -0500 From: Bryan Drewery Reply-To: Ports FreeBSD Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ports FreeBSD , pkg@freebsd.org Subject: [CFT] SSP Package Repository available References: <523D79CD.2090302@FreeBSD.org> In-Reply-To: <523D79CD.2090302@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K5G4LOnFU7x5CMaL6D0wm5KIVLpq9PTjB" X-Mailman-Approved-At: Wed, 20 Aug 2014 17:14:24 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:34:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K5G4LOnFU7x5CMaL6D0wm5KIVLpq9PTjB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/21/2013 5:49 AM, Bryan Drewery wrote: > Ports now support enabling Stack Protector [1] support on FreeBSD 10 > i386 and amd64, and older releases on amd64 only currently. >=20 > Support may be added for earlier i386 releases once all ports properly > respect LDFLAGS. >=20 > To enable, just add WITH_SSP=3Dyes to your make.conf and rebuild all po= rts. >=20 > The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all > may optionally be set instead. >=20 > Please help test this on your system. We would like to eventually enabl= e > this by default, but need to identify any major ports that have run-tim= e > issues due to it. >=20 > [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection >=20 We have not had any feedback on this yet and want to get it enabled by default for ports and packages. We now have a repository that you can use rather than the default to help test. We need your help to identify any issues before switching the default. This repository is available for: head 10.0 9.1,9.2,9.3 It is not available for 8.4. If someone is willing to test on 8.4 I will build a repository for it. Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf: FreeBSD: { enabled: no } FreeBSD_ssp: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } Once that is done you should force reinstall packages from this repositor= y: pkg update pkg upgrade -f Thanks for your help! Bryan Drewery On behalf of portmgr. --K5G4LOnFU7x5CMaL6D0wm5KIVLpq9PTjB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT9M4OAAoJEDXXcbtuRpfPudQH/RV3dAPGOMV+RRC3IGo0l7bB rjr5J5xQK4FuIYenMhkEV+p8Wh/ow9P3GXBQtR4ki/x3Jgk7Xw5YlC4PfJyPdFpM 90wx0IjtT9i5CLTGF+psTgeV5Oh50jWnpy8wggsK+CfFtgqRebdbQvqIWOtKuDdT R5QtxF9U4ZDHCJTEVLsiCeY4SP3N2eqwS4MHX1/92I1xJxbETDQ0CjvoQ5ojfmEi crtNhk4QNUxmmElmxM71iiElbZPfdf3UbqDupQm80eTHNj5Adda8+Mo1ZmUsJYM6 YimDcpNTumctOVLXobpBZEJtOExAsajO1v/aFGWJz4kp2AkGwCLXHowNpHbb/u4= =ElhW -----END PGP SIGNATURE----- --K5G4LOnFU7x5CMaL6D0wm5KIVLpq9PTjB-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:00:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07F7FD75 for ; Wed, 20 Aug 2014 18:00:16 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD0503E56 for ; Wed, 20 Aug 2014 18:00:15 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hy4so9406321vcb.41 for ; Wed, 20 Aug 2014 11:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=MJTGqY/f6vPCFJ+wDYucJUuauwEawWI3zKqjYn+keJE=; b=D8yqdMc2FKqEr7ePBz6k+gJhiwM9IrEDEGvm+fVdZ3VvVzebVl1sOQ3RyUayXo3UNZ FZj3ydu4MtJj/qM7b4kPlpADvXt1EszuHVenyjelXewpj/ktKuWbSzVaE8lH1FQIo9uP 0JBB1/O354nFgwOQWUJKE5XQg9dJB5fTapgdzlxOAejFD1v445YzBq+Nz53n7zoV9JHS EUm6uyZhNNou3WUJwqTi4j/rvWVKuko5nX+fZiepPmwwXSqouOZZcCCS+tRulsB188Aa beqs7LodBDrqnJKvH3voApB1aXG5WjizDiGWvXR3hyYoViY+AtAXFo/wpeBGABjGmQ4f jhqA== MIME-Version: 1.0 X-Received: by 10.221.61.5 with SMTP id wu5mr37674383vcb.13.1408557614751; Wed, 20 Aug 2014 11:00:14 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.225.201 with HTTP; Wed, 20 Aug 2014 11:00:14 -0700 (PDT) Date: Wed, 20 Aug 2014 11:00:14 -0700 X-Google-Sender-Auth: f9e89JTPKtlqsVmtjOhWA67L6UM Message-ID: Subject: RFC: Remove pty(4) From: Davide Italiano To: freebsd-current Content-Type: text/plain; charset=UTF-8 Cc: Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:00:16 -0000 One of my personal goals for 11 is to get rid of cloning mechanism entirely, and pty(4) is one of the few in-kernel drivers still relying on such mechanism. It's not possible, at least to my understanding, converting pty(4) to cdevpriv(9) as happened with other drivers. This is mainly because we always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and userspace loops over ptyXX and after it successfully opens it tries to open the other one with the same suffix. So, having a single device is not really enough. My option, instead, is that of removing pty(4), which is nothing more than a compatibility driver, and move pmtx(4) code somewhere else. The main drawback of the removal of this is that it makes impossible to run FreeBSD <= 7 jails and SSH into them. I personally don't consider this a huge issue, in light of the fact that FreeBSD-7 has been EOL for a long time, but I would like to hear other people comments. The code review for the proposed change can be found here: https://reviews.freebsd.org/D659 If I won't get any objection I'll commit this in one week time, i.e. August 27th. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:04:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09E32F36 for ; Wed, 20 Aug 2014 18:04:18 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E9F963028 for ; Wed, 20 Aug 2014 18:04:17 +0000 (UTC) Received: from Alfreds-MacBook-Pro.local (unknown [12.69.234.201]) by elvis.mu.org (Postfix) with ESMTPSA id E7153346DE81 for ; Wed, 20 Aug 2014 11:04:16 -0700 (PDT) Message-ID: <53F4E37A.6020702@mu.org> Date: Wed, 20 Aug 2014 11:05:46 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: RFC: Remove pty(4) References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:04:18 -0000 On 8/20/14 11:00 AM, Davide Italiano wrote: > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. > > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. > I don't think that we want to break userland apps pre-7.x. Do you mean just jails are broken? Or is all pre-7.x compat? I believe either is dicey. What is the reason for getting rid of cloning? What is the difficulty in maintaining the old interface? -Alfred From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:11:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C36D98E7; Wed, 20 Aug 2014 18:11:50 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85DD83423; Wed, 20 Aug 2014 18:11:50 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9243C1FE027; Wed, 20 Aug 2014 20:11:47 +0200 (CEST) Message-ID: <53F4E4F2.3060709@selasky.org> Date: Wed, 20 Aug 2014 20:12:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Davide Italiano , freebsd-current Subject: Re: RFC: Remove pty(4) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:11:50 -0000 On 08/20/14 20:00, Davide Italiano wrote: > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. > > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. > Hi, There is support for creating character device aliases, regarding paired devices. BTW: Can an application using libcuse fix this issue in userspace? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:13:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BED1A00; Wed, 20 Aug 2014 18:13:35 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DC1634FA; Wed, 20 Aug 2014 18:13:35 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.125]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s7KIDPdb067425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 11:13:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53F4E544.9070606@freebsd.org> Date: Wed, 20 Aug 2014 11:13:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Davide Italiano , freebsd-current Subject: Re: RFC: Remove pty(4) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:13:35 -0000 On 8/20/14, 11:00 AM, Davide Italiano wrote: > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. > > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. I agree with Alfred. breaking old jails is a no no. many people still use them. Me included. I sometimes run jails back to 1.1, not everything works, but enough does to build 1.1 binaries for certain devices. From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:16:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08755C0A for ; Wed, 20 Aug 2014 18:16:35 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0E503534 for ; Wed, 20 Aug 2014 18:16:34 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id v10so12188141pde.10 for ; Wed, 20 Aug 2014 11:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=EViyLty8mS1NilCpGRuN/5rREF2i3Pq/WXZqVYeiRNQ=; b=k8VijXtj7srJD34NiiJxzfbDJgy2bvJUuWb0SAW9AVmG1H3a67J9FkA6xzKcAVnjYE +cluSdDlXeGIvc9a2ApGDbcKw/p57ofm5n9eRrNgNB+OO6j3Ms+hXl+t0cOnt1rhyeRq zvA7ITWXsfBp7nMtLudFQZyruBO8Kdacm6CI9rt5ikLZKNLNYYi20EsQOokGFDILbeSw +BVE4Y7qCJhomqlzOmdsDS7YNYfTTSjiosPW+Lfus/61roVot3xzkv5++jJYoSLGJAKZ Gdoq9Aow1AycNc3XHlMkkffdpMYrxgwEB6pmr7gAWyKvagUzggjCLKg8NXPT9SzaoUU+ b0Fw== X-Received: by 10.67.12.175 with SMTP id er15mr30590135pad.143.1408558590171; Wed, 20 Aug 2014 11:16:30 -0700 (PDT) Received: from [10.15.207.237] (mobile-166-137-215-030.mycingular.net. [166.137.215.30]) by mx.google.com with ESMTPSA id px5sm23040018pbc.23.2014.08.20.11.16.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 11:16:29 -0700 (PDT) References: <53F4E37A.6020702@mu.org> Mime-Version: 1.0 (1.0) In-Reply-To: <53F4E37A.6020702@mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9D23D164-E7D1-40EB-91AE-FD5DA1F2EB65@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: RFC: Remove pty(4) Date: Wed, 20 Aug 2014 11:16:26 -0700 To: Alfred Perlstein Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:16:35 -0000 > On Aug 20, 2014, at 11:05, Alfred Perlstein wrote: >=20 >> On 8/20/14 11:00 AM, Davide Italiano wrote: >> One of my personal goals for 11 is to get rid of cloning mechanism >> entirely, and pty(4) is one of the few in-kernel drivers still relying >> on such mechanism. >> It's not possible, at least to my understanding, converting pty(4) to >> cdevpriv(9) as happened with other drivers. This is mainly because we >> always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and >> userspace loops over ptyXX and after it successfully opens it tries to >> open the other one with the same suffix. So, having a single device is >> not really enough. >> My option, instead, is that of removing pty(4), which is nothing more >> than a compatibility driver, and move pmtx(4) code somewhere else. >> The main drawback of the removal of this is that it makes impossible >> to run FreeBSD <=3D 7 jails and SSH into them. I personally don't >> consider this a huge issue, in light of the fact that FreeBSD-7 has >> been EOL for a long time, but I would like to hear other people >> comments. >>=20 >> The code review for the proposed change can be found here: >> https://reviews.freebsd.org/D659 >>=20 >> If I won't get any objection I'll commit this in one week time, i.e. >> August 27th. > I don't think that we want to break userland apps pre-7.x. Do you mean ju= st jails are broken? Or is all pre-7.x compat? I believe either is dicey. = What is the reason for getting rid of cloning? What is the difficulty in ma= intaining the old interface? Doing this would also break login shells, xterms, etc, right? Some compa= nies I worked for built their appliance products on newer OSes, and they wer= e based off of 6 and 7. This seems like something that deserves being tossed= into the compat layer if it's something that can be converted over to the n= ew interface. Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:19:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BF29E24 for ; Wed, 20 Aug 2014 18:19:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 EEAB2359B for ; Wed, 20 Aug 2014 18:19:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7KIJbnh008669 for ; Wed, 20 Aug 2014 18:19:37 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7KIJbof008663 for freebsd-current@freebsd.org; Wed, 20 Aug 2014 18:19:37 GMT (envelope-from bdrewery) Received: (qmail 52885 invoked from network); 20 Aug 2014 13:19:36 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 20 Aug 2014 13:19:36 -0500 Message-ID: <53F4E6B3.7060209@FreeBSD.org> Date: Wed, 20 Aug 2014 13:19:31 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Julian Elischer , Davide Italiano , freebsd-current Subject: Re: RFC: Remove pty(4) References: <53F4E544.9070606@freebsd.org> In-Reply-To: <53F4E544.9070606@freebsd.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mx3vo1gnDsHI59IVJCgT3hF4bL8QrBHTM" Cc: Ed Schouten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:19:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mx3vo1gnDsHI59IVJCgT3hF4bL8QrBHTM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/20/2014 1:13 PM, Julian Elischer wrote: > On 8/20/14, 11:00 AM, Davide Italiano wrote: >> One of my personal goals for 11 is to get rid of cloning mechanism >> entirely, and pty(4) is one of the few in-kernel drivers still relying= >> on such mechanism. >> It's not possible, at least to my understanding, converting pty(4) to >> cdevpriv(9) as happened with other drivers. This is mainly because we >> always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and >> userspace loops over ptyXX and after it successfully opens it tries to= >> open the other one with the same suffix. So, having a single device is= >> not really enough. >> My option, instead, is that of removing pty(4), which is nothing more >> than a compatibility driver, and move pmtx(4) code somewhere else. >> The main drawback of the removal of this is that it makes impossible >> to run FreeBSD <=3D 7 jails and SSH into them. I personally don't >> consider this a huge issue, in light of the fact that FreeBSD-7 has >> been EOL for a long time, but I would like to hear other people >> comments. >> >> The code review for the proposed change can be found here: >> https://reviews.freebsd.org/D659 >> >> If I won't get any objection I'll commit this in one week time, i.e. >> August 27th. > I agree with Alfred. > breaking old jails is a no no. > many people still use them. Me included. > I sometimes run jails back to 1.1, > not everything works, but enough does to build 1.1 binaries for certain= > devices. +1 to keeping compat. --=20 Regards, Bryan Drewery --Mx3vo1gnDsHI59IVJCgT3hF4bL8QrBHTM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT9Oa0AAoJEDXXcbtuRpfPBY0H/RvFmD+8k8Z8mV+4+v+TAzAw Gnj3lJ6lrtgYTPKExTFcerpGBZI94JON+laQTBIf8OPFWgzI3ZMWhIIgqr1Lrx9r NbxAMV1xdREt04PWfmLprH7kfxnPJOVXaY2Fa+ozX9r1sByXBtOgnphF9ASiiXOp aRAhH6I1X5ByGNv3KVrImonFXuBhigGMzYmzCV1ZG+FsTIHxX2PC0Wv+JMZYKhfs 1taWe/Gq384AH9xjAjUI2w/FrX2BLyjN8IfbnZGeiwobNikNLDdgbx96S05gep83 Aw3Cz4DZ07lPtnhCNy7Edhmu/Cm+rjIqkwfe8WOonoMDENXmIAKNrNTuFV90ZQM= =VtHH -----END PGP SIGNATURE----- --Mx3vo1gnDsHI59IVJCgT3hF4bL8QrBHTM-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 18:44:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A224B90D; Wed, 20 Aug 2014 18:44:31 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E6A938B3; Wed, 20 Aug 2014 18:44:31 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lf10so12789518pab.15 for ; Wed, 20 Aug 2014 11:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7GC/NyvsdtfbrqnjCHst0OjcrxRKe5VSynfwWwyIYtw=; b=w5A5IBHMUlaA4Rp2nOON2UvyzvPFLy0CWG7H0xhhbkq/gQqVQu996OVrkyH9UvlYcC Xz2NZaXDv2Rpkt6jdsoRlFbe2PRC/WPAl+juf5he0wSIXauvZALj/z90zqzIu2LHjOHi 4WDLtcDYatOnTbe84VtKplpok2DlmB4Z5AJNzKIMcvmccbYa5c6Vh03kk2T6gif9TvYA ziEuJdKhYbWLINQZOrKPkK5sgVnHFn3d3IondpHIAs7WA2rIhsis/DJZdukdJfgRXrIv HOiALxG1lEeVVIb9KblvoOYVkfYo1DmxC8BYLw/GUzGBAzisMxrC9Yq1d/s5dEBRB+Jx LMEw== X-Received: by 10.68.69.46 with SMTP id b14mr54338257pbu.70.1408560270443; Wed, 20 Aug 2014 11:44:30 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id ou8sm11171547pbc.84.2014.08.20.11.44.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Aug 2014 11:44:29 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <53F4EC8A.9090804@FreeBSD.org> Date: Wed, 20 Aug 2014 11:44:26 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-net@freebsd.org, FreeBSD Current Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> In-Reply-To: <53F44F91.2060006@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:44:31 -0000 On 08/20/14 00:34, Hans Petter Selasky wrote: > Hi, > > A month has passed since the last e-mail on this topic, and in the > meanwhile some new patches have been created and tested: > > Basically the approach has been changed a little bit: > > - The creation of hardware transmit rings has been made independent of > the TCP stack. This allows firewall applications to forward traffic into > hardware transmit rings aswell, and not only native TCP applications. > This should be one more reason to get the feature into the kernel. > > - A hardware transmit ring basically can have two modes: FIXED-RATE or > AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed > bytes per second rate. In the automatic mode you can configure a time > after which the TX queue must be empty. The hardware driver uses this to > configure the actual rate. In automatic mode you can also set an upper > and lower transmit rate limit. > > - The MBUF has got a new field in the packet header: "txringid" > > - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of > the "txringid" field in the mbuf. > > The current patch [see attachment] should be much simpler and less > intrusive than the previous one. > > Any comments ? Here are some thoughts. The first two bullets cover relatively minor issues, the rest are more important. - All of the mbuf pkthdr fields today have the same meaning no matter what the context. It is not clear what txringid's global meaning is. Is it even possible for driver foo to interpret it the same way as driver bar? What if the number of rings are different, or if the ring at the particular index for foo is setup differently than the ring at that same index for bar? You are attempting to influence the driver's txq selection and traditionally the mbuf's flowid has been used for this purpose. Have you considered allowing the user to set the flowid directly? And mark it as such via a new rsstype so the kernel will leave it alone. - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include mbuf.h in more places just to get this definition. What's the advantage of this? style(9) isn't too fond of typedefs either. Also, drivers *do* need to know the width of the flowid. At least lagg(4) looks at the high bits of the flowid (see flowid_shift in lagg). How high it can go depends on the width of the flowid. - Interfaces can come and go, routes can change, and so the relationship between an inpcb and txringid is not stable at all. What happens when the outbound route for an inpcb changes? - The in_ratectlreq structure that you propose is inadequate in its current form. For example, cxgbe's hardware can do rate limiting on a per-ring as well as per-connection basis, and it allows for pps, bandwidth, or min-max limits. I think this is the critical piece that we NIC maintainers must agree on before any code hits the core kernel: how to express a rate-limit policy in a standard way and allow for hardware assistance opportunistically. ipfw(4)'s dummynet is probably interested in this part too, so it's great that Luigi is paying attention to this thread. - The RATECTL ioctls deal with in_ratectlreq so we need to standardize the ratectlreq structure before these ioctls can be considered generic ifnet ioctls. This is the reason cxgbetool (and not ifconfig) has a private ioctl to frob cxgbe's per-queue rate-limiters. I did not want to add ifnet ioctls that in reality were cxgbe only. Ditto for i2c ioctls. Now we have multiple drivers with i2c and melifaro@ is doing the right thing by promoting these private ioctls to a standard ifnet ioctl. Have you considered a private mlxtool as a stop gap measure? To summarize my take on all of this: we need a standard ratectlreq structure, a standard way to associate an inpcb with one, and a standard way to pass on this info to if_transmit. After all this is in place we could even have a dummynet-ish software layer that implements rate limiters when the underlying hardware offers no assistance. Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 19:25:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A34D865; Wed, 20 Aug 2014 19:25:13 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 322913C74; Wed, 20 Aug 2014 19:25:13 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 572C91FE027; Wed, 20 Aug 2014 21:25:11 +0200 (CEST) Message-ID: <53F4F626.9030806@selasky.org> Date: Wed, 20 Aug 2014 21:25:26 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Navdeep Parhar , freebsd-net@freebsd.org, FreeBSD Current Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> <53F4EC8A.9090804@FreeBSD.org> In-Reply-To: <53F4EC8A.9090804@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:25:13 -0000 On 08/20/14 20:44, Navdeep Parhar wrote: > On 08/20/14 00:34, Hans Petter Selasky wrote: >> Hi, >> >> A month has passed since the last e-mail on this topic, and in the >> meanwhile some new patches have been created and tested: >> >> Basically the approach has been changed a little bit: >> >> - The creation of hardware transmit rings has been made independent of >> the TCP stack. This allows firewall applications to forward traffic into >> hardware transmit rings aswell, and not only native TCP applications. >> This should be one more reason to get the feature into the kernel. >> >> - A hardware transmit ring basically can have two modes: FIXED-RATE or >> AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed >> bytes per second rate. In the automatic mode you can configure a time >> after which the TX queue must be empty. The hardware driver uses this to >> configure the actual rate. In automatic mode you can also set an upper >> and lower transmit rate limit. >> >> - The MBUF has got a new field in the packet header: "txringid" >> >> - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of >> the "txringid" field in the mbuf. >> >> The current patch [see attachment] should be much simpler and less >> intrusive than the previous one. >> >> Any comments ? > > > Here are some thoughts. The first two bullets cover relatively > minor issues, the rest are more important. > > - All of the mbuf pkthdr fields today have the same meaning no matter > what the context. It is not clear what txringid's global meaning is. > Is it even possible for driver foo to interpret it the same way as > driver bar? What if the number of rings are different, or if the ring > at the particular index for foo is setup differently than the ring at > that same index for bar? You are attempting to influence the driver's > txq selection and traditionally the mbuf's flowid has been used for > this purpose. Have you considered allowing the user to set the flowid > directly? And mark it as such via a new rsstype so the kernel will > leave it alone. Hi, At work so to speak, we have tried to make a simple approach that will not break existing code, without trying to optimise the possibilities and reduce memory footprint. > > - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include > mbuf.h in more places just to get this definition. What's the > advantage of this? style(9) isn't too fond of typedefs either. Also, > drivers *do* need to know the width of the flowid. At least lagg(4) > looks at the high bits of the flowid (see flowid_shift in lagg). How > high it can go depends on the width of the flowid. The flowid should be typedef'ed. Else how can you know its type passing flowid along function arguments and so on? > > - Interfaces can come and go, routes can change, and so the relationship > between an inpcb and txringid is not stable at all. What happens when > the outbound route for an inpcb changes? This is managed separately by a daemon or such. The problem about using the "inpcb" approach which you are suggesting, is that you limit the rate control feature to traffic which is bound by sockets. Can your way of doing rate control be useful to non-socket based firewall applications, for example? You also assume a 1:1 mapping between "inpcb" and the flowID, right. What about M:N mappings, where multiple streams should share the same flowID, because it makes more sense? > > - The in_ratectlreq structure that you propose is inadequate in its > current form. For example, cxgbe's hardware can do rate limiting on a > per-ring as well as per-connection basis, and it allows for pps, > bandwidth, or min-max limits. I think this is the critical piece that > we NIC maintainers must agree on before any code hits the core kernel: > how to express a rate-limit policy in a standard way and allow for > hardware assistance opportunistically. ipfw(4)'s dummynet is probably > interested in this part too, so it's great that Luigi is paying > attention to this thread. My "in_ratectlreq" is a work in progress. > > - The RATECTL ioctls deal with in_ratectlreq so we need to standardize > the ratectlreq structure before these ioctls can be considered generic > ifnet ioctls. This is the reason cxgbetool (and not ifconfig) has a > private ioctl to frob cxgbe's per-queue rate-limiters. I did not want > to add ifnet ioctls that in reality were cxgbe only. Ditto for i2c > ioctls. Now we have multiple drivers with i2c and melifaro@ is doing > the right thing by promoting these private ioctls to a standard ifnet > ioctl. Have you considered a private mlxtool as a stop gap measure? It might end that we need to create our own tool for this, having vendor specific IOCTLs, if we cannot agree how to do this in a general way. > > To summarize my take on all of this: we need a standard ratectlreq > structure, Agree. > a standard way to associate an inpcb with one, Maybe. > and a standard > way to pass on this info to if_transmit. Agree. > After all this is in place we > could even have a dummynet-ish software layer that implements rate > limiters when the underlying hardware offers no assistance. Right. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 20:15:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72E54FFF; Wed, 20 Aug 2014 20:15:40 +0000 (UTC) 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 2B5AB3199; Wed, 20 Aug 2014 20:15:40 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XKCIC-000J6t-Qz; Thu, 21 Aug 2014 00:15:36 +0400 Date: Thu, 21 Aug 2014 00:15:36 +0400 From: Slawa Olhovchenkov To: Davide Italiano Subject: Re: RFC: Remove pty(4) Message-ID: <20140820201536.GA37134@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 Cc: Ed Schouten , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:15:40 -0000 On Wed, Aug 20, 2014 at 11:00:14AM -0700, Davide Italiano wrote: > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. FreeBSD EOL, but still working. # uname -a FreeBSD XXX 5.4-STABLE FreeBSD 5.4-STABLE #3: Fri Mar 29 13:52:44 MSK 2013 slw@:/usr/obj/usr/src/sys/RADIUS i386 And may be exist software for this version, don't exist for modern OS. > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. Waht about porting software, relaying on /dev/ptyXX and /dev/ttyXX? From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 21:19:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46996A59; Wed, 20 Aug 2014 21:19:23 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11AC73776; Wed, 20 Aug 2014 21:19:23 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id lj1so12898170pab.5 for ; Wed, 20 Aug 2014 14:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wC3I/mNwfLeWhtE91XDSY9x3swf3q0V2anpuPnmDWHM=; b=lFrm3J9i9EARyasiC+gsrR20gCmEMn5sogrZ6fNK5KGB2E12nQtfmuQhzQpR+so0fj KzmKWfis5/7S/6nzq00uTEZsBx4e2viSjoltXGTjpx01aidtRvpkGigz/kiOwei+djqx SDywElYLdRbXJLzcbViQ/zd19q5io5pJp3xlDYBSydhaAnHbLJdS7GtUk2JJuM0rD1eR 4ZftptVXdo15s1nWYSJhmca/gKuAWGPqlECPfea6Ba94QDO77wwGuF6yW6jtHhL2/p0s 1YZKGwZg9Jzhy+lIUa/194WG50P8G+34+rGT3HsYoimLEkbAqsK9acMr6lS5VxE9j2HN ZYCg== X-Received: by 10.70.128.17 with SMTP id nk17mr6082686pdb.89.1408569562649; Wed, 20 Aug 2014 14:19:22 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id a5sm35523341pdp.38.2014.08.20.14.19.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Aug 2014 14:19:21 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <53F510D8.4060801@FreeBSD.org> Date: Wed, 20 Aug 2014 14:19:20 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-net@freebsd.org, FreeBSD Current Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> <53F4EC8A.9090804@FreeBSD.org> <53F4F626.9030806@selasky.org> In-Reply-To: <53F4F626.9030806@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:19:23 -0000 On 08/20/14 12:25, Hans Petter Selasky wrote: > On 08/20/14 20:44, Navdeep Parhar wrote: >> On 08/20/14 00:34, Hans Petter Selasky wrote: >>> Hi, >>> >>> A month has passed since the last e-mail on this topic, and in the >>> meanwhile some new patches have been created and tested: >>> >>> Basically the approach has been changed a little bit: >>> >>> - The creation of hardware transmit rings has been made independent of >>> the TCP stack. This allows firewall applications to forward traffic into >>> hardware transmit rings aswell, and not only native TCP applications. >>> This should be one more reason to get the feature into the kernel. >>> >>> - A hardware transmit ring basically can have two modes: FIXED-RATE or >>> AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed >>> bytes per second rate. In the automatic mode you can configure a time >>> after which the TX queue must be empty. The hardware driver uses this to >>> configure the actual rate. In automatic mode you can also set an upper >>> and lower transmit rate limit. >>> >>> - The MBUF has got a new field in the packet header: "txringid" >>> >>> - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of >>> the "txringid" field in the mbuf. >>> >>> The current patch [see attachment] should be much simpler and less >>> intrusive than the previous one. >>> >>> Any comments ? >> >> >> Here are some thoughts. The first two bullets cover relatively >> minor issues, the rest are more important. >> >> - All of the mbuf pkthdr fields today have the same meaning no matter >> what the context. It is not clear what txringid's global meaning is. >> Is it even possible for driver foo to interpret it the same way as >> driver bar? What if the number of rings are different, or if the ring >> at the particular index for foo is setup differently than the ring at >> that same index for bar? You are attempting to influence the driver's >> txq selection and traditionally the mbuf's flowid has been used for >> this purpose. Have you considered allowing the user to set the flowid >> directly? And mark it as such via a new rsstype so the kernel will >> leave it alone. > > Hi, > > At work so to speak, we have tried to make a simple approach that will > not break existing code, without trying to optimise the possibilities > and reduce memory footprint. > >> >> - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include >> mbuf.h in more places just to get this definition. What's the >> advantage of this? style(9) isn't too fond of typedefs either. Also, >> drivers *do* need to know the width of the flowid. At least lagg(4) >> looks at the high bits of the flowid (see flowid_shift in lagg). How >> high it can go depends on the width of the flowid. > > The flowid should be typedef'ed. Else how can you know its type passing > flowid along function arguments and so on? It's just a simple 32 bit unsigned int and all drivers know exactly what it is. I don't think we need type checking for trivial stuff like this. We trust code to do the right thing and that's the correct tradeoff here, in my opinion. Or else we'd end up with errno_t, fd_t, etc. and programming in C would not be fun anymore. Here's a hyperbolic example: errno_t socket(domain_t domain, socktype_t type, protocol_t protocol); (oops, it returns an int -1 or 0 so errno_t is not strictly correct, but you get my point). > >> >> - Interfaces can come and go, routes can change, and so the relationship >> between an inpcb and txringid is not stable at all. What happens when >> the outbound route for an inpcb changes? > > This is managed separately by a daemon or such. The problem about using > the "inpcb" approach which you are suggesting, is that you limit the > rate control feature to traffic which is bound by sockets. Can your way > of doing rate control be useful to non-socket based firewall > applications, for example? > > You also assume a 1:1 mapping between "inpcb" and the flowID, right. > What about M:N mappings, where multiple streams should share the same > flowID, because it makes more sense? You're right that an inpcb based scheme won't work for non-socket based firewall. inpcb represents an endpoint, almost always with an associated socket, and it mostly has a 1:1 relation with an n-tuple (SO_LISTEN and UDP sockets with no default destination are notable exceptions). If you're talking of non-socket based firewalls, then where is the inpcb coming from? Firewalls typically keep their own state for the n-tuples that they are interested in. It almost seems like you need a n-tuple -> rate_limit mapping scheme instead of inpcb -> rate_limit. Regards, Navdeep > >> >> - The in_ratectlreq structure that you propose is inadequate in its >> current form. For example, cxgbe's hardware can do rate limiting on a >> per-ring as well as per-connection basis, and it allows for pps, >> bandwidth, or min-max limits. I think this is the critical piece that >> we NIC maintainers must agree on before any code hits the core kernel: >> how to express a rate-limit policy in a standard way and allow for >> hardware assistance opportunistically. ipfw(4)'s dummynet is probably >> interested in this part too, so it's great that Luigi is paying >> attention to this thread. > > My "in_ratectlreq" is a work in progress. > >> >> - The RATECTL ioctls deal with in_ratectlreq so we need to standardize >> the ratectlreq structure before these ioctls can be considered generic >> ifnet ioctls. This is the reason cxgbetool (and not ifconfig) has a >> private ioctl to frob cxgbe's per-queue rate-limiters. I did not want >> to add ifnet ioctls that in reality were cxgbe only. Ditto for i2c >> ioctls. Now we have multiple drivers with i2c and melifaro@ is doing >> the right thing by promoting these private ioctls to a standard ifnet >> ioctl. Have you considered a private mlxtool as a stop gap measure? > > It might end that we need to create our own tool for this, having vendor > specific IOCTLs, if we cannot agree how to do this in a general way. > >> >> To summarize my take on all of this: we need a standard ratectlreq >> structure, > > Agree. > >> a standard way to associate an inpcb with one, > > Maybe. > >> and a standard >> way to pass on this info to if_transmit. > > Agree. > >> After all this is in place we >> could even have a dummynet-ish software layer that implements rate >> limiters when the underlying hardware offers no assistance. > > Right. > > --HPS From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 21:40:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 418F1E3B; Wed, 20 Aug 2014 21:40:20 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF4923923; Wed, 20 Aug 2014 21:40:19 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so7413005qab.4 for ; Wed, 20 Aug 2014 14:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vgQmpE2gTpgOy1yKj0ZSu2AdiXnnzDCKthQUTvZMsOA=; b=EDnqwKk1m3WmtWsG/7ary8bvMhjjVG+XtaC89DnLJjfCIHs4MCVpJ1yvkWIPx6ac91 blmneV3dac7MBWqMaIZJqeSegrUKRXVbCu9koDWqiR5ujZ0o7RB3qDduMrKU1S/22AiL y3N7hGpYbTG9BdpXfhFRrbbPAJX0B4YXR9N0O9+SLz13YbKSBpe/BoDWVLG51+LKopWC Hg3uJxuQ0910+1YQRM/NXR0AVvVRTvZdMVPksKXcMjSL2dGWM1z6ociY3Ipa1xQBFQF6 OYJt0ZikNgDk2SXWh6cmnPGdDgFm546E1HuOUDhsnWfOGBNxysTD4q/JK30SyncTlhwf QU+A== MIME-Version: 1.0 X-Received: by 10.224.75.130 with SMTP id y2mr81650108qaj.72.1408570818873; Wed, 20 Aug 2014 14:40:18 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.224.17.129 with HTTP; Wed, 20 Aug 2014 14:40:18 -0700 (PDT) In-Reply-To: <53F4F626.9030806@selasky.org> References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> <53F4EC8A.9090804@FreeBSD.org> <53F4F626.9030806@selasky.org> Date: Wed, 20 Aug 2014 14:40:18 -0700 X-Google-Sender-Auth: U8es1S4X4Uk_24FVyfgq3Ls0hIY Message-ID: Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] From: "K. Macy" To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Navdeep Parhar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:40:20 -0000 > > > >> - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include >> mbuf.h in more places just to get this definition. What's the >> advantage of this? style(9) isn't too fond of typedefs either. Also, >> drivers *do* need to know the width of the flowid. At least lagg(4) >> looks at the high bits of the flowid (see flowid_shift in lagg). How >> high it can go depends on the width of the flowid. >> > > The flowid should be typedef'ed. Else how can you know its type passing > flowid along function arguments and so on? I agree with Navdeep. It's usage should be obvious from context. This just pollutes the namespace. > > > >> - Interfaces can come and go, routes can change, and so the relationship >> between an inpcb and txringid is not stable at all. What happens when >> the outbound route for an inpcb changes? >> > > This is managed separately by a daemon or such. No it's not. Currently, unless you're using flowtables, the route and llentry are looked up for every single outbound packet. Most users are lightly enough loaded that they don't see the potential 8x reduction in pps from the added overhead. > The problem about using the "inpcb" approach which you are suggesting, is > that you limit the rate control feature to traffic which is bound by > sockets. Can your way of doing rate control be useful to non-socket based > firewall applications, for example? > > You also assume a 1:1 mapping between "inpcb" and the flowID, right. What > about M:N mappings, where multiple streams should share the same flowID, > because it makes more sense? That doesn't make any sense to me. FlowIDs are not a limited resource like 8-bit ASIDs where clever resource management was required. An M:N mapping would permit arbitrary interleaving of multiple streams which simply doesn't seem useful unless there is some critical case where it is a huge performance win. In general it is adding complexity for a gratuitous generalization. > > > >> - The in_ratectlreq structure that you propose is inadequate in its >> current form. For example, cxgbe's hardware can do rate limiting on a >> per-ring as well as per-connection basis, and it allows for pps, >> bandwidth, or min-max limits. I think this is the critical piece that >> we NIC maintainers must agree on before any code hits the core kernel: >> how to express a rate-limit policy in a standard way and allow for >> hardware assistance opportunistically. ipfw(4)'s dummynet is probably >> interested in this part too, so it's great that Luigi is paying >> attention to this thread. >> > > My "in_ratectlreq" is a work in progress. Which means that it probably makes sense to not impinge upon the core system until it is more refined. > - The RATECTL ioctls deal with in_ratectlreq so we need to standardize >> the ratectlreq structure before these ioctls can be considered generic >> ifnet ioctls. This is the reason cxgbetool (and not ifconfig) has a >> private ioctl to frob cxgbe's per-queue rate-limiters. I did not want >> to add ifnet ioctls that in reality were cxgbe only. Ditto for i2c >> ioctls. Now we have multiple drivers with i2c and melifaro@ is doing >> the right thing by promoting these private ioctls to a standard ifnet >> ioctl. Have you considered a private mlxtool as a stop gap measure? >> > > It might end that we need to create our own tool for this, having vendor > specific IOCTLs, if we cannot agree how to do this in a general way. > > > >> To summarize my take on all of this: we need a standard ratectlreq >> structure, >> > > Agree. > > > a standard way to associate an inpcb with one, >> > > Maybe. Associating it with an inpcb doesn't exclude adding a mechanism for supporting it in firewalls. -K From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 21:55:27 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C31524A0 for ; Wed, 20 Aug 2014 21:55:27 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) (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 798CE3AED for ; Wed, 20 Aug 2014 21:55:27 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.9/8.14.9) with ESMTP id s7KLtMEL092477 for ; Wed, 20 Aug 2014 17:55:26 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.9/8.14.9/Submit) id s7KLtMGX092476 for current@freebsd.org; Wed, 20 Aug 2014 17:55:22 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 20 Aug 2014 17:55:22 -0400 From: "Michael W. Lucas" To: current@freebsd.org Subject: gbde destroy doesn't match man page? Message-ID: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Wed, 20 Aug 2014 17:55:26 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:55:27 -0000 Hi, Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde destroy -n -1. It's in the examples. When I try it I get: # gbde destroy da0p1 -n -1 gbde: illegal option -- n usage: gbde attach destination [-k keyfile] [-l lockfile] [-p pass-phrase] gbde detach destination gbde init destination [-i] [-f filename] [-K new-keyfile] [-L new-lockfile] [-P new-pass-phrase] gbde setkey destination [-n key] [-k keyfile] [-l lockfile] [-p pass-phrase] [-K new-keyfile] [-L new-lockfile] [-P new-pass-phrase] gbde nuke destination [-n key] [-k keyfile] [-l lockfile] [-p pass-phrase] gbde destroy destination [-k keyfile] [-l lockfile] [-p pass-phrase] Anyone know if this is a software bug or a doc bug? Thanks, ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 20 23:46:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5B297A7; Wed, 20 Aug 2014 23:46:23 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8110A34DB; Wed, 20 Aug 2014 23:46:23 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id hq11so9962654vcb.2 for ; Wed, 20 Aug 2014 16:46:22 -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=KGzfOpC29+NnqDPFkOr6f7sTSICwtJf5/6h2RQuhGiI=; b=CknxcyXxeQFNM6Z4DXrOpMaCzstqbzhf4+V9lwH+LKIQLsr8Jai4n0u+ujq4n2J2fj sQ1TqW9hryIQh/vYqRMBK2lbtLl91ZOFYAD7qDtQQGzcbcKmxYxJ5s4ArsUQtnUBMtg2 NNy1IKNYhbDVPH4Sg0rZrbk5H+v9pgmroYJy6zYTxaZdBoPFIF0WqC+onZt+tJGNS/xK MMbX8c7mzJY3rM8QjbM3tngNeWSwLBas24+JvK82JC1QZnSAZi4+GTu8f9x8UXRIN7ZL pIPU9AIw8LnZ7iEUZdaqLSiLyittE8GLfVDruoD2Z14/TvDEcISwLF1MsDptTv14o9hX MwrQ== MIME-Version: 1.0 X-Received: by 10.220.74.10 with SMTP id s10mr4089221vcj.61.1408578382635; Wed, 20 Aug 2014 16:46:22 -0700 (PDT) Received: by 10.221.18.133 with HTTP; Wed, 20 Aug 2014 16:46:22 -0700 (PDT) Received: by 10.221.18.133 with HTTP; Wed, 20 Aug 2014 16:46:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Aug 2014 18:46:22 -0500 Message-ID: Subject: Re: RFC: Remove pty(4) From: "Sam Fourman Jr." To: Davide Italiano Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ed Schouten , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 23:46:23 -0000 Sam Fourman Jr. On Aug 20, 2014 1:00 PM, "Davide Italiano" wrote: > > One of my personal goals for 11 is to get rid of cloning mechanism > entirely, and pty(4) is one of the few in-kernel drivers still relying > on such mechanism. > It's not possible, at least to my understanding, converting pty(4) to > cdevpriv(9) as happened with other drivers. This is mainly because we > always need a pair of devices (/dev/ptyXX and /dev/ttyXX) and > userspace loops over ptyXX and after it successfully opens it tries to > open the other one with the same suffix. So, having a single device is > not really enough. > My option, instead, is that of removing pty(4), which is nothing more > than a compatibility driver, and move pmtx(4) code somewhere else. > The main drawback of the removal of this is that it makes impossible > to run FreeBSD <= 7 jails and SSH into them. I personally don't > consider this a huge issue, in light of the fact that FreeBSD-7 has > been EOL for a long time, but I would like to hear other people > comments. > > The code review for the proposed change can be found here: > https://reviews.freebsd.org/D659 > > If I won't get any objection I'll commit this in one week time, i.e. > August 27th. > > -- > Davide > I am all for the advancement of FreeBSD, but I for one maintain appliance products based on 7.x, most of the time I vote for out with the old in with the new... But are we certain all options for keeping compat have been explored? Just my 2c Sam Fourman Jr. > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 08:01:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 802C5FC5 for ; Thu, 21 Aug 2014 08:01:02 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 663F63435 for ; Thu, 21 Aug 2014 08:01:02 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id E54F2C2C for ; Thu, 21 Aug 2014 01:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1408608061; bh=2kaEN1yYVdEA+xbUyhreXaAV0u2vF91LK4Vp56p4qjo=; h=From:To:Subject:Date; b=Byi0DyiiZ5p9HzxnnLKbI7A1hV5jSBCigIOU/6nJQV4bmD2w8qGrm7c1CzM9W9L0r Z60bGbnQvI/W6O+hy846usYuT2gEmycplWWBGCztr6j+8jiVrbVVfqPfOyKQvZvzgz 4xRN/T8vbuwkLRglBqv/SMABKzvVYuxzpbNmTT14= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Beware, ZFS on head! Date: Thu, 21 Aug 2014 01:00:57 -0700 Message-ID: <1941128.cnvqpMJCeM@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3204357.arlZtY7Ylx"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 08:01:02 -0000 --nextPart3204357.arlZtY7Ylx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Depending on how you build it, you may either get a kernel compile fail= ure (if=20 you build zfs into the core kernel with "options ZFS"), or possibly eve= n an=20 invalid zfs.ko with an undefined symbol that can't be used at reboot ti= me. Be=20 exceptionally careful. I suggest, before rebooting, do a=20 # nm /boot/kernel/zfs.ko | grep atomic_dec If you see: U atomic_dec_64_nv .. you will have a sub-optimal reboot experience and you may want to sa= ve your=20 kernel.old. (no output =3D> you're fine =3D> carry on!) =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart3204357.arlZtY7Ylx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT9ac9AAoJEDXWlwnsgJ4EQMAH+welvkoYs/vt/b8uU7YeCAkA aZJYL96JhB1PBDn4YKr4LdaNOjsFyaUzUkAHKaAx5lYOxnsgudwxC+0huyqJ6q44 1jNYItU4PzLxkOpbZskf9Ac7j0YzVQukUa00M6/0ne6O7VNPCbsjE9WIL1SkgXDh 20Bo5IWqMahrh7qmgk08F6xiBaiwFGX0z1TMJdXv+ZOtVbPl2xXmYz2FhnFURypW KYSi/BYJ1O36hUIXamoFJDF96E6R8yLV62AGCTKSnaupmLdUTd0hNYqZ6ravHC6j o8QhQGyGYQldnTpAi0VZgq3Zh5nRX3id9cHTIkyl+QWrRuKw0loH963daA48wBg= =qpwq -----END PGP SIGNATURE----- --nextPart3204357.arlZtY7Ylx-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 10:35:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B572672E; Thu, 21 Aug 2014 10:35:05 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8EE346B; Thu, 21 Aug 2014 10:35:05 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hf2LH53VdzCQ; Thu, 21 Aug 2014 12:35:03 +0200 (CEST) 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=jakla2; t=1408617299; x=1411209300; bh=XDy P9fcubail9xd6vXYf0j/6P2hOckeSAEt+11alrHA=; b=Gj/ZGj2W3USAinS+J58 8nI25UyWWtTnsDJ9BmYSyZMN975UbvEITltqziM7zoZ0Ud1Lwy0BNu+eRfgOCYl9 VxKK47TYQncmDVuTwS30KXwmrbyc+73oNhVCpsirrL9SI6cX1V3lhPCpJeY5O0F7 UI9v6xX2DvKoalHYEI5x8Fjc= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id S3jWCBm9uQeA; Thu, 21 Aug 2014 12:34:59 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Thu, 21 Aug 2014 12:34:59 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hf2LC558Pz6M; Thu, 21 Aug 2014 12:34:59 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Thu, 21 Aug 2014 12:34:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 21 Aug 2014 12:34:59 +0200 From: Mark Martinec To: freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available Organization: J. Stefan Institute In-Reply-To: References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.2 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 10:35:05 -0000 Bryan Drewery wrote: > Ports now support enabling Stack Protector [1] support on FreeBSD 10 > i386 and amd64, and older releases on amd64 only currently. > > Support may be added for earlier i386 releases once all ports properly > respect LDFLAGS. > > To enable, just add WITH_SSP=yes to your make.conf and rebuild all > ports. > > The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all > may optionally be set instead. That's probably SSP_CFLAGS, not SSP_CLFAGS. Does clang (in 10-STABLE or CURRENT) support also the option -fstack-protector-strong ? Is 'world' by default compiled with -fstack-protector (and if not, why not). Mark From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 15:53:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 566929FB for ; Thu, 21 Aug 2014 15:53:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 365BF3608 for ; Thu, 21 Aug 2014 15:53:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7LFrfNP048993 for ; Thu, 21 Aug 2014 15:53:41 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7LFrfF0048992 for freebsd-current@freebsd.org; Thu, 21 Aug 2014 15:53:41 GMT (envelope-from bdrewery) Received: (qmail 71906 invoked from network); 21 Aug 2014 10:53:35 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 21 Aug 2014 10:53:35 -0500 Message-ID: <53F615FA.6030604@FreeBSD.org> Date: Thu, 21 Aug 2014 10:53:30 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Martinec , freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L1d2c6nOepHLleWSrekLTAvqL04Om3dD6" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:53:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L1d2c6nOepHLleWSrekLTAvqL04Om3dD6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/21/2014 5:34 AM, Mark Martinec wrote: > Bryan Drewery wrote: >> Ports now support enabling Stack Protector [1] support on FreeBSD 10 >> i386 and amd64, and older releases on amd64 only currently. >> >> Support may be added for earlier i386 releases once all ports properly= >> respect LDFLAGS. >> >> To enable, just add WITH_SSP=3Dyes to your make.conf and rebuild all p= orts. >> >> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all= >> may optionally be set instead. >=20 > That's probably SSP_CFLAGS, not SSP_CLFAGS. Nice find. >=20 >=20 > Does clang (in 10-STABLE or CURRENT) support also the > option -fstack-protector-strong ? Not sure if clang 3.4 has it, but I found a patch for it here: https://github.com/archlinuxarm/PKGBUILDs/blob/master/extra/llvm/clang-3.= 4-fstack-protector-strong.patch >=20 > Is 'world' by default compiled with -fstack-protector > (and if not, why not). World has been built with -fstack-protector by default since 2008. At least in 8.0+. >=20 > Mark > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" --=20 Regards, Bryan Drewery --L1d2c6nOepHLleWSrekLTAvqL04Om3dD6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT9hX6AAoJEDXXcbtuRpfP3+kH/09KAmslS64jiMpM2X0VttAo S/f1J87gCQnIdNbH5NWwZjHxBWOuaSoMnMywVqX1v5YirINi2kmmWAqD6owmjdux ZlvfK7Ne9u1eGJE4adHnoNPsqpDH5rKK/fKvbD1H6KClJkD3+Eo4hMpGF4a5rgQT +RawXpJEC4xR3dFoP6rM7BPHwrkVYJdpcB7xluycuJa4URZtjML7Ps1Mf/QMmohQ fz9m2eTnGATBlyWXeoBo7lhrS12O8CXCx+cHqQ/dMFAzHU/ux3A/Pa3cXxMx7T8J Z3kZCBZNqFuIC8BGMWL5Bs8/YqQrA+G/TUliVE+Hmj2hkB8jaNHn19aR+r4IyA8= =5zS+ -----END PGP SIGNATURE----- --L1d2c6nOepHLleWSrekLTAvqL04Om3dD6-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 16:07:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AACC610 for ; Thu, 21 Aug 2014 16:07:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 01301377C for ; Thu, 21 Aug 2014 16:07:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s7LG7iTG052560 for ; Thu, 21 Aug 2014 16:07:44 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s7LG7iJj052555 for freebsd-current@freebsd.org; Thu, 21 Aug 2014 16:07:44 GMT (envelope-from bdrewery) Received: (qmail 57478 invoked from network); 21 Aug 2014 11:07:43 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 21 Aug 2014 11:07:43 -0500 Message-ID: <53F61949.6050402@FreeBSD.org> Date: Thu, 21 Aug 2014 11:07:37 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Martinec , freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> <53F615FA.6030604@FreeBSD.org> In-Reply-To: <53F615FA.6030604@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K1H6qDe1gG8W5Rw04xAOp5wpg0DJ8Kdn2" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:07:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K1H6qDe1gG8W5Rw04xAOp5wpg0DJ8Kdn2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/21/2014 10:53 AM, Bryan Drewery wrote: > On 8/21/2014 5:34 AM, Mark Martinec wrote: >> Bryan Drewery wrote: >>> Ports now support enabling Stack Protector [1] support on FreeBSD 10 >>> i386 and amd64, and older releases on amd64 only currently. >>> >>> Support may be added for earlier i386 releases once all ports properl= y >>> respect LDFLAGS. >>> >>> To enable, just add WITH_SSP=3Dyes to your make.conf and rebuild all = ports. >>> >>> The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-al= l >>> may optionally be set instead. >> >> That's probably SSP_CFLAGS, not SSP_CLFAGS. >=20 > Nice find. >=20 >> >> >> Does clang (in 10-STABLE or CURRENT) support also the >> option -fstack-protector-strong ? >=20 > Not sure if clang 3.4 has it, but I found a patch for it here: I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 in CURRENT. --=20 Regards, Bryan Drewery --K1H6qDe1gG8W5Rw04xAOp5wpg0DJ8Kdn2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJT9hlJAAoJEDXXcbtuRpfP650H/10cEnYz8bEfH6YLxXUFRkFu aJu8Xrz1PBcXaCyyHD2rwXlB26CWvT8Mxq6QGec21L45+koBCIF5mTnifAoDpqjE xfTHqpohcHsDUlg9jY0wMvewFjcWNK+oJtxU6GforZNt+/qfX1U/P2ZKr6dN2HRJ TwpUhZ2HSFtgzQhq8Dl2NJUdy+fwa4vITX+VyFr7xIFZ5tBGt+D24ygo4ZeQQFtG i5ZX9CNBrur49RTlyrh8nv/ZcR59e7C5v9lbnBWx2hWmbayGHsV7Lah++oXLmz+u iYBqrbUfLCdtERn8C49XEe3cJ+4TNmRpgN1ZUFVclydZ7RyuwyYmad2Vd9OxP8g= =j4gi -----END PGP SIGNATURE----- --K1H6qDe1gG8W5Rw04xAOp5wpg0DJ8Kdn2-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 19:26:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B35946FF for ; Thu, 21 Aug 2014 19:26:26 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 6DEC13CA1 for ; Thu, 21 Aug 2014 19:26:26 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XKY01-001GRR-Rg>; Thu, 21 Aug 2014 21:26:17 +0200 Received: from g226060206.adsl.alicedsl.de ([92.226.60.206] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XKY01-003D7P-Pa>; Thu, 21 Aug 2014 21:26:17 +0200 Date: Thu, 21 Aug 2014 21:26:19 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r270287: crash Message-ID: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.3) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/WLZNGOXvzJfMNoQ+QVyx=Q1"; protocol="application/pgp-signature" X-Originating-IP: 92.226.60.206 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:26:26 -0000 --Sig_/WLZNGOXvzJfMNoQ+QVyx=Q1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I can not see at what point (on modern systems like Ivy Bridge). On older Core2Duo systems I get a trap 12 in APIC or similar. While I was able to start kernel.old on the modern systems, I fail on both kernel and kernel.old on the C2D system. I'd like to know whether there is a way to save the system I can not reboot the on-disk kernels snce they are, woderfull, compromised. Is there a possible scenario like: a) boot from DVD ROM or USB most recent snapshot b) establish network with on-disk config, svn checkout recent sources into on-disk file hierarchy c) build repaired/patched kernel and install on on-disk (not on the emergency boot media). Thanks, help appreciated and what is about this crash affecting recent CURRENT r270287, what has corrupted the system? Regards, Oliver --Sig_/WLZNGOXvzJfMNoQ+QVyx=Q1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT9kfiAAoJEOgBcD7A/5N8fFAIAJN/CaVXaJS7zb4xYAnQE6Gt hgX4QQFz1/8I3cVuCeUi1yWHOVBiQWBnEih2hhqEeUhaLyzVYiVqp+0ZyytqcaXY JDrCS8/YLWRs4WzgOnOyVjw4R42jptKq7bN2OoSDdNHObDIhEOKwKqj+S4TogtNd naU9nfYT3IyZmJ3rjrAKQj2QagOHTqVy4fcv4dl/ZYgZzymV6Xj3v3mcw1BlYd/p RtE9KBhBVWs9/m3PsRpeU6H/1DtW5QdF+ybEJtMHk6/PvMGlyWih1QKVl5QB2CAt GlLqdIdmCzc8zi/LewjRO7dszEBYWJ+3FoMOdZpZtfgLWckw/fRZHKFAUmAZuIE= =0Z8j -----END PGP SIGNATURE----- --Sig_/WLZNGOXvzJfMNoQ+QVyx=Q1-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 19:32:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01AD9BFF for ; Thu, 21 Aug 2014 19:32:05 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C626C3D6E for ; Thu, 21 Aug 2014 19:32:05 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id fp1so14403264pdb.5 for ; Thu, 21 Aug 2014 12:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qQghEFj203GtgmPRhFC+rxEeV7xS0ruBiGbYLxMCI1Y=; b=IVejD9Kz1ZaHzEv2ajybi1lHeA5MszlXPDOidj5bRvN6mHzIDecfUNdMryR7ZzE5+o D2IO5+qXdskndjaWdJlhf20/svA/8M5eNG7K3Aa8M1Tp59HWnQM2YsN11xnsDDbSqGNs pFzqwtFgWXebRA+HOEJdeYb6lC6IeRW/gcRcsB7u/wQ5+LGmgdbdIN8qftE9i/5JJis3 K/ChxzU7q1Gvfq/5KkYtkZfodofNwfDz02DcCOlFYIhIkYHFpNDAzNYZgqT60n/DVorT ipAz0vXgNfR+zwChABTMe5eYAw2bBNwYyjTuSGm9cfVYAzrSZayNqIKq86NiINACGtNZ vFaA== X-Received: by 10.68.241.138 with SMTP id wi10mr780438pbc.126.1408649525322; Thu, 21 Aug 2014 12:32:05 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:8d:53e0:9bd6:2ebb? ([2601:8:ab80:7d6:8d:53e0:9bd6:2ebb]) by mx.google.com with ESMTPSA id bo1sm18749326pdb.76.2014.08.21.12.32.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 12:32:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_905A9233-F865-4455-B099-CCA203DE8D7B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r270287: crash From: yaneurabeya@gmail.com In-Reply-To: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> Date: Thu, 21 Aug 2014 12:32:03 -0700 Message-Id: References: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> To: "O. Hartmann" X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:32:06 -0000 --Apple-Mail=_905A9233-F865-4455-B099-CCA203DE8D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 21, 2014, at 12:26 PM, O. Hartmann = wrote: > FreeBSD r270287 crashes/reboots instantanously on loading the kernel. = I > can not see at what point (on modern systems like Ivy Bridge). On = older > Core2Duo systems I get a trap 12 in APIC or similar. >=20 > While I was able to start kernel.old on the modern systems, I fail on > both kernel and kernel.old on the C2D system. >=20 > I'd like to know whether there is a way to save the system I can not > reboot the on-disk kernels snce they are, woderfull, compromised. >=20 > Is there a possible scenario like: >=20 > a) boot from DVD ROM or USB most recent snapshot > b) establish network with on-disk config, svn checkout recent sources > into on-disk file hierarchy > c) build repaired/patched kernel and install on on-disk (not on the > emergency boot media). I would grab a snapshot ISO or USB disk image: = ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/ = . After that you can mount your filesystems, revert to an earlier SVN = revision, and repair your system that way. You could also copy over the = /boot/kernel as long as you didn=92t have/need any customizations. > Thanks, help appreciated and what is about this crash affecting recent > CURRENT r270287, what has corrupted the system? That=92s a better question. Booting off newer sources worked on my VM at = least, but it=92s not real hardware. Maybe something dealing with = vt(4)/xen? HTH! -Garrett --Apple-Mail=_905A9233-F865-4455-B099-CCA203DE8D7B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT9kkzAAoJEMZr5QU6S73e/KIH/id970a+NsmmOOkT01a2xOPd gM3/mGP6a3lzh2/7LCs7EY/sa1KMsVhG2f52ci0hCRVfC++HQ9AIGlFWGyp2cUu+ hC8Wv12J8cPiCpbZZfkZU+9SfBQX4+8uGx5PorwKxCH4EUF3nLRfzzSNT01UAG0m iXcOff4/cWBkUhlN6Xf8PF9fYjOsffqiP9U9100NHYYFAqKU9DAXHNuHhajC3b34 zckn8kZ+/zRBj7uqQWg8z2NbwStx9v41cNh0OOBrAZWHf49rHsrynRpctaw5ATJU vzfC9JxpMSKbJGH/dOjjE4deMahhELyHhGjhKN9abxoebaASFBnd/gnkuy8Q3rA= =ythS -----END PGP SIGNATURE----- --Apple-Mail=_905A9233-F865-4455-B099-CCA203DE8D7B-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 21 20:47:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AA19F65 for ; Thu, 21 Aug 2014 20:47:12 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4EF35A8 for ; Thu, 21 Aug 2014 20:47:12 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so5414310iec.33 for ; Thu, 21 Aug 2014 13:47:11 -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:content-transfer-encoding; bh=HUSK6WtxVRd/rThJF8lNWuDrOQMXRdO/InaNxdKypkc=; b=ThA6GA6yrHZ0LpeVGvc1TEMw5En3C4G43Tqmq6XO9k3LKUYTTGlx030SySFo2GBlsP WwvYtNHF8aOMXwPGtirffpEASc8tfHoxBtgxSTzqZ7y8eY+4WDwRX1n6irTgfHXi/9WG phTXdrnCaZqinL9KiSS/4LLtov2Mjkgk+2Mi/Ow4FFthztQml4j7BVJ+HrJvO6oBuI/u xx1w928/JO7ao5cBCz4b2A/Px0KgciWOu3GlUNn0nMSBwHUN/xyPojjxA35moSn4TKB+ 5Y90kzC9uqkyRIFfCw22WI6I9eFSVFHdCQAr9gAc5ht5Mwlh4YGljU+Gv1TObIf9z+nS 9UKA== MIME-Version: 1.0 X-Received: by 10.42.63.129 with SMTP id c1mr3023177ici.82.1408654031496; Thu, 21 Aug 2014 13:47:11 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Thu, 21 Aug 2014 13:47:11 -0700 (PDT) In-Reply-To: References: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> Date: Thu, 21 Aug 2014 13:47:11 -0700 Message-ID: Subject: Re: r270287: crash From: Garrett Cooper To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:47:12 -0000 On Thu, Aug 21, 2014 at 12:32 PM, wrote: > On Aug 21, 2014, at 12:26 PM, O. Hartmann w= rote: > >> FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I >> can not see at what point (on modern systems like Ivy Bridge). On older >> Core2Duo systems I get a trap 12 in APIC or similar. >> >> While I was able to start kernel.old on the modern systems, I fail on >> both kernel and kernel.old on the C2D system. >> >> I'd like to know whether there is a way to save the system I can not >> reboot the on-disk kernels snce they are, woderfull, compromised. >> >> Is there a possible scenario like: >> >> a) boot from DVD ROM or USB most recent snapshot >> b) establish network with on-disk config, svn checkout recent sources >> into on-disk file hierarchy >> c) build repaired/patched kernel and install on on-disk (not on the >> emergency boot media). > > I would grab a snapshot ISO or USB disk image: ftp://ftp.freebsd.org/pub/= FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/ . After that you can mount y= our filesystems, revert to an earlier SVN revision, and repair your system = that way. You could also copy over the /boot/kernel as long as you didn=E2= =80=99t have/need any customizations. > >> Thanks, help appreciated and what is about this crash affecting recent >> CURRENT r270287, what has corrupted the system? > > That=E2=80=99s a better question. Booting off newer sources worked on my = VM at least, but it=E2=80=99s not real hardware. Maybe something dealing wi= th vt(4)/xen? One important note is that my CURRENT VM on my Macbook runs i386, not a= md64. Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 08:47:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45D63BEB for ; Fri, 22 Aug 2014 08:47:13 +0000 (UTC) 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 09DF4360B for ; Fri, 22 Aug 2014 08:47:12 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=i915.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XKkV4-000O56-S2 for freebsd-current@freebsd.org; Fri, 22 Aug 2014 10:47:11 +0200 Message-ID: <53F7038E.3080005@dumbbell.fr> Date: Fri, 22 Aug 2014 10:47:10 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: r269471 make unusable VT console References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> In-Reply-To: <53F37B2D.3070807@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:47:13 -0000 On 19.08.2014 18:28, Jean-Sbastien Pdron wrote: > Here's a first version of the patch I was talking about: > https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. -- Jean-Sbastien Pdron From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 09:17:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68792690 for ; Fri, 22 Aug 2014 09:17:20 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2676338A0 for ; Fri, 22 Aug 2014 09:17:20 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id e89so9997299qgf.17 for ; Fri, 22 Aug 2014 02:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rYIE6aHzRBpGpL59MXLhV9U1zQ1wg2/METeVyUspPCw=; b=v9uKl4tedFnSEZHx/2E/uPqocU/RJfg0sk1BQF4TDVoKMjuQHJsST+JsFEkjo+p2HR cXcWf6Ojc3uk6nfcW9SIjE+uxjMYmKaJNO9nNHKoOatcIiVXKyOcONGeyaHYWVlbP+3o YBWMELRgaraooistYAutXWmgytUPeD4Xd4AfyAkDYml/VX0z0JHC+sDUzBCCe9vHtO5+ ISFswkcQt5Doh3iYw5waMeL8qufB6j87eZOj9HRhmN3IwTlM9YhFTwfundbBkc+NVI7f INm92dm/W7gVzMz8q9ib8B6EpH7tbGj5r95bRAp5/3vmTAZ6iglwWpYjO7hGExmk23bh DFPQ== MIME-Version: 1.0 X-Received: by 10.229.202.199 with SMTP id ff7mr5986564qcb.9.1408699039180; Fri, 22 Aug 2014 02:17:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Fri, 22 Aug 2014 02:17:19 -0700 (PDT) In-Reply-To: <53F7038E.3080005@dumbbell.fr> References: <20140812232807.0f3aa02570becec15e056af2@fbsd.es> <20140816011444.301a98d6187aca27e3a2481b@ddteam.net> <53EE9CFF.4080607@freebsd.org> <53F30DF3.1090301@dumbbell.fr> <53F37B2D.3070807@FreeBSD.org> <53F7038E.3080005@dumbbell.fr> Date: Fri, 22 Aug 2014 02:17:19 -0700 X-Google-Sender-Auth: ynl56yWX2NkluU8yysvV5_vZjWw Message-ID: Subject: Re: r269471 make unusable VT console From: Adrian Chadd To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 09:17:20 -0000 On 22 August 2014 01:47, Jean-S=C3=A9bastien P=C3=A9dron wrote: > On 19.08.2014 18:28, Jean-S=C3=A9bastien P=C3=A9dron wrote: >> >> Here's a first version of the patch I was talking about: >> https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch > > > This is now in HEAD, as of r270322. Again, this is unfinished work, but i= t > already brings improvements. Woo! Thanks! -a From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 11:34:40 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 378EBB7D; Fri, 22 Aug 2014 11:34:40 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 B5A5135B1; Fri, 22 Aug 2014 11:34:39 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s7MBYYtI037780; Fri, 22 Aug 2014 13:34:34 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 636B93E17; Fri, 22 Aug 2014 13:34:34 +0200 (CEST) Message-ID: <53F72AC4.7040108@omnilan.de> Date: Fri, 22 Aug 2014 13:34:28 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Yuri Subject: Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2)) References: <522300E3.6050303@rawbw.com> <522419F4.5010605@rawbw.com> In-Reply-To: <522419F4.5010605@rawbw.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBDCF6DF9B7F08E8A477FFBB7" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 22 Aug 2014 13:34:35 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 11:34:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBDCF6DF9B7F08E8A477FFBB7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): > Please check in this patch: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181741 > Please MFC into 9.X > > Description of the problem is within PR. > > Thanks, > Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? Thanks, -Harry --------------enigBDCF6DF9B7F08E8A477FFBB7 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.18 (FreeBSD) iEYEARECAAYFAlP3KskACgkQLDqVQ9VXb8hkZACeMRKTFHVdEG/8uqycKIwJg1j4 howAoMJ1D9CS492eJD8ikl4NIJUfWhu7 =PhYh -----END PGP SIGNATURE----- --------------enigBDCF6DF9B7F08E8A477FFBB7-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 16:07:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 311B7836; Fri, 22 Aug 2014 16:07:41 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD823347B; Fri, 22 Aug 2014 16:07:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e0c6:9330:fbaa:25a7] (unknown [IPv6:2001:7b8:3a7:0:e0c6:9330:fbaa:25a7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 71D75B803; Fri, 22 Aug 2014 18:07:29 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_CD016B2C-64EC-41AC-B961-F8A38CC90A5F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT] SSP Package Repository available From: Dimitry Andric In-Reply-To: <53F61949.6050402@FreeBSD.org> Date: Fri, 22 Aug 2014 18:07:16 +0200 Message-Id: References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> <53F615FA.6030604@FreeBSD.org> <53F61949.6050402@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.1878.6) Cc: Mark Martinec , freebsd-current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:07:41 -0000 --Apple-Mail=_CD016B2C-64EC-41AC-B961-F8A38CC90A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Aug 2014, at 18:07, Bryan Drewery wrote: > On 8/21/2014 10:53 AM, Bryan Drewery wrote: >> On 8/21/2014 5:34 AM, Mark Martinec wrote: >>> Bryan Drewery wrote: >>>> Ports now support enabling Stack Protector [1] support on FreeBSD = 10 >>>> i386 and amd64, and older releases on amd64 only currently. >>>>=20 >>>> Support may be added for earlier i386 releases once all ports = properly >>>> respect LDFLAGS. >>>>=20 >>>> To enable, just add WITH_SSP=3Dyes to your make.conf and rebuild = all ports. >>>>=20 >>>> The default SSP_CLFAGS is -fstack-protector, but = -fstack-protector-all >>>> may optionally be set instead. >>>=20 >>> That's probably SSP_CFLAGS, not SSP_CLFAGS. >>=20 >> Nice find. >>=20 >>>=20 >>>=20 >>> Does clang (in 10-STABLE or CURRENT) support also the >>> option -fstack-protector-strong ? >>=20 >> Not sure if clang 3.4 has it, but I found a patch for it here: >=20 > I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 = in > CURRENT. Indeed, support for -fstack-protector-strong was added after clang 3.4. Upstream is in the process of releasing clang 3.5; they're currently at -rc3, and unless something weird happens, the actual release should be soonish. That said, it might take a while to get this version into the base system, because there are some problems to overcome. The major one being, after 3.4 llvm and clang require a C++11-compatible compiler and standard library to build. :-) If there is a great demand for -fstack-protector-strong support, I can see if it can be backported to our 3.4 version. -Dimitry --Apple-Mail=_CD016B2C-64EC-41AC-B961-F8A38CC90A5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlP3ar0ACgkQsF6jCi4glqNbmwCg8SYm7jnC6VpIhQV3JW3iNWp6 LkMAoLOG2K/OAlZhmy0VxqHiLwlZM6bQ =9sNE -----END PGP SIGNATURE----- --Apple-Mail=_CD016B2C-64EC-41AC-B961-F8A38CC90A5F-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 16:49:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50D19809 for ; Fri, 22 Aug 2014 16:49:17 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D218838CC for ; Fri, 22 Aug 2014 16:49:16 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id ty20so10318044lab.18 for ; Fri, 22 Aug 2014 09:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=ZffaQC6cYkaVfV4D7UMcCxbyU3KYASgk/ZdR5zhqpYg=; b=G56gJlPZVOHveW1zt3KZPCpIPINnZsv58RHNogLLxduwdlzY6dDgkEDue+bsjIQJ4X RCvmcxfwJFG4IattfnyDgb6t3B0OLdvGQGUeQY/uMPr/v59Ic2ythgjl+70dVjw7LZgc 5kT9S9fyJMR43YJpEVJ174LUtwzz2XzEZeVFgA75/2aSKOxkHgHOISxzxK4AiXY9WUwQ TakoTJLrA4TAEA/I3inbSLtBMxsMrpNXzbQ1YJjjAN4Snju5jY60yF8duQJwHa6j2Ucv ALGCxrZJ/hufjFwmuc3CJOw3CwYwEessmi0WzMtQDugf1djgOE2yre2vsBG8rzZecuJD o9vg== MIME-Version: 1.0 X-Received: by 10.112.163.103 with SMTP id yh7mr5371062lbb.73.1408726154640; Fri, 22 Aug 2014 09:49:14 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Fri, 22 Aug 2014 09:49:14 -0700 (PDT) Date: Fri, 22 Aug 2014 09:49:14 -0700 X-Google-Sender-Auth: sPStit8XTFWWC_KD3-SXHZSML8k Message-ID: Subject: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:49:17 -0000 Hi, I did the following: (1) Created a chroot from a src checkout/build with: make installworld DESTDIR=/opt2/branches/test1 make installkernel DESTDIR=/opt2/branches/test1 make distribution DESTDIR=/opt2/branches/test1 (2) Created a UFS image, /tmp/file.img using makefs based on the contents of /opt2/branches/test1 (3) Verified with bhyve that the UFS image booted properly. (4) Created an image with: cd /opt2/branches mkimg -v -s gpt -b test1/boot/pmbr -p freebsd-boot:=test1/boot/gptboot -p freebsd-ufs:=/tmp/file.img -o /tmp/foo1.img (5) Tried to boot the image with qemu: qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img SeaBIOS (version rel-1.7.4-0-g96917a8-20140203_153353-nilsson.home.kraxel.org) iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+7FFC6110+7FF26110 C900 Booting from Hard Disk... BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/2096120kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@dibbler.crodrigues.org, Wed Aug 20 21:58:27 PDT 2014) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK If I mdconfig the foo1.img disk image, and do a gpart show, I see: => 3 1784944 md0 GPT (872M) 3 32 1 freebsd-boot (16K) 35 1784912 2 freebsd-ufs (872M) Any idea what I am doing wrong? Thanks. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 17:24:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BE87948; Fri, 22 Aug 2014 17:24:51 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id C16153D6E; Fri, 22 Aug 2014 17:24:50 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hfqNc4cpFz184; Fri, 22 Aug 2014 19:24:48 +0200 (CEST) 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=jakla2; t=1408728278; x=1411320279; bh=FNN F8ueDjyw9445L6wg3pN1LEmIpZvxIorQbmul18yE=; b=cfOFrRCqvJtb7S1m9eT oxBqY4aSsq4EsLaXpxn8D/xPNSC9g9yTdUVtPpyJOkOqIZewFiZDgP7E+T4RE/hf hbHtpO2wYUET2NBX8bM5MnCAan1CJj/vEBZaoE/WNnqFQ0SWCNDmBPBPXxQPDehc 3VTjtU9CcXeYt5YTdvKGgEho= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id xX4380njnH3H; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hfqNQ2QFXzJY; Fri, 22 Aug 2014 19:24:38 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Fri, 22 Aug 2014 19:24:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Aug 2014 19:24:38 +0200 From: Mark Martinec To: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [CFT] SSP Package Repository available Organization: J. Stefan Institute In-Reply-To: References: <523D79CD.2090302@FreeBSD.org> <53F4CE0E.8040106@FreeBSD.org> <53F615FA.6030604@FreeBSD.org> <53F61949.6050402@FreeBSD.org> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:24:51 -0000 2014-08-22 18:07, Dimitry Andric wrote: > On 21 Aug 2014, at 18:07, Bryan Drewery wrote: >> On 8/21/2014 10:53 AM, Bryan Drewery wrote: >>> On 8/21/2014 5:34 AM, Mark Martinec wrote: >>>> Does clang (in 10-STABLE or CURRENT) support also the >>>> option -fstack-protector-strong ? >>>=20 >>> Not sure if clang 3.4 has it, but I found a patch for it here: >>=20 >> I'm told that clang 3.5 has support for it. We do not (yet) have 3.5=20 >> in >> CURRENT. >=20 > Indeed, support for -fstack-protector-strong was added after clang 3.4. > Upstream is in the process of releasing clang 3.5; they're currently at > -rc3, and unless something weird happens, the actual release should be > soonish. >=20 > That said, it might take a while to get this version into the base > system, because there are some problems to overcome. The major one > being, after 3.4 llvm and clang require a C++11-compatible compiler and > standard library to build. :-) >=20 > If there is a great demand for -fstack-protector-strong support, I can > see if it can be backported to our 3.4 version. Don't know how much demand there is. Just these days I was investigating what looks like a memory corruption in perl under FreeBSD 10, and=20 realized the -fstack-protector-strong would be just the right thing to try first. (I ended up recompiling perl with gcc48). Just some random references I came across: https://en.wikipedia.org/wiki/Buffer_overflow_protection All Fedora packages are compiled with -fstack-protector since Fedora Core 5, and -fstack-protector-strong since Fedora 20. [...] All Arch Linux packages built since 4 May 2014 use -fstack-protector-strong. https://fedorahosted.org/fesco/ticket/1128 Benefit over the current default "-fstack-protector" =3D>=20 "-fstack-protector" is regarded as "not secure enough" (only "protects" < 2% functions in Chromium project). "-fstack-protector-strong" hits the balance between= =20 the over-simplified "-fstack-protector" and over-killing=20 "-fstack-protector-all". [...] The stack-protector option is over-simplified, which ignores pointer=20 cast, address computation, while the stack-protector-all is over-killing, using this option results in too much performance overhead. http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/ A normal x86_64 =E2=80=9Cdefconfig=E2=80=9D build, without stack protect= or had a kernel text size of 11430641 bytes with 36110 function bodies. Adding CONFIG_CC_STACKPROTECTOR_REGULAR increased the kernel text size to 11468490 (a +0.33% change), with 1015 of 36110 functions stack-protected (2.81%). Using CONFIG_CC_STACKPROTECTOR_STRONG increased the kernel text size to 11692790 (+2.24%), with 7401 of 36110 functions stack-protected (20.5%). And 20% is a far-cry from 100% if support for -fstack-protector-all was added back to the kernel. > If there is a great demand for -fstack-protector-strong support, > I can see if it can be backported to our 3.4 version. I guess the answer to that question is whether the goal/wish of a default WITH_SSP_PORTS / SSP_CFLAGS would be to switch to the -fstack-protector-strong before clang 3.5 comes into base. Mark From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 19:08:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69A4FD4A for ; Fri, 22 Aug 2014 19:08:08 +0000 (UTC) Received: from odin.blazingdot.com (odin.blazingdot.com [204.109.60.170]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBEA381E for ; Fri, 22 Aug 2014 19:08:08 +0000 (UTC) Received: by odin.blazingdot.com (Postfix, from userid 1001) id 4B72D130CCD; Fri, 22 Aug 2014 15:02:46 -0400 (EDT) Date: Fri, 22 Aug 2014 15:02:46 -0400 From: Marcus Reid To: "O. Hartmann" Subject: Re: r270287: crash Message-ID: <20140822190246.GA1069@blazingdot.com> References: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:08:08 -0000 On Thu, Aug 21, 2014 at 09:26:19PM +0200, O. Hartmann wrote: > FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I > can not see at what point (on modern systems like Ivy Bridge). On older > Core2Duo systems I get a trap 12 in APIC or similar. Are you using VirtualBox? I just fixed a crash that fits your description by recompiling virtualbox-ose-kmod. Marcus From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 19:16:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D919243C for ; Fri, 22 Aug 2014 19:16:34 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id BD7813919 for ; Fri, 22 Aug 2014 19:16:34 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id A21EB56436 for ; Fri, 22 Aug 2014 14:16:33 -0500 (CDT) Message-ID: <53F79710.6090700@vangyzen.net> Date: Fri, 22 Aug 2014 15:16:32 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: ktrace -c behavior Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:16:34 -0000 What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. ...I would expect the second command to clear the trace point for context switches. It doesn't. I have to specify -tw with the -c to get that behavior. This makes sense; it's just not what I was expecting. Assuming we want to keep this behavior, can we clarify the -c flag in man page? I would suggest: If the -t flag is not specified, clear the default set of trace points. Thanks, Eric From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 19:20:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0E0A574 for ; Fri, 22 Aug 2014 19:20:36 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C70739B8 for ; Fri, 22 Aug 2014 19:20:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7MJKYZ5043119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 12:20:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7MJKYvx043118; Fri, 22 Aug 2014 12:20:34 -0700 (PDT) (envelope-from jmg) Date: Fri, 22 Aug 2014 12:20:34 -0700 From: John-Mark Gurney To: Eric van Gyzen Subject: Re: ktrace -c behavior Message-ID: <20140822192034.GA71691@funkthat.com> Mail-Followup-To: Eric van Gyzen , freebsd-current@freebsd.org References: <53F79710.6090700@vangyzen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F79710.6090700@vangyzen.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 22 Aug 2014 12:20:35 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:20:36 -0000 Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: > What behavior would you expect from this sequence of commands? > > ktrace -tw -p 1234 > ktrace -c -p 1234 > > Based on this... > > -c Clear the trace points associated with the specified file > or processes. and/or just add specified: Clear the specified trace points ... > ...I would expect the second command to clear the trace point for > context switches. It doesn't. I have to specify -tw with the -c to get > that behavior. This makes sense; it's just not what I was expecting. > > Assuming we want to keep this behavior, can we clarify the -c flag in > man page? I would suggest: > > If the -t flag is not specified, clear the default set of trace points. Maybe we should add a new trace point string that is a (for all).. so you can do ktrace -ta -c? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 19:26:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F651A70 for ; Fri, 22 Aug 2014 19:26:43 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 11F333A34 for ; Fri, 22 Aug 2014 19:26:42 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 406CB56436 for ; Fri, 22 Aug 2014 14:26:42 -0500 (CDT) Message-ID: <53F79971.4050802@vangyzen.net> Date: Fri, 22 Aug 2014 15:26:41 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ktrace -c behavior References: <53F79710.6090700@vangyzen.net> <20140822192034.GA71691@funkthat.com> In-Reply-To: <20140822192034.GA71691@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:26:43 -0000 On 08/22/2014 15:20, John-Mark Gurney wrote: > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: >> What behavior would you expect from this sequence of commands? >> >> ktrace -tw -p 1234 >> ktrace -c -p 1234 >> >> Based on this... >> >> -c Clear the trace points associated with the specified file >> or processes. > and/or just add specified: > Clear the specified trace points ... But what if I didn't specify them? >> ...I would expect the second command to clear the trace point for >> context switches. It doesn't. I have to specify -tw with the -c to get >> that behavior. This makes sense; it's just not what I was expecting. >> >> Assuming we want to keep this behavior, can we clarify the -c flag in >> man page? I would suggest: >> >> If the -t flag is not specified, clear the default set of trace points. > Maybe we should add a new trace point string that is a (for all).. so > you can do ktrace -ta -c? That would be handy. Eric From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 20:45:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB2E9A0A; Fri, 22 Aug 2014 20:45:41 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (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 81CA03270; Fri, 22 Aug 2014 20:45:40 +0000 (UTC) Received: from [172.29.13.53] ([66.129.239.12]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7MKjVO2063690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Aug 2014 13:45:33 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_AF903E99-764A-4C6C-BB17-9990EA486BEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: Date: Fri, 22 Aug 2014 13:45:26 -0700 Message-Id: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:45:41 -0000 --Apple-Mail=_AF903E99-764A-4C6C-BB17-9990EA486BEC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Aug 22, 2014, at 9:49 AM, Craig Rodrigues wrote: > > (5) Tried to boot the image with qemu: > > qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img *snip* > If I mdconfig the foo1.img disk image, and do a gpart show, I see: > > => 3 1784944 md0 GPT (872M) > 3 32 1 freebsd-boot (16K) > 35 1784912 2 freebsd-ufs (872M) > > Any idea what I am doing wrong? To the best of my knowledge, qemu is the thing you're doing wrong :-) I have so far not been able to boot an image created by mkimg with a FreeBSD-hosted qemu. o VMware and VirtualBox are fine. o A non-FreeBSD hosted qemu also works fine. If your host is running -current, make sure to set MALLOC_CONF=junk:false. It improves behaviour on FreeBSD for boot0/boo1. HTH (probably not), -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_AF903E99-764A-4C6C-BB17-9990EA486BEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP3q+YACgkQpgWlLWHuifaVtACZAQb8lsBLWhd2gf3eUQRHaazu EjQAn08QJPUlK3klu06C7PSFwog3mkkO =PXbQ -----END PGP SIGNATURE----- --Apple-Mail=_AF903E99-764A-4C6C-BB17-9990EA486BEC-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 20:49:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8633B4B for ; Fri, 22 Aug 2014 20:49:32 +0000 (UTC) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 704203295 for ; Fri, 22 Aug 2014 20:49:32 +0000 (UTC) Received: from fwd17.aul.t-online.de (fwd17.aul.t-online.de [172.20.27.64]) by mailout07.t-online.de (Postfix) with SMTP id E4EBE47D5E7 for ; Fri, 22 Aug 2014 22:49:23 +0200 (CEST) Received: from mail.jd.home (E2srZQZfZhQEGS8C-tdJu+dFGgdXYyyiDuIAGOjJWz6objp4AN6d2rdDOX+z+xnQA5@[91.55.227.12]) by fwd17.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1XKvly-3aN47M0; Fri, 22 Aug 2014 22:49:22 +0200 Received: from router.jd.home (unknown [127.0.0.1]) by mail.jd.home (Postfix) with ESMTP id 8379320690 for ; Fri, 22 Aug 2014 22:49:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jd.home Received: from mail.jd.home ([127.0.0.1]) by router.jd.home (mail.jd.home [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAPwMZ91S9WA for ; Fri, 22 Aug 2014 22:49:16 +0200 (CEST) Received: from t400-fedora.jd.home (t400-fedora.jd.home [192.168.1.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.jd.home (Postfix) with ESMTPSA id 318112068C for ; Fri, 22 Aug 2014 22:49:16 +0200 (CEST) Message-ID: <53F7ACCB.8000701@T-Online.de> Date: Fri, 22 Aug 2014 22:49:15 +0200 From: =?ISO-8859-15?Q?J=FCrgen_Dankoweit?= Reply-To: Juergen.Dankoweit@T-Online.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [patch] USB after second suspend/resume on ThinkPads. References: <20140616192155.GE13481@brick.home> In-Reply-To: <20140616192155.GE13481@brick.home> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ID: E2srZQZfZhQEGS8C-tdJu+dFGgdXYyyiDuIAGOjJWz6objp4AN6d2rdDOX+z+xnQA5 X-TOI-MSGID: f170378d-454f-4ab6-bd1b-e21903ac71f0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:49:32 -0000 Hello, Thanks for the patch. It works without any problems on my Thinkpad T400 with FreeBSD 10.0. Best regards Juergen -------------------------------------------------------------------------- Homepage: www.dankoweit.de From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 21:15:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14AEC400; Fri, 22 Aug 2014 21:15:58 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1013551; Fri, 22 Aug 2014 21:15:57 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id x19so7232904ier.34 for ; Fri, 22 Aug 2014 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pgIU6KcAcMzMgGYcJrQ0R+VYeRIl/aLrFUj6nQLj5FY=; b=j98CEh9HPA+jdl/0omcujiL8jR+gbiAhzGVMHwj7OwWQtf0s8MhTufqa98+MIstQiV XhwXKp/49IIYl6mAlfz8tf2zremot41dOHJR575OaVLuvbXZY2Cj82zSEZwjq6r2DmzS Al+r7TWbmRUIXL6QBo+r6mEUejZfMesaURZJwlgzNt+Y3S969eYxjpqlbCHhsOkQ4k82 dJyiiPn9nB62keCjAy4mua5qS4Z1B/i+YlM3obpbCIoT0G4mfIsoRUrkz7qjVeJpcQGG nyZr9W4hPrf3xkAYrLqaiF89n/96vk0Ar92ivYqnKi6e66fNvCNTXtpS9FhuVgX3jD2u 3RZg== X-Received: by 10.50.62.50 with SMTP id v18mr1044863igr.21.1408742157201; Fri, 22 Aug 2014 14:15:57 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Fri, 22 Aug 2014 14:15:37 -0700 (PDT) In-Reply-To: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> From: Ed Maste Date: Fri, 22 Aug 2014 17:15:37 -0400 X-Google-Sender-Auth: 7VCBtxHyTyJ_sd5sYMRJlUcO6K4 Message-ID: Subject: Re: mkimg used to create gpt image, problem booting To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:15:58 -0000 On 22 August 2014 16:45, Marcel Moolenaar wrote: > > I have so far not been able to boot an image created > by mkimg with a FreeBSD-hosted qemu. > o VMware and VirtualBox are fine. > o A non-FreeBSD hosted qemu also works fine. For what it's worth, I have no trouble booting a mkimg-created image with QEMU on FreeBSD, and have been using it regularly for vt(4) and UEFI development. Some particulars: * Host is amd64 stable/10 with some additional MFC candidates (uname reports "FreeBSD 10.0-STABLE #1 r268946+94ba9c8(stable-10)") * My mkimg command was "mkimg -s gpt -b $ROOTDIR/boot/pmbr -p efi:=$ROOTDIR/boot/boot1.efifat -p freebsd-boot:=$ROOTDIR/boot/gptboot -p freebsd-ufs:=ufs -p freebsd-swap::1M -o img" * QEMU installed from the package, qemu-devel-2.0.0_2 * SeaBIOS version info printed at startup is the same as Craig's From owner-freebsd-current@FreeBSD.ORG Fri Aug 22 22:29:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD62D59B for ; Fri, 22 Aug 2014 22:29:33 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 974173B23 for ; Fri, 22 Aug 2014 22:29:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XKxKm-002fIi-Sq>; Sat, 23 Aug 2014 00:29:24 +0200 Received: from g229106249.adsl.alicedsl.de ([92.229.106.249] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XKxKm-001OJl-QZ>; Sat, 23 Aug 2014 00:29:24 +0200 Date: Sat, 23 Aug 2014 00:29:13 +0200 From: "O. Hartmann" To: Marcus Reid Subject: Re: r270287: crash Message-ID: <20140823002913.134ff447@munin.walstatt.dyndns.org> In-Reply-To: <20140822190246.GA1069@blazingdot.com> References: <20140821212619.6bdffad0@munin.walstatt.dyndns.org> <20140822190246.GA1069@blazingdot.com> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.3) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/nsfaj8=_XKjnw/t/muYW0EF"; protocol="application/pgp-signature" X-Originating-IP: 92.229.106.249 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 22:29:33 -0000 --Sig_/nsfaj8=_XKjnw/t/muYW0EF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 22 Aug 2014 15:02:46 -0400 Marcus Reid wrote: > On Thu, Aug 21, 2014 at 09:26:19PM +0200, O. Hartmann wrote: > > FreeBSD r270287 crashes/reboots instantanously on loading the > > kernel. I can not see at what point (on modern systems like Ivy > > Bridge). On older Core2Duo systems I get a trap 12 in APIC or > > similar. >=20 > Are you using VirtualBox? I just fixed a crash that fits your > description by recompiling virtualbox-ose-kmod. >=20 > Marcus I indeed use VirtualBox, but as of this moment, I have disabled the loading of the kernel module. The box still gets stuck and for unknown reason, ALL(!!!!) CURRENT systems (different generatins of hardware, with or without integrated GPU) show question marks on the screen and no usefull screen when vt is enabled and in backward vga compatible mode. This also happens with nVidia dedicated PCIe GPUs as well as with Ivy Bridge integrated IGP 2500. The port virtualbox-ose-kmod is compiled everytime I compile a kernel/kernel mods via=20 PORTS_MODULES=3D"emulators/virtualbox-ose-kmod" in /etc/src.conf. This unmature vt stuff starts to bother. --Sig_/nsfaj8=_XKjnw/t/muYW0EF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT98REAAoJEOgBcD7A/5N8HNsH/3mOu+ifiPjDw7VVS3VcHVrk sRC2i3UppvQOMpTlICdHoqstR4aVfDJfFpWzgTxaqmhoOCbmzPdrbS330rNLagbB RioE8GU08Tz5TsNfFH4rpXpBpCs9PnvAJQlRTobqLsqQGgbnakXOiip2x5F8QsHe PyTCgStZPslrSPNcS25+U8x01s5+QTJH6NdeJk+lIRakGCuNiBrZglgqgXvDpkTs kvIsQSWo57TMqVw9Nj7aftc7W+GolMMhAtDsWYPLtbcMMWNWGpreF5h5xIiLdRtC Fo8VTwkgdi8L1tqp0WtC4Zyl5vt+DWBXeLiqdZB77kQum08J2XA1cAUDZAc7SgY= =vQt/ -----END PGP SIGNATURE----- --Sig_/nsfaj8=_XKjnw/t/muYW0EF-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 05:16:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC3AF15D for ; Sat, 23 Aug 2014 05:16:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 95FB53F50 for ; Sat, 23 Aug 2014 05:16:36 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XL3gn-003ZKP-UW>; Sat, 23 Aug 2014 07:16:33 +0200 Received: from f052160134.adsl.alicedsl.de ([78.52.160.134] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XL3gn-001vTb-SV>; Sat, 23 Aug 2014 07:16:33 +0200 Date: Sat, 23 Aug 2014 07:16:28 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze Message-ID: <20140823071628.5722d405@munin.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.3) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/S8I7pdQUuWMNmNdsCLtxQkE"; protocol="application/pgp-signature" X-Originating-IP: 78.52.160.134 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 05:16:36 -0000 --Sig_/S8I7pdQUuWMNmNdsCLtxQkE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On different platforms with different graphics hardware, recent CURRENT r 270386 shows a screen filled with question marks when booting, impossible to check the status or make enter commands. The systems don't boot into X11 graphical mode on systems were configured, they freeze. Those freezes/crashes happen on dedicated GPUs (all nVidia with nVidia BLOB). All systems use new vt in vga compat mode/textmode. The question marks occur on all systems, with Intel HD2500/HD2000 iGPU and on dedicated GPU hardware. Except of the nVidia BLOB, the freezing box doesn't load any suspicous kernel (foreign) kernel module (like vboxdrv.ko) at the time.=20 I expect at least the vga textmode console in vt() working. Can the inventor of this mess plaese revert the code to a working version? --Sig_/S8I7pdQUuWMNmNdsCLtxQkE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT+COyAAoJEOgBcD7A/5N87A4H/2G5kyF6TqUoM3mi/i6V31yY PLU4RpMZHO+VJZLdQf0SgtQIKJBVvmB1Yvx3N+5+Bxi66RCBKy9+7CcoT21aAVq8 uMLcHW9fM2FQShXdDPDjbpcArJm1twgE+7nk+92EVPmirhY4cjwajhhv/Hg0lLnq FNbPTjr+oYsIhAWkWhZSbTsFrdZH/t9t7ZubjCyesv9QIaPsiD9bhREVNLiiGJSv 1Uwx/rQMubpIbArsqcjyX+u/k7WTbn8Ytnc5zD96Dgncf9sIDd5ppqRAovCsDiq9 RJbmDZunqDvcJrkqKf1yklpuznNmnFSBlBHMvBBFt1ixqtyTVWea2RwLgNI+qqY= =tbpS -----END PGP SIGNATURE----- --Sig_/S8I7pdQUuWMNmNdsCLtxQkE-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 05:57:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE515957 for ; Sat, 23 Aug 2014 05:57:41 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 76D523266 for ; Sat, 23 Aug 2014 05:57:41 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XL4KZ-003egy-Hy>; Sat, 23 Aug 2014 07:57:39 +0200 Received: from g226057125.adsl.alicedsl.de ([92.226.57.125] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XL4KZ-001yeb-Fs>; Sat, 23 Aug 2014 07:57:39 +0200 Date: Sat, 23 Aug 2014 07:57:34 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT]: r270386: PANIC: ncpus is 0 with non-zero map when vt() is used Message-ID: <20140823075734.1687e584@munin.walstatt.dyndns.org> In-Reply-To: <20140823071628.5722d405@munin.walstatt.dyndns.org> References: <20140823071628.5722d405@munin.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd9.3) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/xWv81Rz9dOWMwR2yrRJ/c3n"; protocol="application/pgp-signature" X-Originating-IP: 92.226.57.125 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 05:57:41 -0000 --Sig_/xWv81Rz9dOWMwR2yrRJ/c3n Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Current r 270386 crashes/freezes with a "panic: ncpus is 0 with non-zero map" when used with vt() console (in text mode, on nVidia GTX560Ti device with nVidia BLOB 343.13). Disabling the nVidia BLOB results in the same crash. --Sig_/xWv81Rz9dOWMwR2yrRJ/c3n Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT+C1TAAoJEOgBcD7A/5N8Qe8IALfTRC9oecnepjTIQSccZVK/ nyD0n97rYQIpxnrxMgJBL7cv58ScHuW/sWIm8GkRqUmSHBuJHT8d2EC7RjsuakUq rXSydH71CrjGGmDexIMM2EJFKKm7MvM1ULn3ZrQNzSGqAfxnt3aATeMvmi9sIXSu 6xRInrng4BrknWIhwTc3mKHJoq0pb1lm1DUvaQP4fpn3QDOtW5dxAYbW5pmm8Vqr BT/rc1vZN+FW9hGAYilLjDGMnSaECXpL/L4afPERoGWeKXATZZbbsfZPl3dEAo4U 91unDhbvWNgWbhgYHuvxtr10EjHl0AhMiLewtD0WZ8Xukb0PL4N2DgExqt1CsXE= =mjgm -----END PGP SIGNATURE----- --Sig_/xWv81Rz9dOWMwR2yrRJ/c3n-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 06:38:55 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20198F65; Sat, 23 Aug 2014 06:38:55 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0656C354A; Sat, 23 Aug 2014 06:38:54 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 6620CA255; Fri, 22 Aug 2014 23:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1408775933; x=1408790333; bh=zsC6jf6k8xXa8zZXmqPYwU592LOQhnsDLBRrKpDTD0M=; h=Date:From:Reply-To:To:CC:Subject; b=TiT9/tcoImO3cHyVddvMNY3WHCOTRiRCYPDOKQJekaKNgP/um2iTzEHnC64MHJepZ GKfHsSTuD6M3dceNr5aMMddwEfO0uBjb40v+sUVGqX+kOoViBAD2/n1IBxSxDxcDD/ lvSzmyq43QYlxKU1IPcmCSUX80U9fqYTTkH0sHF0= Message-ID: <53F836FC.9000104@delphij.net> Date: Fri, 22 Aug 2014 23:38:52 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: FreeBSD Current , =?UTF-8?B?SmVhbi1Tw6li?= =?UTF-8?B?YXN0aWVuIFDDqWRyb24=?= Subject: Recent vt(4) broke moused when hw.vga.textmode=1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: re@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 06:38:55 -0000 Hi, I have seen this panic via serial console, but the console is completely unusable at the time. VGA console is full of '?'. Booting single user mode, I can provoke the panic with '/etc/rc.d/moused start ums0'. === Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 0e Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c cpuid = 6; fault code = supervisor read data, page not present apic id = 0c instruction pointer = 0x20:0xffffffff803abcf7 fault virtual address = 0x2c stack pointer = 0x28:0xfffffe085f1b3880 fault code = supervisor read data, page not present frame pointer = 0x28:0xfffffe085f1b38e0 instruction pointer = 0x20:0xffffffff803ae562 code segment = base 0x0, limit 0xfffff, type 0x1b stack pointer = 0x28:0xfffffe083c9b9950 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, frame pointer = 0x28:0xfffffe083c9b9a10 IOPL = 0 current process = code segment = base 0x0, limit 0xfffff, type 0x1b The instruction pointer is Line 831 of "/usr/src/sys/dev/vt/vt_core.c". Reverting /sys/dev/vt to r270269 would solve the panic, but I haven't investigated further. Cheers, From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 06:44:21 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4442F139; Sat, 23 Aug 2014 06:44:21 +0000 (UTC) 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 0A9FD35E6; Sat, 23 Aug 2014 06:44:20 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=i915.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XL53i-000Ov1-JP; Sat, 23 Aug 2014 08:44:18 +0200 Message-ID: <53F83842.7060302@dumbbell.fr> Date: Sat, 23 Aug 2014 08:44:18 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: d@delphij.net, FreeBSD Current Subject: Re: Recent vt(4) broke moused when hw.vga.textmode=1 References: <53F836FC.9000104@delphij.net> In-Reply-To: <53F836FC.9000104@delphij.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: re@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 06:44:21 -0000 On 23.08.2014 08:38, Xin Li wrote: > Hi, Hello! > I have seen this panic via serial console, but the console is completely > unusable at the time. VGA console is full of '?'. Oh crap, sorry for the breakage... I look into this right now. -- Jean-Sébastien Pédron From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 06:55:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 118534AE for ; Sat, 23 Aug 2014 06:55:11 +0000 (UTC) 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 CBDC536AF for ; Sat, 23 Aug 2014 06:55:10 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=i915.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XL5ED-000P1x-36 for freebsd-current@freebsd.org; Sat, 23 Aug 2014 08:55:09 +0200 Message-ID: <53F83ACD.9060202@FreeBSD.org> Date: Sat, 23 Aug 2014 08:55:09 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze References: <20140823071628.5722d405@munin.walstatt.dyndns.org> In-Reply-To: <20140823071628.5722d405@munin.walstatt.dyndns.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 06:55:11 -0000 On 23.08.2014 07:16, O. Hartmann wrote: > I expect at least the vga textmode console in vt() working. Can the > inventor of this mess plaese revert the code to a working version? Hello! I'm responsible for that and currently working on fixing it. Sorry for the breakage :-/ -- Jean-Sbastien Pdron From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 07:09:06 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADF5491E for ; Sat, 23 Aug 2014 07:09:06 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id 721EF3781 for ; Sat, 23 Aug 2014 07:09:06 +0000 (UTC) Received: from [10.10.10.103] (h60n6-th-c-d4.ias.bredband.telia.com [217.208.44.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id 6F5DFB059B for ; Sat, 23 Aug 2014 08:59:57 +0200 (CEST) From: Joel Dahl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot Message-Id: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> Date: Sat, 23 Aug 2014 09:02:10 +0200 To: current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:09:06 -0000 Hi, Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on = my IBM T43 laptop but encountered some problems. The memstick = installation went fine and I pretty much used default values everywhere, = but upon reboot I got =94Boot loader too large=94. Nothing more. Any = ideas? Joel= From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 07:13:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD94CB24 for ; Sat, 23 Aug 2014 07:13:40 +0000 (UTC) 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 A2FB03811 for ; Sat, 23 Aug 2014 07:13:40 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=i915.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XL5W6-000PDW-UL for freebsd-current@freebsd.org; Sat, 23 Aug 2014 09:13:39 +0200 Message-ID: <53F83F22.2020902@dumbbell.fr> Date: Sat, 23 Aug 2014 09:13:38 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze References: <20140823071628.5722d405@munin.walstatt.dyndns.org> In-Reply-To: <20140823071628.5722d405@munin.walstatt.dyndns.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:13:41 -0000 On 23.08.2014 07:16, O. Hartmann wrote: > On different platforms with different graphics hardware, recent CURRENT > r 270386 shows a screen filled with question marks when booting, The '?' filling screen issue is fixed in HEAD as of r270388. Again, sorry for that. Thank you for reporting the problem! -- Jean-Sbastien Pdron From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 07:17:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EFE1D89 for ; Sat, 23 Aug 2014 07:17:28 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (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 331063834 for ; Sat, 23 Aug 2014 07:17:27 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id A8A2537B605; Sat, 23 Aug 2014 02:17:19 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3hg9sB3ZGszxZ; Sat, 23 Aug 2014 02:17:18 -0500 (CDT) Date: Sat, 23 Aug 2014 02:17:18 -0500 From: "Matthew D. Fuller" To: Joel Dahl Subject: Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot Message-ID: <20140823071718.GA46031@over-yonder.net> References: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.4 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:17:28 -0000 On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of Joel Dahl, and lo! it spake thus: > > Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot > on my IBM T43 laptop but encountered some problems. The memstick > installation went fine and I pretty much used default values > everywhere, but upon reboot I got ”Boot loader too large”. Nothing > more. Any ideas? The freebsd-boot partition is bigger than five hundred twenty-mumble k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart resize -i 1 -s 512k ada23' (untested, sub your disk). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 07:42:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43205355 for ; Sat, 23 Aug 2014 07:42:15 +0000 (UTC) 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 093353A32 for ; Sat, 23 Aug 2014 07:42:15 +0000 (UTC) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=i915.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XL5xl-000PWH-9F for freebsd-current@freebsd.org; Sat, 23 Aug 2014 09:42:13 +0200 Message-ID: <53F845D5.5050805@dumbbell.fr> Date: Sat, 23 Aug 2014 09:42:13 +0200 From: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Recent vt(4) broke moused when hw.vga.textmode=1 References: <53F836FC.9000104@delphij.net> In-Reply-To: <53F836FC.9000104@delphij.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:42:15 -0000 On 23.08.2014 08:38, Xin Li wrote: > Fatal trap 12: page fault while in kernel mode And the crash is fixed in r270390. Thank you for reporting this! -- Jean-Sbastien Pdron From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 08:17:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4825BC3 for ; Sat, 23 Aug 2014 08:17:24 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A6FB33C77 for ; Sat, 23 Aug 2014 08:17:24 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 8803CA695; Sat, 23 Aug 2014 01:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1408781843; x=1408796243; bh=jtqpLg9hhgaO9O2VkoNUIKGmdPRFHaw1MYN6kZs/OXo=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=HMWGNO2FdRv/xb3ChuswSAsqRsOtfd6VOiPUtSZYLvuJPl1HhCckQ3fjSCRhCiIkU vnnJ/txy755V9c/DUxMaqLwwolw6a1+UK9POd0KDdsAD7/gPPfmpO1mAV+Htwvk9ca Kg4K/i0i0F8Fa4RnczeS0Gf+sNL0zxX9zhLjyn3M= Message-ID: <53F84E13.4030303@delphij.net> Date: Sat, 23 Aug 2014 01:17:23 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: =?windows-1252?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-current@freebsd.org Subject: Re: Recent vt(4) broke moused when hw.vga.textmode=1 References: <53F836FC.9000104@delphij.net> <53F845D5.5050805@dumbbell.fr> In-Reply-To: <53F845D5.5050805@dumbbell.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 08:17:24 -0000 On 8/23/14 12:42 AM, Jean-Sbastien Pdron wrote: > On 23.08.2014 08:38, Xin Li wrote: >> Fatal trap 12: page fault while in kernel mode > > And the crash is fixed in r270390. > > Thank you for reporting this! I have verified and r270390 have fixed the crash, thanks for the prompt fix! Cheers, From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 09:42:07 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3941CBB1 for ; Sat, 23 Aug 2014 09:42:07 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id E40B1331C for ; Sat, 23 Aug 2014 09:42:06 +0000 (UTC) Received: from [10.10.10.103] (h60n6-th-c-d4.ias.bredband.telia.com [217.208.44.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id 25505B059B; Sat, 23 Aug 2014 11:39:50 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot From: Joel Dahl In-Reply-To: <20140823071718.GA46031@over-yonder.net> Date: Sat, 23 Aug 2014 11:42:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34C87683-51C4-4EE2-AA01-C100F06178F7@vnode.se> References: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> <20140823071718.GA46031@over-yonder.net> To: "Matthew D. Fuller" X-Mailer: Apple Mail (2.1878.6) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 09:42:07 -0000 23 aug 2014 kl. 09:17 skrev Matthew D. Fuller = : > On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of > Joel Dahl, and lo! it spake thus: >>=20 >> Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot >> on my IBM T43 laptop but encountered some problems. The memstick >> installation went fine and I pretty much used default values >> everywhere, but upon reboot I got =94Boot loader too large=94. = Nothing >> more. Any ideas? >=20 > The freebsd-boot partition is bigger than five hundred twenty-mumble > k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart > resize -i 1 -s 512k ada23' (untested, sub your disk). Yes, gpart fixed it. Thanks. But it=92s annoying. Why is manual tinkering required here? Why isn=92t = it set to 512k by default? I checked the handbook (2.6.3), and it says =94the freebsd-boot = partition should be no larger than 512K due to current boot code = limitations=94 ... Joel= From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 18:45:49 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CF2099C for ; Sat, 23 Aug 2014 18:45:49 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C0D830F4 for ; Sat, 23 Aug 2014 18:45:49 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id a108so11535746qge.24 for ; Sat, 23 Aug 2014 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=xrSDKex1DZkWsJWI0K6s+9lEJH/Gh47VnGRu3mgOBZ8=; b=Bf29j/cEpQ64wkmXPMbWJoKbj6kXfKf8i86oTC479EvzDkTO/jOeqAWZoltFCgCTN8 dRtwKTjZ8N8ix7uyX0mJdcAAoflqwAJiilqCZo7zryoPXdDgNTb7vhJaVoSsLWhZn4sl qfPQlmobJX+2UT7DCCS/pTYOPZEehfYA6MA4sLO1ad4Atgt5s26LY6laZhmXO0jCXOlw hExchu5dHCyXu3VV8J8g2XIZvujVj4k1OzeEh7iHuRP1QAqslLhag6PgfydssCvW9SJ/ MJLszKMVQb6DwauTIOK+9294MxuMjKv+af0v0EX7XAQwdF5ICmTFu7hAtKwUZHBh0HX2 mqnA== MIME-Version: 1.0 X-Received: by 10.140.80.167 with SMTP id c36mr18543167qgd.52.1408819548403; Sat, 23 Aug 2014 11:45:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sat, 23 Aug 2014 11:45:48 -0700 (PDT) In-Reply-To: <34C87683-51C4-4EE2-AA01-C100F06178F7@vnode.se> References: <06EAD266-05B9-4BC3-B99B-400534336533@vnode.se> <20140823071718.GA46031@over-yonder.net> <34C87683-51C4-4EE2-AA01-C100F06178F7@vnode.se> Date: Sat, 23 Aug 2014 11:45:48 -0700 X-Google-Sender-Auth: bba0ahtTDp2f1AYBmsISJUgaXvM Message-ID: Subject: Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot From: Adrian Chadd To: Joel Dahl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "current@freebsd.org" , "Matthew D. Fuller" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 18:45:49 -0000 I thought there was a recent discussion about this. Would you mind filing a bug so this gets looked at? -a On 23 August 2014 02:42, Joel Dahl wrote: > > 23 aug 2014 kl. 09:17 skrev Matthew D. Fuller : > >> On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of >> Joel Dahl, and lo! it spake thus: >>> >>> Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot >>> on my IBM T43 laptop but encountered some problems. The memstick >>> installation went fine and I pretty much used default values >>> everywhere, but upon reboot I got =E2=80=9DBoot loader too large=E2=80= =9D. Nothing >>> more. Any ideas? >> >> The freebsd-boot partition is bigger than five hundred twenty-mumble >> k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart >> resize -i 1 -s 512k ada23' (untested, sub your disk). > > Yes, gpart fixed it. Thanks. > > But it=E2=80=99s annoying. Why is manual tinkering required here? Why isn= =E2=80=99t it set to 512k by default? > > I checked the handbook (2.6.3), and it says =E2=80=9Dthe freebsd-boot par= tition should be no larger than 512K due to current boot code limitations= =E2=80=9D ... > > Joel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 19:00:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6A2C1CF for ; Sat, 23 Aug 2014 19:00:43 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E48E3236 for ; Sat, 23 Aug 2014 19:00:42 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id ty20so11261231lab.4 for ; Sat, 23 Aug 2014 12:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5xzZArOPH2UXrceuxoV86Yk5yMFbXdHdNHf3uU+cabI=; b=tHmWP1lvBuY/db18x+PulcPJcuf+ANJ1shoX1ZPDfYKW2UX4ijAO8ju9GeolRmZnG6 nQyV2bmTPMWsp/5I9vw7fMuzF7x/hkSKexFqyg5syeJVGKOBR/vxtgDB72nq/adFSXcO JV7M5I/S+sOn8z021uSOhUhmhNDGb7v+MREuLnNQXwb/B35hJ1oPhKS+Pn+zewsjkErM r2MHneoBq9R2HXFl4mSpDi9IRUqesZ34B8Zo4t5bpJeNwk9LXaL+VN4Pz9nfOn4wSr93 rsFGyi0w3lldLrgs16v7fbt9g6D0LPYycWJABak3OV1v7HpdV/uv7A6z4Op0i+Tak7hy 0B6w== MIME-Version: 1.0 X-Received: by 10.152.21.98 with SMTP id u2mr3212375lae.80.1408820440874; Sat, 23 Aug 2014 12:00:40 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sat, 23 Aug 2014 12:00:40 -0700 (PDT) In-Reply-To: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> Date: Sat, 23 Aug 2014 12:00:40 -0700 X-Google-Sender-Auth: sw6GaqHPaxRhpYNoNBQk-j4Ztac Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 19:00:43 -0000 On Fri, Aug 22, 2014 at 1:45 PM, Marcel Moolenaar wrote: > >> If I mdconfig the foo1.img disk image, and do a gpart show, I see: >> >> => 3 1784944 md0 GPT (872M) >> 3 32 1 freebsd-boot (16K) >> 35 1784912 2 freebsd-ufs (872M) >> >> Any idea what I am doing wrong? > > To the best of my knowledge, qemu is the thing you're > doing wrong :-) Hi, I transferred foo1.img to a Mac with VirtualBox, converted it to VMDK with "VBoxManage convertfromraw --format VMDK", and tried to boot it in VirtualBox. I got the same error as in QEMU. It looks like /boot/loader runs, but I cannot do "ls" to see the root file system. I created another disk image with a GPT layout, but this time using the FreeBSD bsdinstall inside a bhyve VM. I noticed the following: WORKING IMAGE BOOTS IN QEMU, CREATED WITH BSDINSTALL ============================================= => 34 10485693 md0 GPT (5.0G) 34 128 1 83bd6b9d-7f41-11dc-be0b-001560b84f0f (64K) 162 9959296 2 516e7cb6-6ecf-11d6-8ff8-00022d09712b (4.7G) 9959458 524288 3 516e7cb5-6ecf-11d6-8ff8-00022d09712b (256M) 10483746 1981 - free - (991K) DOES NOT BOOT IN QEMU, CREATED WITH MKIMG =================================================== => 3 1784944 md1 GPT (872M) 3 32 1 83bd6b9d-7f41-11dc-be0b-001560b84f0f (16K) 35 1784912 2 516e7cb6-6ecf-11d6-8ff8-00022d09712b (872M) I ran the following crazy experiment, just to see what would happen: dd if=/dev/md1s2 of=/dev/md0s2 bs=8192 I then tried to boot the first image with QEMU, and it booted successfully, with my UFS file system that I had previously created with makefs. I'm not sure where to look for the problem. I notice that in the non-working image, the offset starts at block 3, while in the working image, the offset starts at block 34. Is that enough to make things not boot? -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 19:11:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4333F7E3; Sat, 23 Aug 2014 19:11:27 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (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 F113933D9; Sat, 23 Aug 2014 19:11:26 +0000 (UTC) Received: from rdelancy-sslvpn-nc.jnpr.net ([66.129.239.10]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s7NJBNWd001165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Aug 2014 12:11:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_72F5DFAB-2007-40D3-9E88-2E5E869EF04C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mkimg used to create gpt image, problem booting From: Marcel Moolenaar In-Reply-To: Date: Sat, 23 Aug 2014 12:11:18 -0700 Message-Id: <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 19:11:27 -0000 --Apple-Mail=_72F5DFAB-2007-40D3-9E88-2E5E869EF04C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On Aug 23, 2014, at 12:00 PM, Craig Rodrigues wrote: > > I ran the following crazy experiment, just to see what would happen: > > dd if=/dev/md1s2 of=/dev/md0s2 bs=8192 > > I then tried to boot the first image with QEMU, and it booted successfully, > with my UFS file system that I had previously created with makefs. > > I'm not sure where to look for the problem. I notice that > in the non-working image, the offset starts at block 3, > while in the working image, the offset starts at block 34. > > Is that enough to make things not boot? Could be. Try the -P option to mkimg. It sets the underlying (unexposed) physical sector size while still working with the visible 512 bytes sectors. The net effect is that for the GPT scheme things get aligned to the physical sector size and that it also causes the image size to be rounded. You can also try emitting vmdk directly to see if that makes a difference. vmdk also has the side- effect of rounding the image to the grain size. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_72F5DFAB-2007-40D3-9E88-2E5E869EF04C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP451YACgkQpgWlLWHuifZqqQCdHdmnk/f8+4/on3uzN1d4XyjY +moAniCJF67+zqrFakevViiBqNYEg03A =AYkU -----END PGP SIGNATURE----- --Apple-Mail=_72F5DFAB-2007-40D3-9E88-2E5E869EF04C-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 20:49:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE512438 for ; Sat, 23 Aug 2014 20:49:52 +0000 (UTC) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54E833C55 for ; Sat, 23 Aug 2014 20:49:52 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id v6so10525616lbi.25 for ; Sat, 23 Aug 2014 13:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=95XHE47YGDj0pl1ocWOXeAT6eiPVfi+HX8XXo3Otx2Y=; b=hpf00HQQIZiW8mfI2c7CwNDrWZO6/6WHE+vq9Ve645Hzp1Db6Ddlf8ZLtWomps9A/M Pfh08vz3E0ofN+l5B9X+lei75DcoTFrSetec8nF1QUc0k7VvvlEfI/O+FLEU5uQWiDCY 5emvM5RLmsmAnlUbK3OwZpUBYFI5Y2bGX9kdXh2D/8uuOqamEHqbWalOzD8Cc1M9rq9C 6Mq5X9dp/wksbTNz4wI9LeeO2OzGFPQQ/y23xfPrfhHrQiGGXqeWOyKP08lR+iLuHQfZ A46Iz41TXnGpkWv60E1mLmGTFJKebIDcni7OSwUUVWH1AIV1Z+egxRnyUwCKi5sUjPTQ CT1g== MIME-Version: 1.0 X-Received: by 10.112.160.38 with SMTP id xh6mr11203641lbb.21.1408826990150; Sat, 23 Aug 2014 13:49:50 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.197.107 with HTTP; Sat, 23 Aug 2014 13:49:50 -0700 (PDT) In-Reply-To: <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> References: <853B0396-2C19-49DF-A8E8-8EB43D107597@xcllnt.net> <7CE168C1-6AF3-4AD2-80DB-192AEC49FD2B@xcllnt.net> Date: Sat, 23 Aug 2014 13:49:50 -0700 X-Google-Sender-Auth: u8oImlcMz_TVYNqVES2wGy0w56I Message-ID: Subject: Re: mkimg used to create gpt image, problem booting From: Craig Rodrigues To: Marcel Moolenaar Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:49:52 -0000 On Sat, Aug 23, 2014 at 12:11 PM, Marcel Moolenaar wrote: > > Could be. Try the -P option to mkimg. It sets the > underlying (unexposed) physical sector size while > still working with the visible 512 bytes sectors. > The net effect is that for the GPT scheme things > get aligned to the physical sector size and that > it also causes the image size to be rounded. > > You can also try emitting vmdk directly to see if > that makes a difference. vmdk also has the side- > effect of rounding the image to the grain size. I tried the following experiments: mkimg -v -f vmdk -s gpt -b test1/boot/pmbr -p freebsd-boot:=test1/boot/gptboot -p freebsd-ufs:=/tmp/file.img -o /tmp/foo1.vmdk When I tried to boot the image in QEMU, I had the same problem as before. It looks like it started writing the image on block 3, same as before. I also tried adding the -P flag, with different values like 2048 and 4096. I ran into the same problem. Hmm. -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Aug 23 22:08:52 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88A6EE58 for ; Sat, 23 Aug 2014 22:08:52 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4D01F32ED for ; Sat, 23 Aug 2014 22:08:51 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 041F716D6; Sat, 23 Aug 2014 22:08:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7NAGgaE023150; Sat, 23 Aug 2014 10:16:42 GMT (envelope-from phk@phk.freebsd.dk) To: "Michael W. Lucas" Subject: Re: gbde destroy doesn't match man page? In-reply-to: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> From: "Poul-Henning Kamp" References: <20140820215522.GA92455@bewilderbeast.blackhelicopters.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23148.1408789002.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Aug 2014 10:16:42 +0000 Message-ID: <23149.1408789002@critter.freebsd.dk> Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 22:08:52 -0000 -------- In message <20140820215522.GA92455@bewilderbeast.blackhelicopters.org>, "M= ichae l W. Lucas" writes: >Playing with GBDE for my FreeBSD disk book, on: > ># uname -a >FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11= :13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 > >According to the man page, I should be able to destroy all copies of >the key with gbde destroy -n -1. It's in the examples. When I >try it I get: I think that is an oversight in the code. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .