From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 09:45:49 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id D0E92F49 for ; Sun, 22 Sep 2013 09:45:49 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C246254D for ; Sun, 22 Sep 2013 09:45:49 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id cb5so1178516wib.1 for ; Sun, 22 Sep 2013 02:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZqoQlXyzyg/mNLnP333QtoIS/hYSaoDwgVdnszoCfio=; b=IlIYWaUKObY8isjHtWGZaRHVWhYD7YkSS4FzOauvew2Oa3eBgnfi3WAgOT2IkK0V1Q lONLgOsiEvqpzc+O7BXG1eONA9msn4DMRiqdXm59vYdexoTaU5LgA8yz28O3qBc3w5c+ UabTd64vd9FeZ4ZlClT2LooOmQI7lTMC/gYUaR6s7AuTPw+JqgLvRplQ06OynzsYiqw9 zt6WvGYgaK70Tb14OTEuXUsXiSgitEq6h/SgAx03li96glO6USS4Y99R9dGcO725PVx7 lFuoknmub+XkqLD1kOV+8dc/L/jsQbwUMMnDSS7zP580CE1z9ezfYBwZVql5bmEqA3BR ukpw== X-Received: by 10.180.212.51 with SMTP id nh19mr9218865wic.14.1379843147630; Sun, 22 Sep 2013 02:45:47 -0700 (PDT) Received: from [192.168.0.10] (182.66.91.91.rev.sfr.net. [91.91.66.182]) by mx.google.com with ESMTPSA id ed12sm17007437wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 02:45:47 -0700 (PDT) Message-ID: <523EBC46.2030003@gmail.com> Date: Sun, 22 Sep 2013 11:45:42 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> In-Reply-To: <20130921123125.309f30eb@thor.walstatt.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 09:45:49 -0000 On 21.09.2013 12:31, O. Hartmann wrote: > > Hello, > > I'd like to switch off this silly "Nakatomi Socrates" message which > reminds me on Linux and their childish naming schemes. > > It is only cosmetics, but it bothers me whenever I switch on the laptop. > > I guess there is a switch already prsent to have in the bootloader > config? > > Thanks, > > oh > Yes, I've already said a few weeks ago that it should not be default as it's really not serious for a system like FreeBSD, I'm happy that it has been removed just before 9.2-RELEASE. Cheers, David From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 11:15:40 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 9C0DC4DA for ; Sun, 22 Sep 2013 11:15:40 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CB82292F for ; Sun, 22 Sep 2013 11:15:39 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VNhda-0007Nw-SO for freebsd-stable@freebsd.org; Sun, 22 Sep 2013 04:15:38 -0700 Date: Sun, 22 Sep 2013 04:15:38 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1379848538873-5845814.post@n5.nabble.com> In-Reply-To: <1379790253717-5845696.post@n5.nabble.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <13CA24D6AB415D428143D44749F57D720FBE43D5@LTCFISWMSGMB21.FNFIS.com> <1379790253717-5845696.post@n5.nabble.com> Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 11:15:40 -0000 FWIW, I've meant "tribute" not orb. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-2-PRE-switch-off-that-stupid-Nakatomi-Socrates-tp5845622p5845814.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 14:17:16 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 4152A86D; Sun, 22 Sep 2013 14:17:16 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 367C82362; Sun, 22 Sep 2013 14:17:15 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so2211425wgh.14 for ; Sun, 22 Sep 2013 07:17:13 -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=NGudCPtC72g5VN0o2QMPQMzN962VhiL9PksFHIUgWF8=; b=o81pGTEfJSuMDvNxxbUwneOWvthZWnZu3crIARbgszOWIWdD6Hw8XbdH2Cy6DSm5hn +d8fptw5DuUCbflEyKOUR2cYYRxelbpsnUX4eb0p5+HOxiSGt74D+HEkVAHdSOyGZza5 x4teoTQTld9s74rba7Mt9IVNaqFqABvaKU7Yb4rlIh0oaMRrGq4Ay6x3zkyeEA4AAfd4 1nkKFHN7j2FNR8xP6Zut33hn59p0Ea5nzlSacLVlfeBD2ybL/Fk4G+JmCgC5Fson7Vpg 3/cYwH7WbvKs15T1xow1q8kbHA8dkNL4o+cyDZM+uezpoE5T74GX+x708BqUNiiFJlV/ hJVg== MIME-Version: 1.0 X-Received: by 10.180.83.228 with SMTP id t4mr9859611wiy.12.1379859433395; Sun, 22 Sep 2013 07:17:13 -0700 (PDT) Received: by 10.217.67.65 with HTTP; Sun, 22 Sep 2013 07:17:13 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Sun, 22 Sep 2013 07:17:13 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 14:17:16 -0000 Just a note for anybody who might have this problem with 9.2 that I am still having this issue with 9.2-releng (unless I patch the kernel) and Andriy hasn't accessed my system yet, to have a look so 9.2 release is likely to have this same issue for some subset of users (maybe only 1, me!). We were able to figure out that my symptoms have nothing to do with the user of powerd (still happens if powerd is not enabled, and the CPU still scales after suspend/resume). As this only appears to affect the disk access, here's the dmesg output related to the SATA hardware and affected disk: ... ahci0: port 0xb880-0xb887,0xb\ 800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb09f mem 0xf7cf7000-0xf7cf77ff \ irq 21 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier supported ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 On Fri, Sep 6, 2013 at 3:01 PM, Adrian Chadd wrote: > .. anything happening? > > > -adrian > > > On 2 September 2013 07:29, Adrian Chadd wrote: > >> >> On 2 September 2013 07:25, Mike Harding wrote: >> >>> It's detailed in the ticket, see >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for >>> 'reverted'. >>> >>> >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for >> now. I'll retest this on my test laptops when I'm back home. >> >> >> >> -adrian >> >> > From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 20:28:16 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 66E07AA0 for ; Sun, 22 Sep 2013 20:28:16 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2826B2497 for ; Sun, 22 Sep 2013 20:28:15 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:43207] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id FD/82-01446-8D25F325; Sun, 22 Sep 2013 20:28:09 +0000 Date: Sun, 22 Sep 2013 20:28:08 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 20:28:16 -0000 I've been unable to establish Internet connection from a new computer with Realtek 811E Ethernet despite this Ethernet chip working on another computer with another MSI motherboard. Problem motherboard is MSI Z77 MPOWER. Older, by two years, motherboard is MSI Z68MA-ED55(B3). uname -a shows FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 I get the same problem with FreeBSD 9.1_STABLE i386. These are USB-stick installations. I was able to connect to the Internet with (MSI) Winki 3 (Linux-based), included on a DVD included in the motherboard package. After nothing but frustration trying to boot USB-stick installations of NetBSD 6.1-STABLE and HEAD (i386), I successfully booted NetBSD-HEAD amd64 from early last May, and "dhclient re0" was successful, whereupon I downloaded, by cvs, the HEAD source tree and pkgsrc tree. This proves or strongly suggests the Ethernet chip is healthy. Anything I can do (at loader prompt or loader.conf?) to make this Ethernet work in FreeBSD? I could update NetBSD-HEAD from source, update the packages through pkgsrc, and build subversion, then checkout the FreeBSD-HEAD source tree, ports and doc trees too, and build FreeBSD-HEAD from source on hard drive using USB-stick installation of FreeBSD 9.2 (prerelease or release). Related part of /var/run/dmesg.boot is re0: port 0xe000-0xe0f f mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX- master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: d4:3d:7e:97:17:e2 Log of "dhclient re0" was DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 192.168.1.1 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 17 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 No DHCPOFFERS received. No working leases in persistent database - sleeping. Somewhat later I got Memory modified after free 0xfffffe0011546800(2048) val=977e3dd 4 @ 0xfffffe0011546800 Memory modified after free 0xfffffe001153b800(2048) val=ffffffff @ 0xfffffe00115 3b800 Memory modified after free 0xfffffe0011524800(2048) val=977e3dd4 @ 0xfffffe00115 24800 VESA: set_mode(): 24(18) -> 24(18) Memory modified after free 0xfffffe0011594000(2048) val=977e3dd4 @ 0xfffffe00115 94000 In one case, when I went to bed on this, hours later the system crashed and went into the debugger (db>), where I was rather lost, couldn't kill dhclient, after some time types "reboot". Should I have posted this to a different list (hardware, questions?)? I would like to find if FreeBSD HEAD (10.0 alphas) would do better. Also, because of nearness of 10.0-RELEASE, I would rather go this track than 9.2 and then update; I already have 9.2 prerelease on other computer. Motherboard also has Atheros Wi-Fi (Atheros AR9271 802.11n), and I also have a USB stick-type WLAN adapter (Hiro Inc H50191, Realtek RTL8191SU 802.11n chip). Tom From owner-freebsd-stable@FreeBSD.ORG Sun Sep 22 23:58:00 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 9A839F4F; Sun, 22 Sep 2013 23:58:00 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E27D20B4; Sun, 22 Sep 2013 23:58:00 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 29D7B28435; Sun, 22 Sep 2013 16:52:45 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id 09F3828434; Sun, 22 Sep 2013 16:52:45 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id 6E2871679862; Sun, 22 Sep 2013 16:52:33 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21055.33473.385334.574140@gargle.gargle.HOWL> Date: Sun, 22 Sep 2013 16:52:33 -0700 To: Andriy Gapon Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: <520202E5.30300@FreeBSD.org> References: <20967.760.95825.310085@gargle.gargle.HOWL> <51E80B30.1090004@FreeBSD.org> <20968.10645.880772.30501@gargle.gargle.HOWL> <520202E5.30300@FreeBSD.org> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@FreeBSD.org, hartzell@alerce.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 23:58:00 -0000 Andriy Gapon writes: > on 18/07/2013 20:44 George Hartzell said the following: > > Andriy Gapon writes: > > > on 17/07/2013 23:47 George Hartzell said the following: > > > > How should I move forward with this? > > > > > > Could you please try to reproduce this problem using a kernel built with > > > INVARIANTS options? > > > > I added INVARIANT_SUPPORT and INVARIANTS options to the GENERIC > > kernel, rebuilt it, installed it and running through my "test case" > > generated a lot of invalid flac files. I"m not sure what the options > > are/were supposed to do though, it looks like they generally lead to > > KASSERTS, which lead to abort()'s. Nothing in /var/log/messages or on > > the console. > > George, > > do you have anything new on this issue? > > Could you please try the following patch? > http://people.freebsd.org/~avg/zfs-putpages.diff > > I expect it to not really fix the issue, but it may help to narrow it down. > Please keep INVARIANTS. > Thank you. > -- > Andriy Gapon Hi Andriy, This weekend I built up a system using the 10.0 beta 2 dvd, then updated /usr/src from head. I grabbed a fresh copy of your patch this afternoon. I applied your patch with no problems. I was unable to build a new kernel though, you have one reference to m->busy, where m is a vm_page_t (if I remember correctly). I dug around a bit and decided that you meant m->busy_lock, which let me build a usable kernel. It looks like INVARIANTS and INVARIANT_SUPPORT are included in the GENERIC conf file. I ran through my test routine with the original system and was able to reproduce the problem. After building and installing a kernel with your patch I was still able to trigger the problem. If anything it was worse (sample size = 1, I know...). I did not see any interesting output in /var/log/messages or to the console or anywhere else obvious. I'm not sure what to do next. It's likely that my m->busy to m->busy_lock change was not The Right Thing to Do and might have invalidated what the patch was trying to do. In any case, I now have a system running HEAD and should be able to test things more easily. Thanks for the help, g. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 12:52:44 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id A9D885AB for ; Mon, 23 Sep 2013 12:52:44 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6E01F2A0D for ; Mon, 23 Sep 2013 12:52:44 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=fJG7LOme c=1 sm=0 a=DktfseARn6RskVgg/AMIPQ==:17 a=I9A6gpd8bSkA:10 a=FRhxRxJff8gA:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=N54-gffFAAAA:8 a=KGjhK52YXX0A:10 a=CA_SMH9JS0kA:10 a=Izron4WtVlaGl-b2DgoA:9 a=Gz3CvalDQgdoON2V:21 a=0zywiSnL4VMkKdjI:21 a=DktfseARn6RskVgg/AMIPQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 98.31.3.233 Received: from [98.31.3.233] ([98.31.3.233:24446] helo=mail.laus.org) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 7E/D3-27973-59930425; Mon, 23 Sep 2013 12:52:37 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.7/8.14.7) with ESMTP id r8NCqapd024338 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Sep 2013 08:52:37 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host laust2 [192.168.1.100] claimed to be [192.168.1.100] From: "Thomas Laus" Organization: ABB To: "Thomas Mueller" , freebsd-stable@freebsd.org Date: Mon, 23 Sep 2013 08:52:45 -0400 Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard Message-ID: <5240399D.30739.12AD6E@lausts.acm.org> Priority: normal In-reply-to: References: X-mailer: Pegasus Mail for Windows (4.63) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:52:44 -0000 > Related part of /var/run/dmesg.boot is > > re0: port > 0xe000-0xe0f f mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at > device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: > MAC rev. 0x00000000 miibus0: on re0 rgephy0: 1000BASE-T media interface> PHY 1 on miibus0 rgephy0: none, 10baseT, > 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX , 100baseTX-FDX-flow, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX- master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet > address: d4:3d:7e:97:17:e2 > Thomas: That NIC chip works for me and gets it's address information using DHCP. Aug 31 16:09:13 mail kernel: FreeBSD 9.2-PRERELEASE #1: Sat Aug 31 12:13:51 EDT 2013 Aug 31 16:09:13 mail kernel: re0: port 0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 Aug 31 16:09:13 mail kernel: re0: Using 1 MSI-X message Aug 31 16:09:13 mail kernel: re0: Chip rev. 0x28000000 Aug 31 16:09:13 mail kernel: re0: MAC rev. 0x00000000 Aug 31 16:09:13 mail kernel: miibus0: on re0 Aug 31 16:09:13 mail kernel: rgephy0: PHY 1 on miibus0 Aug 31 16:09:13 mail kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Aug 31 16:09:13 mail kernel: re0: Ethernet address: 70:71:bc:18:1b:97 Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 13:37:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 7EE49F7E for ; Mon, 23 Sep 2013 13:37:17 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4503C2D5C for ; Mon, 23 Sep 2013 13:37:16 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id A7E6CA631; Mon, 23 Sep 2013 15:37:09 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id DFFE91A3; Mon, 23 Sep 2013 15:37:08 +0200 (CEST) Date: Mon, 23 Sep 2013 15:37:08 +0200 From: Patrick Lamaiziere To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130923153708.45c3be3d@mr129166> In-Reply-To: <20130920151705.33aae120@mr129166> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:37:17 -0000 Le Fri, 20 Sep 2013 15:17:05 +0200, Patrick Lamaiziere a écrit : > Le Thu, 12 Sep 2013 10:36:43 +0300, > Konstantin Belousov a écrit : > > Hello, > > > Might be, your issue is that some filesystems do not care about > > proper locking mode for the fifos. UFS carefully disables shared > > locking for VFIFO, but it seems ZFS is not. I can propose the > > following band-aid, which could help you. > > > > I have no idea is it the same issue as the kqueue panic. > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > index c53030a..00bd998 100644 > > --- a/sys/kern/vfs_vnops.c > > +++ b/sys/kern/vfs_vnops.c > > @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, > > struct ucred *cred, return (error); > > } > > } > > + if (vp->v_type == VFIFO && VOP_ISLOCKED(vp) != > > LK_EXCLUSIVE) > > + vn_lock(vp, LK_UPGRADE | LK_RETRY); > > if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) > > return (error); > > > > @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) > > struct mount *mp; > > int error, lock_flags; > > > > - if (!(flags & FWRITE) && vp->v_mount != NULL && > > + if (vp->v_type != VFIFO && !(flags & FWRITE) && > > vp->v_mount != NULL && vp->v_mount->mnt_kern_flag & > > MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; > > else > Ok This has been mfced to 9.2-STABLE. But I still see this panic with 9-2/STABLE of today (Revision : 255811). This may be better because before the box paniced within minutes and now within hours (still using poudriere). panic: fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808ebfcd stack pointer = 0x28:0xffffff824c2e0630 frame pointer = 0x28:0xffffff824c2e06a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 54243 (gvfsd-trash) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff80939ad6 at kdb_backtrace+0x66 #1 0xffffffff808ffacd at panic+0x1cd #2 0xffffffff80cdfbe9 at trap_fatal+0x289 #3 0xffffffff80cdff4f at trap_pfault+0x20f #4 0xffffffff80ce0504 at trap+0x344 #5 0xffffffff80cc9b43 at calltrap+0x8 #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 #7 0xffffffff808c4793 at kqueue_register+0x3e3 #8 0xffffffff808c4de8 at kern_kevent+0x108 #9 0xffffffff808c5950 at sys_kevent+0x90 #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 Full core.txt : http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 Thanks, regards. From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 15:00:51 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 07059E99; Mon, 23 Sep 2013 15:00:51 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77D0F2380; Mon, 23 Sep 2013 15:00:49 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r8NF0d29034679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 17:00:40 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <52405797.9020609@omnilan.de> Date: Mon, 23 Sep 2013 17:00:39 +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: Amitabh Kant Subject: Re: 9.2 panic with wcb4xxp (dahdi-kmod26-2.6.1.r10738) References: <523B04C3.30100@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF001B03F6AB0ED02DC1351D8" Cc: freebsd-isdn@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:00:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF001B03F6AB0ED02DC1351D8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Amitabh Kant's Nachricht vom 21.09.2013 03:24 (localtime): > On Thu, Sep 19, 2013 at 7:35 PM, Harald Schmalzbauer > > wrote: > > Hello, > > unloading the kernel module of dahdi-kmod26-2.6.1.r10738 leads to t= his > panic: > > > > > wcb4xxp0: <6>Did not do the highestorder stuff > <6>dahdi: Detected time shift. > <5>dahdi_echocan_mg2: Registered echo canceler 'MG2' > > Starting asterisk afterwards also leads to panic. > I guess dahdi development stalled, but I wanted to try it because I= 'd > prefer freeswitch and need BRI support... > Is somebody familiar with dahdi and interested in making it work wi= th > FreeBSD 9.2? > > Thanks, > > -Harry (not subscribed to isdn@) > > > > Have you been able to solve the problem? I am running Freeswitch (from > git, not port) and dahdi/dahdi-kmod26 (from port) with PRI line > (Digium 8 span and single span) without any problems on 9.1. Will test > it on 9.2 and get back to you if I see a panic . Hello Amitabh, couldn't solve my problem. First, dahdi_scan doesn't detect ports jumpered to NT mode. I need 2 port= s in NT mode, so trying anything else with dahdi before my settings get c= orrectly recognized is probably not worth the time. Also I have to investigate if it is still true that libpri doesn't suppor= t ptmp in NT mode!?! In general, the freebsd dahdi port doesn't seem to be in good shape; Coul= dn't find any docs about sysctls (dahdi.wcb4xxp.teignorered, '-d' shows n= othing :-( ), no man page =96 hard to find out anything about dahdi in Fr= eeBSD, not even the supported hardwhere seems to be documentend anywhere.= =2E. Any hints highly appreciated, although I think the better way was to teac= h FreeTDM speaking CAPI. HPS does a great job keeping all kind of ISDN ha= rdware supported by i4b (ISDN4BSD)! Or to make chan_capi work with asterisk11 =96 the lesser evil than fighti= ng dahid... Thanks, -Harry --------------enigF001B03F6AB0ED02DC1351D8 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) iEYEARECAAYFAlJAV5cACgkQLDqVQ9VXb8gsiACeMGNFGvcvxrdGwAYozpzZ2YKS SbAAoMkPiPFp03l1xibo+Z6XuwFQ5G7T =DyeN -----END PGP SIGNATURE----- --------------enigF001B03F6AB0ED02DC1351D8-- From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 18:17:05 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id C254AD30 for ; Mon, 23 Sep 2013 18:17:05 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3C02F91 for ; Mon, 23 Sep 2013 18:17:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id A2F8E14D5EF for ; Mon, 23 Sep 2013 20:16:53 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=ham Authentication-Results: galore.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Kgv5hhiZqR-U for ; Mon, 23 Sep 2013 20:16:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 45A5F14D5F6 for ; Mon, 23 Sep 2013 20:16:53 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 galore.getmail.no 45A5F14D5F6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1379960213; bh=nkOg3fCOMLxu2DwJi9+Ts2pfnXM5fI3hCives/HAbIg=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=E0y+QTQ/yRyNEsloNKh1b7TgNR/vE9XEbSRCztH3OES+050Vh/0CLh8XpA+YRmqh5 STFg0KVJ23Oyeka9Rky3z0MoqZAjM4cDxVt6p3G3O08Zlr1ivsK6nIgMhUz1dj4OP+ mrKXK48XKT0xbdrl7qqTn8sEJT50II8BcYlKm9H8= X-Virus-Scanned: amavisd-new at Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FmbWmYtoiDu4 for ; Mon, 23 Sep 2013 20:16:53 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by galore.getmail.no (Postfix) with ESMTPSA id 224FE14D5EF for ; Mon, 23 Sep 2013 20:16:53 +0200 (CEST) Date: Mon, 23 Sep 2013 20:16:52 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard Message-Id: <20130923201652.6077480310595862fc9df015@getmail.no> In-Reply-To: References: X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd8.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:17:05 -0000 On Sun, 22 Sep 2013 20:28:08 +0000 "Thomas Mueller" wrote: > I've been unable to establish Internet connection from a new computer with Realtek 811E Ethernet despite this Ethernet chip working on another computer with another MSI motherboard. In additiin to the information you have already provided, you should also provide relevant output from pciconf, like so: root@kg-core1# pciconf -lv | grep -A 4 re0 re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet (substitute the name of your interface for "re0") and also ifconfig output like this: root@kg-core1# ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=8209b ether 50:46:5d:8b:a2:ea inet 10.1.150.50 netmask 0xffff0000 broadcast 10.1.255.255 media: Ethernet autoselect (1000baseT ) status: active (again, substitute the name of your interface for "re0") As far as fault-finding "tricks" go, here is one that have helped me on several occasions in the past: before doing anything with a network interface (in other words, before starting DHCP), try doing a 'ifconfig up' for example ifconfig re0 up After that, use the interface normally. If it works, you have found a bug related to the driver and the specific hardware revsion of you card. Create a PR for it. HTH -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Mon Sep 23 20:31:48 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 7842D73A for ; Mon, 23 Sep 2013 20:31:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFE6927DA for ; Mon, 23 Sep 2013 20:31:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8NKVgTd096733; Mon, 23 Sep 2013 23:31:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8NKVgTd096733 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8NKVfhw096732; Mon, 23 Sep 2013 23:31:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Sep 2013 23:31:41 +0300 From: Konstantin Belousov To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130923203141.GV41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqL8xdl27knXeD23" Content-Disposition: inline In-Reply-To: <20130923153708.45c3be3d@mr129166> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:31:48 -0000 --tqL8xdl27knXeD23 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2013 at 03:37:08PM +0200, Patrick Lamaiziere wrote: > Le Fri, 20 Sep 2013 15:17:05 +0200, > Patrick Lamaiziere a ?crit : >=20 > > Le Thu, 12 Sep 2013 10:36:43 +0300, > > Konstantin Belousov a ?crit : > >=20 > > Hello, > >=20 > > > Might be, your issue is that some filesystems do not care about > > > proper locking mode for the fifos. UFS carefully disables shared > > > locking for VFIFO, but it seems ZFS is not. I can propose the > > > following band-aid, which could help you. > > >=20 > > > I have no idea is it the same issue as the kqueue panic. > > >=20 > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > index c53030a..00bd998 100644 > > > --- a/sys/kern/vfs_vnops.c > > > +++ b/sys/kern/vfs_vnops.c > > > @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, > > > struct ucred *cred, return (error); > > > } > > > } > > > + if (vp->v_type =3D=3D VFIFO && VOP_ISLOCKED(vp) !=3D > > > LK_EXCLUSIVE) > > > + vn_lock(vp, LK_UPGRADE | LK_RETRY); > > > if ((error =3D VOP_OPEN(vp, fmode, cred, td, fp)) !=3D 0) > > > return (error); > > > =20 > > > @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) > > > struct mount *mp; > > > int error, lock_flags; > > > =20 > > > - if (!(flags & FWRITE) && vp->v_mount !=3D NULL && > > > + if (vp->v_type !=3D VFIFO && !(flags & FWRITE) && > > > vp->v_mount !=3D NULL && vp->v_mount->mnt_kern_flag & > > > MNTK_EXTENDED_SHARED) lock_flags =3D LK_SHARED; > > > else > >=20 >=20 > Ok This has been mfced to 9.2-STABLE. But I still see this panic with > 9-2/STABLE of today (Revision=9A: 255811). This may be better because > before the box paniced within minutes and now within hours (still using p= oudriere). >=20 > panic: > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff808ebfcd > stack pointer =3D 0x28:0xffffff824c2e0630 > frame pointer =3D 0x28:0xffffff824c2e06a0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 54243 (gvfsd-trash) > trap number =3D 12 > panic: page fault > cpuid =3D 2 > KDB: stack backtrace: > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > #1 0xffffffff808ffacd at panic+0x1cd > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > #3 0xffffffff80cdff4f at trap_pfault+0x20f > #4 0xffffffff80ce0504 at trap+0x344 > #5 0xffffffff80cc9b43 at calltrap+0x8 > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > #8 0xffffffff808c4de8 at kern_kevent+0x108 > #9 0xffffffff808c5950 at sys_kevent+0x90 > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 >=20 > Full core.txt :=20 > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 For start, please load the core into kgdb and for frame 8 p *kn Also, please follow http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html to recompile kernel with the debugging options and try to recreate the pani= c. --tqL8xdl27knXeD23 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQKUsAAoJEJDCuSvBvK1BwPYP/0agnpAChZUykUahx+8Jfut4 A/WVnPNrKQlAxL879/JMxdtt0rcA8oBFn/B7nWCFrC7m9lhihcqm5LqCrm5VgMon xySzk/0tpikX4ucRijXX0M+1jcJbpdcsIjUx616qeg6t9VDoW5fj6J8SGzySiPcn 2OCcSpzBj69jDdDOGE24gTA7jg+SaL5XVT3g1f640bk01MuML5t/lnHdsmF+F34K mZdI9sWl2S+UzbfgqX/FqBOp6emvgr38HJcOEw39xsjytPrvddi6B0P4StkQCUcK mZFBJBZC0nBKEsjj2fW3g73eMlvQWIYbwYGePIGkaLmC+aQFUpaw50XGc2QpxF4l pyP0xmnl3o2ffSGWF++gH8ZcmQPnXOGqUbrArnDztmHjTKqUGNtzyhowUbJWICe4 4c9iTarFkCYA5tsJZf+UlC+V1myBT7FQ3X1QCELmR1LeGESW3cC+NiwAlu2Sbymk pQtTXSEGeqViRWHoG4fzeO8F1sRXfaZypKjq8pn43OepdY8xfOraDTQlcOqUh9Zs xUe+oSAh8vZrazb0GFImue1oJyADTWR683m4hXEFNpA7QNiB4xxFkC1BJErE2ZWA N3Lex9y2muA6TCk2YeWB+TJxyHcWkMQSbMBojJ+Nvk+KI5qTzUCRIOUBWj7nulgb EePHiXqTz2+sxkmH0kx2 =6unz -----END PGP SIGNATURE----- --tqL8xdl27knXeD23-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 00:46:12 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 71AEDEC2; Tue, 24 Sep 2013 00:46:12 +0000 (UTC) (envelope-from amitabhkant@gmail.com) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 304FA24E1; Tue, 24 Sep 2013 00:46:12 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h16so1449564oag.38 for ; Mon, 23 Sep 2013 17:46: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:from:date:message-id:subject:to :cc:content-type; bh=LpVznlGynoxP2DR76kPDs7aKm6DaWK/pKCO89Kads5I=; b=d+ccN2W2cIhK7WExmZd4hTr7pdMhzxH+LWJlBDbDUIccs6P3kwrZHY8d0R4VFhd9Jm prQ5XD2BQIaEO5fihV3/Ul5I/grxiX1B173kFrNLHGsXM91VSRi+BsFKl2fW3HwTtWfk Z/qSzb6lbccQECMHFGwJP/j9AiGmOGXg8hDXAwRXIwL36F0dvEURUZzm17X7dPT/kfSc XBKAZnFmfkW//h3z+7pgCGu3Z6aCQ7gXP4RmoW8LN5ES/wlxO5oAYWrJnshJBlXj5oOU F714az60zybjTCigBK/vK6Y0fwIdHbydiFWHjwHsjBILQYnujYAJaPL9V19BYA6eqfym 0Q4w== X-Received: by 10.182.237.44 with SMTP id uz12mr23095112obc.11.1379983571480; Mon, 23 Sep 2013 17:46:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.97.39 with HTTP; Mon, 23 Sep 2013 17:45:51 -0700 (PDT) In-Reply-To: <52405797.9020609@omnilan.de> References: <523B04C3.30100@omnilan.de> <52405797.9020609@omnilan.de> From: Amitabh Kant Date: Tue, 24 Sep 2013 06:15:51 +0530 Message-ID: Subject: Re: 9.2 panic with wcb4xxp (dahdi-kmod26-2.6.1.r10738) To: Harald Schmalzbauer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-isdn@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 00:46:12 -0000 On Mon, Sep 23, 2013 at 8:30 PM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > Bez=FCglich Amitabh Kant's Nachricht vom 21.09.2013 03:24 (localtime): > > On Thu, Sep 19, 2013 at 7:35 PM, Harald Schmalzbauer > > > wrote: > > > > Hello, > > > > unloading the kernel module of dahdi-kmod26-2.6.1.r10738 leads to > this > > panic: > > > > > > > > > > wcb4xxp0: <6>Did not do the highestorder stuff > > <6>dahdi: Detected time shift. > > <5>dahdi_echocan_mg2: Registered echo canceler 'MG2' > > > > Starting asterisk afterwards also leads to panic. > > I guess dahdi development stalled, but I wanted to try it because I= 'd > > prefer freeswitch and need BRI support... > > Is somebody familiar with dahdi and interested in making it work wi= th > > FreeBSD 9.2? > > > > Thanks, > > > > -Harry (not subscribed to isdn@) > > > > > > > > Have you been able to solve the problem? I am running Freeswitch (from > > git, not port) and dahdi/dahdi-kmod26 (from port) with PRI line > > (Digium 8 span and single span) without any problems on 9.1. Will test > > it on 9.2 and get back to you if I see a panic . > Hello Amitabh, > > couldn't solve my problem. > First, dahdi_scan doesn't detect ports jumpered to NT mode. I need 2 port= s > in NT mode, so trying anything else with dahdi before my settings get > correctly recognized is probably not worth the time. > Also I have to investigate if it is still true that libpri doesn't suppor= t > ptmp in NT mode!?! > In general, the freebsd dahdi port doesn't seem to be in good shape; > Couldn't find any docs about sysctls (dahdi.wcb4xxp.teignorered, '-d' sho= ws > nothing :-( ), no man page =96 hard to find out anything about dahdi in > FreeBSD, not even the supported hardwhere seems to be documentend > anywhere... > > Any hints highly appreciated, although I think the better way was to teac= h > FreeTDM speaking CAPI. HPS does a great job keeping all kind of ISDN > hardware supported by i4b (ISDN4BSD)! > Or to make chan_capi work with asterisk11 =96 the lesser evil than fighti= ng > dahid... > > Thanks, > > -Harry > > > Hello Harry Sadly, there is not much help while installing/using dahdi on FreeBSD. There does not seem to by any sysctls defined for dahdi which are needed to set for certain cards. Infact, for the 8 span card, to change the default T1 to E1, I had to make changes in the code directly. Amitabh From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 05:39:57 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 88608F25 for ; Tue, 24 Sep 2013 05:39:57 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 520202233 for ; Tue, 24 Sep 2013 05:39:56 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:31375] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 9F/64-16087-6A521425; Tue, 24 Sep 2013 05:39:50 +0000 Date: Tue, 24 Sep 2013 05:39:50 +0000 Message-ID: <9F.64.16087.6A521425@cdptpa-oedge02> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard References: <20130923201652.6077480310595862fc9df015@getmail.no> X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 05:39:57 -0000 for MSI Z77 MPOWER motherboard: re0@pci0:2:0:0: class=0x020000 card=0x77511462 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet ifconfig re0 shows re0: flags=8802 metric 0 mtu 1500 options=8209b ether d4:3d:7e:97:17:e2 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active dhclient re0 produces DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 12 DHCPOFFER from 192.168.1.1 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 192.168.1.1 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 16 No DHCPOFFERS received. No working leases in persistent database - sleeping. Ethernet chip data for older motherboard, MSI Z68MA-ED55(B3), is re0@pci0:3:0:0: class=0x020000 card=0x76761462 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet So I still can not connect on the newer motherboard as I can with the older motherboard, despite the same chip; card has a different ID. Tom From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 07:44:34 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 38123790 for ; Tue, 24 Sep 2013 07:44:34 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id F345A2817 for ; Tue, 24 Sep 2013 07:44:33 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id EF7EDA77B; Tue, 24 Sep 2013 09:44:31 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id 826AD397; Tue, 24 Sep 2013 09:44:28 +0200 (CEST) Date: Tue, 24 Sep 2013 09:44:27 +0200 From: Patrick Lamaiziere To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924094427.0f4b902a@mr129166> In-Reply-To: <20130923203141.GV41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 07:44:34 -0000 Le Mon, 23 Sep 2013 23:31:41 +0300, Konstantin Belousov a écrit : Hello, ... > > Ok This has been mfced to 9.2-STABLE. But I still see this panic > > with 9-2/STABLE of today (Revision : 255811). This may be better > > because before the box paniced within minutes and now within hours > > (still using poudriere). > > > > panic: > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff808ebfcd > > stack pointer = 0x28:0xffffff824c2e0630 > > frame pointer = 0x28:0xffffff824c2e06a0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 54243 (gvfsd-trash) > > trap number = 12 > > panic: page fault > > cpuid = 2 > > KDB: stack backtrace: > > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > > #1 0xffffffff808ffacd at panic+0x1cd > > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > > #3 0xffffffff80cdff4f at trap_pfault+0x20f > > #4 0xffffffff80ce0504 at trap+0x344 > > #5 0xffffffff80cc9b43 at calltrap+0x8 > > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > > #8 0xffffffff808c4de8 at kern_kevent+0x108 > > #9 0xffffffff808c5950 at sys_kevent+0x90 > > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > > > Full core.txt : > > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 > > For start, please load the core into kgdb and for > frame 8 > p *kn (kgdb) frame 8 #8 0xffffffff8099d043 in filt_vfsvnode (kn=0xfffffe0147a7f000, hint=0) at /usr/src/sys/kern/vfs_subr.c:4600 4600 VI_LOCK(vp); (kgdb) p *kn $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq = 0xfffffe01079a6200, kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = 0xfffffe016949e190, p_proc = 0xfffffe016949e190, p_aio = 0xfffffe016949e190, p_lio = 0xfffffe016949e190}, kn_fop = 0xffffffff812fd440, kn_hook = 0xfffffe0119d0b1f8, kn_hookid = 0} > Also, please follow > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > to recompile kernel with the debugging options and try to recreate > the panic. It's building. Thanks, regards From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 08:29:16 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 5B6F36C3 for ; Tue, 24 Sep 2013 08:29:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED81F2A94 for ; Tue, 24 Sep 2013 08:29:15 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8O8T9vM079066; Tue, 24 Sep 2013 11:29:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8O8T9vM079066 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8O8T9gh079065; Tue, 24 Sep 2013 11:29:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Sep 2013 11:29:09 +0300 From: Konstantin Belousov To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924082909.GH41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I+bMzLstCROLYLmh" Content-Disposition: inline In-Reply-To: <20130924094427.0f4b902a@mr129166> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:29:16 -0000 --I+bMzLstCROLYLmh Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 24, 2013 at 09:44:27AM +0200, Patrick Lamaiziere wrote: > Le Mon, 23 Sep 2013 23:31:41 +0300, > Konstantin Belousov a ?crit : >=20 > Hello, >=20 > ... >=20 >=20 > > > Ok This has been mfced to 9.2-STABLE. But I still see this panic > > > with 9-2/STABLE of today (Revision=9A: 255811). This may be better > > > because before the box paniced within minutes and now within hours > > > (still using poudriere). > > >=20 > > > panic: > > > fault code =3D supervisor read data, page not present > > > instruction pointer =3D 0x20:0xffffffff808ebfcd > > > stack pointer =3D 0x28:0xffffff824c2e0630 > > > frame pointer =3D 0x28:0xffffff824c2e06a0 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 54243 (gvfsd-trash) > > > trap number =3D 12 > > > panic: page fault > > > cpuid =3D 2 > > > KDB: stack backtrace: > > > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > > > #1 0xffffffff808ffacd at panic+0x1cd > > > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > > > #3 0xffffffff80cdff4f at trap_pfault+0x20f > > > #4 0xffffffff80ce0504 at trap+0x344 > > > #5 0xffffffff80cc9b43 at calltrap+0x8 > > > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > > > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > > > #8 0xffffffff808c4de8 at kern_kevent+0x108 > > > #9 0xffffffff808c5950 at sys_kevent+0x90 > > > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > > > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > >=20 > > > Full core.txt :=20 > > > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 > >=20 > > For start, please load the core into kgdb and for > > frame 8 > > p *kn >=20 > (kgdb) frame 8 > #8 0xffffffff8099d043 in filt_vfsvnode (kn=3D0xfffffe0147a7f000, hint=3D= 0) > at /usr/src/sys/kern/vfs_subr.c:4600 > 4600 VI_LOCK(vp); > (kgdb) p *kn > $1 =3D {kn_link =3D {sle_next =3D 0x0}, kn_selnext =3D {sle_next =3D 0x0}= ,=20 > kn_knlist =3D 0x0, kn_tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0},=20 > kn_kq =3D 0xfffffe01079a6200, kn_kevent =3D {ident =3D 62, filter =3D -= 4,=20 > flags =3D 32784, fflags =3D 0, data =3D 0, udata =3D 0x0}, kn_status = =3D 24,=20 > kn_sfflags =3D 47, kn_sdata =3D 0, kn_ptr =3D {p_fp =3D 0xfffffe016949e= 190,=20 > p_proc =3D 0xfffffe016949e190, p_aio =3D 0xfffffe016949e190,=20 > p_lio =3D 0xfffffe016949e190}, kn_fop =3D 0xffffffff812fd440,=20 > kn_hook =3D 0xfffffe0119d0b1f8, kn_hookid =3D 0} =46rom the kgdb, also please do p *(struct vnode *)0xfffffe0119d0b1f8 >=20 >=20 > > Also, please follow > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html > > to recompile kernel with the debugging options and try to recreate > > the panic. >=20 > It's building. Please try the following. diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index aa165a0..5715f35 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4421,10 +4421,14 @@ filt_vfsdetach(struct knote *kn) static int filt_vfsread(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; struct vattr va; int res; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; + /* * filesystem is gone, so set the EOF flag and schedule * the knote for deletion. @@ -4450,8 +4454,11 @@ filt_vfsread(struct knote *kn, long hint) static int filt_vfswrite(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; VI_LOCK(vp); =20 /* @@ -4469,9 +4476,12 @@ filt_vfswrite(struct knote *kn, long hint) static int filt_vfsvnode(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; int res; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; VI_LOCK(vp); if (kn->kn_sfflags & hint) kn->kn_fflags |=3D hint; --I+bMzLstCROLYLmh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQU1VAAoJEJDCuSvBvK1BAacQAKci+a9PoDBfh+yAsEhqLK0I 5/qXLqv9yjqRPnDYuHoBpMuO7V67pon5UhOc0AqkWQg491sYE2+UGg8Or/+v5O89 twQhhOPmJgvoRNTKyL+tbVDHf1i0XqyR5AccClktpqgJ0JFv2XDIuCc+3dP6WwIm uD0nV8DrzZsP4v+fVJRSi1ggvHrFiBFcYnL89YUdFwJ1ueom2I1XOf5oDuUkFA/P wDELqq57e/gQPDMZEw4Mi0YlXDzUn9dF4NyW8wop05ChnJTBrCxuZ28Q+YJihPbu 4KV/fCpGoXD5DzMqjtiLRiEemvIworlWZcLJESLETct1svr6g3EQ134Qf99JQAlG fEm3KjBlinOHnUqTmSAi7yOVroOc9WTDIX1vID6kPnLR93VMHe+d0oP4YwxcXEo7 FovrGbyGvPd4Kg8yGr3yTWO/KFHJjWjQTseXJcr6ZauhfU2j8Dr+5sTkE2ABHhDY qdgfFd42DFnwipvarmiS+l++ZcEFA3aUVPBib+HeLK2jd9M6DAO5Bya8n97yYY9u SF3Rpb26D0I1PxLfFwYqKT/kr8OtQZaNqrKSHyqOruTO4T1Bxq7CZyKMGrdIt9p4 DcKq2ZWfEp9bIgvHZ3QqJNYpbijiAkwwhDfUtQohyQqAQ5pxJSwUbC7s4ppJyt/n jIWGsUH6BSIE6mnCTLr2 =V4Uu -----END PGP SIGNATURE----- --I+bMzLstCROLYLmh-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 09:47:41 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 958F5343 for ; Tue, 24 Sep 2013 09:47:41 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id F22132ECF for ; Tue, 24 Sep 2013 09:47:40 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id D6DD8A7AB; Tue, 24 Sep 2013 11:47:38 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id 72C691BB; Tue, 24 Sep 2013 11:47:38 +0200 (CEST) Date: Tue, 24 Sep 2013 11:47:38 +0200 From: Patrick Lamaiziere To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924114738.60c700c9@mr129166> In-Reply-To: <20130924082909.GH41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 09:47:41 -0000 Le Tue, 24 Sep 2013 11:29:09 +0300, Konstantin Belousov a écrit : Hello, ... > > > > Ok This has been mfced to 9.2-STABLE. But I still see this panic > > > > with 9-2/STABLE of today (Revision : 255811). This may be better > > > > because before the box paniced within minutes and now within > > > > hours (still using poudriere). > > > > > > > > panic: > > > > fault code = supervisor read data, page not present > > > > instruction pointer = 0x20:0xffffffff808ebfcd > > > > stack pointer = 0x28:0xffffff824c2e0630 > > > > frame pointer = 0x28:0xffffff824c2e06a0 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 54243 (gvfsd-trash) > > > > trap number = 12 > > > > panic: page fault > > > > cpuid = 2 > > > > KDB: stack backtrace: > > > > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > > > > #1 0xffffffff808ffacd at panic+0x1cd > > > > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > > > > #3 0xffffffff80cdff4f at trap_pfault+0x20f > > > > #4 0xffffffff80ce0504 at trap+0x344 > > > > #5 0xffffffff80cc9b43 at calltrap+0x8 > > > > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > > > > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > > > > #8 0xffffffff808c4de8 at kern_kevent+0x108 > > > > #9 0xffffffff808c5950 at sys_kevent+0x90 > > > > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > > > > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > > > > > > > Full core.txt : > > > > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 > > > > > > For start, please load the core into kgdb and for > > > frame 8 > > > p *kn > > > > (kgdb) frame 8 > > #8 0xffffffff8099d043 in filt_vfsvnode (kn=0xfffffe0147a7f000, > > hint=0) at /usr/src/sys/kern/vfs_subr.c:4600 > > 4600 VI_LOCK(vp); > > (kgdb) p *kn > > $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0}, > > kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, > > kn_kq = 0xfffffe01079a6200, kn_kevent = {ident = 62, filter = -4, > > flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = > > 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = > > 0xfffffe016949e190, p_proc = 0xfffffe016949e190, p_aio = > > 0xfffffe016949e190, p_lio = 0xfffffe016949e190}, kn_fop = > > 0xffffffff812f0, kn_hook = 0xfffffe0119d0b1f8, kn_hookid = 0} > From the kgdb, also please do > p *(struct vnode *)0xfffffe0119d0b1f8 With a kernel with debug info, this panic becomes mtx_lock() of destroyed mutex panic: mtx_lock() of destroyed mutex http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt @ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2 KDB: stack backtrace: #0 0xffffffff80920286 at kdb_backtrace+0x66 #1 0xffffffff808e738d at panic+0x1cd #2 0xffffffff808d58d6 at _mtx_lock_flags+0x116 #3 0xffffffff8098143b at filt_vfsvnode+0x3b #4 0xffffffff808b213a at kqueue_register+0x4ca #5 0xffffffff808b2688 at kern_kevent+0x108 #6 0xffffffff808b3190 at sys_kevent+0x90 #7 0xffffffff80cbd975 at amd64_syscall+0x2f5 #8 0xffffffff80ca8557 at Xfast_syscall+0xf7 (kgdb) frame 5 #5 0xffffffff808b213a in kqueue_register (kq=0xfffffe00ddc98900, kev=0xffffff824bb5f880, td=0xfffffe00b1e7f000, waitok=1) at /usr/src/sys/kern/kern_event.c:1136 1136 event = kn->kn_fop->f_event(kn, 0); (kgdb) p *kn $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0xfffffe011c232b00}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq = 0xfffffe00ddc98900, kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = { p_fp = 0xfffffe00ddd4d870, p_proc = 0xfffffe00ddd4d870, p_aio = 0xfffffe00ddd4d870, p_lio = 0xfffffe00ddd4d870}, kn_fop = 0xffffffff812fcca0, kn_hook = 0xfffffe02064a6000, kn_hookid = 0} (kgdb) p *(struct vnode *)0xfffffe02064a6000 $2 = {v_type = VBAD, v_tag = 0xffffffff80d89084 "none", v_op = 0x0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfffffe020d3e6000, tqe_prev = 0xfffffe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0xffffff8000de9698}, v_hash = 238022, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe02064a6060}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff80f56e48 "ufs", lo_flags = 91881472, lo_data = 0, lo_witness = 0xffffff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822, 18446744071573768556, 18446744071576111075, 18446744071606114523, 18446744071576111075, 18446744071572113927, 18446744071572067653, 18446744071606111219, 18446744071572016126, 18446744071572018094, 18446744071575427445, 18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = { lo_name = 0xffffffff80f6f8a3 "vnode interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0xffffff80006a9600}, mtx_lock = 6}, v_vnlock = 0xfffffe02064a6098, v_holdcnt = 0, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_actfreelist = {tqe_next = 0xfffffe0086625a40, tqe_prev = 0xfffffe020d3e61a8}, v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff80f781ec "bufobj interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0xffffff80006b1680}, mtx_lock = 6}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe02064a61d8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe02064a61f8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff812f9960, bo_bsize = 32768, bo_object = 0x0, bo_synclist = {le_next = 0xfffffe001d797bf8, le_prev = 0xfffffe005f632240}, bo_private = 0xfffffe02064a6000, __bo_vnode = 0xfffffe02064a6000}, v_pollinfo = 0xfffffe00b15dc540, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe02064a6278}, rl_currdep = 0x0}} ----------- > Please try the following. > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index aa165a0..5715f35 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -4421,10 +4421,14 @@ filt_vfsdetach(struct knote *kn) > static int > filt_vfsread(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > struct vattr va; > int res; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > + > /* > * filesystem is gone, so set the EOF flag and schedule > * the knote for deletion. > @@ -4450,8 +4454,11 @@ filt_vfsread(struct knote *kn, long hint) > static int > filt_vfswrite(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > VI_LOCK(vp); > > /* > @@ -4469,9 +4476,12 @@ filt_vfswrite(struct knote *kn, long hint) > static int > filt_vfsvnode(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > int res; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > VI_LOCK(vp); > if (kn->kn_sfflags & hint) > kn->kn_fflags |= hint; With this I've got another panic 'vn_lock zero hold count' (it is an assertion in vfs_vnops.c) : http://user.lamaiziere.net/patrick/public/panic_zero_hold_count.txt panic: vn_lock 0xfffffe018afd0000: zero hold count cpuid = 4 KDB: stack backtrace: #0 0xffffffff80920286 at kdb_backtrace+0x66 #1 0xffffffff808e738d at panic+0x1cd #2 0xffffffff80994abd at _vn_lock+0xcd #3 0xffffffff808aff57 at knlist_remove_kq+0x67 #4 0xffffffff808b1617 at knote_fdclose+0x177 #5 0xffffffff808ab1a9 at kern_close+0xe9 #6 0xffffffff80cbd9b5 at amd64_syscall+0x2f5 #7 0xffffffff80ca8597 at Xfast_syscall+0xf7 (kgdb) #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff808e792e in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff808e7364 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80994abd in _vn_lock (vp=0xfffffe018afd0000, flags=0, file=0x0, line=0) at /usr/src/sys/kern/vfs_vnops.c:1398 #4 0xffffffff808aff57 in knlist_remove_kq (knl=0xfffffe0056b053b0, kn=0xfffffe018a9c0b80, knlislocked=0, kqislocked=0) at /usr/src/sys/kern/kern_event.c:1843 #5 0xffffffff808b1617 in knote_fdclose (td=0xfffffe0056c2a000, fd=62) at /usr/src/sys/kern/kern_event.c:2065 #6 0xffffffff808ab1a9 in kern_close (td=0xfffffe0056c2a000, fd=62) at /usr/src/sys/kern/kern_descrip.c:1250 #7 0xffffffff80cbd9b5 in amd64_syscall (td=0xfffffe0056c2a000, traced=0) at subr_syscall.c:135 #8 0xffffffff80ca8597 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x00000008032f3bcc in ?? () Previous frame inner to this frame (corrupt stack?) the code of frame 3 is (kgdb) frame 3 #3 0xffffffff80994abd in _vn_lock (vp=0xfffffe018afd0000, flags=0, file=0x0, line=0) at /usr/src/sys/kern/vfs_vnops.c:1398 1398 KASSERT(vp->v_holdcnt != 0, (kgdb) l 1393 1394 VNASSERT((flags & LK_TYPE_MASK) != 0, vp, 1395 ("vn_lock called with no locktype.")); 1396 do { 1397 #ifdef DEBUG_VFS_LOCKS 1398 KASSERT(vp->v_holdcnt != 0, 1399 ("vn_lock %p: zero hold count", vp)); 1400 #endif 1401 error = VOP_LOCK1(vp, flags, file, line); 1402 flags &= ~LK_INTERLOCK; /* Interlock is always dropped. */ the vp is = (kgdb) p *(struct vnode *) 0xfffffe018afd0000 $2 = {v_type = VDIR, v_tag = 0xffffffff80f56e88 "ufs", v_op = 0xffffffff8132c800, v_data = 0xfffffe013a2a7348, v_mount = 0xfffffe0009c00b70, v_nmntvnodes = { tqe_next = 0xfffffe018ace3520, tqe_prev = 0xfffffe018afd02b8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { le_next = 0x0, le_prev = 0xffffff8000e29f00}, v_hash = 236846, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe018afd0060}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff80f56e88 "ufs", lo_flags = 91947008, lo_data = 0, lo_witness = 0xffffff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822, 18446744071573768620, 18446744071576111139, 18446744071606114523, 18446744071576111139, 18446744071572113991, 18446744071572067715, 18446744071606111219, 18446744071572016126, 18446744071572018094, 18446744071575427509, 18446744071575340439, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = { lo_name = 0xffffffff80f6f8e3 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006a9600}, mtx_lock = 4}, v_vnlock = 0xfffffe018afd0098, v_holdcnt = 0, v_usecount = 0, v_iflag = 256, v_vflag = 0, v_writecount = 0, v_actfreelist = {tqe_next = 0xfffffe018ace3cd0, tqe_prev = 0xfffffe00aefe6e78}, v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff80f7822c "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006b1680}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe018afd01d8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe018afd01f8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff812f99a0, bo_bsize = 32768, bo_object = 0xfffffe01f8a6c570, bo_synclist = {le_next = 0xfffffe018afd0448, le_prev = 0xfffffe00096d5ca0}, bo_private = 0xfffffe018afd0000, __bo_vnode = 0xfffffe018afd0000}, v_pollinfo = 0xfffffe0056b05380, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe018afd0278}, rl_currdep = 0x0}} ------- Thanks a lot, regards. From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 12:14:49 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id E9E30A34 for ; Tue, 24 Sep 2013 12:14:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4118F2837 for ; Tue, 24 Sep 2013 12:14:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8OCEZZ7026844; Tue, 24 Sep 2013 15:14:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8OCEZZ7026844 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8OCEYLP026843; Tue, 24 Sep 2013 15:14:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 24 Sep 2013 15:14:34 +0300 From: Konstantin Belousov To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924121434.GI41229@kib.kiev.ua> References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NqggDZQ8GcqffSaB" Content-Disposition: inline In-Reply-To: <20130924114738.60c700c9@mr129166> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:14:49 -0000 --NqggDZQ8GcqffSaB Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 24, 2013 at 11:47:38AM +0200, Patrick Lamaiziere wrote: > Le Tue, 24 Sep 2013 11:29:09 +0300, > Konstantin Belousov a ?crit : >=20 > Hello, >=20 > ... >=20 > > > > > Ok This has been mfced to 9.2-STABLE. But I still see this panic > > > > > with 9-2/STABLE of today (Revision=9A: 255811). This may be better > > > > > because before the box paniced within minutes and now within > > > > > hours (still using poudriere). > > > > >=20 > > > > > panic: > > > > > fault code =3D supervisor read data, page not present > > > > > instruction pointer =3D 0x20:0xffffffff808ebfcd > > > > > stack pointer =3D 0x28:0xffffff824c2e0630 > > > > > frame pointer =3D 0x28:0xffffff824c2e06a0 > > > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > > > current process =3D 54243 (gvfsd-trash) > > > > > trap number =3D 12 > > > > > panic: page fault > > > > > cpuid =3D 2 > > > > > KDB: stack backtrace: > > > > > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > > > > > #1 0xffffffff808ffacd at panic+0x1cd > > > > > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > > > > > #3 0xffffffff80cdff4f at trap_pfault+0x20f > > > > > #4 0xffffffff80ce0504 at trap+0x344 > > > > > #5 0xffffffff80cc9b43 at calltrap+0x8 > > > > > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > > > > > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > > > > > #8 0xffffffff808c4de8 at kern_kevent+0x108 > > > > > #9 0xffffffff808c5950 at sys_kevent+0x90 > > > > > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > > > > > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > > > >=20 > > > > > Full core.txt :=20 > > > > > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 > > > >=20 > > > > For start, please load the core into kgdb and for > > > > frame 8 > > > > p *kn > > >=20 > > > (kgdb) frame 8 > > > #8 0xffffffff8099d043 in filt_vfsvnode (kn=3D0xfffffe0147a7f000, > > > hint=3D0) at /usr/src/sys/kern/vfs_subr.c:4600 > > > 4600 VI_LOCK(vp); > > > (kgdb) p *kn > > > $1 =3D {kn_link =3D {sle_next =3D 0x0}, kn_selnext =3D {sle_next =3D = 0x0},=20 > > > kn_knlist =3D 0x0, kn_tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0},= =20 > > > kn_kq =3D 0xfffffe01079a6200, kn_kevent =3D {ident =3D 62, filter = =3D -4,=20 > > > flags =3D 32784, fflags =3D 0, data =3D 0, udata =3D 0x0}, kn_sta= tus =3D > > > 24, kn_sfflags =3D 47, kn_sdata =3D 0, kn_ptr =3D {p_fp =3D > > > 0xfffffe016949e190, p_proc =3D 0xfffffe016949e190, p_aio =3D > > > 0xfffffe016949e190, p_lio =3D 0xfffffe016949e190}, kn_fop =3D > > > 0xffffffff812f0, kn_hook =3D 0xfffffe0119d0b1f8, kn_hookid =3D 0} > > From the kgdb, also please do > > p *(struct vnode *)0xfffffe0119d0b1f8 >=20 > With a kernel with debug info, this panic becomes mtx_lock() of > destroyed mutex > panic: mtx_lock() of destroyed mutex >=20 > http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt >=20 > @ /usr/src/sys/kern/vfs_subr.c:4600 cpuid =3D 2 > KDB: stack backtrace: > #0 0xffffffff80920286 at kdb_backtrace+0x66 > #1 0xffffffff808e738d at panic+0x1cd > #2 0xffffffff808d58d6 at _mtx_lock_flags+0x116 > #3 0xffffffff8098143b at filt_vfsvnode+0x3b > #4 0xffffffff808b213a at kqueue_register+0x4ca > #5 0xffffffff808b2688 at kern_kevent+0x108 > #6 0xffffffff808b3190 at sys_kevent+0x90 > #7 0xffffffff80cbd975 at amd64_syscall+0x2f5 > #8 0xffffffff80ca8557 at Xfast_syscall+0xf7 >=20 > (kgdb) frame 5 > #5 0xffffffff808b213a in kqueue_register (kq=3D0xfffffe00ddc98900, kev= =3D0xffffff824bb5f880, td=3D0xfffffe00b1e7f000, waitok=3D1) at /usr/src/sys= /kern/kern_event.c:1136 > 1136 event =3D kn->kn_fop->f_event(kn, 0); >=20 > (kgdb) p *kn > $1 =3D {kn_link =3D {sle_next =3D 0x0}, kn_selnext =3D {sle_next =3D 0xff= fffe011c232b00}, kn_knlist =3D 0x0, kn_tqe =3D {tqe_next =3D 0x0, tqe_prev = =3D 0x0}, kn_kq =3D 0xfffffe00ddc98900,=20 > kn_kevent =3D {ident =3D 62, filter =3D -4, flags =3D 32784, fflags =3D= 0, data =3D 0, udata =3D 0x0}, kn_status =3D 24, kn_sfflags =3D 47, kn_sda= ta =3D 0, kn_ptr =3D { > p_fp =3D 0xfffffe00ddd4d870, p_proc =3D 0xfffffe00ddd4d870, p_aio =3D= 0xfffffe00ddd4d870, p_lio =3D 0xfffffe00ddd4d870}, kn_fop =3D 0xffffffff81= 2fcca0,=20 > kn_hook =3D 0xfffffe02064a6000, kn_hookid =3D 0} >=20 > (kgdb) p *(struct vnode *)0xfffffe02064a6000 > $2 =3D {v_type =3D VBAD, v_tag =3D 0xffffffff80d89084 "none", v_op =3D 0x= 0, v_data =3D 0x0, v_mount =3D 0x0, v_nmntvnodes =3D {tqe_next =3D 0xfffffe= 020d3e6000,=20 > tqe_prev =3D 0xfffffe0086625a68}, v_un =3D {vu_mount =3D 0x0, vu_sock= et =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_next = =3D 0x0,=20 > le_prev =3D 0xffffff8000de9698}, v_hash =3D 238022, v_cache_src =3D {= lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff= e02064a6060}, v_cache_dd =3D 0x0,=20 > v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, v_lock =3D = {lock_object =3D {lo_name =3D 0xffffffff80f56e48 "ufs", lo_flags =3D 918814= 72, lo_data =3D 0,=20 > lo_witness =3D 0xffffff80006c3400}, lk_lock =3D 1, lk_exslpfail =3D= 0, lk_timo =3D 51, lk_pri =3D 96, lk_stack =3D {depth =3D 12, pcs =3D {184= 46744071571296822,=20 > 18446744071573768556, 18446744071576111075, 18446744071606114523,= 18446744071576111075, 18446744071572113927, 18446744071572067653, 18446744= 071606111219,=20 > 18446744071572016126, 18446744071572018094, 18446744071575427445,= 18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock =3D {lock_object = =3D { > lo_name =3D 0xffffffff80f6f8a3 "vnode interlock", lo_flags =3D 1690= 8288, lo_data =3D 0, lo_witness =3D 0xffffff80006a9600}, mtx_lock =3D 6}, v= _vnlock =3D 0xfffffe02064a6098,=20 > v_holdcnt =3D 0, v_usecount =3D 0, v_iflag =3D 128, v_vflag =3D 0, v_wr= itecount =3D 0, v_actfreelist =3D {tqe_next =3D 0xfffffe0086625a40, tqe_pre= v =3D 0xfffffe020d3e61a8},=20 > v_bufobj =3D {bo_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80f781= ec "bufobj interlock", lo_flags =3D 16908288, lo_data =3D 0, lo_witness =3D= 0xffffff80006b1680},=20 > mtx_lock =3D 6}, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_la= st =3D 0xfffffe02064a61d8}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D {b= v_hd =3D {tqh_first =3D 0x0,=20 > tqh_last =3D 0xfffffe02064a61f8}, bv_root =3D 0x0, bv_cnt =3D 0},= bo_numoutput =3D 0, bo_flag =3D 0, bo_ops =3D 0xffffffff812f9960, bo_bsize= =3D 32768, bo_object =3D 0x0,=20 > bo_synclist =3D {le_next =3D 0xfffffe001d797bf8, le_prev =3D 0xfffffe= 005f632240}, bo_private =3D 0xfffffe02064a6000, __bo_vnode =3D 0xfffffe0206= 4a6000},=20 > v_pollinfo =3D 0xfffffe00b15dc540, v_label =3D 0x0, v_lockf =3D 0x0, v_= rl =3D > {rl_waiters =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffffe02064a6278}, > rl_currdep =3D 0x0}} >=20 >=20 > ----------- >=20 > > Please try the following. > >=20 > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > > index aa165a0..5715f35 100644 > > --- a/sys/kern/vfs_subr.c > > +++ b/sys/kern/vfs_subr.c > > @@ -4421,10 +4421,14 @@ filt_vfsdetach(struct knote *kn) > > static int > > filt_vfsread(struct knote *kn, long hint) > > { > > - struct vnode *vp =3D (struct vnode *)kn->kn_hook; > > + struct vnode *vp; > > struct vattr va; > > int res; > > =20 > > + if ((kn->kn_status & KN_DETACHED) !=3D 0) > > + return (0); > > + vp =3D (struct vnode *)kn->kn_hook; > > + > > /* > > * filesystem is gone, so set the EOF flag and schedule > > * the knote for deletion. > > @@ -4450,8 +4454,11 @@ filt_vfsread(struct knote *kn, long hint) > > static int > > filt_vfswrite(struct knote *kn, long hint) > > { > > - struct vnode *vp =3D (struct vnode *)kn->kn_hook; > > + struct vnode *vp; > > =20 > > + if ((kn->kn_status & KN_DETACHED) !=3D 0) > > + return (0); > > + vp =3D (struct vnode *)kn->kn_hook; > > VI_LOCK(vp); > > =20 > > /* > > @@ -4469,9 +4476,12 @@ filt_vfswrite(struct knote *kn, long hint) > > static int > > filt_vfsvnode(struct knote *kn, long hint) > > { > > - struct vnode *vp =3D (struct vnode *)kn->kn_hook; > > + struct vnode *vp; > > int res; > > =20 > > + if ((kn->kn_status & KN_DETACHED) !=3D 0) > > + return (0); > > + vp =3D (struct vnode *)kn->kn_hook; > > VI_LOCK(vp); > > if (kn->kn_sfflags & hint) > > kn->kn_fflags |=3D hint; >=20 > With this I've got another panic 'vn_lock zero hold count' (it is an asse= rtion in vfs_vnops.c) : >=20 For this one I have another patch, written some time ago, http://people.freebsd.org/~kib/misc/vnode_filter.1.patch Please see below for combined patch, thank you for the testing and detailed reports. > http://user.lamaiziere.net/patrick/public/panic_zero_hold_count.txt >=20 > panic: vn_lock 0xfffffe018afd0000: zero hold count > cpuid =3D 4 > KDB: stack backtrace: > #0 0xffffffff80920286 at kdb_backtrace+0x66 > #1 0xffffffff808e738d at panic+0x1cd > #2 0xffffffff80994abd at _vn_lock+0xcd > #3 0xffffffff808aff57 at knlist_remove_kq+0x67 > #4 0xffffffff808b1617 at knote_fdclose+0x177 > #5 0xffffffff808ab1a9 at kern_close+0xe9 > #6 0xffffffff80cbd9b5 at amd64_syscall+0x2f5 > #7 0xffffffff80ca8597 at Xfast_syscall+0xf7 >=20 > (kgdb) #0 doadump (textdump=3D) at pcpu.h:234 > #1 0xffffffff808e792e in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:449 > #2 0xffffffff808e7364 in panic (fmt=3D0x1
) > at /usr/src/sys/kern/kern_shutdown.c:637 > #3 0xffffffff80994abd in _vn_lock (vp=3D0xfffffe018afd0000, flags=3D0, f= ile=3D0x0,=20 > line=3D0) at /usr/src/sys/kern/vfs_vnops.c:1398 > #4 0xffffffff808aff57 in knlist_remove_kq (knl=3D0xfffffe0056b053b0,=20 > kn=3D0xfffffe018a9c0b80, knlislocked=3D0, kqislocked=3D0) > at /usr/src/sys/kern/kern_event.c:1843 > #5 0xffffffff808b1617 in knote_fdclose (td=3D0xfffffe0056c2a000, fd=3D62) > at /usr/src/sys/kern/kern_event.c:2065 > #6 0xffffffff808ab1a9 in kern_close (td=3D0xfffffe0056c2a000, fd=3D62) > at /usr/src/sys/kern/kern_descrip.c:1250 > #7 0xffffffff80cbd9b5 in amd64_syscall (td=3D0xfffffe0056c2a000, traced= =3D0) > at subr_syscall.c:135 > #8 0xffffffff80ca8597 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:391 > #9 0x00000008032f3bcc in ?? () > Previous frame inner to this frame (corrupt stack?) >=20 > the code of frame 3 is > (kgdb) frame 3 > #3 0xffffffff80994abd in _vn_lock (vp=3D0xfffffe018afd0000, flags=3D0, f= ile=3D0x0, line=3D0) at /usr/src/sys/kern/vfs_vnops.c:1398 > 1398 KASSERT(vp->v_holdcnt !=3D 0, > (kgdb) l > 1393=09 > 1394 VNASSERT((flags & LK_TYPE_MASK) !=3D 0, vp, > 1395 ("vn_lock called with no locktype.")); > 1396 do { > 1397 #ifdef DEBUG_VFS_LOCKS > 1398 KASSERT(vp->v_holdcnt !=3D 0, > 1399 ("vn_lock %p: zero hold count", vp)); > 1400 #endif > 1401 error =3D VOP_LOCK1(vp, flags, file, line); > 1402 flags &=3D ~LK_INTERLOCK; /* Interlock is always dropped. */ >=20 > the vp is =3D=20 > (kgdb) p *(struct vnode *) 0xfffffe018afd0000 > $2 =3D {v_type =3D VDIR, v_tag =3D 0xffffffff80f56e88 "ufs", v_op =3D 0xf= fffffff8132c800, v_data =3D 0xfffffe013a2a7348, v_mount =3D 0xfffffe0009c00= b70, v_nmntvnodes =3D { > tqe_next =3D 0xfffffe018ace3520, tqe_prev =3D 0xfffffe018afd02b8}, v_= un =3D {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo = =3D 0x0}, v_hashlist =3D { > le_next =3D 0x0, le_prev =3D 0xffffff8000e29f00}, v_hash =3D 236846, = v_cache_src =3D {lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0x0, tqh= _last =3D 0xfffffe018afd0060},=20 > v_cache_dd =3D 0x0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_cle= n =3D 0, v_lock =3D {lock_object =3D {lo_name =3D 0xffffffff80f56e88 "ufs",= lo_flags =3D 91947008, lo_data =3D 0,=20 > lo_witness =3D 0xffffff80006c3400}, lk_lock =3D 1, lk_exslpfail =3D= 0, lk_timo =3D 51, lk_pri =3D 96, lk_stack =3D {depth =3D 12, pcs =3D {184= 46744071571296822,=20 > 18446744071573768620, 18446744071576111139, 18446744071606114523,= 18446744071576111139, 18446744071572113991, 18446744071572067715, 18446744= 071606111219,=20 > 18446744071572016126, 18446744071572018094, 18446744071575427509,= 18446744071575340439, 0, 0, 0, 0, 0, 0}}}, v_interlock =3D {lock_object = =3D { > lo_name =3D 0xffffffff80f6f8e3 "vnode interlock", lo_flags =3D 1697= 3824, lo_data =3D 0, lo_witness =3D 0xffffff80006a9600}, mtx_lock =3D 4}, v= _vnlock =3D 0xfffffe018afd0098,=20 > v_holdcnt =3D 0, v_usecount =3D 0, v_iflag =3D 256, v_vflag =3D 0, v_wr= itecount =3D 0, v_actfreelist =3D {tqe_next =3D 0xfffffe018ace3cd0, tqe_pre= v =3D 0xfffffe00aefe6e78},=20 > v_bufobj =3D {bo_mtx =3D {lock_object =3D {lo_name =3D 0xffffffff80f782= 2c "bufobj interlock", lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D= 0xffffff80006b1680},=20 > mtx_lock =3D 4}, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_la= st =3D 0xfffffe018afd01d8}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D {b= v_hd =3D {tqh_first =3D 0x0,=20 > tqh_last =3D 0xfffffe018afd01f8}, bv_root =3D 0x0, bv_cnt =3D 0},= bo_numoutput =3D 0, bo_flag =3D 0, bo_ops =3D 0xffffffff812f99a0, bo_bsize= =3D 32768,=20 > bo_object =3D 0xfffffe01f8a6c570, bo_synclist =3D {le_next =3D 0xffff= fe018afd0448, le_prev =3D 0xfffffe00096d5ca0}, bo_private =3D 0xfffffe018af= d0000,=20 > __bo_vnode =3D 0xfffffe018afd0000}, v_pollinfo =3D 0xfffffe0056b05380= , v_label =3D 0x0, v_lockf =3D 0x0, v_rl =3D {rl_waiters =3D {tqh_first =3D= 0x0,=20 > tqh_last =3D 0xfffffe018afd0278}, rl_currdep =3D 0x0}} >=20 diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 3cbc95f..d3013a0 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4397,6 +4399,7 @@ vfs_kqfilter(struct vop_kqfilter_args *ap) v_addpollinfo(vp); if (vp->v_pollinfo =3D=3D NULL) return (ENOMEM); + vhold(vp); knl =3D &vp->v_pollinfo->vpi_selinfo.si_note; knlist_add(knl, kn, 0); =20 @@ -4412,17 +4415,23 @@ filt_vfsdetach(struct knote *kn) struct vnode *vp =3D (struct vnode *)kn->kn_hook; =20 KASSERT(vp->v_pollinfo !=3D NULL, ("Missing v_pollinfo")); + kn->kn_hook =3D NULL; knlist_remove(&vp->v_pollinfo->vpi_selinfo.si_note, kn, 0); + vdrop(vp); } =20 /*ARGSUSED*/ static int filt_vfsread(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; struct vattr va; int res; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; + /* * filesystem is gone, so set the EOF flag and schedule * the knote for deletion. @@ -4448,8 +4457,11 @@ filt_vfsread(struct knote *kn, long hint) static int filt_vfswrite(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; VI_LOCK(vp); =20 /* @@ -4467,9 +4479,12 @@ filt_vfswrite(struct knote *kn, long hint) static int filt_vfsvnode(struct knote *kn, long hint) { - struct vnode *vp =3D (struct vnode *)kn->kn_hook; + struct vnode *vp; int res; =20 + if ((kn->kn_status & KN_DETACHED) !=3D 0) + return (0); + vp =3D (struct vnode *)kn->kn_hook; VI_LOCK(vp); if (kn->kn_sfflags & hint) kn->kn_fflags |=3D hint; --NqggDZQ8GcqffSaB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQYIpAAoJEJDCuSvBvK1Bfp0QAIwIe9R8UYOh6eDtw3M9CHpd z2VjMASCjHyEKPEUwN0AIDRvEsPxJI0Q4Mt7Q5XQ2eiqYV1QTrWPy2EvTJ1wKr5u Bgmzz7rJNd4x/+Ih51qJI4opFowT7vwP+V07F8R3fcrX9ISfRzbztbvMe4/oAMqB iLjvyfeXsBBVVirwNEyIzm/SlNKv79lHN57LQ4TQLSOUFAmPR6lniwZkJYbH8WWA QDuEJ/8aYiBaSv7o8rkwN7RH+YuA/YxM0y9Y9hQoMgUo6LoI6pMdH10AtMlwOJ4B Pcr1/uKojxaVGWaeR2UDC2cqtb3jFMiujZdlzAg9Oi3hYqy2iJ/ZWJENezuwCt+v VjAHnKWGOT4d9/VSR4wrbUIyX1MlC/n+E4BV0ZYxBmM5K2GGOU0aP9GxZZJYsVyo Xfkvywm7eWtCNQD57QJGLoR30O8orGjzNK2ef00JyfliW2pibhcb1AwlQgo5nUXc LCmyPLN5dvwFSBR8IhUsqJPKPYG8bYRpzWZJt4n+hJ8Tuybw6z2j+0ybjtx7bV13 D0OwomL8Fo7A4U/CoBjmTvHmZM95isKvdSkuwVIg7n6Zu8jzlk7aZ7Ua8IqfswDy 676ff04+8Bgaf8zo/iFuFZSG8HtMaxk5KQ2rSkU39W/nBknmk18a4wJ4wqxESmmX pTYIhuK7QaP9twgpJhEy =ze+r -----END PGP SIGNATURE----- --NqggDZQ8GcqffSaB-- From owner-freebsd-stable@FreeBSD.ORG Tue Sep 24 17:45:22 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id CD5B2C28 for ; Tue, 24 Sep 2013 17:45:22 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFF32D77 for ; Tue, 24 Sep 2013 17:45:22 +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 r8OHjIxU032371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 10:45:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8OHjIoi032370; Tue, 24 Sep 2013 10:45:18 -0700 (PDT) (envelope-from jmg) Date: Tue, 24 Sep 2013 10:45:17 -0700 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924174517.GB14220@funkthat.com> Mail-Followup-To: Konstantin Belousov , Patrick Lamaiziere , freebsd-stable@freebsd.org References: <20130911171913.GG41229@kib.kiev.ua> <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130924121434.GI41229@kib.kiev.ua> 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-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]); Tue, 24 Sep 2013 10:45:18 -0700 (PDT) Cc: freebsd-stable@freebsd.org, Patrick Lamaiziere X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:45:22 -0000 Konstantin Belousov wrote this message on Tue, Sep 24, 2013 at 15:14 +0300: > On Tue, Sep 24, 2013 at 11:47:38AM +0200, Patrick Lamaiziere wrote: > > Le Tue, 24 Sep 2013 11:29:09 +0300, > > Konstantin Belousov a ?crit : > > > > Hello, > > > > ... > > > > > > > > Ok This has been mfced to 9.2-STABLE. But I still see this panic > > > > > > with 9-2/STABLE of today (Revision : 255811). This may be better > > > > > > because before the box paniced within minutes and now within > > > > > > hours (still using poudriere). > > > > > > > > > > > > panic: > > > > > > fault code = supervisor read data, page not present > > > > > > instruction pointer = 0x20:0xffffffff808ebfcd > > > > > > stack pointer = 0x28:0xffffff824c2e0630 > > > > > > frame pointer = 0x28:0xffffff824c2e06a0 > > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > > current process = 54243 (gvfsd-trash) > > > > > > trap number = 12 > > > > > > panic: page fault > > > > > > cpuid = 2 > > > > > > KDB: stack backtrace: > > > > > > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > > > > > > #1 0xffffffff808ffacd at panic+0x1cd > > > > > > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > > > > > > #3 0xffffffff80cdff4f at trap_pfault+0x20f > > > > > > #4 0xffffffff80ce0504 at trap+0x344 > > > > > > #5 0xffffffff80cc9b43 at calltrap+0x8 > > > > > > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > > > > > > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > > > > > > #8 0xffffffff808c4de8 at kern_kevent+0x108 > > > > > > #9 0xffffffff808c5950 at sys_kevent+0x90 > > > > > > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > > > > > > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > > > > > > > > > > > Full core.txt : > > > > > > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 > > > > > > > > > > For start, please load the core into kgdb and for > > > > > frame 8 > > > > > p *kn > > > > > > > > (kgdb) frame 8 > > > > #8 0xffffffff8099d043 in filt_vfsvnode (kn=0xfffffe0147a7f000, > > > > hint=0) at /usr/src/sys/kern/vfs_subr.c:4600 > > > > 4600 VI_LOCK(vp); > > > > (kgdb) p *kn > > > > $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0}, > > > > kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, > > > > kn_kq = 0xfffffe01079a6200, kn_kevent = {ident = 62, filter = -4, > > > > flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = > > > > 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = > > > > 0xfffffe016949e190, p_proc = 0xfffffe016949e190, p_aio = > > > > 0xfffffe016949e190, p_lio = 0xfffffe016949e190}, kn_fop = > > > > 0xffffffff812f0, kn_hook = 0xfffffe0119d0b1f8, kn_hookid = 0} > > > From the kgdb, also please do > > > p *(struct vnode *)0xfffffe0119d0b1f8 > > > > With a kernel with debug info, this panic becomes mtx_lock() of > > destroyed mutex > > panic: mtx_lock() of destroyed mutex > > > > http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt > > > > @ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2 > > KDB: stack backtrace: > > #0 0xffffffff80920286 at kdb_backtrace+0x66 > > #1 0xffffffff808e738d at panic+0x1cd > > #2 0xffffffff808d58d6 at _mtx_lock_flags+0x116 > > #3 0xffffffff8098143b at filt_vfsvnode+0x3b > > #4 0xffffffff808b213a at kqueue_register+0x4ca > > #5 0xffffffff808b2688 at kern_kevent+0x108 > > #6 0xffffffff808b3190 at sys_kevent+0x90 > > #7 0xffffffff80cbd975 at amd64_syscall+0x2f5 > > #8 0xffffffff80ca8557 at Xfast_syscall+0xf7 > > > > (kgdb) frame 5 > > #5 0xffffffff808b213a in kqueue_register (kq=0xfffffe00ddc98900, kev=0xffffff824bb5f880, td=0xfffffe00b1e7f000, waitok=1) at /usr/src/sys/kern/kern_event.c:1136 > > 1136 event = kn->kn_fop->f_event(kn, 0); > > > > (kgdb) p *kn > > $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0xfffffe011c232b00}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq = 0xfffffe00ddc98900, > > kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = { > > p_fp = 0xfffffe00ddd4d870, p_proc = 0xfffffe00ddd4d870, p_aio = 0xfffffe00ddd4d870, p_lio = 0xfffffe00ddd4d870}, kn_fop = 0xffffffff812fcca0, > > kn_hook = 0xfffffe02064a6000, kn_hookid = 0} > > > > (kgdb) p *(struct vnode *)0xfffffe02064a6000 > > $2 = {v_type = VBAD, v_tag = 0xffffffff80d89084 "none", v_op = 0x0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfffffe020d3e6000, > > tqe_prev = 0xfffffe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, > > le_prev = 0xffffff8000de9698}, v_hash = 238022, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe02064a6060}, v_cache_dd = 0x0, > > v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff80f56e48 "ufs", lo_flags = 91881472, lo_data = 0, > > lo_witness = 0xffffff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822, > > 18446744071573768556, 18446744071576111075, 18446744071606114523, 18446744071576111075, 18446744071572113927, 18446744071572067653, 18446744071606111219, > > 18446744071572016126, 18446744071572018094, 18446744071575427445, 18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = { > > lo_name = 0xffffffff80f6f8a3 "vnode interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0xffffff80006a9600}, mtx_lock = 6}, v_vnlock = 0xfffffe02064a6098, > > v_holdcnt = 0, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_actfreelist = {tqe_next = 0xfffffe0086625a40, tqe_prev = 0xfffffe020d3e61a8}, > > v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff80f781ec "bufobj interlock", lo_flags = 16908288, lo_data = 0, lo_witness = 0xffffff80006b1680}, > > mtx_lock = 6}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe02064a61d8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, > > tqh_last = 0xfffffe02064a61f8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff812f9960, bo_bsize = 32768, bo_object = 0x0, > > bo_synclist = {le_next = 0xfffffe001d797bf8, le_prev = 0xfffffe005f632240}, bo_private = 0xfffffe02064a6000, __bo_vnode = 0xfffffe02064a6000}, > > v_pollinfo = 0xfffffe00b15dc540, v_label = 0x0, v_lockf = 0x0, v_rl = > > {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffffe02064a6278}, > > rl_currdep = 0x0}} > > > > > > ----------- > > > > > Please try the following. > > > > > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > > > index aa165a0..5715f35 100644 > > > --- a/sys/kern/vfs_subr.c > > > +++ b/sys/kern/vfs_subr.c > > > @@ -4421,10 +4421,14 @@ filt_vfsdetach(struct knote *kn) > > > static int > > > filt_vfsread(struct knote *kn, long hint) > > > { > > > - struct vnode *vp = (struct vnode *)kn->kn_hook; > > > + struct vnode *vp; > > > struct vattr va; > > > int res; > > > > > > + if ((kn->kn_status & KN_DETACHED) != 0) > > > + return (0); > > > + vp = (struct vnode *)kn->kn_hook; > > > + > > > /* > > > * filesystem is gone, so set the EOF flag and schedule > > > * the knote for deletion. > > > @@ -4450,8 +4454,11 @@ filt_vfsread(struct knote *kn, long hint) > > > static int > > > filt_vfswrite(struct knote *kn, long hint) > > > { > > > - struct vnode *vp = (struct vnode *)kn->kn_hook; > > > + struct vnode *vp; > > > > > > + if ((kn->kn_status & KN_DETACHED) != 0) > > > + return (0); > > > + vp = (struct vnode *)kn->kn_hook; > > > VI_LOCK(vp); > > > > > > /* > > > @@ -4469,9 +4476,12 @@ filt_vfswrite(struct knote *kn, long hint) > > > static int > > > filt_vfsvnode(struct knote *kn, long hint) > > > { > > > - struct vnode *vp = (struct vnode *)kn->kn_hook; > > > + struct vnode *vp; > > > int res; > > > > > > + if ((kn->kn_status & KN_DETACHED) != 0) > > > + return (0); > > > + vp = (struct vnode *)kn->kn_hook; > > > VI_LOCK(vp); > > > if (kn->kn_sfflags & hint) > > > kn->kn_fflags |= hint; > > > > With this I've got another panic 'vn_lock zero hold count' (it is an assertion in vfs_vnops.c) : > > > For this one I have another patch, written some time ago, > http://people.freebsd.org/~kib/misc/vnode_filter.1.patch > > Please see below for combined patch, thank you for the testing and > detailed reports. > > > http://user.lamaiziere.net/patrick/public/panic_zero_hold_count.txt > > > > panic: vn_lock 0xfffffe018afd0000: zero hold count > > cpuid = 4 > > KDB: stack backtrace: > > #0 0xffffffff80920286 at kdb_backtrace+0x66 > > #1 0xffffffff808e738d at panic+0x1cd > > #2 0xffffffff80994abd at _vn_lock+0xcd > > #3 0xffffffff808aff57 at knlist_remove_kq+0x67 > > #4 0xffffffff808b1617 at knote_fdclose+0x177 > > #5 0xffffffff808ab1a9 at kern_close+0xe9 > > #6 0xffffffff80cbd9b5 at amd64_syscall+0x2f5 > > #7 0xffffffff80ca8597 at Xfast_syscall+0xf7 > > > > (kgdb) #0 doadump (textdump=) at pcpu.h:234 > > #1 0xffffffff808e792e in kern_reboot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:449 > > #2 0xffffffff808e7364 in panic (fmt=0x1
) > > at /usr/src/sys/kern/kern_shutdown.c:637 > > #3 0xffffffff80994abd in _vn_lock (vp=0xfffffe018afd0000, flags=0, file=0x0, > > line=0) at /usr/src/sys/kern/vfs_vnops.c:1398 > > #4 0xffffffff808aff57 in knlist_remove_kq (knl=0xfffffe0056b053b0, > > kn=0xfffffe018a9c0b80, knlislocked=0, kqislocked=0) > > at /usr/src/sys/kern/kern_event.c:1843 > > #5 0xffffffff808b1617 in knote_fdclose (td=0xfffffe0056c2a000, fd=62) > > at /usr/src/sys/kern/kern_event.c:2065 > > #6 0xffffffff808ab1a9 in kern_close (td=0xfffffe0056c2a000, fd=62) > > at /usr/src/sys/kern/kern_descrip.c:1250 > > #7 0xffffffff80cbd9b5 in amd64_syscall (td=0xfffffe0056c2a000, traced=0) > > at subr_syscall.c:135 > > #8 0xffffffff80ca8597 in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:391 > > #9 0x00000008032f3bcc in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > the code of frame 3 is > > (kgdb) frame 3 > > #3 0xffffffff80994abd in _vn_lock (vp=0xfffffe018afd0000, flags=0, file=0x0, line=0) at /usr/src/sys/kern/vfs_vnops.c:1398 > > 1398 KASSERT(vp->v_holdcnt != 0, > > (kgdb) l > > 1393 > > 1394 VNASSERT((flags & LK_TYPE_MASK) != 0, vp, > > 1395 ("vn_lock called with no locktype.")); > > 1396 do { > > 1397 #ifdef DEBUG_VFS_LOCKS > > 1398 KASSERT(vp->v_holdcnt != 0, > > 1399 ("vn_lock %p: zero hold count", vp)); > > 1400 #endif > > 1401 error = VOP_LOCK1(vp, flags, file, line); > > 1402 flags &= ~LK_INTERLOCK; /* Interlock is always dropped. */ > > > > the vp is = > > (kgdb) p *(struct vnode *) 0xfffffe018afd0000 > > $2 = {v_type = VDIR, v_tag = 0xffffffff80f56e88 "ufs", v_op = 0xffffffff8132c800, v_data = 0xfffffe013a2a7348, v_mount = 0xfffffe0009c00b70, v_nmntvnodes = { > > tqe_next = 0xfffffe018ace3520, tqe_prev = 0xfffffe018afd02b8}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = { > > le_next = 0x0, le_prev = 0xffffff8000e29f00}, v_hash = 236846, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffffe018afd0060}, > > v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object = {lo_name = 0xffffffff80f56e88 "ufs", lo_flags = 91947008, lo_data = 0, > > lo_witness = 0xffffff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822, > > 18446744071573768620, 18446744071576111139, 18446744071606114523, 18446744071576111139, 18446744071572113991, 18446744071572067715, 18446744071606111219, > > 18446744071572016126, 18446744071572018094, 18446744071575427509, 18446744071575340439, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = { > > lo_name = 0xffffffff80f6f8e3 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006a9600}, mtx_lock = 4}, v_vnlock = 0xfffffe018afd0098, > > v_holdcnt = 0, v_usecount = 0, v_iflag = 256, v_vflag = 0, v_writecount = 0, v_actfreelist = {tqe_next = 0xfffffe018ace3cd0, tqe_prev = 0xfffffe00aefe6e78}, > > v_bufobj = {bo_mtx = {lock_object = {lo_name = 0xffffffff80f7822c "bufobj interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0xffffff80006b1680}, > > mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xfffffe018afd01d8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, > > tqh_last = 0xfffffe018afd01f8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff812f99a0, bo_bsize = 32768, > > bo_object = 0xfffffe01f8a6c570, bo_synclist = {le_next = 0xfffffe018afd0448, le_prev = 0xfffffe00096d5ca0}, bo_private = 0xfffffe018afd0000, > > __bo_vnode = 0xfffffe018afd0000}, v_pollinfo = 0xfffffe0056b05380, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, > > tqh_last = 0xfffffe018afd0278}, rl_currdep = 0x0}} > > I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. Thanks. > @@ -4412,17 +4415,23 @@ filt_vfsdetach(struct knote *kn) > struct vnode *vp = (struct vnode *)kn->kn_hook; > > KASSERT(vp->v_pollinfo != NULL, ("Missing v_pollinfo")); > + kn->kn_hook = NULL; > knlist_remove(&vp->v_pollinfo->vpi_selinfo.si_note, kn, 0); > + vdrop(vp); > } > > /*ARGSUSED*/ > static int > filt_vfsread(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > struct vattr va; > int res; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > + > /* > * filesystem is gone, so set the EOF flag and schedule > * the knote for deletion. > @@ -4448,8 +4457,11 @@ filt_vfsread(struct knote *kn, long hint) > static int > filt_vfswrite(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > VI_LOCK(vp); > > /* > @@ -4467,9 +4479,12 @@ filt_vfswrite(struct knote *kn, long hint) > static int > filt_vfsvnode(struct knote *kn, long hint) > { > - struct vnode *vp = (struct vnode *)kn->kn_hook; > + struct vnode *vp; > int res; > > + if ((kn->kn_status & KN_DETACHED) != 0) > + return (0); > + vp = (struct vnode *)kn->kn_hook; > VI_LOCK(vp); > if (kn->kn_sfflags & hint) > kn->kn_fflags |= hint; -- 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-stable@FreeBSD.ORG Tue Sep 24 21:21:34 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 2B5679AF for ; Tue, 24 Sep 2013 21:21:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8B8A2C32 for ; Tue, 24 Sep 2013 21:21:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8OLLRiN043446; Wed, 25 Sep 2013 00:21:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8OLLRiN043446 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8OLLRYU043445; Wed, 25 Sep 2013 00:21:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Sep 2013 00:21:27 +0300 From: Konstantin Belousov To: Patrick Lamaiziere , freebsd-stable@freebsd.org Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130924212127.GQ41229@kib.kiev.ua> References: <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PgVg6bJejIHNFqRl" Content-Disposition: inline In-Reply-To: <20130924174517.GB14220@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:21:34 -0000 --PgVg6bJejIHNFqRl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > I'd like to understand why you think protecting these functions w/ > the _DETACHED check is correct... In kern_event.c, all calls to > f_detach are followed by knote_drop which will ensure that the knote > is removed and free, so no more f_event calls will be called on that > knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. --PgVg6bJejIHNFqRl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQgJWAAoJEJDCuSvBvK1BW5UP/RKHmw7vio4PnCbXcBfjfWWX CKClfIeVOvMGmouOWzUUZzsVnb5ne9LMWOkpCyIwFMAxXrD5m9OKVmfWV5LTb5DF CXLGeK/DIAYUd1bJVhgTE/NCVCK2FpvYTLDW257+S+oGvwYaYK/n5QfOtwATf21l gAXn41A8mrfSLgvX05bNr+We05AJ5bB4NwIIDc3IkatbqNgPFnX+ffmiUut9yHOZ fjN15LhfHaIUz7f781x8Chyv6F89aQDZZFswl6dvzecU4cHSuiBu5YrSQMOEN9rs pYVS/fCQjEG0T9i0tvf0W2Tfhhxg8noU7wi5QSihhImg+3vyLdTyLPtMVE2r0C99 V4NqVSc3Tf1okAIUsZv1weKlMF9VdZ17yTOiDZ/wm5mzNu1u5zeZKhZBqEpfucCV hlnXA4qG34+crBVIeTn/PvxbBJIrHweddMZG1nE7P8+v7gZI7uIJbDSs7lWDGfbt K5VI3XhAMgr9hshG4XARNKhsIhcB7MaBStE2JkNM+Wckuo5jqaVtCEDJPh7mIHph 9bng0YRZtPn18zUfIIIj/yM2spwixMKkO4NI5JXF2+k+4pB9oSS+vv5qDKNvY0cH 1mJ89vHfQhEz8vOsvQp9rNHqPGzbuDjkcYxc451KdQFft8QcCThEf2i4pKdzZ44U 053gy6wKf3oaguNuS+kE =13Cg -----END PGP SIGNATURE----- --PgVg6bJejIHNFqRl-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 00:16:19 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 46807A94 for ; Wed, 25 Sep 2013 00:16:19 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7D332601 for ; Wed, 25 Sep 2013 00:16:18 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id eo20so4381359lab.31 for ; Tue, 24 Sep 2013 17:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RTLpDWKrc0lSbjISf1CCdcQRmtdwkNx5rS05cldsQ3E=; b=Hnlmx9/5p3sX1e31tjl1hwkmojX9qIgUToBc7h6suqy4RdWmcNAXRLV8T/EFuqymr+ 098/A/0IslfZOdBAtnzySxGStgmBIbuC9uWlSNOjE3MeA5NChesPcF/XR3QMfNi0PFSD Hq7UO8GPYwUhXseLAqk3HWVMaCDFw/+Z9JAxd7SQUk4maBxDITAuI1APJpdoA7Kkg5s3 GcnFNAvdYgJMg8rFymckt3SYQOBDwMBrr1LSlTwI6/FMjc4oZcqNStZeZCUc/zaBbQ++ yd9A18+b19p3iiNPkzc50KiHRpEJKfoVsG0iVnRpuYGE3yu77m0zgByaJJnvXAk86A3y 0L5g== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr26277169lbb.14.1380068175747; Tue, 24 Sep 2013 17:16:15 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Tue, 24 Sep 2013 17:16:15 -0700 (PDT) Date: Tue, 24 Sep 2013 17:16:15 -0700 Message-ID: Subject: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Jack Vogel , "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 00:16:19 -0000 Hello Jack, list, I've been dealing with a nagging problem for a day now and decided to ask a quick question here. Basically I am building a brand new FreeBSD 9.1-RELEASE router which has a dual port fiber NIC (X520-SR2 10GbE Dual-Port Server Adapter (82599ES) 10GBASE-SR - LC). The network card is recognized fine by the ix driver and overall works fine. The issue is when I start adding vlans to this card. It seems like every time I add a brand new vlan it "freezes" all the rest of the vlans already configured on that one physical interface. I loose ping between my locally connected peers. Example: ifconfig vlan200 create # this is OK ifconfig vlan200 inet 1.2.3.1/30 vlan 200 vlandev ix1 description DEBUG # this second line makes the rest of the vlans freeze for 6-7 seconds On the switch side (Juniper) the physical interface flaps. There's nothing in logs/dmesg. If I configure the above vlan on an em0 interface - things are just smooth. I read some similar complaints that have surfaced in the past: * http://readlist.com/lists/freebsd.org/freebsd-net/5/26378.html * http://marc.info/?l=freebsd-net&m=130929760904438 Any idea what might be the problem? Any improvements in 9.2-RC4 in this regards? Thank you in advance, -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 06:36:16 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 115C7CD5 for ; Wed, 25 Sep 2013 06:36:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB02F2AEE for ; Wed, 25 Sep 2013 06:36:15 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id rd3so4748939pab.4 for ; Tue, 24 Sep 2013 23:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kEsFuMYVrEA3lM0Ut9rz/arly1bO5mSJX8UscGsgToI=; b=p1w64IdD1+uH+IG4+AfNLftKuaiDTzLBDNkWKDxVeG09IQYdeuCqe1c+JkFBd+WLLQ VuxWc/f1VAYnqNcLqqFnHQRqwYEXTDW+7OTiw8T0kuBS47fUeVIETdjT0t0a+nrgd1xM FNfu8r7NEKbViJkQBspuuBfQS8mQCKI7vA7CxT1wIho7P/ARolYTHlB30fghtTNVtHOY NMZQCiV5UsAjo/wAhAjurYZNikVEQn+J115rWu75AciuS+zjKLBNUnbkVj/PsqDX17lj KayYwcqkwSog3sZ9M9pZFqKwQG1APz51SNqpA6WgD4egXJq2cJsB3kxAXkW2yOWrJido f4+w== X-Received: by 10.66.219.233 with SMTP id pr9mr32352284pac.45.1380090975557; Tue, 24 Sep 2013 23:36:15 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id yo2sm50784552pab.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Sep 2013 23:36:14 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 25 Sep 2013 15:36:10 +0900 From: Yonghyeon PYUN Date: Wed, 25 Sep 2013 15:36:10 +0900 To: Thomas Mueller Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard Message-ID: <20130925063610.GA1507@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 06:36:16 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Sep 22, 2013 at 08:28:08PM +0000, Thomas Mueller wrote: > I've been unable to establish Internet connection from a new computer with Realtek 811E Ethernet despite this Ethernet chip working on another computer with another MSI motherboard. > > Problem motherboard is MSI Z77 MPOWER. > > Older, by two years, motherboard is MSI Z68MA-ED55(B3). > > uname -a shows > > FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 > > I get the same problem with FreeBSD 9.1_STABLE i386. > > These are USB-stick installations. > > I was able to connect to the Internet with (MSI) Winki 3 (Linux-based), included on a DVD included in the motherboard package. > > After nothing but frustration trying to boot USB-stick installations of NetBSD 6.1-STABLE and HEAD (i386), I successfully booted NetBSD-HEAD amd64 from early last May, and "dhclient re0" was successful, whereupon I downloaded, by cvs, the HEAD source tree and pkgsrc tree. > > This proves or strongly suggests the Ethernet chip is healthy. > > Anything I can do (at loader prompt or loader.conf?) to make this Ethernet work in FreeBSD? > > I could update NetBSD-HEAD from source, update the packages through pkgsrc, and build subversion, then checkout the FreeBSD-HEAD source tree, ports and doc trees too, and build FreeBSD-HEAD from source on hard drive using USB-stick installation of FreeBSD 9.2 (prerelease or release). > > Related part of /var/run/dmesg.boot is > > re0: port 0xe000-0xe0f > f mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00000000 It looks like 8168E-VL. Could you try attached patch and show me the dmesg output(re(4) and rgephy(4) only)? The patch was generated to support 8106E but it will correctly show MAC revision number. > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX > , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX- > master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: d4:3d:7e:97:17:e2 > > > Log of "dhclient re0" was > > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 > DHCPOFFER from 192.168.1.1 Driver got a response but it seems it was discarded. > DHCPREQUEST on re0 to 255.255.255.255 port 67 > DHCPREQUEST on re0 to 255.255.255.255 port 67 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 6 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 13 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 17 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > > Somewhat later I got > > Memory modified after free 0xfffffe0011546800(2048) val=977e3dd > 4 @ 0xfffffe0011546800 > Memory modified after free 0xfffffe001153b800(2048) val=ffffffff @ 0xfffffe00115 > 3b800 > Memory modified after free 0xfffffe0011524800(2048) val=977e3dd4 @ 0xfffffe00115 > 24800 > VESA: set_mode(): 24(18) -> 24(18) > Memory modified after free 0xfffffe0011594000(2048) val=977e3dd4 @ 0xfffffe00115 > 94000 > The size(2048) indicates mbuf cluster which in turn means bad things happened in re(4). I have no idea how this can happen though. If you assign static IP addressi to re(4), does the driver works as expected? > > In one case, when I went to bed on this, hours later the system crashed and went into the debugger (db>), where I was rather lost, couldn't kill dhclient, after some time types "reboot". > > Should I have posted this to a different list (hardware, questions?)? > > I would like to find if FreeBSD HEAD (10.0 alphas) would do better. Also, because of nearness of 10.0-RELEASE, I would rather go this track than 9.2 and then update; I already have 9.2 prerelease on other computer. > > Motherboard also has Atheros Wi-Fi (Atheros AR9271 802.11n), and I also have a USB stick-type WLAN adapter (Hiro Inc H50191, Realtek RTL8191SU 802.11n chip). > > Tom --fdj2RfSjLxBAspz7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.8106.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 255757) +++ sys/dev/re/if_re.c (working copy) @@ -223,6 +223,7 @@ { RL_HWREV_8402, RL_8169, "8402", RL_MTU }, { RL_HWREV_8105E, RL_8169, "8105E", RL_MTU }, { RL_HWREV_8105E_SPIN1, RL_8169, "8105E", RL_MTU }, + { RL_HWREV_8106E, RL_8169, "8106E", RL_MTU }, { RL_HWREV_8168B_SPIN2, RL_8169, "8168", RL_JUMBO_MTU }, { RL_HWREV_8168B_SPIN3, RL_8169, "8168", RL_JUMBO_MTU }, { RL_HWREV_8168C, RL_8169, "8168C/8111C", RL_JUMBO_MTU_6K }, @@ -1367,10 +1368,11 @@ break; default: device_printf(dev, "Chip rev. 0x%08x\n", hwrev & 0x7c800000); + sc->rl_macrev = hwrev & 0x00700000; hwrev &= RL_TXCFG_HWREV; break; } - device_printf(dev, "MAC rev. 0x%08x\n", hwrev & 0x00700000); + device_printf(dev, "MAC rev. 0x%08x\n", sc->rl_macrev); while (hw_rev->rl_desc != NULL) { if (hw_rev->rl_rev == hwrev) { sc->rl_type = hw_rev->rl_type; @@ -1408,6 +1410,7 @@ case RL_HWREV_8401E: case RL_HWREV_8105E: case RL_HWREV_8105E_SPIN1: + case RL_HWREV_8106E: sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_FASTETHER | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD; @@ -1429,7 +1432,7 @@ sc->rl_flags |= RL_FLAG_MACSLEEP; /* FALLTHROUGH */ case RL_HWREV_8168C: - if ((hwrev & 0x00700000) == 0x00200000) + if (sc->rl_macrev == 0x00200000) sc->rl_flags |= RL_FLAG_MACSLEEP; /* FALLTHROUGH */ case RL_HWREV_8168CP: Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 255757) +++ sys/pci/if_rlreg.h (working copy) @@ -189,6 +189,7 @@ #define RL_HWREV_8105E 0x40800000 #define RL_HWREV_8105E_SPIN1 0x40C00000 #define RL_HWREV_8402 0x44000000 +#define RL_HWREV_8106E 0x44800000 #define RL_HWREV_8168F 0x48000000 #define RL_HWREV_8411 0x48800000 #define RL_HWREV_8139 0x60000000 @@ -877,6 +878,7 @@ bus_dma_tag_t rl_parent_tag; uint8_t rl_type; const struct rl_hwrev *rl_hwrev; + uint32_t rl_macrev; int rl_eecmd_read; int rl_eewidth; int rl_expcap; --fdj2RfSjLxBAspz7-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 07:51:48 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id C1863B9 for ; Wed, 25 Sep 2013 07:51:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7F62F1C for ; Wed, 25 Sep 2013 07:51:48 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id e12so4319425vbg.1 for ; Wed, 25 Sep 2013 00:51:47 -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=cRcKqwKL9VLQ21SaZ6/rq3/ScS6Q/wntvJQFoEHYgZ8=; b=KdJITcq1rVHx1TEpW9kJ+EWQ5Yc+3YH2aINsCI1+32sApj+9b4dxAqYVo6VpdEiHY5 2f5hf/yxO18ho6rA5xwyPPMewKMzhJHjFB/M+t//9z3pseWzCphqBKw7lbHeVy9yJQKe SELy4UZAhyOpF13oQ+M/p5EJTkRkNSD30yuMuno1AODzdYk7DJfDpxiUNzunusyNLX2N Miows7iiLHvQ4HWUB/wMF/2jEv9YXke/Y7TbYL2h3rxIuVSXYMnnGtJasILQsvYUu1VS Jh5BodPPb8qWZ4uKr/lq76LsVBbR2LwOlcf5TnGz+RQaJD5bpE7uJMFf3kh6tPyvZdVv 2REg== MIME-Version: 1.0 X-Received: by 10.52.157.134 with SMTP id wm6mr9433800vdb.26.1380095507632; Wed, 25 Sep 2013 00:51:47 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Wed, 25 Sep 2013 00:51:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 00:51:47 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Jack Vogel To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 07:51:48 -0000 I will look into this. Jack On Tue, Sep 24, 2013 at 5:16 PM, Rumen Telbizov wrote: > Hello Jack, list, > > I've been dealing with a nagging problem for a day now and decided to ask a > quick question here. > > Basically I am building a brand new FreeBSD 9.1-RELEASE router which has a > dual port fiber NIC (X520-SR2 10GbE Dual-Port Server Adapter (82599ES) > 10GBASE-SR - LC). The network card is recognized fine by the ix driver and > overall works fine. > > The issue is when I start adding vlans to this card. It seems like every > time I add a brand new vlan it "freezes" all the rest of the vlans already > configured on that one physical interface. I loose ping between my locally > connected peers. > > Example: > ifconfig vlan200 create # this is OK > ifconfig vlan200 inet 1.2.3.1/30 vlan 200 vlandev ix1 description DEBUG # > this second line makes the rest of the vlans freeze for 6-7 seconds > > On the switch side (Juniper) the physical interface flaps. There's nothing > in logs/dmesg. > > If I configure the above vlan on an em0 interface - things are just smooth. > > I read some similar complaints that have surfaced in the past: > * http://readlist.com/lists/freebsd.org/freebsd-net/5/26378.html > * http://marc.info/?l=freebsd-net&m=130929760904438 > > Any idea what might be the problem? Any improvements in 9.2-RC4 in this > regards? > > Thank you in advance, > > -- > Rumen Telbizov > Unix Systems Administrator > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 07:58:14 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id AA73A280 for ; Wed, 25 Sep 2013 07:58:14 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 70B942F6E for ; Wed, 25 Sep 2013 07:58:14 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 0FEDBA969; Wed, 25 Sep 2013 09:58:07 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id 62EB27A9; Wed, 25 Sep 2013 09:58:06 +0200 (CEST) Date: Wed, 25 Sep 2013 09:58:05 +0200 From: Patrick Lamaiziere To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130925095805.2072f0cc@mr129166> In-Reply-To: <20130924212127.GQ41229@kib.kiev.ua> References: <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 07:58:14 -0000 Le Wed, 25 Sep 2013 00:21:27 +0300, Konstantin Belousov a écrit : Hello, > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > I'd like to understand why you think protecting these functions w/ > > the _DETACHED check is correct... In kern_event.c, all calls to > > f_detach are followed by knote_drop which will ensure that the knote > > is removed and free, so no more f_event calls will be called on that > > knote.. > > My current belief is that what happens is a glitch in the > kqueue_register(). After a new knote is created and attached, the kq > lock is dropped and then f_event() is called. If the vnode is > reclaimed or possible freed meantime, f_event() seems to dereference > freed memory, since kn_hook points to freed vnode. > > The issue as I see it is that vnode lifecycle is detached from the > knote lifecycle. Might be, only the second patch, which acquires a > hold reference on the vnode for each knote, is really needed. But > before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see. If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Many thanks Konstantin, Regards From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 08:06:39 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id A5D81534 for ; Wed, 25 Sep 2013 08:06:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44B512026 for ; Wed, 25 Sep 2013 08:06:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8P86XXb007069; Wed, 25 Sep 2013 11:06:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8P86XXb007069 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8P86Xgl007068; Wed, 25 Sep 2013 11:06:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Sep 2013 11:06:33 +0300 From: Konstantin Belousov To: Patrick Lamaiziere Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130925080633.GY41229@kib.kiev.ua> References: <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> <20130925095805.2072f0cc@mr129166> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zxscdqhVGwTkkwBg" Content-Disposition: inline In-Reply-To: <20130925095805.2072f0cc@mr129166> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 08:06:39 -0000 --zxscdqhVGwTkkwBg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2013 at 09:58:05AM +0200, Patrick Lamaiziere wrote: > Le Wed, 25 Sep 2013 00:21:27 +0300, > Konstantin Belousov a ?crit : >=20 > Hello, >=20 > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > > I'd like to understand why you think protecting these functions w/ > > > the _DETACHED check is correct... In kern_event.c, all calls to > > > f_detach are followed by knote_drop which will ensure that the knote > > > is removed and free, so no more f_event calls will be called on that > > > knote.. > >=20 > > My current belief is that what happens is a glitch in the > > kqueue_register(). After a new knote is created and attached, the kq > > lock is dropped and then f_event() is called. If the vnode is > > reclaimed or possible freed meantime, f_event() seems to dereference > > freed memory, since kn_hook points to freed vnode. > >=20 > > The issue as I see it is that vnode lifecycle is detached from the > > knote lifecycle. Might be, only the second patch, which acquires a > > hold reference on the vnode for each knote, is really needed. But > > before going into any conclusions, I want to see the testing results. >=20 > Testing looks good with your latest patch. I was able to run a complete > poudriere bulk (870 packages). I'm running another bulk to see. >=20 > If you have other patches to test just ask, I have not updated my > packages because there was a change to make gvfsd to ignore some > poudriere activity. So I guess it will be harder to see this > problem. Very good, thank you. Could you, please, test with the only patch http://people.freebsd.org/~kib/misc/vnode_filter.1.patch applied ? I wonder would it be enough. --zxscdqhVGwTkkwBg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQpmIAAoJEJDCuSvBvK1BroEQAJq1jhs+/606PQa8aoeXNStV TWDgiA6kWQEQryBfmwPkaYa3lmZCgN+7PAtMMrWk5S8zIJJmZbBj5IZg5++c6bR/ 2A1OTUB8opiH3PA+HqEpXJ3/e99tNw5D3O6VaMV92I1Qgt5MxuAk6mZFz0k+EQIJ 8Fls+Il3CxstmpzEkBRQfcOiqBmpenoiGUHBe60YRpmCXaUI8VWkI6TbayGbvmEI QdhOke64xs7mDi5Repb2fZqYBn5ARMppuIdgMkwLt/0SiVSEzyct6rjDAZsXGLtD hhfGNqVPYPI/zcVxeUJZyvCeC0NbQtupSFlf/IplP/717VAhB/cYWoUX76MdmO49 BWJ7Lji+UP9RRyuz0CzdjZSv6b1Kw3ES8rVC+gNhTbuje1acFvwOl6ZOeVASlzht Jv68HQlHCpg80CL0MHEf6NA/rrZtWjQOz3kw6Yn72g61TqbLE292zuRtjkzkjYFL PPnO/K1sL0k/nv96gUNDYKj1JDQtTlpk0CvouJYYdR3vklCgOY33ytInhy8nP54M BMi31ZWTogRIbfAMrmFITNYzmvOaTP83hXhP/5sb2+ioV5HJ6hyXDPBGh6Nfcjen Af+obcHOqws8hNdmFNU1GNwESQyxnyd1rUmYfxo3I7oBTfKnKf/WW21/7hyY7cAB J6KvaTyTO1RsPUNmXfx8 =MOOh -----END PGP SIGNATURE----- --zxscdqhVGwTkkwBg-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 08:33:07 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 0E557BDB for ; Wed, 25 Sep 2013 08:33:07 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 867F62205 for ; Wed, 25 Sep 2013 08:33:05 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r8P8V5OP037361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Sep 2013 11:31:06 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Daniel Kalchev In-Reply-To: Date: Wed, 25 Sep 2013 10:31:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E619068-9015-4013-A99E-CEE8948C7455@digsys.bg> References: To: Rumen Telbizov X-Mailer: Apple Mail (2.1510) Cc: "freebsd-stable@freebsd.org" , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 08:33:07 -0000 On 25.09.2013, at 02:16, Rumen Telbizov wrote: >=20 >=20 > Example: > ifconfig vlan200 create # this is OK > ifconfig vlan200 inet 1.2.3.1/30 vlan 200 vlandev ix1 description = DEBUG # > this second line makes the rest of the vlans freeze for 6-7 seconds >=20 > On the switch side (Juniper) the physical interface flaps. There's = nothing > in logs/dmesg. >=20 Might be, you have spanning tree enabled on the switch port and when the = interface "flaps" it needs time to converge. Disable spanning tree on = the port and the reset will be very short. Daniel From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 12:15:58 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id A7861EB8 for ; Wed, 25 Sep 2013 12:15:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6573320F5 for ; Wed, 25 Sep 2013 12:15:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VOo0T-0004NP-Jy for freebsd-stable@freebsd.org; Wed, 25 Sep 2013 14:15:49 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Sep 2013 14:15:49 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Sep 2013 14:15:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: strsvis breakage when upgrading to from 9.1 to 9-STABLE Date: Wed, 25 Sep 2013 14:15:39 +0200 Lines: 65 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ldp27c2T6jlwwIAuJ5kuJkQpkoOdKkUDW" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 X-Enigmail-Version: 1.5.2 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:15:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ldp27c2T6jlwwIAuJ5kuJkQpkoOdKkUDW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've sent a similar query before, but didn't receive any answers. When upgrading from 9.1 to 9-STABLE, the buildworld fails with: =3D=3D=3D> usr.bin/xinstall (all) cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/xinstall/xinstall.c cc -O2 -pipe -I/usr/src/usr.bin/xinstall/../../contrib/mtree -I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -I/usr/src/usr.bin/xinstall/../../lib/libmd -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/usr.bin/xinstall/../../contrib/mtree/getid.c cc1: warnings being treated as errors /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of function 'strsvis' /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern declaration of 'strsvis' Digging around, it looks like strsvis is in the 9-STABLE sources but not in the installed system's (9.1) sources. I assume the build process is pulling in system headers and libraries, but that seems wrong. Isn't the build process supposed to pull in only sources from /usr/src and libraries which are freshly built instead of the system ones? What would be the workaround for the above problem? --ldp27c2T6jlwwIAuJ5kuJkQpkoOdKkUDW 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.21 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJC0+tfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSw5CQCePRY82VY+85bcIsyZLQS6cQFa UH0An0VKlqyfvl/uvc1nQ3Jrqln8ziEd =Aock -----END PGP SIGNATURE----- --ldp27c2T6jlwwIAuJ5kuJkQpkoOdKkUDW-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 15:09:31 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id CC584B0C; Wed, 25 Sep 2013 15:09:31 +0000 (UTC) (envelope-from bengta@P142s.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4273E2C67; Wed, 25 Sep 2013 15:09:30 +0000 (UTC) Received: from P142s.sics.se (n176-p236.kthopen.kth.se [130.229.176.236]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r8PF1bZk058755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 17:01:38 +0200 (CEST) (envelope-from bengta@P142s.sics.se) Received: from P142s.sics.se (localhost [127.0.0.1]) by P142s.sics.se (8.14.7/8.14.7) with ESMTP id r8PF1Nau003202; Wed, 25 Sep 2013 17:01:23 +0200 (CEST) (envelope-from bengta@P142s.sics.se) Received: (from bengta@localhost) by P142s.sics.se (8.14.7/8.14.7/Submit) id r8PF1NWK003201; Wed, 25 Sep 2013 17:01:23 +0200 (CEST) (envelope-from bengta@P142s.sics.se) From: Bengt Ahlgren To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance In-Reply-To: (Adrian Chadd's message of "Fri, 6 Sep 2013 15:01:26 -0700") References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) Date: Wed, 25 Sep 2013 17:01:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon , Mike Harding X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:09:31 -0000 Now having some experience with my "new" TP X201 and Intel/KMS graphics, I also ran into severe Xorg perfomance issues, but it was _not_ connected to suspend/resume, because it persisted after a clean reboot. I plugged in a projector to the VGA port, and used xrandr. The Xorg server seemed to come to a halt, in practice unusable. After the fact I saw in the log file that there were tons of these messages: [ 136.238] (II) intel(0): EDID vendor "IFS", prod id 4354 [ 136.238] (II) intel(0): Using hsync ranges from config file [ 136.238] (II) intel(0): Using vrefresh ranges from config file [ 136.238] (II) intel(0): Printing DDC gathered Modelines: [ 136.238] (II) intel(0): Modeline "1280x800"x0.0 83.40 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 136.238] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 136.238] (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 136.238] (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 136.238] (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 136.238] (II) intel(0): Modeline "1280x720"x60.0 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) [ 136.238] (II) intel(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 136.238] (II) intel(0): Modeline "1366x768"x59.8 84.75 1366 1431 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) [ 136.238] (II) intel(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) [ 136.238] (II) intel(0): Modeline "1400x1050"x0.0 121.75 1400 1488 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) [ 136.238] (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 136.238] (II) intel(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) That is, the Xorg server constantly queried the display device for its capabilities (perhaps on behalf of some client - I run KDE, so you never know what it tries to do...). This seems to be a somewhat known issue: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857 Is this something different, or is this a variant of the slowdown others are seeing? Bengt Adrian Chadd writes: > .. anything happening? > > > -adrian > > > On 2 September 2013 07:29, Adrian Chadd wrote: > >> >> On 2 September 2013 07:25, Mike Harding wrote: >> >>> It's detailed in the ticket, see >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for >>> 'reverted'. >>> >>> >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. >> I'll retest this on my test laptops when I'm back home. >> >> >> >> -adrian From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 15:44:54 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 8F9B01A9; Wed, 25 Sep 2013 15:44:54 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A07922E7D; Wed, 25 Sep 2013 15:44:53 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hj3so5418252wib.0 for ; Wed, 25 Sep 2013 08:44:51 -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=mStZWZReWnzDWce3TJZPHGJ9KqC77CFPhn/GMNZaELc=; b=khaxSDl/g3DtTlkhcxpGPKtY5jscGDekYOjd+nFwL/dXtT+QQUdmU8M0fJ4AuaZuYm Puw8N4nFjNTU3mBRCDFugAzM0xHGJlUebiRuO1qDuyR+cWGMtMSnGWTG6zE7lLaR2ao/ IpBpd71rAS4uCSah2F9AIJvDbNpIGtZTfVYtR5ELhiX3YRmkx1GqiJ5qqt9K0CD5xSrR 0p0xz2yfeEXCD9Y/zBtndz8soPBW4vr16tCHhlyhEXGYgGzMiMOZw92rWqLSQ2phITvb QuIKX+iNURyxNh/Vk6T1cPy2pZgKCGof4uIYNLNk4v+silkYL7BM3UCW7EM9rTWjPFTm e/Gw== MIME-Version: 1.0 X-Received: by 10.180.94.233 with SMTP id df9mr18119659wib.63.1380123891452; Wed, 25 Sep 2013 08:44:51 -0700 (PDT) Received: by 10.217.67.65 with HTTP; Wed, 25 Sep 2013 08:44:51 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Wed, 25 Sep 2013 08:44:51 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Bengt Ahlgren Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD Stable Mailing List , "freebsd-acpi@freebsd.org" , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:44:54 -0000 My slowdown manifests as extremely slow disk access, even with low CPU. This happens even if CPU scaling is disabled, or if I am remotely accessing the system, with no X. On Wed, Sep 25, 2013 at 8:01 AM, Bengt Ahlgren wrote: > Now having some experience with my "new" TP X201 and Intel/KMS graphics, > I also ran into severe Xorg perfomance issues, but it was _not_ > connected to suspend/resume, because it persisted after a clean reboot. > > I plugged in a projector to the VGA port, and used xrandr. The Xorg > server seemed to come to a halt, in practice unusable. After the fact I > saw in the log file that there were tons of these messages: > > [ 136.238] (II) intel(0): EDID vendor "IFS", prod id 4354 > [ 136.238] (II) intel(0): Using hsync ranges from config file > [ 136.238] (II) intel(0): Using vrefresh ranges from config file > [ 136.238] (II) intel(0): Printing DDC gathered Modelines: > [ 136.238] (II) intel(0): Modeline "1280x800"x0.0 83.40 1280 1344 > 1480 1680 800 801 804 828 -hsync +vsync (49.6 kHz eP) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 > 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 > 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 > 840 480 481 484 500 -hsync -vsync (37.5 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 > 832 480 489 492 520 -hsync -vsync (37.9 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 > 864 480 483 486 525 -hsync -vsync (35.0 kHz e) > [ 136.238] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 > 800 480 490 492 525 -hsync -vsync (31.5 kHz e) > [ 136.238] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 > 900 400 412 414 449 -hsync +vsync (31.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 > 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 > 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 > 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 > 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) > [ 136.238] (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 > 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 > 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) > [ 136.238] (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 > 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) > [ 136.238] (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 > 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x720"x60.0 74.48 1280 1336 > 1472 1664 720 721 724 746 -hsync +vsync (44.8 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x960"x0.0 108.00 1280 1376 > 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 > 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1366x768"x59.8 84.75 1366 1431 > 1567 1776 768 771 781 798 -hsync +vsync (47.7 kHz e) > [ 136.238] (II) intel(0): Modeline "1440x900"x0.0 106.50 1440 1520 > 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz e) > [ 136.238] (II) intel(0): Modeline "1400x1050"x0.0 121.75 1400 1488 > 1632 1864 1050 1053 1057 1089 -hsync +vsync (65.3 kHz e) > [ 136.238] (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > [ 136.238] (II) intel(0): Modeline "1680x1050"x0.0 146.25 1680 1784 > 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) > > That is, the Xorg server constantly queried the display device for its > capabilities (perhaps on behalf of some client - I run KDE, so you never > know what it tries to do...). > > This seems to be a somewhat known issue: > > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857 > > Is this something different, or is this a variant of the slowdown others > are seeing? > > Bengt > > Adrian Chadd writes: > > > .. anything happening? > > > > > > -adrian > > > > > > On 2 September 2013 07:29, Adrian Chadd wrote: > > > >> > >> On 2 September 2013 07:25, Mike Harding wrote: > >> > >>> It's detailed in the ticket, see > >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for > >>> 'reverted'. > >>> > >>> > >> Ok. You and avg@ are digging into it deeper, so I'll leave it be for > now. > >> I'll retest this on my test laptops when I'm back home. > >> > >> > >> > >> -adrian > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 16:19:59 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 0C3FDF9F for ; Wed, 25 Sep 2013 16:19:59 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7F5020DC for ; Wed, 25 Sep 2013 16:19:58 +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 r8PGJtc5050241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 09:19:55 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8PGJs6P050240; Wed, 25 Sep 2013 09:19:54 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Sep 2013 09:19:54 -0700 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130925161954.GO14220@funkthat.com> Mail-Followup-To: Konstantin Belousov , Patrick Lamaiziere , freebsd-stable@freebsd.org References: <20130912073643.GM41229@kib.kiev.ua> <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130924212127.GQ41229@kib.kiev.ua> 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-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]); Wed, 25 Sep 2013 09:19:55 -0700 (PDT) Cc: freebsd-stable@freebsd.org, Patrick Lamaiziere X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:19:59 -0000 Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300: > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > I'd like to understand why you think protecting these functions w/ > > the _DETACHED check is correct... In kern_event.c, all calls to > > f_detach are followed by knote_drop which will ensure that the knote > > is removed and free, so no more f_event calls will be called on that > > knote.. > > My current belief is that what happens is a glitch in the > kqueue_register(). After a new knote is created and attached, the kq > lock is dropped and then f_event() is called. If the vnode is reclaimed > or possible freed meantime, f_event() seems to dereference freed memory, > since kn_hook points to freed vnode. Well, if that happens, then the vnode isn't properly clearing up the knote before it gets reclaimed... It is the vnode's responsibility to make sure any knotes that are associated w/ it get cleaned up properly.. > The issue as I see it is that vnode lifecycle is detached from the knote > lifecycle. Might be, only the second patch, which acquires a hold reference > on the vnode for each knote, is really needed. But before going into any > conclusions, I want to see the testing results. The vnode lifecycle can't/shouldn't be detached from the knote lifecycle since the knote contains a pointer to the vnode... There is the function knlist_clear that can be used to clean up knotes when the object goes away.. I was looking at the code, is there a good reason why you do VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in the vfs_knllock/vfs_knlunlock functions? Because kq code will modify the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions, so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to vfs_knllock/vfs_knlunlock... -- 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-stable@FreeBSD.ORG Wed Sep 25 16:41:02 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 3FBAD76A for ; Wed, 25 Sep 2013 16:41:02 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id ED4CF2292 for ; Wed, 25 Sep 2013 16:41:01 +0000 (UTC) Received: by lath.rinet.ru (Postfix, from userid 222) id 994B7697; Wed, 25 Sep 2013 20:40:53 +0400 (MSK) Date: Wed, 25 Sep 2013 20:40:53 +0400 From: Oleg Bulyzhin To: Rumen Telbizov Subject: Re: FreeBSD 9.1 ix driver vlan problem Message-ID: <20130925164053.GB76403@lath.rinet.ru> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:41:02 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm running my ixgbe servers with attached patch. It does solve this problem for me. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --mxv5cy4qt+RJ9ypb Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ixgbe.diff" Index: sys/dev/ixgbe/ixgbe.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ixgbe/ixgbe.c,v retrieving revision 1.53.2.6.2.2 diff -u -r1.53.2.6.2.2 ixgbe.c --- sys/dev/ixgbe/ixgbe.c 17 Nov 2012 08:47:49 -0000 1.53.2.6.2.2 +++ sys/dev/ixgbe/ixgbe.c 20 Sep 2013 12:39:27 -0000 @@ -1198,9 +1198,6 @@ IXGBE_WRITE_REG(hw, IXGBE_RDT(i), adapter->num_rx_desc - 1); } - /* Set up VLAN support and filter */ - ixgbe_setup_vlan_hw_support(adapter); - /* Enable Receive engine */ rxctrl = IXGBE_READ_REG(hw, IXGBE_RXCTRL); if (hw->mac.type == ixgbe_mac_82598EB) @@ -1284,6 +1281,9 @@ /* Initialize the FC settings */ ixgbe_start_hw(hw); + /* Set up VLAN support and filter */ + ixgbe_setup_vlan_hw_support(adapter); + /* And now turn on interrupts */ ixgbe_enable_intr(adapter); @@ -4736,7 +4736,8 @@ bit = vtag & 0x1F; adapter->shadow_vfta[index] |= (1 << bit); ++adapter->num_vlans; - ixgbe_init_locked(adapter); + //ixgbe_init_locked(adapter); + ixgbe_setup_vlan_hw_support(adapter); IXGBE_CORE_UNLOCK(adapter); } @@ -4763,7 +4764,8 @@ adapter->shadow_vfta[index] &= ~(1 << bit); --adapter->num_vlans; /* Re-init to load the changes */ - ixgbe_init_locked(adapter); + //ixgbe_init_locked(adapter); + ixgbe_setup_vlan_hw_support(adapter); IXGBE_CORE_UNLOCK(adapter); } @@ -4785,6 +4787,20 @@ if (adapter->num_vlans == 0) return; + /* Setup the queues for vlans */ + for (int i = 0; i < adapter->num_queues; i++) { + rxr = &adapter->rx_rings[i]; + /* On 82599 the VLAN enable is per/queue in RXDCTL */ + if (hw->mac.type != ixgbe_mac_82598EB) { + ctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(i)); + ctrl |= IXGBE_RXDCTL_VME; + IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(i), ctrl); + } + rxr->vtag_strip = TRUE; + } + + if ((ifp->if_capenable & IFCAP_VLAN_HWFILTER) == 0) + return; /* ** A soft reset zero's out the VFTA, so ** we need to repopulate it now. @@ -4803,18 +4819,6 @@ if (hw->mac.type == ixgbe_mac_82598EB) ctrl |= IXGBE_VLNCTRL_VME; IXGBE_WRITE_REG(hw, IXGBE_VLNCTRL, ctrl); - - /* Setup the queues for vlans */ - for (int i = 0; i < adapter->num_queues; i++) { - rxr = &adapter->rx_rings[i]; - /* On 82599 the VLAN enable is per/queue in RXDCTL */ - if (hw->mac.type != ixgbe_mac_82598EB) { - ctrl = IXGBE_READ_REG(hw, IXGBE_RXDCTL(i)); - ctrl |= IXGBE_RXDCTL_VME; - IXGBE_WRITE_REG(hw, IXGBE_RXDCTL(i), ctrl); - } - rxr->vtag_strip = TRUE; - } } static void --mxv5cy4qt+RJ9ypb-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 16:57:10 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 32D5BDB3; Wed, 25 Sep 2013 16:57:10 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86FDA238F; Wed, 25 Sep 2013 16:57:09 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id gx14so5318477lab.9 for ; Wed, 25 Sep 2013 09:57:07 -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=hFPv4Mn7DIJQFFVS7UJyXmsWoGK3fqpgXVGVhTP90MY=; b=WHsaCK6oYCmpA6yZYIieqTQ2Dv19+seA/ugxmEoAYMT1IleTUXxIAq1CSHeJt5Cf89 jxR+BpRcX/q977B4I4bbYNe+epGH/IilOCwoSp44FYAlV+c/YpwqkHw33VvElBqfbhmp E77N/FP4rpx+adbtNsTIzQhbbSlBHLU3mv4Vu8qg1Ca4rUzNOnFVCMFaBlY+9H23DM4d nxp9c5XUiFz6i5bwBsw8MTnj6+HcGIt7P2jUPyvAP9K6xRuvdsK40VsBWXtSPdOKr5jg qFnuEL/t4g3jukQdWwlOVYBGSg1TtH4KL6c9yJt6auHMgp9no0DYkqVirJvCdvnDIBdS xlUg== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr30621298lab.11.1380128227289; Wed, 25 Sep 2013 09:57:07 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Wed, 25 Sep 2013 09:57:07 -0700 (PDT) In-Reply-To: <20130925164053.GB76403@lath.rinet.ru> References: <20130925164053.GB76403@lath.rinet.ru> Date: Wed, 25 Sep 2013 09:57:07 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Oleg Bulyzhin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:57:10 -0000 Thanks for the patch Oleg. I'll give it a try but I would also like to hear back from Jack. Oleg, can you confirm that you're experiencing the exact same problem/behavior? What kind of switch is connected on the other end? Thanks, Rumen Telbizov On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin wrote: > > I'm running my ixgbe servers with attached patch. > It does solve this problem for me. > > -- > Oleg. > > ================================================================ > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > ================================================================ > > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 17:01:27 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 16705F45; Wed, 25 Sep 2013 17:01:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B65C523FA; Wed, 25 Sep 2013 17:01:26 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id c14so5053220vea.29 for ; Wed, 25 Sep 2013 10:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LtFaVryeiVTyQYxliaPnG1TlnJDA5/37ZDZXtxkg2hY=; b=cAXSidekSwjsAp+iR8fK5mNUReXtCxBHqirXOvumExlFtTiknIdLBFuoH/RYJ8dXVU JU8ZA0mvL9VH9yKh3BJkS6R9BzPr+E2R+qrgw5Og5TXxEnjs4F8ydLXBtNRkAnjPJaeX A10ICdkH6hIFrfmFp9LQCXBT9tkm+DWAlrW/Bv4aLcAWgvemo5NpogW4Q7nDfTKEFB56 48g1dBAGiB1FXQ15sVEFlp/OsUYsmLM8zu/6SvwK4G9/FaCuA5QdswzOVul7kzI4IyJi eeeBslJP+2SNW7J2s2QDgam8JVL61TkNXL0VvJAyhzRRCAPsZ4Txs8sCPtnTVPlgDztu 3n3A== MIME-Version: 1.0 X-Received: by 10.52.164.102 with SMTP id yp6mr29438853vdb.14.1380128485375; Wed, 25 Sep 2013 10:01:25 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Wed, 25 Sep 2013 10:01:25 -0700 (PDT) In-Reply-To: References: <20130925164053.GB76403@lath.rinet.ru> Date: Wed, 25 Sep 2013 10:01:25 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Jack Vogel To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Oleg Bulyzhin , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:01:27 -0000 Rumen, I'd like to know if you can check the spanning tree setting as Daniel mentioned and if that solves it, I do know that that can cause considerable delay in link transitions. Also, can you see if you see different behavior by going to the latest 9.2 bits? Oleg thanks for the patch, I will check it out and have my validation engineer do some tests and we'll get to the bottom of this. Jack On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote: > Thanks for the patch Oleg. > I'll give it a try but I would also like to hear back from Jack. > > Oleg, can you confirm that you're experiencing the exact same > problem/behavior? What kind of switch is connected on the other end? > > Thanks, > Rumen Telbizov > > > On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin wrote: > > > > > I'm running my ixgbe servers with attached patch. > > It does solve this problem for me. > > > > -- > > Oleg. > > > > ================================================================ > > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > > ================================================================ > > > > > > > -- > Rumen Telbizov > Unix Systems Administrator > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 17:03:58 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 71329ED for ; Wed, 25 Sep 2013 17:03:58 +0000 (UTC) (envelope-from 3fRdDUg8JDlABwAAG2072s3GsIJy4s03.u64x9wwtAv-ABst3wx9wwtAv.69y@calendar-server.bounces.google.com) Received: from mail-vc0-x24a.google.com (mail-vc0-x24a.google.com [IPv6:2607:f8b0:400c:c03::24a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26B70241D for ; Wed, 25 Sep 2013 17:03:58 +0000 (UTC) Received: by mail-vc0-f202.google.com with SMTP id gd11so711421vcb.5 for ; Wed, 25 Sep 2013 10:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:auto-submitted:message-id:date:subject :from:to:content-type; bh=aWSSgn9EwIC3mv84rAHHb0rykiVK5QIqUtkyWAlAwnA=; b=D1llljMO9bZZX2e89zbrN5XvdjJetJcGh5UbHg77cNcYse6lCy/v46rZXgTyi7sbnu VZL7LT9KsCb/A5JzcnbmUi0IhGH3VNkhqekCEMFGKekUAOcoztCb0cVI9atYAYRyPIOs YlDqlxl8oz+pgRXEh5EsIiYegWYpRlfdfNN5eQgcTCjMeeClg1OLC/LjAue6xkC50mKT diTIVm8+GSJpi1mhYy7CgHG8tsTLsEFfn4bzT4WrGzNFdPd3WOAK+93yg0JxMPBsmStO q1fu0Hgsn8P3svW/vzO2rIGmaAGelE+e2sef+zCMaKOIN7mxRRkZG6KLGp8ycr0qZ+93 cnzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:auto-submitted:message-id:date:subject :from:to:content-type; bh=aWSSgn9EwIC3mv84rAHHb0rykiVK5QIqUtkyWAlAwnA=; b=xhoaY+QR2WmrO+OZBdJutPolYmFLVkqdV5vzWC/rA2Cqd2LAkvhX2U14TJhxkNyGYH MennXcyKoN8/8fuO8wc2TSE8bkuV5qDnnFQp5UIiRgPz4edXtuRwMubNMcv85XbbWV8x gd8HoAVZwx4YT9lS4Rj5TeCaokJ+frszmtlHGrrsx48OIjUpEG8JVPPVDp75bakRPAOQ 9LuwWAH9jAT/cI40Xq0Pgy9njzUtHlcUZ7yROhknAWpoW6pH8GgL8JwE/XvQKnO+qvD7 4xlbz/RqsSRmYpmYNpu3XNMDhKV0Ma8bmi5yxwXIrIxvMX1sHJixjzmvzZo95h+Zd11M b+uQ== MIME-Version: 1.0 X-Received: by 10.236.6.134 with SMTP id 6mr11102162yhn.7.1380128637275; Wed, 25 Sep 2013 10:03:57 -0700 (PDT) Sender: Google Calendar Auto-Submitted: auto-generated Message-ID: <089e0115efae2b5cbb04e7383d44@google.com> Date: Wed, 25 Sep 2013 17:03:57 +0000 Subject: Invitation: Hello Dear, @ Wed 25 Sep 2013 13:00 - 14:00 (tessykipkalya01@gmail.com) From: "tessykipkalya01@gmail.com" To: "freebsd-stable@freebsd.org" Content-Type: multipart/mixed; boundary=089e0115efae2b5cb104e7383d43 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "tessykipkalya01@gmail.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:03:58 -0000 --089e0115efae2b5cb104e7383d43 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBI ZWxsbyBEZWFyLA0KSGVsbG8gRGVhciwNCk15IG5hbWUgaXMgTXMgVGVzc3ksIGEgdGFsbCBnb29k IGxvb2tpbmcgeW91bmcgZ2lybCxzbyBsb3ZlbHkgYW5kIGNhcmluZyAgDQp3aXRoIGdvb2QgdW5k ZXJzdGFuZGluZy5mYWlyIGluIGNvbXBsZXhpb24sY2FyZSB3aXRoIGdvb2Qgc2hhcmluZyxob25l c3R5LiAgDQpJIHNhdyB5b3VyIHByb2ZpbGUgd2hpY2ggaW50ZXJlc3RlZCBtZSBtdWNoIGFuZCBp IGRlY2lkZWQgdG8gY29udGFjdCB5b3UuIEkgIA0KcmVhbGx5IHdhbnQgdG8gaGF2ZSBhIGdvb2Qg ZnJpZW5kc2hpcCB3aXRoIHlvdSBldmVuIGlmIHlvdSBoYXZlIG1hcnJpZWQgd2UgIA0KY2FuIGJl IGZyaWVuZHMgLGkgaGF2ZSBhIHJlYXNvbiBvZiBzZWxlY3RpbmcgeW91IGFzIG15IGZyaWVuZCxw bHMgaWYgeW91ICANCndpc2ggdG8ga25vdyBtb3JlLlBscyBjb250YWN0IG1lIHRocm91Z2ggdGhp cyBteSBlLW1haWwgYWRkcmVzcyBvayAsV2UgbmVlZCAgDQp0byB0YWxrIGFuZCBrbm93IG91cnNl bGYgbW9yZSBhbmQgZXF1YWxseSBzaGFyZSBwaWN0dXJlcyB0byBlYWNoIG90aGVyLmhvcGUgIA0K dG8gaGVhciBmcm9tIHlvdS4NClBsZWFzZSByZXBseSBtZSB3aXRoIG15IGUtbWFpbCBhZGRyZXNz IGhlcmUNCih0ZXNzeWtpcGthbHlhQHlhaG9vLmNvbSkNCllvdXJzIE5ldyBGcmllbmQNCnRlc3N5 IFRoYW5rDQpXaGVuOiBXZWQgMjUgU2VwIDIwMTMgMTM6MDAgliAxNDowMCBFYXN0ZXJuIFRpbWUN CkNhbGVuZGFyOiB0ZXNzeWtpcGthbHlhMDFAZ21haWwuY29tDQpXaG86DQogICAgIChHdWVzdCBs aXN0IGhhcyBiZWVuIGhpZGRlbiBhdCBvcmdhbmlzZXIncyByZXF1ZXN0KQ0KDQpFdmVudCBkZXRh aWxzOiAgDQpodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVX JmVpZD1hVEkzYm1Sd2JXNTFNR28wY1dKbGFHSnlZV1JuTW1kaWIyOGdabkpsWldKelpDMXpkR0Zp YkdWQVpuSmxaV0p6WkM1dmNtYyZ0b2s9TWpVamRHVnpjM2xyYVhCcllXeDVZVEF4UUdkdFlXbHNM bU52YlRrd1ltUmtabUl5TWpBeFl6RTRaV1k1TURKaVpEZ3lNV1U1WWpRNVpHWmlaV0kyWlRNMk16 VSZjdHo9QW1lcmljYS9OZXdfWW9yayZobD1lbl9HQg0KDQpJbnZpdGF0aW9uIGZyb20gR29vZ2xl IENhbGVuZGFyOiBodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyLw0KDQpZb3UgYXJlIHJl Y2VpdmluZyB0aGlzIGNvdXJ0ZXN5IGVtYWlsIGF0IHRoZSBhY2NvdW50ICANCmZyZWVic2Qtc3Rh YmxlQGZyZWVic2Qub3JnIGJlY2F1c2UgeW91IGFyZSBhbiBhdHRlbmRlZSBvZiB0aGlzIGV2ZW50 Lg0KDQpUbyBzdG9wIHJlY2VpdmluZyBmdXR1cmUgbm90aWZpY2F0aW9ucyBmb3IgdGhpcyBldmVu dCwgZGVjbGluZSB0aGlzIGV2ZW50LiAgDQpBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIHNpZ24gdXAg Zm9yIGEgR29vZ2xlIGFjY291bnQgYXQgIA0KaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jYWxlbmRh ci8gYW5kIGNvbnRyb2wgeW91ciBub3RpZmljYXRpb24gc2V0dGluZ3MgZm9yICANCnlvdXIgZW50 aXJlIGNhbGVuZGFyLg0K --089e0115efae2b5cb104e7383d43-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 17:20:39 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 4057E5A7; Wed, 25 Sep 2013 17:20:39 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id ED0D524FD; Wed, 25 Sep 2013 17:20:38 +0000 (UTC) Received: by lath.rinet.ru (Postfix, from userid 222) id 04133E32; Wed, 25 Sep 2013 21:20:38 +0400 (MSK) Date: Wed, 25 Sep 2013 21:20:37 +0400 From: Oleg Bulyzhin To: Rumen Telbizov Subject: Re: FreeBSD 9.1 ix driver vlan problem Message-ID: <20130925172037.GA98000@lath.rinet.ru> References: <20130925164053.GB76403@lath.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , Oleg Bulyzhin , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:20:39 -0000 On Wed, Sep 25, 2013 at 09:57:07AM -0700, Rumen Telbizov wrote: > Thanks for the patch Oleg. > I'll give it a try but I would also like to hear back from Jack. > > Oleg, can you confirm that you're experiencing the exact same > problem/behavior? What kind of switch is connected on the other end? It looks very similar. I've tested with dlink dgs-3620-28tc + Cisco SFP-H10GB-CU1M and (i'm not sure here) with loopback to 2nd port of Intel X520-DA2 card. I've found 2 problems in current ixgbe driver: 1) few seconds link loss on vlan reconfiguration (both create/destroy). 2) if you have configured vlans over ix0 and then run ifconfig ix0 vlanhwfilter your vlans will stop working until you "touch" ix0 vlan configuration (create one more vlan or destroy existing one). Patch solves both for me. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:14:41 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 741E02EC; Wed, 25 Sep 2013 18:14:41 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF8D32844; Wed, 25 Sep 2013 18:14:40 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id y6so171342lbh.35 for ; Wed, 25 Sep 2013 11:14:38 -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=yrUwHPpRHoLkMH1YiByqKlISq6H7yDzFuIySz14RTmk=; b=p8xaOso1uxeDGXCDtLKQJfSf07LJkigdlbg3eqYt47gzt580ztpEGGPE+eZ8fovoe3 MP+3+C2rA6Fzzu9xVhabhvg627mQKZPJLNhNMXS/XqiARMonYuja8TOtGiN+K1dvEut8 KS/c2RX+j0pfUxOfT3LaPQRthmwa81RJ4hLOu72U6t4OcGzIsKpJI4nd5iYDOc9xYNfq 5UcbhniXGqvEFwEx+qNK80CPVFsac4xEv0zQ++jnkJnHBYbVfSI6vjsUGoYY33Y8FfMh BarEY19XFMWz0Lxr6l/PhFSoMyNvyY3MKcQLfCk8aMdj3HPdHn1TAy4ChYGW1Op77eDL 8Ing== MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr387128lbc.24.1380132878685; Wed, 25 Sep 2013 11:14:38 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Wed, 25 Sep 2013 11:14:38 -0700 (PDT) In-Reply-To: References: <20130925164053.GB76403@lath.rinet.ru> Date: Wed, 25 Sep 2013 11:14:38 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Oleg Bulyzhin , Jack Vogel , andree@opendns.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:14:41 -0000 Hi Jack, Thanks for the suggestions and looking into this. Here are a few additional bits of information that you requested: 1. We did disable spanning tree on the switch port and the result of that is that basically now creating/destroying a vlan on the ix interface makes it freeze for about 3 seconds from previously 6. 2. I brought manually the physical interface down (ifconfig ix1 down) and then up and measured the time it took for the interface on the switch to show as up - and that was again about 3 seconds. So basically it seems to me like that's how long it normally takes for a link to be negotiated. 3. We tweaked a setting on the switch which instructs the port to be down for 5 seconds before it's considered down. Then repeated the test again and the result was that now the "freeze" period got reduced to 1.5 seconds and no ping packets were lost but one of the packets returned with 1500 ms delay. My guess on this one is that since the switch ignored the flapping of the interface, bringing it back up was much faster. So it does mask the problem somewhat but it is still there - the interface seems to go down. Next steps: 1. I will reinstall this machine with the latest 9.2 and repeat the tests see what happens. 2. If the previous one fails - I'll try the patch that Oleg sent. Thanks a lot for providing that patch. I'll update this list with more findings. Thank you, Rumen Telbizov On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel wrote: > Rumen, > > I'd like to know if you can check the spanning tree setting as Daniel > mentioned and if that solves it, > I do know that that can cause considerable delay in link transitions. > Also, can you see if you see > different behavior by going to the latest 9.2 bits? > > Oleg thanks for the patch, I will check it out and have my validation > engineer do some tests and > we'll get to the bottom of this. > > Jack > > > > On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote: > >> Thanks for the patch Oleg. >> I'll give it a try but I would also like to hear back from Jack. >> >> Oleg, can you confirm that you're experiencing the exact same >> problem/behavior? What kind of switch is connected on the other end? >> >> Thanks, >> Rumen Telbizov >> >> >> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin wrote: >> >> > >> > I'm running my ixgbe servers with attached patch. >> > It does solve this problem for me. >> > >> > -- >> > Oleg. >> > >> > ================================================================ >> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === >> > ================================================================ >> > >> > >> >> >> -- >> Rumen Telbizov >> >> Unix Systems Administrator >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:16:45 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id BE1155EF for ; Wed, 25 Sep 2013 18:16:45 +0000 (UTC) (envelope-from corbe@corbe.net) Received: from a0i166.smtpcorp.com (a0i166.smtpcorp.com [64.131.95.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 920112898 for ; Wed, 25 Sep 2013 18:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Subject:In-Reply-To:References:Cc:To:From:Message-ID; bh=N+bTe2Pl1m7KdPxgBAnD0zjRbP5d2y2k0iDt/CboUgw=; b=G0EDB3elJsy+bxR4xfFsNBi3RAYfsa34U6/d/8h6844b1gAkbQfRABM2po0Lo8NmNWdSihNo/J9JVzwCyPjgf8rkeKlsecFy1jceSp12YTCiCXNJa4b8n7GdErb9x1iEBJignWsJwqaMR+SDnCg30uf+bCm2AfQJBL1p2Rg971A=; Message-ID: <1F6A12D6D90C4D1792369B0AFC82173A@poopsackHD> From: "Daniel Corbe" To: "Daniel Kalchev" , "Rumen Telbizov" References: <3E619068-9015-4013-A99E-CEE8948C7455@digsys.bg> In-Reply-To: <3E619068-9015-4013-A99E-CEE8948C7455@digsys.bg> Subject: Re: FreeBSD 9.1 ix driver vlan problem Date: Wed, 25 Sep 2013 14:03:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Smtpcorp-Track: 314078952.3.55160347 Cc: freebsd-stable@freebsd.org, Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:16:45 -0000 Why would disabling STP on the switch *shorten* the amount of time it takes for the port to come up? At least on Cisco switches, it takes ~45 seconds for the switching topology to converge with STP disabled. Shorter periods if you enable portfast or uplinkfast. -----Original Message----- From: Daniel Kalchev Sent: Wednesday, September 25, 2013 4:31 AM To: Rumen Telbizov Cc: freebsd-stable@freebsd.org ; Jack Vogel Subject: Re: FreeBSD 9.1 ix driver vlan problem On 25.09.2013, at 02:16, Rumen Telbizov wrote: > > > Example: > ifconfig vlan200 create # this is OK > ifconfig vlan200 inet 1.2.3.1/30 vlan 200 vlandev ix1 description DEBUG # > this second line makes the rest of the vlans freeze for 6-7 seconds > > On the switch side (Juniper) the physical interface flaps. There's nothing > in logs/dmesg. > Might be, you have spanning tree enabled on the switch port and when the interface "flaps" it needs time to converge. Disable spanning tree on the port and the reset will be very short. Daniel _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:23:52 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id CC9D39D0; Wed, 25 Sep 2013 18:23:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76B302939; Wed, 25 Sep 2013 18:23:52 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id jy13so39660veb.19 for ; Wed, 25 Sep 2013 11:23:51 -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=Ya1fOe4KvEUq2g61Wt7EoprwQpvdJJAzUnRBHUJM0mk=; b=Ww8/sSYAIdpuuf5yaU6K3aCayoWkl+fP5PRHtJZi0bT4Y+r+vwp4M8nSNjWrcVrWxc OMkqfhyNHat8S9nunAksONKpoGyapzWQnM2eWHzkcI3skJyQGDzGi9zUh3uEB7o7Xe9n IL3su6LwOTu0A3MpX8mxOggjOdOxSOnASu4vsbV+A5hMuPjxVbTdsBtT17xlFLkLoOEI /OV9DIDUMopJb8hT1H7US+ZQti5Ae/9T2l98uVHYdNmJ0Ym52uEyVE25/E98NSLkAzmZ YLheFZUJP0qwAlW5it+6m6dX1bK4mrPQuD00VkEWMaaELTZApDuhslD4Sb9tL2xLENTr mHVw== MIME-Version: 1.0 X-Received: by 10.58.75.18 with SMTP id y18mr1708566vev.33.1380133431520; Wed, 25 Sep 2013 11:23:51 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Wed, 25 Sep 2013 11:23:51 -0700 (PDT) In-Reply-To: References: <20130925164053.GB76403@lath.rinet.ru> Date: Wed, 25 Sep 2013 11:23:51 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Jack Vogel To: Rumen Telbizov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Oleg Bulyzhin , Jack Vogel , andree@opendns.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:23:53 -0000 Thanks for the investigation, I guess what I'm wondering the most right now is if the patch from Oleg is a good change in general, so any others that can test and give me results would be appreciated. Thanks, Jack On Wed, Sep 25, 2013 at 11:14 AM, Rumen Telbizov wrote: > Hi Jack, > > Thanks for the suggestions and looking into this. > Here are a few additional bits of information that you requested: > > 1. We did disable spanning tree on the switch port and the result of that > is that basically now creating/destroying a vlan on the ix interface makes > it freeze for about 3 seconds from previously 6. > 2. I brought manually the physical interface down (ifconfig ix1 down) and > then up and measured the time it took for the interface on the switch to > show as up - and that was again about 3 seconds. So basically it seems to > me like that's how long it normally takes for a link to be negotiated. > 3. We tweaked a setting on the switch which instructs the port to be down > for 5 seconds before it's considered down. Then repeated the test again and > the result was that now the "freeze" period got reduced to 1.5 seconds and > no ping packets were lost but one of the packets returned with 1500 ms > delay. My guess on this one is that since the switch ignored the flapping > of the interface, bringing it back up was much faster. So it does mask the > problem somewhat but it is still there - the interface seems to go down. > > Next steps: > 1. I will reinstall this machine with the latest 9.2 and repeat the tests > see what happens. > 2. If the previous one fails - I'll try the patch that Oleg sent. Thanks a > lot for providing that patch. > > I'll update this list with more findings. > > Thank you, > Rumen Telbizov > > > > On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel wrote: > >> Rumen, >> >> I'd like to know if you can check the spanning tree setting as Daniel >> mentioned and if that solves it, >> I do know that that can cause considerable delay in link transitions. >> Also, can you see if you see >> different behavior by going to the latest 9.2 bits? >> >> Oleg thanks for the patch, I will check it out and have my validation >> engineer do some tests and >> we'll get to the bottom of this. >> >> Jack >> >> >> >> On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote: >> >>> Thanks for the patch Oleg. >>> I'll give it a try but I would also like to hear back from Jack. >>> >>> Oleg, can you confirm that you're experiencing the exact same >>> problem/behavior? What kind of switch is connected on the other end? >>> >>> Thanks, >>> Rumen Telbizov >>> >>> >>> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin wrote: >>> >>> > >>> > I'm running my ixgbe servers with attached patch. >>> > It does solve this problem for me. >>> > >>> > -- >>> > Oleg. >>> > >>> > ================================================================ >>> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === >>> > ================================================================ >>> > >>> > >>> >>> >>> -- >>> Rumen Telbizov >>> >>> Unix Systems Administrator >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >>> " >>> >> >> > > > -- > Rumen Telbizov > Unix Systems Administrator > From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:30:04 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id F1157B6F; Wed, 25 Sep 2013 18:30:03 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37976298F; Wed, 25 Sep 2013 18:30:03 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id y6so191516lbh.20 for ; Wed, 25 Sep 2013 11:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XqjLVOmCzFfgXa1+scaABSyBrNy6SOBGHr6I3zzd7eA=; b=pF4/tX0lAhgrXA8C1GWvwQmMfyETZ6vqTBqjyU0gjq8sGRCm4f5r4eWVsKDJbSVFL9 5OEJTqjwNGfisreYsG/12AlJNUFsj06P35YECeYVURySGf+vATsdoGxWw4ctCvLaWNGN rMWcgixGcnkmcxD1a5fHq2wUHpx/jl1l2q0giE8NefGZru3gNZDDXh0D98f+CE9esrCq Fc0ClmI1CguDFoTNqvQ17my3xmSx85vDWBTOpCpCHZ0lUsNOQLO02Rdtiw5uOzb3mc/J wxjy2RNeQlH+4RIf6rErvrGq/1gK0Dufea7MHmmw1CLRYdF+k1YdtD82AWX0xn0IwYua Ms/w== MIME-Version: 1.0 X-Received: by 10.152.37.166 with SMTP id z6mr13411142laj.25.1380133801143; Wed, 25 Sep 2013 11:30:01 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Wed, 25 Sep 2013 11:30:01 -0700 (PDT) In-Reply-To: References: <20130925164053.GB76403@lath.rinet.ru> Date: Wed, 25 Sep 2013 11:30:01 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Oleg Bulyzhin , Jack Vogel , andree@opendns.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:30:04 -0000 Jack, Can you reproduce this problem yourself? Does it make sense to experience this behavior? Thanks, Rumen Telbizov On Wed, Sep 25, 2013 at 11:23 AM, Jack Vogel wrote: > > Thanks for the investigation, I guess what I'm wondering the most right > now is if the patch from > Oleg is a good change in general, so any others that can test and give me > results would be appreciated. > > Thanks, > > Jack > > On Wed, Sep 25, 2013 at 11:14 AM, Rumen Telbizov wrote: > >> Hi Jack, >> >> Thanks for the suggestions and looking into this. >> Here are a few additional bits of information that you requested: >> >> 1. We did disable spanning tree on the switch port and the result of that >> is that basically now creating/destroying a vlan on the ix interface makes >> it freeze for about 3 seconds from previously 6. >> 2. I brought manually the physical interface down (ifconfig ix1 down) and >> then up and measured the time it took for the interface on the switch to >> show as up - and that was again about 3 seconds. So basically it seems to >> me like that's how long it normally takes for a link to be negotiated. >> 3. We tweaked a setting on the switch which instructs the port to be down >> for 5 seconds before it's considered down. Then repeated the test again and >> the result was that now the "freeze" period got reduced to 1.5 seconds and >> no ping packets were lost but one of the packets returned with 1500 ms >> delay. My guess on this one is that since the switch ignored the flapping >> of the interface, bringing it back up was much faster. So it does mask the >> problem somewhat but it is still there - the interface seems to go down. >> >> Next steps: >> 1. I will reinstall this machine with the latest 9.2 and repeat the tests >> see what happens. >> 2. If the previous one fails - I'll try the patch that Oleg sent. Thanks >> a lot for providing that patch. >> >> I'll update this list with more findings. >> >> Thank you, >> Rumen Telbizov >> >> >> >> On Wed, Sep 25, 2013 at 10:01 AM, Jack Vogel wrote: >> >>> Rumen, >>> >>> I'd like to know if you can check the spanning tree setting as Daniel >>> mentioned and if that solves it, >>> I do know that that can cause considerable delay in link transitions. >>> Also, can you see if you see >>> different behavior by going to the latest 9.2 bits? >>> >>> Oleg thanks for the patch, I will check it out and have my validation >>> engineer do some tests and >>> we'll get to the bottom of this. >>> >>> Jack >>> >>> >>> >>> On Wed, Sep 25, 2013 at 9:57 AM, Rumen Telbizov wrote: >>> >>>> Thanks for the patch Oleg. >>>> I'll give it a try but I would also like to hear back from Jack. >>>> >>>> Oleg, can you confirm that you're experiencing the exact same >>>> problem/behavior? What kind of switch is connected on the other end? >>>> >>>> Thanks, >>>> Rumen Telbizov >>>> >>>> >>>> On Wed, Sep 25, 2013 at 9:40 AM, Oleg Bulyzhin >>>> wrote: >>>> >>>> > >>>> > I'm running my ixgbe servers with attached patch. >>>> > It does solve this problem for me. >>>> > >>>> > -- >>>> > Oleg. >>>> > >>>> > ================================================================ >>>> > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === >>>> > ================================================================ >>>> > >>>> > >>>> >>>> >>>> -- >>>> Rumen Telbizov >>>> >>>> Unix Systems Administrator >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to " >>>> freebsd-stable-unsubscribe@freebsd.org" >>>> >>> >>> >> >> >> -- >> Rumen Telbizov >> Unix Systems Administrator >> > > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:32:34 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 1877FCDB for ; Wed, 25 Sep 2013 18:32:34 +0000 (UTC) (envelope-from majo-freebsd-stable@cerny.sk) Received: from mail.cerny.sk (mail.cerny.sk [80.79.31.23]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB6B329E5 for ; Wed, 25 Sep 2013 18:32:33 +0000 (UTC) Received: from [10.0.1.100] (ip-78-45-148-209.net.upcbroadband.cz [78.45.148.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.cerny.sk (Postfix) with ESMTPSA id 3C9EA2DFA4B for ; Wed, 25 Sep 2013 20:23:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cerny.sk; s=mail; t=1380133404; bh=YiagGx5A1KL2EQb76JQVYA5cmGqyySq+fRy2i/pkfZA=; h=From:Subject:Date:To; b=H/qYvaqjtvtSUV+2+kqpfraLe+1G7+4EafMnDSQc0SyYDfZNalPLz7Y/ETUVV3W55 53znvWuWvML0PVOVhF6YeaF3wIVUS+qExs8/kefMmczJ9oPtBdx5vwCb6iHd9vzjV2 /qmrtwbIOksCgAOknTOdX/wNvDaXlwY2z6SaAPuw= From: =?utf-8?Q?Mari=C3=A1n_=C4=8Cern=C3=BD?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Only one CPU core detected on Supermicro E3-1240 v3 Message-Id: <0EB9861A-8A57-45E3-BBA7-BE7C6EA69B55@cerny.sk> Date: Wed, 25 Sep 2013 20:23:20 +0200 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:32:34 -0000 Hello, I am trying to install FreeBSD 9.2-RC4 on Supermicro server with Intel = Xeon E3-1240 v3 processor. The processor has 4 cores with 8 threads. = However only one core is detected (with two threads): FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 The motherboard is Supermicro X10SLM-F. All cores are enabled in BIOS = and the latest firmware is installed (version 1.1a, Build Date = 08/20/2013). Output from dmesg is available here: = https://www.dropbox.com/s/u7hp8mlq2wo3oi5/dmesg.txt I have tried FreeBSD 9.1 as well and it behaves the same - only one core = is detected. What can I do so that all cores are properly detected? Marian= From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 18:32:54 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id A060ADD5; Wed, 25 Sep 2013 18:32:54 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 5955F29ED; Wed, 25 Sep 2013 18:32:54 +0000 (UTC) Received: by lath.rinet.ru (Postfix, from userid 222) id 387F5157B; Wed, 25 Sep 2013 22:32:53 +0400 (MSK) Date: Wed, 25 Sep 2013 22:32:53 +0400 From: Oleg Bulyzhin To: Rumen Telbizov Subject: Re: FreeBSD 9.1 ix driver vlan problem Message-ID: <20130925183253.GA1315@lath.rinet.ru> References: <20130925164053.GB76403@lath.rinet.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , andree@opendns.com, Oleg Bulyzhin , Jack Vogel , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:32:54 -0000 On Wed, Sep 25, 2013 at 11:14:38AM -0700, Rumen Telbizov wrote: > Next steps: > 1. I will reinstall this machine with the latest 9.2 and repeat the tests > see what happens. I didnt test 9.2 but i checked recent HEAD - it has vlan problem too. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 19:40:30 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 1449B31F for ; Wed, 25 Sep 2013 19:40:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B83F2E25 for ; Wed, 25 Sep 2013 19:40:29 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8PJeLBn052766; Wed, 25 Sep 2013 22:40:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8PJeLBn052766 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8PJeLBn052765; Wed, 25 Sep 2013 22:40:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Sep 2013 22:40:21 +0300 From: Konstantin Belousov To: Patrick Lamaiziere , freebsd-stable@freebsd.org Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130925194021.GB41229@kib.kiev.ua> References: <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> <20130925161954.GO14220@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lt3+jajHwVbO5afw" Content-Disposition: inline In-Reply-To: <20130925161954.GO14220@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:40:30 -0000 --Lt3+jajHwVbO5afw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +030= 0: > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > > I'd like to understand why you think protecting these functions w/ > > > the _DETACHED check is correct... In kern_event.c, all calls to > > > f_detach are followed by knote_drop which will ensure that the knote > > > is removed and free, so no more f_event calls will be called on that > > > knote.. > >=20 > > My current belief is that what happens is a glitch in the > > kqueue_register(). After a new knote is created and attached, the kq > > lock is dropped and then f_event() is called. If the vnode is reclaimed > > or possible freed meantime, f_event() seems to dereference freed memory, > > since kn_hook points to freed vnode. >=20 > Well, if that happens, then the vnode isn't properly clearing up the > knote before it gets reclaimed... It is the vnode's responsibility to > make sure any knotes that are associated w/ it get cleaned up properly.. See below. >=20 > > The issue as I see it is that vnode lifecycle is detached from the knote > > lifecycle. Might be, only the second patch, which acquires a hold refe= rence > > on the vnode for each knote, is really needed. But before going into a= ny > > conclusions, I want to see the testing results. >=20 > The vnode lifecycle can't/shouldn't be detached from the knote lifecycle > since the knote contains a pointer to the vnode... There is the function > knlist_clear that can be used to clean up knotes when the object goes > away.. This is done from the vdropl() (null hold count) -> destroy_vpollinfo(). But this is too late, IMO. vdropl() is only executing with the vnode interlock locked, and knote lock is vnode lock. This way, you might get far enough into vdropl in other thread, while trying to operate on a vnode with zero hold count in some kqueue code path. We do not drain the vnode lock holders when destroying vnode, because VFS interface require that anybody locking the vnode own a hold reference on it. My short patch should fix exactly this issue, hopefully we will see. >=20 > I was looking at the code, is there a good reason why you do > VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in > the vfs_knllock/vfs_knlunlock functions? Because kq code will modify > the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions, > so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to > vfs_knllock/vfs_knlunlock... vfs_knllock() is fine. The problematic case if the VOP_{PRE,POST}->VFS_KNOTE->VN_KNOTE->KNOTE calls from the VOPs. If you look at the vfs_knl_assert_locked(), you would note that the function only asserts that vnode is locked, not that it is locked exclusively. This is because some filesystems started require from VFS to do e.g. VOP_WRITE() with the vnode only shared-locked, and KNOTE() is called with shared-locked vnode lock. The vfs_knllock() obtain the exclusive lock on the vnode, so kqueue callers are fine. Taking vnode interlock inside the filters provides enough exclusion for the VOP callers. --Lt3+jajHwVbO5afw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSQzwkAAoJEJDCuSvBvK1BDekP/RgJ2MlujaNwLRt65C26SHpn zo6uV1spTzobO4gxD8CQbFiwr0etmxET5YyixmIaI84m4X3qd+PWlTdcLFvshqSu QxAzuQddPingKEfVrp917NFmMloz7LAIdE72WtUG5n4Un//QP0o4xQRpVOcSLQkr 8ciahh400WTyc5uj6dygqndl9/DdbkA2TE9HT5RCHZc2av3bkPHmw+HvymqeHejC dspDcwgjDiiPkjEWlXmSiQV2aZz/g0gcDKFb/0t3tZBR56DQOzScdrsU92GBnz5K IHt1gBYGIXSnN/6im9N+dDYyDdDkJ8Ac2trcWPcpZNdbevC3V1Pffem6SFThnkvt +b+Gq/7LEnQhDlVgn1LsTMmu/RrCJrVacvJukr5t++F3UpFv+XFft9QO4v/SUxPP +3cm7qQAyV2gQHkbQpbkk+t8IB/L6gSP41OeqSrLPWIxFa0qRkJnBCG5T5RgOwbn InO0alLwFTnqqc8tmnRxn0hMYsS/OhIknp6x3/s14zjyUcHalhzRBlaiZbsEVyW2 srxTB7rggkPzowzOOrXwhCirsXwDZGE2eGjEcdt6bO/S7cn6k9+OPrzMiV+tffKT JL9j61YGsMwKJR5fZz3Sv9CLJq99aPSEIJV0zWX2crPP0fjicKKm3frCt1I9l1Lw b+rtvdTDtFH8GmdZRAcd =cfCM -----END PGP SIGNATURE----- --Lt3+jajHwVbO5afw-- From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 20:15:54 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 78BB8E6A for ; Wed, 25 Sep 2013 20:15:54 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D8FA20DD for ; Wed, 25 Sep 2013 20:15:54 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ia10so158816vcb.6 for ; Wed, 25 Sep 2013 13:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f1y7wf9GB7jR1ONVx2kFkoluHhvCX1GfnoNHJUtpro4=; b=B8dE0XNNt2d4m3JH10ZSSAYo+ZLgj0tb2riyMBwE7mzhdJ4ymSSgc57ZdIGd5Nr99x r/5LztgcSIBGUNcit9dK3iw5+Azwj/O2vnE3GfMXXjx3GxSAHxwB5UKu7WC1LU4eAQyN QS7arTqDyPw3xXH6M0ifHEAMnmJ5JKnY/A331ozV7kewau/3LyWTuhqw5ty9b8y56OIg Gib46P46kiNWJziOffh/q2BV0KjEk53m+orsj0TyVfTeEDoD/7zowiM8nC4pkxBYVc02 vPJojRpCapPqAP8bPjGdX3pKWSd1k4omYd9w0IvGdAdKno8riS3Z+cVY9mz3DyFMfvM8 Injg== MIME-Version: 1.0 X-Received: by 10.52.108.230 with SMTP id hn6mr11529037vdb.28.1380140153245; Wed, 25 Sep 2013 13:15:53 -0700 (PDT) Received: by 10.221.4.137 with HTTP; Wed, 25 Sep 2013 13:15:53 -0700 (PDT) Date: Wed, 25 Sep 2013 16:15:53 -0400 Message-ID: Subject: Package build out to FTP distribution process From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:15:54 -0000 Can someone please describe the FreeBSD package building and publishing to FTP process? Consider the following representative directories... ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.2-release/All/ ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/All/ I'm not really interested in the release hierarchy, since other than some kind of urgent fix, it has been a onetime build and publish event and it ages with every future commit. It's process is fairly obvious. Now for the 'stable' hierarchy, that is updated over time. But how, under what policy and process, etc? What determines when an update is pushed out? Are there some minimum set of pkg that must build for it to be pushed? There must be some interim builds going on, where is the output from those? Can it be made accessible via web? Why is the update frequency so low and erratic? Is there some kind of strategic signoff behind the name 'stable' or is it just a reasonably named dumping area for a build from ports HEAD? Are there groups focused on running builds and squashing dependency checkpoints? I think of all the users who wish to use packages but perhaps cannot because... - months can go by before a popular package reappears from having gone missing. - the port itself may be a current version, which means somewhere there is a good build with it, but the published package is a rather old version for a long time. - something in ports may not appear as a package but may not be pkg banned, perhaps due to the above. So in general, what is the process behind populating the stable hierarchies of packages? And how can and what are the improvements to be made? Perhaps specifically regarding frequency and completeness. But also in general. Is this all wiki'd somewhere? From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 20:31:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 0AE933BE; Wed, 25 Sep 2013 20:31:17 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1D921F9; Wed, 25 Sep 2013 20:31:16 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ea20so176106lab.13 for ; Wed, 25 Sep 2013 13:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OWMEALMGqz6YeijQoATVb4E6O/fcuDfX0atALBLsCOQ=; b=qOXD0sz+YOhH+VihYh/NAYkjQAAfjUP4aalG6vbcr2Fe1tbPAsc2BqtZrk07KemB9W zBuVZPzpv6fxY91Y5C1FCXtOeQa2t01ggfHueIWNcZH2yMIps/ImvjyEUmB0ntoJQ5e2 FQ1Fk8OkZZjG1NxPw4GSc6y4mK+1ak1DUaNqiHv8MauJp4umCrF7LkFDJw8nHBtJk7TQ 2X8H5WjMlb3yqh04OQQ7sejwM7n/3AIeaUpnUyTL3ek91uPcQqW299GthIeEjn5eiiS0 2e1r/SwA2zr9Imq889SEx1/4rb+CnC+gRTSgwA7bloRT5A6ffhOthN8iuJZ+VVXqP2dm eB9Q== MIME-Version: 1.0 X-Received: by 10.152.88.20 with SMTP id bc20mr2852631lab.37.1380141074277; Wed, 25 Sep 2013 13:31:14 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Wed, 25 Sep 2013 13:31:14 -0700 (PDT) In-Reply-To: <20130925183253.GA1315@lath.rinet.ru> References: <20130925164053.GB76403@lath.rinet.ru> <20130925183253.GA1315@lath.rinet.ru> Date: Wed, 25 Sep 2013 13:31:14 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Oleg Bulyzhin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Andree Toonk , "freebsd-stable@freebsd.org" , Jack Vogel , Jack Vogel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:31:17 -0000 Thanks for the heads-up Oleg, although not the news that I was hoping for. So what I am going to do right now is reinstall with 9.2 and recompile the driver with your patch. I'll come back to the list with my results. It would be really nice if Jack et al could test that patch themselves and endorse/incorporate into future FreeBSD releases. From the comments I am not sure if Jack really approves on it or there's a better way of fixing things. Thank you, Rumen Telbizov On Wed, Sep 25, 2013 at 11:32 AM, Oleg Bulyzhin wrote: > On Wed, Sep 25, 2013 at 11:14:38AM -0700, Rumen Telbizov wrote: > > > Next steps: > > 1. I will reinstall this machine with the latest 9.2 and repeat the tests > > see what happens. > > I didnt test 9.2 but i checked recent HEAD - it has vlan problem too. > > -- > Oleg. > > ================================================================ > === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === > ================================================================ > > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Wed Sep 25 21:06:22 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 8EFC8E82 for ; Wed, 25 Sep 2013 21:06:22 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 357B32434 for ; Wed, 25 Sep 2013 21:06:21 +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 r8PL6F4R054262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 14:06:16 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8PL6F71054261; Wed, 25 Sep 2013 14:06:15 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Sep 2013 14:06:15 -0700 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130925210615.GS14220@funkthat.com> Mail-Followup-To: Konstantin Belousov , Patrick Lamaiziere , freebsd-stable@freebsd.org References: <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> <20130925161954.GO14220@funkthat.com> <20130925194021.GB41229@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130925194021.GB41229@kib.kiev.ua> 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-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]); Wed, 25 Sep 2013 14:06:16 -0700 (PDT) Cc: freebsd-stable@freebsd.org, Patrick Lamaiziere X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:06:22 -0000 Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 22:40 +0300: > On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote: > > Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300: > > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > > > I'd like to understand why you think protecting these functions w/ > > > > the _DETACHED check is correct... In kern_event.c, all calls to > > > > f_detach are followed by knote_drop which will ensure that the knote > > > > is removed and free, so no more f_event calls will be called on that > > > > knote.. > > > > > > My current belief is that what happens is a glitch in the > > > kqueue_register(). After a new knote is created and attached, the kq > > > lock is dropped and then f_event() is called. If the vnode is reclaimed > > > or possible freed meantime, f_event() seems to dereference freed memory, > > > since kn_hook points to freed vnode. > > > > Well, if that happens, then the vnode isn't properly clearing up the > > knote before it gets reclaimed... It is the vnode's responsibility to > > make sure any knotes that are associated w/ it get cleaned up properly.. > See below. > > > > > > The issue as I see it is that vnode lifecycle is detached from the knote > > > lifecycle. Might be, only the second patch, which acquires a hold reference > > > on the vnode for each knote, is really needed. But before going into any > > > conclusions, I want to see the testing results. > > > > The vnode lifecycle can't/shouldn't be detached from the knote lifecycle > > since the knote contains a pointer to the vnode... There is the function > > knlist_clear that can be used to clean up knotes when the object goes > > away.. > This is done from the vdropl() (null hold count) -> destroy_vpollinfo(). > But this is too late, IMO. vdropl() is only executing with the vnode > interlock locked, and knote lock is vnode lock. This way, you might > get far enough into vdropl in other thread, while trying to operate on > a vnode with zero hold count in some kqueue code path. > > We do not drain the vnode lock holders when destroying vnode, because > VFS interface require that anybody locking the vnode own a hold reference > on it. My short patch should fix exactly this issue, hopefully we will see. Which clearly wasn't happening before... With the above, and rereading your patch, I understand how this patch should fix the issue and bring the life cycle of the two back into sync... > > I was looking at the code, is there a good reason why you do > > VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in > > the vfs_knllock/vfs_knlunlock functions? Because kq code will modify > > the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions, > > so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to > > vfs_knllock/vfs_knlunlock... > > vfs_knllock() is fine. The problematic case if the > VOP_{PRE,POST}->VFS_KNOTE->VN_KNOTE->KNOTE calls from the VOPs. If you > look at the vfs_knl_assert_locked(), you would note that the function > only asserts that vnode is locked, not that it is locked exclusively. > This is because some filesystems started require from VFS to do e.g. > VOP_WRITE() with the vnode only shared-locked, and KNOTE() is called > with shared-locked vnode lock. > > The vfs_knllock() obtain the exclusive lock on the vnode, so kqueue > callers are fine. Taking vnode interlock inside the filters provides > enough exclusion for the VOP callers. Ahh, ok, makes sense now.. Clearly I need to learn more about the VFS/vnope system.. :) Thanks for the explanations... -- 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-stable@FreeBSD.ORG Wed Sep 25 21:10:16 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 7427B8F; Wed, 25 Sep 2013 21:10:16 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E75B824A9; Wed, 25 Sep 2013 21:10:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r8PLADsx041934; Thu, 26 Sep 2013 01:10:13 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 26 Sep 2013 01:10:13 +0400 (MSK) From: Dmitry Morozovsky To: Rumen Telbizov Subject: Re: FreeBSD 9.1 ix driver vlan problem In-Reply-To: Message-ID: References: <20130925164053.GB76403@lath.rinet.ru> <20130925183253.GA1315@lath.rinet.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 26 Sep 2013 01:10:13 +0400 (MSK) Cc: "freebsd-stable@freebsd.org" , Jack Vogel , Oleg Bulyzhin , Jack Vogel , Andree Toonk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:10:16 -0000 On Wed, 25 Sep 2013, Rumen Telbizov wrote: > Thanks for the heads-up Oleg, although not the news that I was hoping for. > > So what I am going to do right now is reinstall with 9.2 and recompile the > driver with your patch. > I'll come back to the list with my results. FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're welcome to test this on your 9 It's supposedly way too late to try to include this fix into 9.2-R, but maybe it's worth the errata notice... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 02:32:38 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 11741EFA for ; Thu, 26 Sep 2013 02:32:38 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id C5A8F2652 for ; Thu, 26 Sep 2013 02:32:37 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:52950] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 36/52-26070-28C93425; Thu, 26 Sep 2013 02:31:30 +0000 Date: Thu, 26 Sep 2013 02:31:30 +0000 Message-ID: <36.52.26070.28C93425@cdptpa-oedge03> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard References: <20130925063610.GA1507@michelle.cdnetworks.com> X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Cc: Yonghyeon PYUN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 02:32:38 -0000 > It looks like 8168E-VL. > Could you try attached patch and show me the dmesg output(re(4) and > rgephy(4) only)? The patch was generated to support 8106E but it > will correctly show MAC revision number. I assume I go to /usr/src and run patch < /home/arlene/computer/re.8106.diff Then rebuild the kernel with -DNO_MODULES and install under a different name, like kernelre? I would install this on USB-stick installation, could do this for i386 USB-stick installation as well. > > Somewhat later I got > > Memory modified after free 0xfffffe0011546800(2048) val=977e3dd > 4 @ 0xfffffe0011546800 > > Memory modified after free 0xfffffe001153b800(2048) val=ffffffff @ 0xfffffe00115 > 3b800 > > Memory modified after free 0xfffffe0011524800(2048) val=977e3dd4 @ 0xfffffe00115 > 24800 > > VESA: set_mode(): 24(18) -> 24(18) > > Memory modified after free 0xfffffe0011594000(2048) val=977e3dd4 @ 0xfffffe00115 > 94000 > The size(2048) indicates mbuf cluster which in turn means bad > things happened in re(4). I have no idea how this can happen > though. > If you assign static IP addressi to re(4), does the driver works as > expected? I can try assigning a static address to re4, not really sure how to set up manually, though I did it long ago in Slackware Linux. I wouldn't have known size 2048 indicated something bad, though the message's presence and system crash indicated that something was fouled up in memory. Tom From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 05:00:45 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 23232587 for ; Thu, 26 Sep 2013 05:00:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EEF1E2B22 for ; Thu, 26 Sep 2013 05:00:44 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p10so630125pdj.4 for ; Wed, 25 Sep 2013 22:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yhOMCjRqDJG9wCTL4r8z57B+qoInRN8SSQcV0Trf/PY=; b=AD4r1ssPG+MZi13GzRjOBEUKuA9D4WumM3g2o3sSlJJQyWJnFhMioLHYnUsz4knAD3 dFBi7p4x1NmuKJfZ5gIFgu7pFtHdJcHffUXjEv7ow0H2fro//ziw9ijhtNjrur22NBnF obF+mIpAjbq5jjzjK+d5SnU6hCjYo/pGqUmRslUqcDmWO3TUfUXeiObTW+Sq28cJGmIm K3H8LtnMsTR8UhGV715oMme6ig98z7TCfjtOORH2xoBxG4FlhfW00ThVXGYu3LlhqwlB gGgRMjW5iKkAti73dEW5DJw+cYhGTn4d/e9PGRdvcJ30HhVUwpCiTkrcZoFWkrlgOvr2 0SMw== X-Received: by 10.66.161.229 with SMTP id xv5mr3014313pab.87.1380171644564; Wed, 25 Sep 2013 22:00:44 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id ve9sm51539632pbc.19.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 22:00:43 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 26 Sep 2013 14:00:39 +0900 From: Yonghyeon PYUN Date: Thu, 26 Sep 2013 14:00:39 +0900 To: Thomas Mueller Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard Message-ID: <20130926050038.GA1494@michelle.cdnetworks.com> References: <20130925063610.GA1507@michelle.cdnetworks.com> <36.52.26070.28C93425@cdptpa-oedge03> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36.52.26070.28C93425@cdptpa-oedge03> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 05:00:45 -0000 On Thu, Sep 26, 2013 at 02:31:30AM +0000, Thomas Mueller wrote: > > It looks like 8168E-VL. > > Could you try attached patch and show me the dmesg output(re(4) and > > rgephy(4) only)? The patch was generated to support 8106E but it > > will correctly show MAC revision number. > > I assume I go to /usr/src and run > patch < /home/arlene/computer/re.8106.diff > Yes. > Then rebuild the kernel with -DNO_MODULES and install under a different name, like kernelre? > Rebuilding kernel should be enough. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html for more information. > I would install this on USB-stick installation, could do this for i386 USB-stick installation as well. > > > > Somewhat later I got > > > > Memory modified after free 0xfffffe0011546800(2048) val=977e3dd > > 4 @ 0xfffffe0011546800 > > > Memory modified after free 0xfffffe001153b800(2048) val=ffffffff @ 0xfffffe00115 > > 3b800 > > > Memory modified after free 0xfffffe0011524800(2048) val=977e3dd4 @ 0xfffffe00115 > > 24800 > > > VESA: set_mode(): 24(18) -> 24(18) > > > Memory modified after free 0xfffffe0011594000(2048) val=977e3dd4 @ 0xfffffe00115 > > 94000 > > > The size(2048) indicates mbuf cluster which in turn means bad > > things happened in re(4). I have no idea how this can happen > > though. > > If you assign static IP addressi to re(4), does the driver works as > > expected? > > I can try assigning a static address to re4, not really sure how to set up manually, though I did it long ago in Slackware Linux. > > I wouldn't have known size 2048 indicated something bad, though the message's presence and system crash indicated that something was fouled up in memory. > > Tom > From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 06:26:15 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 3F1E3D58 for ; Thu, 26 Sep 2013 06:26:15 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id D27CC2F33 for ; Thu, 26 Sep 2013 06:26:14 +0000 (UTC) Received: from charlemagne.dc19.boland.org (37-251-15-238.FTTH.ispfabriek.nl [37.251.15.238]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r8Q6Q6sD022421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Sep 2013 08:26:07 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <5243D37E.6030703@boland.org> Date: Thu, 26 Sep 2013 08:26:06 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 CC: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 ix driver vlan problem References: <3E619068-9015-4013-A99E-CEE8948C7455@digsys.bg> <1F6A12D6D90C4D1792369B0AFC82173A@poopsackHD> In-Reply-To: <1F6A12D6D90C4D1792369B0AFC82173A@poopsackHD> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:26:15 -0000 On 09/25/2013 20:03, Daniel Corbe wrote: > Why would disabling STP on the switch *shorten* the amount of time it takes for > the port to come up? At least on Cisco switches, it takes ~45 seconds for the > switching topology to converge with STP disabled. Shorter periods if you enable > portfast or uplinkfast. What is meant, I believe, is that the port should be configured as an edge port ("spanning-tree portfast [trunk]" in cisco lingo, "set edge" for junipers). You don't ever want to disable STP anywhere - that's just a recipe for disaster. Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 07:19:49 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 44CC7766 for ; Thu, 26 Sep 2013 07:19:49 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0A89A22C7 for ; Thu, 26 Sep 2013 07:19:48 +0000 (UTC) Received: from mr129166.localdomain (mr129166.cri.univ-rennes1.fr [129.20.129.166]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 572D6AB34; Thu, 26 Sep 2013 09:19:47 +0200 (CEST) Received: from mr129166 (localhost [127.0.0.1]) by mr129166.localdomain (Postfix) with ESMTP id 5E4033AB; Thu, 26 Sep 2013 09:19:46 +0200 (CEST) Date: Thu, 26 Sep 2013 09:19:45 +0200 From: Patrick Lamaiziere To: Konstantin Belousov Subject: Re: Possible kqueue related issue on STABLE/RC. Message-ID: <20130926091945.44f70996@mr129166> In-Reply-To: <20130925080633.GY41229@kib.kiev.ua> References: <20130920151705.33aae120@mr129166> <20130923153708.45c3be3d@mr129166> <20130923203141.GV41229@kib.kiev.ua> <20130924094427.0f4b902a@mr129166> <20130924082909.GH41229@kib.kiev.ua> <20130924114738.60c700c9@mr129166> <20130924121434.GI41229@kib.kiev.ua> <20130924174517.GB14220@funkthat.com> <20130924212127.GQ41229@kib.kiev.ua> <20130925095805.2072f0cc@mr129166> <20130925080633.GY41229@kib.kiev.ua> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:19:49 -0000 Le Wed, 25 Sep 2013 11:06:33 +0300, Konstantin Belousov a écrit : Hello, > > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: > > > > I'd like to understand why you think protecting these functions > > > > w/ the _DETACHED check is correct... In kern_event.c, all > > > > calls to f_detach are followed by knote_drop which will ensure > > > > that the knote is removed and free, so no more f_event calls > > > > will be called on that knote.. > > > > > > My current belief is that what happens is a glitch in the > > > kqueue_register(). After a new knote is created and attached, the > > > kq lock is dropped and then f_event() is called. If the vnode is > > > reclaimed or possible freed meantime, f_event() seems to > > > dereference freed memory, since kn_hook points to freed vnode. > > > > > > The issue as I see it is that vnode lifecycle is detached from the > > > knote lifecycle. Might be, only the second patch, which acquires > > > a hold reference on the vnode for each knote, is really needed. > > > But before going into any conclusions, I want to see the testing > > > results. > > > > Testing looks good with your latest patch. I was able to run a > > complete poudriere bulk (870 packages). I'm running another bulk to > > see.. I've made another bulk without problem (with complete patch) > > If you have other patches to test just ask, I have not updated my > > packages because there was a change to make gvfsd to ignore some > > poudriere activity. So I guess it will be harder to see this > > problem. > Could you, please, test with the only patch > http://people.freebsd.org/~kib/misc/vnode_filter.1.patch > applied ? I wonder would it be enough. Looks good with this single patch too, one poudriere bulk is completed and I'm doing another just in case (but I think it would have already paniced, that's quite reproductible). Thanks, regards. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 08:09:38 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 544A7F69 for ; Thu, 26 Sep 2013 08:09:38 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB0F2646 for ; Thu, 26 Sep 2013 08:09:37 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:35805] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 75/B0-09602-0CBE3425; Thu, 26 Sep 2013 08:09:37 +0000 Date: Thu, 26 Sep 2013 08:09:36 +0000 Message-ID: <75.B0.09602.0CBE3425@cdptpa-oedge03> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard References: <20130925063610.GA1507@michelle.cdnetworks.com> <36.52.26070.28C93425@cdptpa-oedge03> <20130926050038.GA1494@michelle.cdnetworks.com> X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Cc: Yonghyeon PYUN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 08:09:38 -0000 I rebuilt the kernel while keeping the existing kernel, installing to /boot/kernelre on the USB stick. Unfortunately all the modules were redundantly rebuilt. Maybe I should have had "-D NO_MODULES" instead of "-DNO_MODULES"? I typed "unload" at the loader prompt, then "boot /boot/kernelre/kernel". I had the same problem as before with dhclient, looked like nothing different. Lines in /var/run/dmesg.boot relating to re0 were: re0: port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: d4:3d:7e:97:17:e2 Tom From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 08:33:33 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id D1F03AAA for ; Thu, 26 Sep 2013 08:33:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A909D2800 for ; Thu, 26 Sep 2013 08:33:33 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj1so1005006pad.28 for ; Thu, 26 Sep 2013 01:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yTYRDWPTUtWVUcz3WQERdiKynem5ectSDv6SLcHA8+g=; b=G86nLt1ZN9NajGbaE1jUFV+5T44EwIv7uI9+g2mAYASxJfP6cfRW1bwGPP1r+rgDEA hhOA7O5E+toJMI6hIAGU5rKO/y6cXbks+xeKSsEQlNsv64QN5pjd/scYbqnViVIpPUOq zf19h147yfwohgarRbs94t+3OLH6hUUKV/4A43JaZsvfE86rUljyf2yeU0yFLSqyr1mo sByhpsmgEfh4llVo6oianDWp13ShUd++ccZOWfUkL0orYFlL4eEVIflEb4mTyg0MhMPI gUwPcF2+Jfn58OWOtnEBaIODeznKT2PgCLx+XAwb4AF2//zv3r0Zqsev/Xcn79mqw8va FLbQ== X-Received: by 10.66.218.166 with SMTP id ph6mr4065154pac.28.1380184412318; Thu, 26 Sep 2013 01:33:32 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id nj9sm738515pbc.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 01:33:31 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 26 Sep 2013 17:33:27 +0900 From: Yonghyeon PYUN Date: Thu, 26 Sep 2013 17:33:27 +0900 To: Thomas Mueller Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard Message-ID: <20130926083326.GB1494@michelle.cdnetworks.com> References: <20130925063610.GA1507@michelle.cdnetworks.com> <36.52.26070.28C93425@cdptpa-oedge03> <20130926050038.GA1494@michelle.cdnetworks.com> <75.B0.09602.0CBE3425@cdptpa-oedge03> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75.B0.09602.0CBE3425@cdptpa-oedge03> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 08:33:33 -0000 On Thu, Sep 26, 2013 at 08:09:36AM +0000, Thomas Mueller wrote: > I rebuilt the kernel while keeping the existing kernel, installing to /boot/kernelre on the USB stick. > > Unfortunately all the modules were redundantly rebuilt. Maybe I should have had "-D NO_MODULES" instead of "-DNO_MODULES"? > > I typed "unload" at the loader prompt, then "boot /boot/kernelre/kernel". > > I had the same problem as before with dhclient, looked like nothing different. The patch was not intended to address your issue. It was for getting correct MAC revision number. So seeing no behavioral change is normal. The MAC revision number now indicates 0x00100000 which means you have slightly different variant. I'll let you know if I happen to find more clue on that MAC revision. > > Lines in /var/run/dmesg.boot relating to re0 were: > > re0: port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d00000-0xf7d03fff irq 17 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00100000 ^^^^^^^^^^^^^^^^^^^^^^^^ > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: d4:3d:7e:97:17:e2 > > > Tom > From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 12:49:31 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id D84FD98D for ; Thu, 26 Sep 2013 12:49:31 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id B142827AC for ; Thu, 26 Sep 2013 12:49:31 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id DE05D33C4B; Thu, 26 Sep 2013 08:43:32 -0400 (EDT) From: Lowell Gilbert To: grarpamp Subject: Re: Package build out to FTP distribution process References: Date: Thu, 26 Sep 2013 08:43:32 -0400 In-Reply-To: (grarpamp@gmail.com's message of "Wed, 25 Sep 2013 16:15:53 -0400") Message-ID: <4438or21or.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 12:49:31 -0000 grarpamp writes: > Is this all wiki'd somewhere? There's plenty of information on the FreeBSD wiki, but you need to read the "portbuild" article from the documentation set first. But bear in mind that a lot of work continues to go into this area, so documentation tends to larg behind reality a bit. From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 14:54:27 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id B5529B65; Thu, 26 Sep 2013 14:54:27 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E94692F4E; Thu, 26 Sep 2013 14:54:26 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id w6so1157384lbh.19 for ; Thu, 26 Sep 2013 07:54:24 -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=A+TIFufwYZfQQ9Qv8G5KMH+V2GV1TSjKBqHEqmLIYIU=; b=Qo9TpNigi66JS8dbRho1TqZ8ToIuzS7ppjcXAQbduZOdmBiv41G5CFcysSiV8s0BH6 9Ei5ln7vdS0FaoLrnyaXGVsVGmqkYXQXgvB4t2QGrtYcXQQ8f1WwL3yZIqXmev+YacvX qWa+fpAfPIP8uir6bgazJviiTyfBtFn8LjvI2qHQh8qTidl4grXhE+Oy/v6YFuhYegty c8l/BBmt2VfbGFVxsmJMMvf23gLvzolt+9kQhD5O+47KAD06rEiK6CEA6aZ4x1AHEoXZ aGohLIxXzvYPVMRhXxjD2M4NImIGmM1NQ0aIMWEuk8z87SCXKo4oAVXLbYeZglQ1+mD/ uZ6Q== MIME-Version: 1.0 X-Received: by 10.112.9.195 with SMTP id c3mr1949779lbb.33.1380207264849; Thu, 26 Sep 2013 07:54:24 -0700 (PDT) Received: by 10.112.157.232 with HTTP; Thu, 26 Sep 2013 07:54:24 -0700 (PDT) In-Reply-To: References: <20130925164053.GB76403@lath.rinet.ru> <20130925183253.GA1315@lath.rinet.ru> Date: Thu, 26 Sep 2013 07:54:24 -0700 Message-ID: Subject: Re: FreeBSD 9.1 ix driver vlan problem From: Rumen Telbizov To: Dmitry Morozovsky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , Jack Vogel , Oleg Bulyzhin , Jack Vogel , Andree Toonk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:54:27 -0000 Hello everyone, Here are the final results of my tests: 1. I reinstalled the router with vanilla 9.2-RC4 and performed the same tests - the results were exactly the same. The problem persisted. 2. Then I applied the patch provided by Oleg and recompiled kernel. This indeed did *fix* the problem and now creating/destroying vlans does NOT cause the interface to flap at all. All the symptoms that I was experiencing seem to be gone. Thank you so very much Oleg and Dmitry! Appreciated. Jack, at this point I am wondering what your opinion on the patch is? Do you approve it for production use yourself or do you think it needs to reworked? Also any plans of incorporating this in -STABLE ? Again, I'd like to thank everyone who helped here and especially Oleg, Dmitry and Jack. Thanks guys! Cheers, Rumen Telbizov On Wed, Sep 25, 2013 at 2:10 PM, Dmitry Morozovsky wrote: > On Wed, 25 Sep 2013, Rumen Telbizov wrote: > > > Thanks for the heads-up Oleg, although not the news that I was hoping > for. > > > > So what I am going to do right now is reinstall with 9.2 and recompile > the > > driver with your patch. > > I'll come back to the list with my results. > > FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're > welcome > to test this on your 9 > > It's supposedly way too late to try to include this fix into 9.2-R, but > maybe > it's worth the errata notice... > > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 16:23:40 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 5620A328 for ; Thu, 26 Sep 2013 16:23:40 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from mproxy8.sbb.rs (mproxy8.sbb.rs [89.216.2.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDF8C2700 for ; Thu, 26 Sep 2013 16:23:39 +0000 (UTC) Received: from knossos (cable-178-148-113-12.dynamic.sbb.rs [178.148.113.12]) by mproxy8.sbb.rs (8.14.4/8.14.4) with ESMTP id r8QFqUEA009707 for ; Thu, 26 Sep 2013 17:52:35 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: from localhost (1000@localhost [local]); by knossos (OpenSMTPD) with ESMTPA id 48564b1a; for ; Thu, 26 Sep 2013 17:52:00 +0200 (CEST) User-Agent: OpenSMTPD enqueuer (Demoosh) Date: Thu, 26 Sep 2013 17:52:00 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Ethernet on new MSI Message-ID: <20130926155200.GA29321@knossos> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy8.sbb.rs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:23:40 -0000 One last shot in the dark: what if you reboot the router in front of the node in question? Sometimes it was surprised, when managing different mac addresses on the same adapter. I might be missing some parts, but did the mobo work before? Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 18:21:11 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 64090E02 for ; Thu, 26 Sep 2013 18:21:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FA872FE3 for ; Thu, 26 Sep 2013 18:21:11 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id r8QIL8fg089221 for ; Thu, 26 Sep 2013 14:21:08 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <52447AF6.8060207@sentex.net> Date: Thu, 26 Sep 2013 14:20:38 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: nanobsd on RELENG9 X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 18:21:11 -0000 I am getting an odd error on a recent i386 releng9 while trying to build a nanobsd image. It dies during installworld in cd /usr/src/etc/../share/man; /usr/obj/nanobsd.full//usr/src/make.i386/make makedb makewhatis /usr/obj/nanobsd.full//_.w/usr/share/man makewhatis /usr/obj/nanobsd.full//_.w/usr/share/openssl/man rm: /tmp/install.bqKyLzJg: Directory not empty *** [installworld] Error code 1 1 error *** [installworld] Error code 2 1 error The only thing special about the environment is that its netbooted and root is mounted via nfs and The error seems to be in /usr/src/Makefile.inc1 ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ ${IMAKEENV} rm -rf ${INSTALLTMP} if I get rid of the rm -rf it works/completes 0{mdttestbox}# mount 10.255.255.1:/home/pxe9alix on / (nfs) devfs on /dev (devfs, local, multilabel) /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) /dev/da0a on /usr/obj (ufs, local, soft-updates) 0{mdttestbox}# ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Sep 26 20:06:32 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 8B53BEB for ; Thu, 26 Sep 2013 20:06:32 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 54C4327AE for ; Thu, 26 Sep 2013 20:06:31 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:61853] helo=localhost) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 0C/1D-18320-6C394425; Thu, 26 Sep 2013 20:06:31 +0000 Date: Thu, 26 Sep 2013 20:06:30 +0000 Message-ID: <0C.1D.18320.6C394425@cdptpa-oedge01> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard References: <20130926083326.GB1494@michelle.cdnetworks.com> <20130926155200.GA29321@knossos> X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Cc: Yonghyeon PYUN X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 20:06:32 -0000 > The patch was not intended to address your issue. It was for > getting correct MAC revision number. So seeing no behavioral change > is normal. > The MAC revision number now indicates 0x00100000 which means you > have slightly different variant. I'll let you know if I happen to > find more clue on that MAC revision. So now there is no advantage in building that kernel for my i386 USB-stick installation. Do I need to file a send-pr? > One last shot in the dark: > what if you reboot the router in front of the node in question? > Sometimes it was surprised, when managing different mac addresses > on the same adapter. > I might be missing some parts, but did the mobo work before? > Best regards > Zoran I believe I can power off the router, and after a minute or two, power back on. Sure the mobo works, even the Ethernet chip works, but not with FreeBSD. I could boot NetBSD-HEAD amd64, dhclient ran ok, and I was able to checkout the system source tree and pkgsrc tree with cvs. So if I can get past the snag in pkg-config, which was dropped by FreeBSD in favor of pkgconf, I could build subversion and checkout the FreeBSD-HEAD source tree. I wonder if my Ethernet chip is better supported in the upcoming FreeBSD-10.0. I also have the on-motherboard quasi-USB WiFi Atheros AR9271 and the Hiro USB-stick-type WiFi adapter, Realtek RTL8191SU chip. I could also try to boot my OpenBSD 5.3 live USB 8 GB, see if Ethernet chip or Wi-Fi works, but OpenBSD can't access my hard drive or GPT-partitioned USB sticks, since OpenBSD does not support GPT, or USB 3.0. Tom From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 00:07:37 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 908B2D8B for ; Fri, 27 Sep 2013 00:07:37 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD072389 for ; Fri, 27 Sep 2013 00:07:36 +0000 (UTC) Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.7/8.14.7) with ESMTP id r8R07SLG060700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Sep 2013 10:07:30 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1380240450; bh=gJoqxvGKIDo5nnOKifT3F8OPBBgDzPjwTiy5l0ysqoU=; h=Date:From:To:Subject; b=pEYZyrDTb0dkyMZFR+Q7bmYuzy4w923NMV0oeOEQ40yspwR+beba7QxMhNHDBnWwt DLAEwclbk5Wf93AgHcmnQEZiqHTt3KPLUW7mSIYz3JbXFgIwbxDe8i0FUj9ehzZHDI uvzFemDBpwb0DSEvo56BjWISJbio9YVRm+F74iIw= Date: Fri, 27 Sep 2013 10:07:28 +1000 From: John Marshall To: freebsd-stable@freebsd.org Subject: 9.2-RC4 amd64 panic: vm_page_unwire Message-ID: <20130927000728.GB19167@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:07:37 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm running 9.2-RC4 on a handful of desktop and server machines (both i386 and amd64). I have seen three panics (all vm_page_unwire) on one of those systems only (amd64 server) during the past week. The first two panics were triggered when shutting down the ntpd daemon (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a later release (p388) has not triggered the panic. The system panicked again overnight, this time while acting as an sftp server receiving large (GB) files from another system. Fri Sep 20 16:48:34 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.0 ... panic: vm_page_unwire: page 0xfffffe0233510578's wire count is zero cpuid =3D 3 KDB: stack backtrace: #0 0xffffffff80490268 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 #3 0xffffffff80678702 at vm_fault_unwire+0xd2 #4 0xffffffff80680841 at vm_map_delete+0x171 #5 0xffffffff80680abf at vm_map_remove+0x5f #6 0xffffffff80683ee9 at vmspace_exit+0xc9 #7 0xffffffff8041f3ad at exit1+0x72d #8 0xffffffff804203ae at sys_sys_exit+0xe #9 0xffffffff806afd6f at amd64_syscall+0x3bf #10 0xffffffff8069a817 at Xfast_syscall+0xf7 Uptime: 2d0h35m3s =20 Fri Sep 20 17:49:57 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.1 ... panic: vm_page_unwire: page 0xfffffe022f5fc238's wire count is zero cpuid =3D 2 KDB: stack backtrace: #0 0xffffffff80490268 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 #3 0xffffffff80678702 at vm_fault_unwire+0xd2 #4 0xffffffff80680841 at vm_map_delete+0x171 #5 0xffffffff80680abf at vm_map_remove+0x5f #6 0xffffffff80683ee9 at vmspace_exit+0xc9 #7 0xffffffff8041f3ad at exit1+0x72d #8 0xffffffff804203ae at sys_sys_exit+0xe #9 0xffffffff806afd6f at amd64_syscall+0x3bf #10 0xffffffff8069a817 at Xfast_syscall+0xf7 Uptime: 59m51s Fri Sep 27 01:51:44 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.2 ... panic: vm_page_unwire: page 0xfffffe0239ecfc48's wire count is zero cpuid =3D 5 KDB: stack backtrace: #0 0xffffffff80490268 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 #3 0xffffffff804d857e at vfs_vmio_release+0x10e #4 0xffffffff804dadc8 at getnewbuf+0x468 #5 0xffffffff804dbb2f at getblk+0x5df #6 0xffffffff80632bb1 at ffs_balloc_ufs2+0x15c1 #7 0xffffffff8065a8d6 at ffs_write+0x246 #8 0xffffffff8070a18f at VOP_WRITE_APV+0x11f #9 0xffffffff80505e77 at vn_write+0x1f7 #10 0xffffffff80503b51 at vn_io_fault+0xb1 #11 0xffffffff804a387c at dofilewrite+0x9c #12 0xffffffff804a3b54 at kern_writev+0x54 #13 0xffffffff804a3bf5 at sys_write+0x65 #14 0xffffffff806afd6f at amd64_syscall+0x3bf #15 0xffffffff8069a817 at Xfast_syscall+0xf7 Uptime: 6d7h46m14s Is this a known problem? Should I file a PR? What additional information should I provide? I have made the core.txt.[0-2] files available in the following directory. The directory is not browsable. http://www.riverwillow.net.au/~john/92rc4/ --=20 John Marshall --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlJEzEAACgkQw/tAaKKahKJ0xACcCsDNpkqlA7rqUfHq02VnMTOc fH8AnA+r2YRRrjbh3P6FO4e7BSeQT0VV =ZNJR -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 03:57:50 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 0B108F45 for ; Fri, 27 Sep 2013 03:57:50 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id 21BC32F26 for ; Fri, 27 Sep 2013 03:57:48 +0000 (UTC) Received: from ppp118-210-127-6.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.127.6]) by ipmail05.adl6.internode.on.net with ESMTP; 27 Sep 2013 13:27:48 +0930 Message-ID: <52450239.7010100@ShaneWare.Biz> Date: Fri, 27 Sep 2013 13:27:45 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: lock order reversal in 10-alpha2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 03:57:50 -0000 After booting from a 10-alpha2 disk I am seeing "lock order reversal" messages show up from time to time. Current logs have 35 entries. The machine normally is running 9.1 from zfs root and I have setup a separate disk (eSATA case connected through backplane port to onboard SATA port) that I have installed 10-alpha amd64 onto a ufs partition to test port building with. I started by building 10 alpha1 and installing onto the new disk. I have since done svn up (last revision is 255868) then rebuilt and installed kernel and world while running 10 and still see these messages. I mentioned the existing 9.1 on zfs which I am not importing while running 10 from ufs as I noticed zfs mentioned in one of the entries. Initially I built with an empty src.conf but the last build I used the following - WITH_BSD_GREP=yes WITH_CLANG_EXTRAS=yes WITH_CTF=yes WITHOUT_LIB32=yes WITH_LLDB=yes Hardware is ASUS P8H61-M LE/USB3 corei5 8GB RAM nvidia GT520 I can provide full copy of log/messages or dmesg if required. A few samples -- messages:Sep 26 02:01:27 leader kernel: lock order reversal: messages-Sep 26 02:01:27 leader kernel: 1st 0xfffffe01eebd07f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 messages-Sep 26 02:01:27 leader kernel: 2nd 0xfffff800122f8200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 messages-Sep 26 02:01:27 leader kernel: KDB: stack backtrace: messages-Sep 26 02:01:27 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0238a8f270 messages-Sep 26 02:01:27 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0238a8f320 messages-Sep 26 02:01:27 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe0238a8f3b0 messages-Sep 26 02:01:27 leader kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe0238a8f3f0 messages-Sep 26 02:01:27 leader kernel: ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfffffe0238a8f430 messages-Sep 26 02:01:27 leader kernel: ufs_direnter() at ufs_direnter+0x688/frame 0xfffffe0238a8f4f0 messages-Sep 26 02:01:27 leader kernel: ufs_makeinode() at ufs_makeinode+0x573/frame 0xfffffe0238a8f6b0 messages-Sep 26 02:01:27 leader kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xfffffe0238a8f6e0 messages-Sep 26 02:01:27 leader kernel: vn_open_cred() at vn_open_cred+0x300/frame 0xfffffe0238a8f830 messages-Sep 26 02:01:27 leader kernel: kern_openat() at kern_openat+0x261/frame 0xfffffe0238a8f9a0 messages-Sep 26 02:01:27 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80185baca, rsp = 0x7fffffffd168, rbp = 0x7fffffffd1a0 --- messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: messages.0-Sep 23 10:08:11 leader kernel: 1st 0xfffff801ba2e65f0 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfffffe01ef93c1c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xfffff801ba2e6240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02397c2300 messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe02397c23b0 messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe02397c2440 messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe02397c2570 messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at ffs_lock+0x84/frame 0xfffffe02397c25c0 messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe02397c25f0 messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at _vn_lock+0xab/frame 0xfffffe02397c2660 messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame 0xfffffe02397c26b0 messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at vfs_hash_get+0xf5/frame 0xfffffe02397c2700 messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at ffs_vgetf+0x41/frame 0xfffffe02397c2790 messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xfffffe02397c2840 messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xfffffe02397c28c0 messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at ffs_fsync+0x20/frame 0xfffffe02397c28f0 messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf0/frame 0xfffffe02397c2920 messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at sys_fsync+0x156/frame 0xfffffe02397c29a0 messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe02397c2ab0 messages.0-Sep 23 10:08:11 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02397c2ab0 messages.0-Sep 23 10:08:11 leader kernel: --- syscall (95, FreeBSD ELF64, sys_fsync), rip = 0x8029a41fa, rsp = 0x7fffffffcf28, rbp = 0x7fffffffcf40 --- messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: messages.0-Sep 23 10:08:11 leader kernel: 1st 0xfffff801ba2e65f0 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfffffe01ef93c1c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xfffff801ba2e6240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02397c2300 messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe02397c23b0 messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe02397c2440 messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe02397c2570 messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at ffs_lock+0x84/frame 0xfffffe02397c25c0 messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe02397c25f0 messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at _vn_lock+0xab/frame 0xfffffe02397c2660 messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame 0xfffffe02397c26b0 messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at vfs_hash_get+0xf5/frame 0xfffffe02397c2700 messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at ffs_vgetf+0x41/frame 0xfffffe02397c2790 messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xfffffe02397c2840 messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xfffffe02397c28c0 messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at ffs_fsync+0x20/frame 0xfffffe02397c28f0 messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf0/frame 0xfffffe02397c2920 messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at sys_fsync+0x156/frame 0xfffffe02397c29a0 messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe02397c2ab0 messages.0-Sep 23 10:08:11 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02397c2ab0 messages.0-Sep 23 10:08:11 leader kernel: --- syscall (95, FreeBSD ELF64, sys_fsync), rip = 0x8029a41fa, rsp = 0x7fffffffcf28, rbp = 0x7fffffffcf40 --- messages.0:Sep 23 10:36:02 leader kernel: lock order reversal: messages.0-Sep 23 10:36:02 leader kernel: 1st 0xfffff801ba9be240 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 messages.0-Sep 23 10:36:02 leader kernel: 2nd 0xfffff801babab7c8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210 messages.0-Sep 23 10:36:02 leader kernel: KDB: stack backtrace: messages.0-Sep 23 10:36:02 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02397ef460 messages.0-Sep 23 10:36:02 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe02397ef510 messages.0-Sep 23 10:36:02 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe02397ef5a0 messages.0-Sep 23 10:36:02 leader kernel: __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe02397ef6d0 messages.0-Sep 23 10:36:02 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe02397ef6f0 messages.0-Sep 23 10:36:02 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe02397ef720 messages.0-Sep 23 10:36:02 leader kernel: _vn_lock() at _vn_lock+0xab/frame 0xfffffe02397ef790 messages.0-Sep 23 10:36:02 leader kernel: vputx() at vputx+0x208/frame 0xfffffe02397ef7f0 messages.0-Sep 23 10:36:02 leader kernel: dounmount() at dounmount+0x327/frame 0xfffffe02397ef870 messages.0-Sep 23 10:36:02 leader kernel: sys_unmount() at sys_unmount+0x356/frame 0xfffffe02397ef9a0 messages.0-Sep 23 10:36:02 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe02397efab0 messages.0-Sep 23 10:36:02 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02397efab0 messages.0-Sep 23 10:36:02 leader kernel: --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191f24a, rsp = 0x7fffffffc3d8, rbp = 0x7fffffffc860 --- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 08:12:32 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 83929DCB for ; Fri, 27 Sep 2013 08:12:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 073FD2A40 for ; Fri, 27 Sep 2013 08:12:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r8R8CQYq027499; Fri, 27 Sep 2013 11:12:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r8R8CQYq027499 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r8R8CLRr027497; Fri, 27 Sep 2013 11:12:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Sep 2013 11:12:21 +0300 From: Konstantin Belousov To: John Marshall Subject: Re: 9.2-RC4 amd64 panic: vm_page_unwire Message-ID: <20130927081221.GK41229@kib.kiev.ua> References: <20130927000728.GB19167@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Osj4Qco9/Oj9hlT0" Content-Disposition: inline In-Reply-To: <20130927000728.GB19167@rwpc15.gfn.riverwillow.net.au> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:12:32 -0000 --Osj4Qco9/Oj9hlT0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2013 at 10:07:28AM +1000, John Marshall wrote: > I'm running 9.2-RC4 on a handful of desktop and server machines (both > i386 and amd64). I have seen three panics (all vm_page_unwire) on one > of those systems only (amd64 server) during the past week. >=20 > The first two panics were triggered when shutting down the ntpd daemon > (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a > later release (p388) has not triggered the panic. The system panicked > again overnight, this time while acting as an sftp server receiving > large (GB) files from another system. >=20 > Fri Sep 20 16:48:34 2013 +1000 > ozsrv04# kgdb kernel.debug /var/crash/vmcore.0 > ... > panic: vm_page_unwire: page 0xfffffe0233510578's wire count is zero > cpuid =3D 3 > KDB: stack backtrace: > #0 0xffffffff80490268 at kdb_backtrace+0x68 > #1 0xffffffff8045630a at panic+0x21a > #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 > #3 0xffffffff80678702 at vm_fault_unwire+0xd2 > #4 0xffffffff80680841 at vm_map_delete+0x171 > #5 0xffffffff80680abf at vm_map_remove+0x5f > #6 0xffffffff80683ee9 at vmspace_exit+0xc9 > #7 0xffffffff8041f3ad at exit1+0x72d > #8 0xffffffff804203ae at sys_sys_exit+0xe > #9 0xffffffff806afd6f at amd64_syscall+0x3bf > #10 0xffffffff8069a817 at Xfast_syscall+0xf7 > Uptime: 2d0h35m3s > =20 > Fri Sep 20 17:49:57 2013 +1000 > ozsrv04# kgdb kernel.debug /var/crash/vmcore.1 > ... > panic: vm_page_unwire: page 0xfffffe022f5fc238's wire count is zero > cpuid =3D 2 > KDB: stack backtrace: > #0 0xffffffff80490268 at kdb_backtrace+0x68 > #1 0xffffffff8045630a at panic+0x21a > #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 > #3 0xffffffff80678702 at vm_fault_unwire+0xd2 > #4 0xffffffff80680841 at vm_map_delete+0x171 > #5 0xffffffff80680abf at vm_map_remove+0x5f > #6 0xffffffff80683ee9 at vmspace_exit+0xc9 > #7 0xffffffff8041f3ad at exit1+0x72d > #8 0xffffffff804203ae at sys_sys_exit+0xe > #9 0xffffffff806afd6f at amd64_syscall+0x3bf > #10 0xffffffff8069a817 at Xfast_syscall+0xf7 > Uptime: 59m51s >=20 > Fri Sep 27 01:51:44 2013 +1000 > ozsrv04# kgdb kernel.debug /var/crash/vmcore.2 > ... > panic: vm_page_unwire: page 0xfffffe0239ecfc48's wire count is zero > cpuid =3D 5 > KDB: stack backtrace: > #0 0xffffffff80490268 at kdb_backtrace+0x68 > #1 0xffffffff8045630a at panic+0x21a > #2 0xffffffff8068bbc2 at vm_page_unwire+0x102 > #3 0xffffffff804d857e at vfs_vmio_release+0x10e > #4 0xffffffff804dadc8 at getnewbuf+0x468 > #5 0xffffffff804dbb2f at getblk+0x5df > #6 0xffffffff80632bb1 at ffs_balloc_ufs2+0x15c1 > #7 0xffffffff8065a8d6 at ffs_write+0x246 > #8 0xffffffff8070a18f at VOP_WRITE_APV+0x11f > #9 0xffffffff80505e77 at vn_write+0x1f7 > #10 0xffffffff80503b51 at vn_io_fault+0xb1 > #11 0xffffffff804a387c at dofilewrite+0x9c > #12 0xffffffff804a3b54 at kern_writev+0x54 > #13 0xffffffff804a3bf5 at sys_write+0x65 > #14 0xffffffff806afd6f at amd64_syscall+0x3bf > #15 0xffffffff8069a817 at Xfast_syscall+0xf7 > Uptime: 6d7h46m14s >=20 > Is this a known problem? Should I file a PR? What additional > information should I provide? >=20 > I have made the core.txt.[0-2] files available in the following > directory. The directory is not browsable. >=20 > http://www.riverwillow.net.au/~john/92rc4/ This might be fixed by r254087-r254090 on stable/9. --Osj4Qco9/Oj9hlT0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSRT3kAAoJEJDCuSvBvK1BB34P/0sSxGYAKiX7YRX8vL0v+ePY kAussXqbVU/b6IXILI/siJbrt4FgxgEzO+SFjwX7w+iOoRm1EOaYgi6w6GcAhAp/ keaIPl+sXUgtDDteW/wBiUCSkJuBi3OSkL0W+yHWDRG5ZfB7vArt0k9FACDYYedJ Vlaxonj1NR0LorI5axOqrsQjClsxgujQIHrWnBEp6G94KHK8kroLgOZqksz28IFe 9u3WWaZx6pXTWzkFzm4N6qtXETs/b9r3i44V+Ye23+IYX74XOOaHTOXGbDDr9/a2 U4R5S9f17H26naf4skShqRJqlh9R7crtWwOSa7BirEj3ojXKiC7hSMgiDYcd8rqM Ebc2HfUkUotdyaI7e+UlIZ9J8PwOOqN5EvR76BqykRtDSAceicCO/n0ley/ZEY0M vNFpr1F28old1WxTe5Zk6rtI5z16X/fI71si/5Sy2NAsz8X02kS3RgoriLLu3AEO c2jsYSeSoj4B/Y5ZtixOnfSv86MOoA9xHnqusoMUd3sNpFJq7j2lSE+FFMoPRYUY xPJ+OHIix1HFVDe9uPuv9E6VHVqkRR2I5gpT5eY6rsIfXhRxYydy38PoXQC5a81T ZV04z9U4yyzWGclPvEknjevDzM3H+Nd3yI2kojzHyEFHJFesFzvpgVhJc0cxrKYC 0EzAwSYXdZbj9xKY3eq4 =B+YX -----END PGP SIGNATURE----- --Osj4Qco9/Oj9hlT0-- From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 08:51:05 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id B90958FF; Fri, 27 Sep 2013 08:51:05 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5BC2C31; Fri, 27 Sep 2013 08:51:04 +0000 (UTC) Received: from [192.168.1.218] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3cmRYX73N6z11G; Fri, 27 Sep 2013 09:50:56 +0100 (BST) Message-ID: <524546ED.5010803@rewt.org.uk> Date: Fri, 27 Sep 2013 09:50:53 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dmitry Morozovsky Subject: Re: FreeBSD 9.1 ix driver vlan problem References: <20130925164053.GB76403@lath.rinet.ru> <20130925183253.GA1315@lath.rinet.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , Jack Vogel , Rumen Telbizov , Jack Vogel , Andree Toonk , Oleg Bulyzhin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:51:05 -0000 On 25/09/2013 22:10, Dmitry Morozovsky wrote: > On Wed, 25 Sep 2013, Rumen Telbizov wrote: > >> Thanks for the heads-up Oleg, although not the news that I was hoping for. >> >> So what I am going to do right now is reinstall with 9.2 and recompile the >> driver with your patch. >> I'll come back to the list with my results. > > FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're welcome > to test this on your 9 > > It's supposedly way too late to try to include this fix into 9.2-R, but maybe > it's worth the errata notice... > > This happens on several other intel chipsets as well, no previous errata was ever noted (legacy em, for example) :( From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 08:59:26 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id CCD77BB5 for ; Fri, 27 Sep 2013 08:59:26 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 26F1E2C99 for ; Fri, 27 Sep 2013 08:59:25 +0000 (UTC) Received: from cpsps-ews03.kpnxchange.com ([10.94.84.170]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 10:58:14 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 10:58:14 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 10:58:14 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 33CED822 for ; Fri, 27 Sep 2013 10:58:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: lock order reversal in 10-alpha2 References: <52450239.7010100@ShaneWare.Biz> Date: Fri, 27 Sep 2013 10:58:14 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <52450239.7010100@ShaneWare.Biz> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 27 Sep 2013 08:58:14.0466 (UTC) FILETIME=[B34B3220:01CEBB5F] X-RcptDomain: freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:59:26 -0000 On Fri, 27 Sep 2013 05:57:45 +0200, Shane Ambler wrote: > After booting from a 10-alpha2 disk I am seeing "lock order reversal" > messages show up from time to time. Current logs have 35 entries. FreeBSD 10-ALPHA is still being build with kernel option WITNESS on. This gives more diagnostics of internal state of the kernel. A lot of these LORs (Lock Order Reverals) should be fixed some day, but are harmless for the continues working of the machine. If you compile FreeBSD 9 with WITNESS on, you will some LORs also. Ronald. > > The machine normally is running 9.1 from zfs root and I have setup a > separate disk (eSATA case connected through backplane port to onboard > SATA port) that I have installed 10-alpha amd64 onto a ufs partition to > test port building with. I started by building 10 alpha1 and installing > onto the new disk. I have since done svn up (last revision is 255868) > then rebuilt and installed kernel and world while running 10 and still > see these messages. > > I mentioned the existing 9.1 on zfs which I am not importing while > running 10 from ufs as I noticed zfs mentioned in one of the entries. > > Initially I built with an empty src.conf but the last build I used the > following - > > WITH_BSD_GREP=yes > WITH_CLANG_EXTRAS=yes > WITH_CTF=yes > WITHOUT_LIB32=yes > WITH_LLDB=yes > > Hardware is ASUS P8H61-M LE/USB3 corei5 8GB RAM nvidia GT520 > > I can provide full copy of log/messages or dmesg if required. > > A few samples -- > > messages:Sep 26 02:01:27 leader kernel: lock order reversal: > messages-Sep 26 02:01:27 leader kernel: 1st 0xfffffe01eebd07f8 bufwait > (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 > messages-Sep 26 02:01:27 leader kernel: 2nd 0xfffff800122f8200 dirhash > (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > messages-Sep 26 02:01:27 leader kernel: KDB: stack backtrace: > messages-Sep 26 02:01:27 leader kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe0238a8f270 > messages-Sep 26 02:01:27 leader kernel: kdb_backtrace() at > kdb_backtrace+0x39/frame 0xfffffe0238a8f320 > messages-Sep 26 02:01:27 leader kernel: witness_checkorder() at > witness_checkorder+0xd23/frame 0xfffffe0238a8f3b0 > messages-Sep 26 02:01:27 leader kernel: _sx_xlock() at > _sx_xlock+0x75/frame 0xfffffe0238a8f3f0 > messages-Sep 26 02:01:27 leader kernel: ufsdirhash_add() at > ufsdirhash_add+0x3b/frame 0xfffffe0238a8f430 > messages-Sep 26 02:01:27 leader kernel: ufs_direnter() at > ufs_direnter+0x688/frame 0xfffffe0238a8f4f0 > messages-Sep 26 02:01:27 leader kernel: ufs_makeinode() at > ufs_makeinode+0x573/frame 0xfffffe0238a8f6b0 > messages-Sep 26 02:01:27 leader kernel: VOP_CREATE_APV() at > VOP_CREATE_APV+0xea/frame 0xfffffe0238a8f6e0 > messages-Sep 26 02:01:27 leader kernel: vn_open_cred() at > vn_open_cred+0x300/frame 0xfffffe0238a8f830 > messages-Sep 26 02:01:27 leader kernel: kern_openat() at > kern_openat+0x261/frame 0xfffffe0238a8f9a0 > messages-Sep 26 02:01:27 leader kernel: amd64_syscall() at > amd64_syscall+0x265/frame 0xfffffe0238a8fab0 > messages-Sep 26 02:01:27 leader kernel: Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe0238a8fab0 > messages-Sep 26 02:01:27 leader kernel: --- syscall (5, FreeBSD ELF64, > sys_open), rip = 0x80185baca, rsp = 0x7fffffffd168, rbp = 0x7fffffffd1a0 > --- > > messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: > messages.0-Sep 23 10:08:11 leader kernel: 1st 0xfffff801ba2e65f0 ufs > (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 > messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfffffe01ef93c1c0 bufwait > (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 > messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xfffff801ba2e6240 ufs > (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 > messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: > messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe02397c2300 > messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at > kdb_backtrace+0x39/frame 0xfffffe02397c23b0 > messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at > witness_checkorder+0xd23/frame 0xfffffe02397c2440 > messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at > __lockmgr_args+0x6f2/frame 0xfffffe02397c2570 > messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at > ffs_lock+0x84/frame 0xfffffe02397c25c0 > messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at > VOP_LOCK1_APV+0xf5/frame 0xfffffe02397c25f0 > messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at > _vn_lock+0xab/frame 0xfffffe02397c2660 > messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame > 0xfffffe02397c26b0 > messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at > vfs_hash_get+0xf5/frame 0xfffffe02397c2700 > messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at > ffs_vgetf+0x41/frame 0xfffffe02397c2790 > messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at > softdep_sync_buf+0x8fa/frame 0xfffffe02397c2840 > messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at > ffs_syncvnode+0x258/frame 0xfffffe02397c28c0 > messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at > ffs_fsync+0x20/frame 0xfffffe02397c28f0 > messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at > VOP_FSYNC_APV+0xf0/frame 0xfffffe02397c2920 > messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at > sys_fsync+0x156/frame 0xfffffe02397c29a0 > messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at > amd64_syscall+0x265/frame 0xfffffe02397c2ab0 > messages.0-Sep 23 10:08:11 leader kernel: Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe02397c2ab0 > messages.0-Sep 23 10:08:11 leader kernel: --- syscall (95, FreeBSD > ELF64, sys_fsync), rip = 0x8029a41fa, rsp = 0x7fffffffcf28, rbp = > 0x7fffffffcf40 --- > > messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: > messages.0-Sep 23 10:08:11 leader kernel: 1st 0xfffff801ba2e65f0 ufs > (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 > messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfffffe01ef93c1c0 bufwait > (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 > messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xfffff801ba2e6240 ufs > (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 > messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: > messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe02397c2300 > messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at > kdb_backtrace+0x39/frame 0xfffffe02397c23b0 > messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at > witness_checkorder+0xd23/frame 0xfffffe02397c2440 > messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at > __lockmgr_args+0x6f2/frame 0xfffffe02397c2570 > messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at > ffs_lock+0x84/frame 0xfffffe02397c25c0 > messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at > VOP_LOCK1_APV+0xf5/frame 0xfffffe02397c25f0 > messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at > _vn_lock+0xab/frame 0xfffffe02397c2660 > messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame > 0xfffffe02397c26b0 > messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at > vfs_hash_get+0xf5/frame 0xfffffe02397c2700 > messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at > ffs_vgetf+0x41/frame 0xfffffe02397c2790 > messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at > softdep_sync_buf+0x8fa/frame 0xfffffe02397c2840 > messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at > ffs_syncvnode+0x258/frame 0xfffffe02397c28c0 > messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at > ffs_fsync+0x20/frame 0xfffffe02397c28f0 > messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at > VOP_FSYNC_APV+0xf0/frame 0xfffffe02397c2920 > messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at > sys_fsync+0x156/frame 0xfffffe02397c29a0 > messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at > amd64_syscall+0x265/frame 0xfffffe02397c2ab0 > messages.0-Sep 23 10:08:11 leader kernel: Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe02397c2ab0 > messages.0-Sep 23 10:08:11 leader kernel: --- syscall (95, FreeBSD > ELF64, sys_fsync), rip = 0x8029a41fa, rsp = 0x7fffffffcf28, rbp = > 0x7fffffffcf40 --- > > messages.0:Sep 23 10:36:02 leader kernel: lock order reversal: > messages.0-Sep 23 10:36:02 leader kernel: 1st 0xfffff801ba9be240 zfs > (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 > messages.0-Sep 23 10:36:02 leader kernel: 2nd 0xfffff801babab7c8 syncer > (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210 > messages.0-Sep 23 10:36:02 leader kernel: KDB: stack backtrace: > messages.0-Sep 23 10:36:02 leader kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe02397ef460 > messages.0-Sep 23 10:36:02 leader kernel: kdb_backtrace() at > kdb_backtrace+0x39/frame 0xfffffe02397ef510 > messages.0-Sep 23 10:36:02 leader kernel: witness_checkorder() at > witness_checkorder+0xd23/frame 0xfffffe02397ef5a0 > messages.0-Sep 23 10:36:02 leader kernel: __lockmgr_args() at > __lockmgr_args+0x6f2/frame 0xfffffe02397ef6d0 > messages.0-Sep 23 10:36:02 leader kernel: vop_stdlock() at > vop_stdlock+0x3c/frame 0xfffffe02397ef6f0 > messages.0-Sep 23 10:36:02 leader kernel: VOP_LOCK1_APV() at > VOP_LOCK1_APV+0xf5/frame 0xfffffe02397ef720 > messages.0-Sep 23 10:36:02 leader kernel: _vn_lock() at > _vn_lock+0xab/frame 0xfffffe02397ef790 > messages.0-Sep 23 10:36:02 leader kernel: vputx() at vputx+0x208/frame > 0xfffffe02397ef7f0 > messages.0-Sep 23 10:36:02 leader kernel: dounmount() at > dounmount+0x327/frame 0xfffffe02397ef870 > messages.0-Sep 23 10:36:02 leader kernel: sys_unmount() at > sys_unmount+0x356/frame 0xfffffe02397ef9a0 > messages.0-Sep 23 10:36:02 leader kernel: amd64_syscall() at > amd64_syscall+0x265/frame 0xfffffe02397efab0 > messages.0-Sep 23 10:36:02 leader kernel: Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe02397efab0 > messages.0-Sep 23 10:36:02 leader kernel: --- syscall (22, FreeBSD > ELF64, sys_unmount), rip = 0x80191f24a, rsp = 0x7fffffffc3d8, rbp = > 0x7fffffffc860 --- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 09:18:43 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 718EC1FF for ; Fri, 27 Sep 2013 09:18:43 +0000 (UTC) (envelope-from amdmiek@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 104852DA7 for ; Fri, 27 Sep 2013 09:18:42 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id c11so2345065wgh.6 for ; Fri, 27 Sep 2013 02:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P6b9G7lGVnWi0UpELSUaAP/i+HUnE3es5dXdvZOwsnM=; b=MuYDSg1vown4Si4Zl5ZzcR2Gn0d8nmPUg+16Pj4cotWQ3wn6VKt2LrjhKOCxRndmWI 61Iqp1uVVNome39Rtcq2zgKkjKCU2NC1gtfNw2Ek8ETAncA5EfgxZ/d1uDlR+zKsIZ+A iBpvjFeesG6xRnLvh07g98hQZJmYUbt/rryiw5dxbJgw7+TTsER8PEVnVDAhNjL7finq 0L/CrnWzOy67EFigNbMxTPcEq0PAANsG/r3x1h+OXz2MWT8+QPpv/pylR/iIBL7rUAtl t2pS3rGNtneIChaxwNdpsa9m2yuFUYjrIk+8Qbclu4tawSDp3f6FirX2WUSAMaymYtV/ q9DQ== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr1060493wjc.42.1380273520914; Fri, 27 Sep 2013 02:18:40 -0700 (PDT) Received: by 10.180.208.43 with HTTP; Fri, 27 Sep 2013 02:18:40 -0700 (PDT) Date: Fri, 27 Sep 2013 13:18:40 +0400 Message-ID: Subject: Running a script via PHP From: Michael BlackHeart To: freebsd-stable Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:18:43 -0000 Hello there, It's quite off-topic, but I'm using freebsd-stable,so The priblem is - running a script that requires root privileges via PHP (or probably CGI - I do not care, just want it to be secure and working). It's all about minidlna service (I use upnp to so mediatomb and other are no options). On FreeBSD it should be resync-ed manually, so I've got a simple script placed in /etc/periodic/daily: more 957.dlna_update #!/bin/sh #Script to daily update minidlna DB a=3D"$*" if (/usr/local/etc/rc.d/minidlna stop 1>/dev/null);then sleep 10 if /usr/local/etc/rc.d/minidlna rescan;then /usr/bin/logger -t minidlna "DB updated." exit 0 else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi else /usr/bin/logger -t minidlna "Error. Failed to update DB." exit 1 fi And it's working fine to me. But it uses service infrastructure. So when I'm trying to run via PHP it fails. For example running under unprivileged user: id uid=3D1001(amd_miek) gid=3D0(wheel) groups=3D0(wheel),5(operator) -rwsr-sr-x 1 root wheel 394 27 =D3=C5=CE 10:58 957.dlna_update* sh -x 957.dlna_update + a=3D'' + /usr/local/etc/rc.d/minidlna stop kill: 10786: Operation not permitted + /usr/bin/logger -t minidlna 'Error. Failed to update DB.' + exit 1 What is the best way to run it via WEB? From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 10:19:32 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id EC8697B1 for ; Fri, 27 Sep 2013 10:19:32 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by mx1.freebsd.org (Postfix) with ESMTP id 63D1B2130 for ; Fri, 27 Sep 2013 10:19:31 +0000 (UTC) Received: from cpsps-ews13.kpnxchange.com ([10.94.84.180]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 12:18:22 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews13.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 12:18:22 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 12:18:22 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id D93D6874 for ; Fri, 27 Sep 2013 12:18:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Running a script via PHP References: Date: Fri, 27 Sep 2013 12:18:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 27 Sep 2013 10:18:22.0421 (UTC) FILETIME=[E50EE850:01CEBB6A] X-RcptDomain: freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 10:19:33 -0000 On Fri, 27 Sep 2013 11:18:40 +0200, Michael BlackHeart = wrote: > Hello there, > It's quite off-topic, but I'm using freebsd-stable,so > > The priblem is - running a script that requires root privileges via PH= P = > (or > probably CGI - I do not care, just want it to be secure and working). > > It's all about minidlna service (I use upnp to so mediatomb and other = are > no options). On FreeBSD it should be resync-ed manually, so I've got a= > simple script placed in /etc/periodic/daily: > > more 957.dlna_update > #!/bin/sh > #Script to daily update minidlna DB > > a=3D"$*" > > if (/usr/local/etc/rc.d/minidlna stop 1>/dev/null);then > sleep 10 > if /usr/local/etc/rc.d/minidlna rescan;then > /usr/bin/logger -t minidlna "DB updated." > exit 0 > else > /usr/bin/logger -t minidlna "Error. Failed to update DB." > exit 1 > fi > else > /usr/bin/logger -t minidlna "Error. Failed to update DB." > exit 1 > fi > > And it's working fine to me. But it uses service infrastructure. So wh= en > I'm trying to run via PHP it fails. For example running under = > unprivileged > user: > > id > uid=3D1001(amd_miek) gid=3D0(wheel) groups=3D0(wheel),5(operator) > > -rwsr-sr-x 1 root wheel 394 27 =D1=81=D0=B5=D0=BD 10:58 957.dlna_updat= e* > > sh -x 957.dlna_update > + a=3D'' > + /usr/local/etc/rc.d/minidlna stop > kill: 10786: Operation not permitted > + /usr/bin/logger -t minidlna 'Error. Failed to update DB.' > + exit 1 > > What is the best way to run it via WEB? You can't setuid a shell script. The executable actually is '/bin/sh' = which just reads the shell script. So you should setuid /bin/sh which is= a = security problem. You can use sudo to do this. (/usr/ports/security/sudo) Ronald. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 13:13:07 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id E138718F for ; Fri, 27 Sep 2013 13:13:07 +0000 (UTC) (envelope-from majo-freebsd-stable@cerny.sk) Received: from mail.cerny.sk (mail.cerny.sk [80.79.31.23]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B6E42C77 for ; Fri, 27 Sep 2013 13:13:07 +0000 (UTC) Received: from [10.0.1.101] (ip-89-176-86-11.net.upcbroadband.cz [89.176.86.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.cerny.sk (Postfix) with ESMTPSA id CF1B32DFAAC for ; Fri, 27 Sep 2013 15:12:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cerny.sk; s=mail; t=1380287579; bh=+Gz1ADfalCFN2k06DH0SEK1GHzNDp2pys+w4ugjQOtg=; h=Subject:From:In-Reply-To:Date:References:To; b=m1AT0P5IGfxabZRFEKdCwxRHk+3YjFasU4oQzB8LYaCtGaVKNCtcqP/m6Iq2ueMpO K2PUxmMM+5cLP2mRHKfATzTk8JhmbPa39LOeznC88lv8/u6eHKlv0U2eDqmvtFYz3R hJV+YTczUXctOm5uCwwd1RqxhVLmEhrC1QSnwb8g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [SOLVED] Only one CPU core detected on Supermicro E3-1240 v3 From: =?utf-8?Q?Mari=C3=A1n_=C4=8Cern=C3=BD?= In-Reply-To: <0EB9861A-8A57-45E3-BBA7-BE7C6EA69B55@cerny.sk> Date: Fri, 27 Sep 2013 15:12:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0EB9861A-8A57-45E3-BBA7-BE7C6EA69B55@cerny.sk> To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:13:07 -0000 Marian Cerny wrote: > I am trying to install FreeBSD 9.2-RC4 on Supermicro server with Intel = Xeon E3-1240 v3 processor. The processor has 4 cores with 8 threads. = However only one core is detected (with two threads): >=20 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >=20 > The motherboard is Supermicro X10SLM-F. All cores are enabled in BIOS = and the latest firmware is installed (version 1.1a, Build Date = 08/20/2013). I have contacted Supermicro support and they have advised me to flash = the latest BIOS but set the JPME2 jumper (Manufacturing Mode Select) and = move it back after flashing. Now the all the cores are detected: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads Marian= From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 21:50:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 56D87399 for ; Fri, 27 Sep 2013 21:50:17 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from st11p05mm-asmtp002.mac.com (st11p05mm-asmtpout005.mac.com [17.172.108.250]) by mx1.freebsd.org (Postfix) with ESMTP id 2F80D2CE9 for ; Fri, 27 Sep 2013 21:50:16 +0000 (UTC) Received: from [17.198.198.221] (unknown [17.198.198.221]) by st11p05mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTT003C30NEW6B0@st11p05mm-asmtp002.mac.com> for freebsd-stable@freebsd.org; Fri, 27 Sep 2013 21:50:04 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-27_09:2013-09-27,2013-09-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309270136 Content-type: text/plain; charset=koi8-r MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Running a script via PHP From: Charles Swiger In-reply-to: Date: Fri, 27 Sep 2013 14:50:02 -0700 Content-transfer-encoding: quoted-printable Message-id: <58E65D87-C41C-4777-9EAA-005CE3506B6A@mac.com> References: To: Michael BlackHeart X-Mailer: Apple Mail (2.1510) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:50:17 -0000 Hi-- On Sep 27, 2013, at 2:18 AM, Michael BlackHeart = wrote: > Hello there, > It's quite off-topic, but I'm using freebsd-stable,so >=20 > The priblem is - running a script that requires root privileges via = PHP (or > probably CGI - I do not care, just want it to be secure and working). Unfortunately the combination of PHP, doing something which needs root, = and security are inherently contradictory. The least risky approach would be to invoke the needed command via sudo, = or=20 possibly a small setuid-root C wrapper program which launches only the = needed script with root permissions. Use sudo unless your C wrapper is careful enough = to use exec() and not system(), sanitizes $PATH and other env variables, and = guards against games with $IFS, shell metachars, and such. Regards, --=20 -Chuck From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 22:06:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id DB085888 for ; Fri, 27 Sep 2013 22:06:17 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 755372DAF for ; Fri, 27 Sep 2013 22:06:17 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hm2so1486194wib.0 for ; Fri, 27 Sep 2013 15:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/86ndMMEwl/saWPjj53zWJk0KHylkVV8KwFTX6W2SJE=; b=wSrV+nHt1/RoczdeSXYFohfO1+cWFSf8RxP4lUppd8ZgmLKMCo8thdofxl0DpiowIH CLIUg90CNrVwZsr1IuEwQ3CB3xpnpuxevPT+p6xVqTV1RVXGRdqOHscg7ub1D5j7RDpb UgyCZkxtKZPTwGWrcP3ZShkvVNVF1SGSvJk3KD1dTeAHoltTv6yuCioJf0mcBblFsmJw HZwQMwJtmQaoTgG0jJgiUenF6fZHllI7PKSjLqFARzTPptOkO9ubLSEkNNrLj75meAU+ EKFt/vB5GT5+nJ446lPDFbkj+Yds/v+0xQOg/U5XCSm1w7zw22K5yt3HQKUw4vMCF7Yd plgA== X-Received: by 10.180.206.244 with SMTP id lr20mr4296608wic.45.1380319575948; Fri, 27 Sep 2013 15:06:15 -0700 (PDT) Received: from [192.168.0.10] (171.33.91.91.rev.sfr.net. [91.91.33.171]) by mx.google.com with ESMTPSA id j5sm339150wia.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 15:06:15 -0700 (PDT) Message-ID: <5246014B.70908@gmail.com> Date: Sat, 28 Sep 2013 00:06:03 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> In-Reply-To: <523D7784.30002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:06:17 -0000 On 21.09.2013 12:40, Matthew Seaman wrote: > On 21/09/2013 11:31, O. Hartmann wrote: >> I'd like to switch off this silly "Nakatomi Socrates" message which >> reminds me on Linux and their childish naming schemes. >> >> It is only cosmetics, but it bothers me whenever I switch on the laptop. >> >> I guess there is a switch already prsent to have in the bootloader >> config? > > It's turned off by default in more recent 9.2-STABLE > > Otherwise: > > loader_logo="orb" > > in /boot/loader.conf -- see loader.conf(5) > > Cheers, > > Matthew > Hi, I have loader_logo="orb" and I still have a message at the right bottom with that stupid joke. It's really pisses me off *now*. I already said it was okay to add a new logo for that stupid joke. But now, I have orb set and I still see that in my bootloader. How can I disable this forever ?! Also in the future you can just forgot that crappy ideas as you can see, nobody liked it. David. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 22:13:32 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 5F4D7A8F; Fri, 27 Sep 2013 22:13:32 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29A832E15; Fri, 27 Sep 2013 22:13:31 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id r8RMDT5D020605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Sep 2013 17:13:30 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Fri, 27 Sep 2013 17:12:47 -0500 From: "Teske, Devin" To: David Demelier Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Topic: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Index: AQHOu86y/8NXTSuq9021mqWuVE4/QA== Date: Fri, 27 Sep 2013 22:12:47 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> In-Reply-To: <5246014B.70908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <899D89D4FAE55F48BC520E7A937E4596@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_09:2013-09-27,2013-09-27,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-stable stable , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:13:32 -0000 On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > On 21.09.2013 12:40, Matthew Seaman wrote: >> On 21/09/2013 11:31, O. Hartmann wrote: >>> I'd like to switch off this silly "Nakatomi Socrates" message which >>> reminds me on Linux and their childish naming schemes. >>>=20 >>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>=20 >>> I guess there is a switch already prsent to have in the bootloader >>> config? >>=20 >> It's turned off by default in more recent 9.2-STABLE >>=20 >> Otherwise: >>=20 >> loader_logo=3D"orb" >>=20 >> in /boot/loader.conf -- see loader.conf(5) >>=20 >> Cheers, >>=20 >> Matthew >>=20 >=20 > Hi, >=20 > I have loader_logo=3D"orb" and I still have a message at the right bottom > with that stupid joke. >=20 I already responded to this once. loader_version=3D"" See version.4th(8). > It's really pisses me off *now*. Why *now*? I already answered this... (link to archives below) http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html If you say that you tried this and it didn't work, then by all means... come back (pissed off or not) and we'll debug the situation. The person that recommended loader_logo was incorrectly thinking you were talking about the ARTWORK that you get by default in RC1-RC3 which is now non-default (requiring loader_logo=3D"tribute" to enable beyond RC3). The "named releases" however are staying enabled by default. And as I answered in the archives... loader_version=3D"whatever you want to name your release" or loader_version=3D"" is how you customize the text which seems to piss you off so much. > I already said it was okay to add a new > logo for that stupid joke. But now, I have orb set and I still see that > in my bootloader. >=20 > How can I disable this forever ?! >=20 http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html > Also in the future you can just forgot that crappy ideas as you can see, > nobody liked it. >=20 Uh... I'm ignoring that. --=20 Devin P.S. You're not winning any friends here. We answered your question and you came back hostile. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 22:32:14 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 1042D12B; Fri, 27 Sep 2013 22:32:14 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D09412EEA; Fri, 27 Sep 2013 22:32:13 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r8RMWCEM013627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Sep 2013 17:32:12 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Fri, 27 Sep 2013 17:32:11 -0500 From: "Teske, Devin" To: David Demelier Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Topic: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Index: AQHOu9Fo/8NXTSuq9021mqWuVE4/QA== Date: Fri, 27 Sep 2013 22:32:10 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC01C3B@LTCFISWMSGMB21.FNFIS.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> In-Reply-To: <5246014B.70908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <9240207F104297409AE5D51FF40CE0CB@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_09:2013-09-27,2013-09-27,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:32:14 -0000 On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > On 21.09.2013 12:40, Matthew Seaman wrote: >> On 21/09/2013 11:31, O. Hartmann wrote: >>> I'd like to switch off this silly "Nakatomi Socrates" message which >>> reminds me on Linux and their childish naming schemes. >>>=20 >>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>=20 >>> I guess there is a switch already prsent to have in the bootloader >>> config? >>=20 >> It's turned off by default in more recent 9.2-STABLE >>=20 >> Otherwise: >>=20 >> loader_logo=3D"orb" >>=20 >> in /boot/loader.conf -- see loader.conf(5) >>=20 >> Cheers, >>=20 >> Matthew >>=20 >=20 > Hi, >=20 > I have loader_logo=3D"orb" and I still have a message at the right bottom > with that stupid joke. >=20 "Named Releases" is far from a joke. Maybe you'd like something a bit more boring like "9.2-RELEASE" The fact is... there is (and only ever will be) one iteration of FreeBSD 9.= 2. I assume that you have had no clue up until this point that there was yet another BSD 9.2. A fictitious version of BSD in a 1980's film, named... Nakatomi Socrates Yeah, we could have decided to let the opportunity pass; to show that we're the first BSD to ever hit 9.2 out of all the flavors, producing the first e= ver non-fictitious BSD 9.2... But where would the fun be in that? Rest assured... I've not seen *any* hollywood films with a number higher than 9.2... so our future looks pretty darn boring. The "name" for 10.0-RELEASE could very well be NULL or boring ol' 10.0-RELEASE But one thing is clear. There is a real tangible benefit to seeing the version on the boot screen. As we move to integrate BE's into the Forth boot screen, it may become paramount to know what version of loader(8) you're using. So please try not to be so judge-mental about these things. This is a real tangible improvement and simply because you've heard that those crazy people in Linux-land are naming their releases... That had zero bearing on why we did it. We may never name another release ever again. I personally would like to see loader(8) set the value to include an SVN re= vision so that everytime you rebuild loader(8), the version info updates; displayed prominently in the bottom right corner (which of course... you'll again be = free to override it if you don't like it... just as you are free to completely disa= ble the entire menu by adding beastie_disable=3DYES to loader.conf(8)). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 22:57:18 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 2C9D68FF; Fri, 27 Sep 2013 22:57:18 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 960072069; Fri, 27 Sep 2013 22:57:17 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id cb5so1480752wib.1 for ; Fri, 27 Sep 2013 15:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V7dOf0cQ41lpJLdc0ALx8H+3VBbf6onPeZLJjRD24gQ=; b=jHhsacOHolRa8GBp+fqeQA30T4Wa52U0GKyO9RA2Q7nXifoO/doiHKe/d3kBD6wKGd Jl4VGX2F84AWuLgKzPVaGM6+3OsCw2rDDNBqWhQYtMUT3rT1YngqP3jTZoKfhw+RDPT3 UdVt1vTtbOFKejkHGLuRtLQGLP9Dd0cmFytOMdlhqLPC1PFK9OakfZiAkKKJOPeMD68E bjAYZUDCQY3drSpMP/R0+JNN+mfzRkWZ6VeJweu1WhZzr8QEGcolzWh040vXcfr+3kab htYJri4RP0SePHnaSvkP1gDKXXPo/BueM3KmmGc1S5Cp4vazA/MgUfkLoC3eJZLXClZz jjaw== X-Received: by 10.180.185.10 with SMTP id ey10mr4500365wic.29.1380322635885; Fri, 27 Sep 2013 15:57:15 -0700 (PDT) Received: from [192.168.0.10] (171.33.91.91.rev.sfr.net. [91.91.33.171]) by mx.google.com with ESMTPSA id i8sm736128wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 15:57:15 -0700 (PDT) Message-ID: <52460D3F.304@gmail.com> Date: Sat, 28 Sep 2013 00:57:03 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: Devin Teske Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:57:18 -0000 On 28.09.2013 00:12, Teske, Devin wrote: > > On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > >> On 21.09.2013 12:40, Matthew Seaman wrote: >>> On 21/09/2013 11:31, O. Hartmann wrote: >>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>> reminds me on Linux and their childish naming schemes. >>>> >>>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>> >>>> I guess there is a switch already prsent to have in the bootloader >>>> config? >>> >>> It's turned off by default in more recent 9.2-STABLE >>> >>> Otherwise: >>> >>> loader_logo="orb" >>> >>> in /boot/loader.conf -- see loader.conf(5) >>> >>> Cheers, >>> >>> Matthew >>> >> >> Hi, >> >> I have loader_logo="orb" and I still have a message at the right bottom >> with that stupid joke. >> > > I already responded to this once. > > loader_version="" > > See version.4th(8). > > >> It's really pisses me off *now*. > > Why *now*? I already answered this... (link to archives below) > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html > > If you say that you tried this and it didn't work, then by all means... > come back (pissed off or not) and we'll debug the situation. > I already asked a few weeks ago what was this strange artwork on my boot loader and I was told to use loader_logo to completely disable it. I've first said that it's funny but I would not recommend to enable it by default because it's really not serious and the artwork was really immature in the scope of the FreeBSD project. Then I was "happy" because I get my orb as usual. And today, I've updated to 9.2-RELEASE SVN tag and saw there was again a message about this stupid "Nakatomi Socrates" version in green. So I needed to check again *why* this has been enabled by default and that's why it was starting to get my nerves. I personally think (but you may totally disagree with) that an operating system *is* an operating system. And I really hate easter eggs or anything else not serious being integrated into the system. I think about a new user installing FreeBSD 9.2, I would not imagine his reaction front of this kind of "tribute" or whatever you call that. For me it stands for "that's not serious, it looks like a toy". Fortunately now it's just a "version" but I would really not imagine when the screen was looking with the "tribute" loader_logo. Seriously, I don't understand why people waste time to create jokes like that instead of working on serious issues. You may think I'm putting to much significance on this kind of matter but I like (and I'm not the only one) serious, clean things. And the real reason that made me yell like that was that I needed to ask / complain a second time to remove that "tribute" thing again. > The person that recommended loader_logo was incorrectly thinking you > were talking about the ARTWORK that you get by default in RC1-RC3 which > is now non-default (requiring loader_logo="tribute" to enable beyond RC3). > > The "named releases" however are staying enabled by default. > > And as I answered in the archives... > > loader_version="whatever you want to name your release" > > or > > loader_version="" > > is how you customize the text which seems to piss you off so much. > Thanks. > > >> I already said it was okay to add a new >> logo for that stupid joke. But now, I have orb set and I still see that >> in my bootloader. >> >> How can I disable this forever ?! >> > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-September/075260.html > > >> Also in the future you can just forgot that crappy ideas as you can see, >> nobody liked it. >> > > Uh... I'm ignoring that. > Check again in the lists, I'm not the only one complaining on that. From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 23:01:12 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 75666A39; Fri, 27 Sep 2013 23:01:12 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEF6E20BA; Fri, 27 Sep 2013 23:01:11 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t60so3379069wes.28 for ; Fri, 27 Sep 2013 16:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZpmxYv+1W0VQlN7/kUh8Zjdk5nin9j6HDttT5ECkNb0=; b=lEyYymrYAw0UbnGlAWrmxf0vB13tBS3Wc8W8q+cCId9eNPtatwBb9I6oxSepJ7P08M ZLpElZvWUGQfiDg915G39uNYAs58j7gI0z6GuXGvNmCe05p2MPMKv+dq/0oarva+Xp3q 67SD6rfy8kEtUKbeUiD9KSvhdWAGDM6hYHtZEdShvDEkk4Psu7yXel2xOUWQ3RPwWRzS Li6WjzlQ+9xoYPHykT7WedTihhbkpw4UYTuyqhifA8E2ObZkN1haM250FdKK0heh/U5j 8zkUaLxdJlFb05NDubQYo4mjfbhOj5rdo68sGjKKYcHxK0TR45E295pMA9V3MQdha1// 27sQ== X-Received: by 10.180.9.41 with SMTP id w9mr4500245wia.21.1380322870349; Fri, 27 Sep 2013 16:01:10 -0700 (PDT) Received: from [192.168.0.10] (171.33.91.91.rev.sfr.net. [91.91.33.171]) by mx.google.com with ESMTPSA id fz8sm765615wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 16:01:10 -0700 (PDT) Message-ID: <52460E2A.3090603@gmail.com> Date: Sat, 28 Sep 2013 01:00:58 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130830 Thunderbird/17.0.8 MIME-Version: 1.0 To: Devin Teske Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01C3B@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC01C3B@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 23:01:12 -0000 On 28.09.2013 00:32, Teske, Devin wrote: > > On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > >> On 21.09.2013 12:40, Matthew Seaman wrote: >>> On 21/09/2013 11:31, O. Hartmann wrote: >>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>> reminds me on Linux and their childish naming schemes. >>>> >>>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>> >>>> I guess there is a switch already prsent to have in the bootloader >>>> config? >>> >>> It's turned off by default in more recent 9.2-STABLE >>> >>> Otherwise: >>> >>> loader_logo="orb" >>> >>> in /boot/loader.conf -- see loader.conf(5) >>> >>> Cheers, >>> >>> Matthew >>> >> >> Hi, >> >> I have loader_logo="orb" and I still have a message at the right bottom >> with that stupid joke. >> > > "Named Releases" is far from a joke. > > Maybe you'd like something a bit more boring like "9.2-RELEASE" > > The fact is... there is (and only ever will be) one iteration of FreeBSD 9.2. > > I assume that you have had no clue up until this point that there was yet > another BSD 9.2. A fictitious version of BSD in a 1980's film, named... > > Nakatomi Socrates Yes I know that, I've already seen the image a lot a few weeks ago. > > Yeah, we could have decided to let the opportunity pass; to show that we're > the first BSD to ever hit 9.2 out of all the flavors, producing the first ever > non-fictitious BSD 9.2... > > But where would the fun be in that? > FreeBSD is not Linux, I (and again, I'm not the only one) thought the idea of naming Linux 3.11 "Linux for workgroups" very stupid. In the Linux world we like to add funny messages / easter eggs directly in the kernel source, but I think this silly and not serious. So I don't really want to bring these Linux manners into our FreeBSD world. > Rest assured... I've not seen *any* hollywood films with a number higher > than 9.2... so our future looks pretty darn boring. > > The "name" for 10.0-RELEASE could very well be NULL or boring ol' > > 10.0-RELEASE > > But one thing is clear. > > There is a real tangible benefit to seeing the version on the boot screen. > > As we move to integrate BE's into the Forth boot screen, it may become > paramount to know what version of loader(8) you're using. > > So please try not to be so judge-mental about these things. > > This is a real tangible improvement and simply because you've heard > that those crazy people in Linux-land are naming their releases... > > That had zero bearing on why we did it. We may never name another release > ever again. > > I personally would like to see loader(8) set the value to include an SVN revision > so that everytime you rebuild loader(8), the version info updates; displayed > prominently in the bottom right corner (which of course... you'll again be free to > override it if you don't like it... just as you are free to completely disable the > entire menu by adding beastie_disable=YES to loader.conf(8)). > From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 23:26:20 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 340D5D4; Fri, 27 Sep 2013 23:26:20 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8494E21DF; Fri, 27 Sep 2013 23:26:19 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ev20so2692598lab.39 for ; Fri, 27 Sep 2013 16:26:17 -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=trPVCMHz5fZKva76fm3ppIS5TnwPf770fGtsyS2zTD4=; b=IBRwobZDRjj4Wjsy5TyLV1vQbGU0jK9LN1vsS7cqdI2KaZlc3VnMHVYNHGT6hIkp7X Awj6IyMEnxw45gJMDYVJoHMt64hoTROQIugr54VbngyjwuF5ypsOK44eQNRO4wDg8olm 1kk6iNo3LeWGwhMfPYVcykGWq2CVQQVRZuePduahrZkEa+yosEnjKjef9JRGz67YFOMS PePZOmAg3nVuIUjPdH/HhzH12WhwfX4eq79ZO0SFAbkVrJ5lHWjfgTFAc/r2p0XdAHOW F0CEzBgtrP/zFnFA97imhRKD7o1W3iXpxEZMPecuA9FZRhqi8Xa+vyRlYDphE4sDoVH+ kM0Q== X-Received: by 10.112.143.3 with SMTP id sa3mr10586257lbb.12.1380324377355; Fri, 27 Sep 2013 16:26:17 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.138.227 with HTTP; Fri, 27 Sep 2013 16:25:56 -0700 (PDT) In-Reply-To: <52460D3F.304@gmail.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> From: Royce Williams Date: Fri, 27 Sep 2013 15:25:56 -0800 X-Google-Sender-Auth: eyRZ0dRXzGo6OvvzjzKlQ5_QioM Message-ID: Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" To: David Demelier Content-Type: text/plain; charset=ISO-8859-1 Cc: Devin Teske , freebsd-stable stable , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 23:26:20 -0000 On Fri, Sep 27, 2013 at 2:57 PM, David Demelier wrote: > > >> I have loader_logo="orb" and I still have a message at the right bottom > >> with that stupid joke. I know that you're passionate about this topic, but if you could drop the subjective parts and focus on the facts, that would be more constructive. > Seriously, I don't understand why people waste time to create jokes like > that instead of working on serious issues. Because we're not robots. We need to occasionally shift gears to avoid burning out. Taking a break to do something playful can actually improve overall productivity. Especially if you're pushing hard to get a world-class OS out the door in your copious free time. > >> Also in the future you can just forgot that crappy ideas as you can see, > >> nobody liked it. I actually thought that it was pretty cool. It may have needed an easier off switch, but I think that it was harmless. > Check again in the lists, I'm not the only one complaining on that. This depends on which lists. I'm not the only one who thought it was cool. People were passing it around and appreciating the reference. I'm honestly mystified by the backlash on this. Did people panic because they thought they'd been hacked? If so, future logo humor could be adjusted to account for this. I understand leaving out true code-based easter eggs, to keep code clean and simple. But this was a humorous logo change for an alpha release. It seems harmless to me. Royce From owner-freebsd-stable@FreeBSD.ORG Fri Sep 27 23:33:45 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id A764930F; Fri, 27 Sep 2013 23:33:45 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6965A2245; Fri, 27 Sep 2013 23:33:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r8RNXhPT007281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Sep 2013 18:33:43 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Fri, 27 Sep 2013 18:33:43 -0500 From: "Teske, Devin" To: David Demelier Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Topic: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Thread-Index: AQHOu86y/8NXTSuq9021mqWuVE4/QA== Date: Fri, 27 Sep 2013 23:33:42 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> In-Reply-To: <52460D3F.304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F74D2F6F9853544A4218F1F79C4766E@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_09:2013-09-27,2013-09-27,1970-01-01 signatures=0 Cc: Devin Teske , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 23:33:45 -0000 On Sep 27, 2013, at 3:57 PM, David Demelier wrote: > On 28.09.2013 00:12, Teske, Devin wrote: >>=20 >> On Sep 27, 2013, at 3:06 PM, David Demelier wrote: >>=20 >>> On 21.09.2013 12:40, Matthew Seaman wrote: >>>> On 21/09/2013 11:31, O. Hartmann wrote: >>>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>>> reminds me on Linux and their childish naming schemes. >>>>>=20 >>>>> It is only cosmetics, but it bothers me whenever I switch on the lapt= op. >>>>>=20 >>>>> I guess there is a switch already prsent to have in the bootloader >>>>> config? >>>>=20 >>>> It's turned off by default in more recent 9.2-STABLE >>>>=20 >>>> Otherwise: >>>>=20 >>>> loader_logo=3D"orb" >>>>=20 >>>> in /boot/loader.conf -- see loader.conf(5) >>>>=20 >>>> Cheers, >>>>=20 >>>> Matthew >>>>=20 >>>=20 >>> Hi, >>>=20 >>> I have loader_logo=3D"orb" and I still have a message at the right bott= om >>> with that stupid joke. >>>=20 >>=20 >> I already responded to this once. >>=20 >> loader_version=3D"" >>=20 >> See version.4th(8). >>=20 >>=20 >>> It's really pisses me off *now*. >>=20 >> Why *now*? I already answered this... (link to archives below) >>=20 >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/pi= permail/freebsd-stable/2013-September/075260.html&k=3D%2FbkpAUdJWZuiTILCq%2= FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3D= z7tFMIIWxpbu4NUJ6O%2BFBM29y7x%2BpF%2Bsj9kfA1f0JxU%3D%0A&s=3Df2e6eb61a04c40d= b454a365487d050393168dfb0d53318972e79c38283de3a50 >>=20 >> If you say that you tried this and it didn't work, then by all means... >> come back (pissed off or not) and we'll debug the situation. >>=20 >=20 > I already asked a few weeks ago what was this strange artwork on my boot > loader and I was told to use loader_logo to completely disable it. >=20 > I've first said that it's funny but I would not recommend to enable it > by default because it's really not serious and the artwork was really > immature in the scope of the FreeBSD project. >=20 > Then I was "happy" because I get my orb as usual. And today, I've > updated to 9.2-RELEASE SVN tag and saw there was again a message about > this stupid "Nakatomi Socrates" version in green. So I needed to check > again *why* this has been enabled by default and that's why it was > starting to get my nerves. >=20 The artwork and the name are separate. The artwork is an RC/Beta easter-egg that disappears at release time. The ability to display a loader_version however stays. > I personally think (but you may totally disagree with) that an operating > system *is* an operating system. And I really hate easter eggs or > anything else not serious being integrated into the system. I think > about a new user installing FreeBSD 9.2, I would not imagine his > reaction front of this kind of "tribute" or whatever you call that. For > me it stands for "that's not serious, it looks like a toy". >=20 Only people downloading an RC or a BETA will see the artwork. This very well could: 1. Drive more people to test RC/BETA cycles 2. Not be an impact to anybody because serious people don't deploy RC or BETA builds to an enterprise. 3. It makes it very clear when you're using an RC or a BETA versus final > Fortunately now it's just a "version" but I would really not imagine > when the screen was looking with the "tribute" loader_logo. >=20 Some folks have told me that they've permanently enabled the artwork. Not everybody that uses FreeBSD uses it in a corporate setting. Naturally, those in a corporate setting will be thankful that final releases won't ever enable a tribute artwork by-default. > Seriously, I don't understand why people waste time to create jokes like > that instead of working on serious issues. >=20 Actually... I flip that on its head. If you work seriously on serious issues long enough... you'll become burned- out. Let me just come right out and say it... I coded it. And after 8 years of "always serious" coding on "always serious" projects h= as made me a dull boy. This little mini-project gave me something to work on t= hat lifted my spirits. > You may think I'm putting to much significance on this kind of matter > but I like (and I'm not the only one) serious, clean things. >=20 Well, maybe the middle ground is that the code is a "seriously clean" thing. It may not be "serious" but it is indeed "seriously clean." Cleanliness allows you to add two lines to loader.conf(5) to kill it: loader_logo=3D"orb" loader_version=3D"" But if you look closer, you'll see that it's really designed to give you or= anybody else a way to brand the OS. PC-BSD changes brand.4th(8) So does NuOS -- self-purported "FreeBSD Distro" (not fork, distro) At $work, we change beastie.4th(8) and brand.4th(8) The tribute -- disabled by default -- could be yet another entry-point for = corporate customers to brand their boxen for customers. Example? Leaving brand.4th(8) alone and just adding a set of tribute functions to pr= oduce the custom boot screen if-and-ony-if loader_logo=3Dtribute. If NuOS had done that... I think it would have been a bit more professional= looking because a tribute screen can completely re-position elements of the screen whereas they only changed the orb artwork and left everything else the same. So... Despite the fact that it may have started out as something less-serious to = work on (giving me a break from nearly a decade of hard [serious] work), it is desi= gned to be an entry-point for many things -- not just "kidding around". Now... You wouldn't want to go telling everybody that works for an *OS* for a deca= de or more... "Thou shalt never stray from the path of being uber-serious!" Come on... Let us have some fun every now and then. Because when we do have fun... we often find ways of turning that functiona= lity into something great (like the ability to use this for a custom boot screen in a= fork or distro). I agree with you that operating systems are supposed to be serious... but w= hat about the operating systems where the volunteers are dedicating double-digit year= s of their life to a single project? FreeBSD has a *lot* of those people. And I would be sad if they didn't have= a chance to have some fun every now and then. > And the real reason that made me yell like that was that I needed to ask > / complain a second time to remove that "tribute" thing again. >=20 Well, I don't think you're going to get the Nakatomi Socrates name removed from the final 9.2-RELEASE. After all... how else are people going to know that there's loader_logo=3Dt= ribute to play with? *smiles* To be honest? I started coding the ability to add a *version* to the bottom of the boot s= creen so many years ago I can't even remember. However... the commit logs show that I added this ability back in 9.0-RELEASE. Here we are at 9.2-RELEASE and we're just now starting to use it. It was *NOT* originally designed to display a *name* but instead a *version= *. See "man version.4th" for the full details. However... I lagged on getting the modifications into loader(8)'s C code th= at would actually export the $loader_version variable. In reality, if you go back to 9.0-RELEASE and add loader_version to loader.= conf it will display the value you set. A cabal approached me about re-purposing it to display a name. So you see... with respect to displaying text at the bottom right of the bo= ot screen, ... we didn't have to code *anything*. It was an unused feature slated for = version- info (which *still* can be implemented... I'm just [as you say] working ser= iously on too many other serious projects to get that in). >> The person that recommended loader_logo was incorrectly thinking you >> were talking about the ARTWORK that you get by default in RC1-RC3 which >> is now non-default (requiring loader_logo=3D"tribute" to enable beyond R= C3). >>=20 >> The "named releases" however are staying enabled by default. >>=20 >> And as I answered in the archives... >>=20 >> loader_version=3D"whatever you want to name your release" >>=20 >> or >>=20 >> loader_version=3D"" >>=20 >> is how you customize the text which seems to piss you off so much. >>=20 >=20 > Thanks. >=20 >>=20 >>=20 >>> I already said it was okay to add a new >>> logo for that stupid joke. But now, I have orb set and I still see that >>> in my bootloader. >>>=20 >>> How can I disable this forever ?! >>>=20 >>=20 >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/pi= permail/freebsd-stable/2013-September/075260.html&k=3D%2FbkpAUdJWZuiTILCq%2= FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3D= z7tFMIIWxpbu4NUJ6O%2BFBM29y7x%2BpF%2Bsj9kfA1f0JxU%3D%0A&s=3Df2e6eb61a04c40d= b454a365487d050393168dfb0d53318972e79c38283de3a50 >>=20 >>=20 >>> Also in the future you can just forgot that crappy ideas as you can see, >>> nobody liked it. >>>=20 >>=20 >> Uh... I'm ignoring that. >>=20 >=20 > Check again in the lists, I'm not the only one complaining on that. I'm on 13 lists, and this thread is the only one that I can see where any c= omplaint has been lodged. Of course... I imagine that the cabal that commissioned the tribute kept me= sheltered from those that would underride my fervor to code the beast. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 00:04:57 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 8C1046DF for ; Sat, 28 Sep 2013 00:04:57 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B49F2388 for ; Sat, 28 Sep 2013 00:04:56 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r8S04OnV005337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Sep 2013 10:04:44 +1000 Message-ID: <52461D08.3070806@swin.edu.au> Date: Sat, 28 Sep 2013 10:04:24 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> In-Reply-To: <5246014B.70908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 00:04:57 -0000 On 09/28/2013 08:06, David Demelier wrote: [..] > Also in the future you can just forgot that crappy ideas as you can see, > nobody liked it. I beg to differ. cheers, gja From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 00:18:15 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 6B07188E for ; Sat, 28 Sep 2013 00:18:15 +0000 (UTC) (envelope-from mauzo@anubis.morrow.me.uk) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 469192400 for ; Sat, 28 Sep 2013 00:18:14 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-169-240-104.range86-169.btcentralplus.com [86.169.240.104]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 9D4FD450B3 for ; Sat, 28 Sep 2013 00:09:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 9D4FD450B3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1380326981; bh=iL9mkHBDDTDNHpgCCPWHoUpY9DAudzx2i6Yw4fQg15U=; h=Date:From:To:Subject:References:In-Reply-To; b=g5aCFy9XVWtlf+GXcNLRynrylarKk5t0my8KA9m70oWVk2Os3P3IEpxWopuWSyK72 QYphiAY+hYiXFyOb0vmCB0PMZoY2/vThJZ7TTpFeMXVyvTwRoIVG/d9qJTELGcx8ah zTHZj3wnDWf75xccAFCXAD9OAVog4SswQMEcVvdA= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id E533FDD80; Sat, 28 Sep 2013 01:09:35 +0100 (BST) Date: Sat, 28 Sep 2013 01:09:35 +0100 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Message-ID: <20130928000930.GA42145@anubis.morrow.me.uk> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52460D3F.304@gmail.com> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 00:18:15 -0000 Quoth David Demelier : > > I personally think (but you may totally disagree with) that an operating > system *is* an operating system. And I really hate easter eggs or > anything else not serious being integrated into the system. I think > about a new user installing FreeBSD 9.2, I would not imagine his > reaction front of this kind of "tribute" or whatever you call that. For > me it stands for "that's not serious, it looks like a toy". Personally I thoroughly approve of a joke every now and then, as long as it doesn't get out of hand. It reassures me there are actual human people working on this who care about what they're doing, rather than some faceless humourless corporation only interested in profit margins. This in turn reassures me that standards will be kept high and bugs will be taken seriously, because that's what people who care do. > Fortunately now it's just a "version" but I would really not imagine > when the screen was looking with the "tribute" loader_logo. While I like the idea of release names in general, I think it's important not to make them more prominent than the real version numbers. I've had to deal with Ubuntu users (I know very little about Ubuntu) in other open-source contexts, and they tend to talk about 'hardy heron' or 'constipated koala' or what-have-you, which just leaves me thinking 'yes, but which is *more recent*?'. So I might rather the default version string was something more like 'FreeBSD 9.2-RELEASE (Nakatomi Socrates)'. Ben From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 02:14:03 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 98B70830 for ; Sat, 28 Sep 2013 02:14:03 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BA622808 for ; Sat, 28 Sep 2013 02:14:03 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id s14so2366433qeb.8 for ; Fri, 27 Sep 2013 19:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qA8dLMaZGjxCgOyyS1jZZ5hh7SY9nNrediQJ0msdWuk=; b=IrPZ2DuNbWLnkSeLrH2VQyjymDDse6YLxbJx0obuTm8LomTOGprYtlMBrNC4O1Zb1N 8e6HA11geIAzR9x1vuA+/KNiBWQbXwckURHrlGWYk3trp+GPVexqUMTL/6Llxhqk2Hdn l5xn8hS70j6nkDWtDpaYE/fpqIYrQqvIwORxYYbUf/NBzrZQjw8FkqjQB0crBgKX558B sN/c7bZAza7LHePO4hSlcXpckHCSjYKqBwxmualN20oy7RdEoA/+K/rXm4UObffOyOR1 gI7DYowqjFBh6Eo8ZfQG5YYeJrs/aty+WfyjORJ8LMhjmjEFmAtv9CPzLVZSj+Ttzu4P 7Bbg== MIME-Version: 1.0 X-Received: by 10.224.67.71 with SMTP id q7mr17620638qai.59.1380334442184; Fri, 27 Sep 2013 19:14:02 -0700 (PDT) Received: by 10.49.39.33 with HTTP; Fri, 27 Sep 2013 19:14:01 -0700 (PDT) Received: by 10.49.39.33 with HTTP; Fri, 27 Sep 2013 19:14:01 -0700 (PDT) In-Reply-To: <52461D08.3070806@swin.edu.au> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <52461D08.3070806@swin.edu.au> Date: Fri, 27 Sep 2013 19:14:01 -0700 Message-ID: Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 02:14:03 -0000 On Sep 27, 2013 5:05 PM, "grenville armitage" wrote: > > > > On 09/28/2013 08:06, David Demelier wrote: > [..] > >> Also in the future you can just forgot that crappy ideas as you can see, >> nobody liked it. > > > I beg to differ. I know it's not a poll, but myself and the 5 people in my office all thought it was awesome, and will be leaving it enabled for as long as 9.2 is installed on our servers. That definitely puts it above "nobody liked it". Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is too short for this. :) From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 02:17:52 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 63369A87 for ; Sat, 28 Sep 2013 02:17:52 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 501B5282A for ; Sat, 28 Sep 2013 02:17:51 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 8C2251A3CCE for ; Fri, 27 Sep 2013 19:17:45 -0700 (PDT) Message-ID: <52463C48.4070409@freebsd.org> Date: Fri, 27 Sep 2013 19:17:44 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <52461D08.3070806@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 02:17:52 -0000 On 9/27/13 7:14 PM, Freddie Cash wrote: > On Sep 27, 2013 5:05 PM, "grenville armitage" wrote: >> >> >> On 09/28/2013 08:06, David Demelier wrote: >> [..] >> >>> Also in the future you can just forgot that crappy ideas as you can see, >>> nobody liked it. >> >> I beg to differ. > I know it's not a poll, but myself and the 5 people in my office all > thought it was awesome, and will be leaving it enabled for as long as 9.2 > is installed on our servers. > > That definitely puts it above "nobody liked it". > > Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is > too short for this. :) > Agreed. When it stop being fun, then it will see a decline in participation. -Alfred From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 02:31:00 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 5F678C45 for ; Sat, 28 Sep 2013 02:31:00 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B30A628C6 for ; Sat, 28 Sep 2013 02:30:59 +0000 (UTC) Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.7/8.14.7) with ESMTP id r8S2Uk3a020325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 28 Sep 2013 12:30:48 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1380335449; bh=FCKuAp/7wrK7h/Xx6Th4Zw6R16Ue06S/EXhY+5qrkvg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ONltKVfu4SPwI6m87w0PQRt1WSeIgPWKPvdiILI8dVGDt4HP/dOJ1C1M3ScKVuvl4 cX6YnlIAawKGtRatM1qYHvWvBNwphBfyX/k31LA+AJGiQETC52A7sgsJT9n8UTsGRP NGyan9YHL2KN2GwDRPVY9eVwWtqfZ6J3J/EYbc2c= Date: Sat, 28 Sep 2013 12:30:46 +1000 From: John Marshall To: Konstantin Belousov Subject: Re: 9.2-RC4 amd64 panic: vm_page_unwire Message-ID: <20130928023046.GA1428@rwpc15.gfn.riverwillow.net.au> References: <20130927000728.GB19167@rwpc15.gfn.riverwillow.net.au> <20130927081221.GK41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20130927081221.GK41229@kib.kiev.ua> OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 02:31:00 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 27 Sep 2013, 11:12 +0300, Konstantin Belousov wrote: > On Fri, Sep 27, 2013 at 10:07:28AM +1000, John Marshall wrote: > > I'm running 9.2-RC4 on a handful of desktop and server machines (both > > i386 and amd64). I have seen three panics (all vm_page_unwire) on one > > of those systems only (amd64 server) during the past week. > > The first two panics were triggered when shutting down the ntpd daemon > > (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a > > later release (p388) has not triggered the panic. The system panicked > > again overnight, this time while acting as an sftp server receiving > > large (GB) files from another system. > > I have made the core.txt.[0-2] files available in the following > > directory. The directory is not browsable. > >=20 > > http://www.riverwillow.net.au/~john/92rc4/ >=20 > This might be fixed by r254087-r254090 on stable/9. Thank you. Those patches applied cleanly to releng/9.2 so I rebuilt a patched 9.2. I double-checked and verified that the following patched files in my releng/9.2@255904 working copy were identical to the same files in stable/9@254090, then I removed /usr/obj/* and built a fresh system. M /usr/src/sys/vm/vm_fault.c M /usr/src/sys/vm/vm_map.c M /usr/src/sys/vm/vm_map.h M /usr/src/sys/vm/vm_object.c M /usr/src/sys/vm/vm_object.h M /usr/src/sys/vm/vm_page.c The system panicked as follows during shutdown after its first boot. The corresponding core.txt.3 file is available at the same location previously posted. Fri Sep 27 22:32:18 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.3 ... Unread portion of the kernel message buffer: . <118>Stopping watchdogd. <118>Waiting for PIDS: 1297 panic: vm_page_unwire: page 0xfffffe023743eb50's wire count is zero cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff80490278 at kdb_backtrace+0x68 #1 0xffffffff8045630a at panic+0x21a #2 0xffffffff8068bac2 at vm_page_unwire+0x102 #3 0xffffffff80678732 at vm_fault_unwire+0xd2 #4 0xffffffff80680851 at vm_map_delete+0x171 #5 0xffffffff80680acf at vm_map_remove+0x5f #6 0xffffffff80683ea9 at vmspace_exit+0xc9 #7 0xffffffff8041f3ad at exit1+0x72d #8 0xffffffff804203ae at sys_sys_exit+0xe #9 0xffffffff806afc6f at amd64_syscall+0x3bf #10 0xffffffff8069a717 at Xfast_syscall+0xf7 Uptime: 7m24s I have now seen this panic on a second server as well (also amd64 but different hardware vendor). This second (unpatched) system also panicked during shutdown as follows. Corresponding file named core.txt.0.system2 is available at the same location as above. Sat Sep 28 06:19:59 2013 +1000 panic: vm_page_unwire: page 0xfffffe0429aa5d18's wire count is zero cpuid =3D 1 KDB: stack backtrace: #0 0xffffffff804e7398 at kdb_backtrace+0x68 #1 0xffffffff804ad43a at panic+0x21a #2 0xffffffff80717d42 at vm_page_unwire+0x102 #3 0xffffffff80704882 at vm_fault_unwire+0xd2 #4 0xffffffff8070c9c1 at vm_map_delete+0x171 #5 0xffffffff8070cc3f at vm_map_remove+0x5f #6 0xffffffff80710069 at vmspace_exit+0xc9 #7 0xffffffff804764dd at exit1+0x72d #8 0xffffffff804774de at sys_sys_exit+0xe #9 0xffffffff8073d7cf at amd64_syscall+0x3bf #10 0xffffffff80728277 at Xfast_syscall+0xf7 Uptime: 5m31s --=20 John Marshall --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlJGP1YACgkQw/tAaKKahKILMgCfdivuO5qbJ1KY74rnn5J1TJZA WC8AnirV5eQcvlQ5rWIQgX1FXOQ9FdRc =jP5j -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 03:22:55 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 88D11686; Sat, 28 Sep 2013 03:22:55 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57B5A2B47; Sat, 28 Sep 2013 03:22:55 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id q10so3352621pdj.21 for ; Fri, 27 Sep 2013 20:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DxsWFch18ZimdLGuSUusn8dsr8PwFDH0v5R2y3nGMGM=; b=TVWAqyZH+HkREqGKPKZsOGAdRi4DU7FJ1hIlG2tUHp3NwDMsW9zsxzRhXM+WR1QHv/ AArd4s/ue70OO1MnDTQ75uqMvPXVuk7A2y6LLpvQh+d/kf5Ef+vdqr0AB5Two/a70Pxd JX8ybscs3CPDWrUe68yryZiT96H+OrYoxxVio3SdJutDw7vMCnfyYnSN2343nyEkfhym x0hDInToEayufCu1oMlDPC/qRQGhCoIvqQJ8OZjTLzJfy/oZ765PdhlJPPnR2MFkJsFK 5473FV0GmUOD8GAAsm/9Brlk+JrLagc9K8KxuRwuneBi2Rmtv+SSPrgsGsQKCmS8Q/I9 DnvQ== X-Received: by 10.66.121.131 with SMTP id lk3mr15167825pab.61.1380338574991; Fri, 27 Sep 2013 20:22:54 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id dw3sm11978973pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 20:22:53 -0700 (PDT) Message-ID: <52464B83.1000106@FreeBSD.org> Date: Sat, 28 Sep 2013 13:22:43 +1000 From: Kubilay Kocak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alfred Perlstein , freebsd-stable@freebsd.org, fjwcash@gmail.com Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <52461D08.3070806@swin.edu.au> <52463C48.4070409@freebsd.org> In-Reply-To: <52463C48.4070409@freebsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: koobs@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 03:22:55 -0000 On 28/09/2013 12:17 PM, Alfred Perlstein wrote: > On 9/27/13 7:14 PM, Freddie Cash wrote: >> On Sep 27, 2013 5:05 PM, "grenville armitage" >> wrote: >>> >>> >>> On 09/28/2013 08:06, David Demelier wrote: >>> [..] >>> >>>> Also in the future you can just forgot that crappy ideas as you can >>>> see, >>>> nobody liked it. >>> >>> I beg to differ. >> I know it's not a poll, but myself and the 5 people in my office all >> thought it was awesome, and will be leaving it enabled for as long as 9.2 >> is installed on our servers. >> >> That definitely puts it above "nobody liked it". >> >> Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is >> too short for this. :) >> > Agreed. When it stop being fun, then it will see a decline in > participation. > > -Alfred > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Both of you have it *right* on the money :) A more discerning question is *why* you thought it was awesome. Poeple might think its obvious, but the answer is *not* a cool logo, nor any Nakatomi reference. The real answer is deeper than that, and goes to the heart of why we feel affinities toward one individual, group, organisation or another. The purpose is entirely non-technical, and *precisely* to be active in honing FreeBSD's brand identity, personality and culture moving forward. If the outcomes are a perception of a community that is approachable and lighthearted, and encouraging participation, so much the better. To those who read this thread, ask yourself first: What message do YOU want to communicate to the world about who we are? Now make your decisions follow from that :) -- Kubilay "koobs" Kocak From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 08:07:29 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id D022DC80; Sat, 28 Sep 2013 08:07:29 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B666D2229; Sat, 28 Sep 2013 08:07:29 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 8E686E6009; Sat, 28 Sep 2013 01:07:23 -0700 (PDT) Received: from [IPv6:2601:7:1680:365:68a2:c43b:d030:f514] (unknown [IPv6:2601:7:1680:365:68a2:c43b:d030:f514]) by chombo.houseloki.net (Postfix) with ESMTPSA id AF6D1916; Sat, 28 Sep 2013 01:07:21 -0700 (PDT) Message-ID: <52468E31.7000604@bluerosetech.com> Date: Sat, 28 Sep 2013 01:07:13 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Devin Teske Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 08:07:29 -0000 Devin, I just want to say that I really liked the reference. I was teaching myself loader/forth and working on a version of it for my own amusement when I saw the commit. Please do continue to make these silly things in the future. I actually run FreeBSD in production and my boss loved it so much we actually have an official change-order ticket to preconfigure all of our production 9.2 systems to show the logo. A guy I work with slated a hack to show it at the login prompt as well. :) As for any of you who objected seriously: it's a joke, a tribute to one of the better cult action movies, and a nice bit of pre-release fun. While there are some Linux distros like RHEL where you can pay someone to listen to your pointless complaints, Devin doesn't get a cent to put up with your whingy little snit. In short, stuff it. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 08:44:44 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 7E52D769 for ; Sat, 28 Sep 2013 08:44:44 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) by mx1.freebsd.org (Postfix) with ESMTP id 404912665 for ; Sat, 28 Sep 2013 08:44:44 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 93E3CBC0D21 for ; Sat, 28 Sep 2013 12:44:43 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 53723E4021F for ; Sat, 28 Sep 2013 12:44:43 +0400 (MSK) Received: from 46.38.32.182.tel.ru (46.38.32.182.tel.ru [46.38.32.182]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTP id HRnH5ITdrF-ihOSWhRO; Sat, 28 Sep 2013 12:44:43 +0400 Message-ID: <524696FA.5090609@passap.ru> Date: Sat, 28 Sep 2013 12:44:42 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> In-Reply-To: <5246014B.70908@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 08:44:44 -0000 28.09.2013 02:06, David Demelier пишет: > On 21.09.2013 12:40, Matthew Seaman wrote: >> On 21/09/2013 11:31, O. Hartmann wrote: >>> I'd like to switch off this silly "Nakatomi Socrates" message which >>> reminds me on Linux and their childish naming schemes. >>> >>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>> >>> I guess there is a switch already prsent to have in the bootloader >>> config? >> >> It's turned off by default in more recent 9.2-STABLE (As I understand the case) The logo in question is (now) turned off... >> Otherwise: >> loader_logo="orb" [*] >> in /boot/loader.conf -- see loader.conf(5) ... but if someone want to use it, add that[*] line to loader.conf... > I have loader_logo="orb" ... just what you have done... > and I still have a message at the right bottom > with that stupid joke. ... and actually get! So it seems that you just misunderstood what Matthew had wrote. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 09:40:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 860D8B88; Sat, 28 Sep 2013 09:40:17 +0000 (UTC) (envelope-from regnauld@x0.dk) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by mx1.freebsd.org (Postfix) with ESMTP id 437882D8D; Sat, 28 Sep 2013 09:40:16 +0000 (UTC) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 30B884CEA35; Sat, 28 Sep 2013 11:32:59 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id p4hRxmLfSpGB; Sat, 28 Sep 2013 11:32:58 +0200 (CEST) Received: from macbook.bluepipe.net (unknown [197.225.31.103]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTPA id B7C314CEA1A; Sat, 28 Sep 2013 11:32:57 +0200 (CEST) Received: by macbook.bluepipe.net (Postfix, from userid 1001) id A55AE139F2DC; Sat, 28 Sep 2013 11:32:54 +0200 (CEST) Date: Sat, 28 Sep 2013 11:32:54 +0200 From: Phil Regnauld To: Devin Teske Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Message-ID: <20130928093254.GB6008@macbook.bluepipe.net> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> X-Operating-System: Darwin 12.4.0 x86_64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 09:40:17 -0000 Teske, Devin (Devin.Teske) writes: > > If you work seriously on serious issues long enough... you'll become burned- > out. Let me just come right out and say it... > > I coded it. And thanks, you got me chuckling - nice to see some humor once in a while. To the offended poster: read the last line of tunefs(8) - there's probably many more places you could use serious time looking for deviations from corporate correctnes. > And after 8 years of "always serious" coding on "always serious" projects has > made me a dull boy. This little mini-project gave me something to work on that > lifted my spirits. Been using it for 20, plan on using it for 20 more. Keep up the good work :) > Come on... > > Let us have some fun every now and then. http://unix.stackexchange.com/questions/89296/what-does-the-windows-flag-in-the-linux-logo-of-kernel-3-11-mean > Because when we do have fun... we often find ways of turning that functionality into > something great (like the ability to use this for a custom boot screen in a fork or distro). Or for kiosk setups where the machine displays something informative on boot. Phil From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 09:59:36 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 2F83B3C6 for ; Sat, 28 Sep 2013 09:59:36 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7B8A209E for ; Sat, 28 Sep 2013 09:59:35 +0000 (UTC) Received: from seedling.local ([78.133.112.70]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r8S9xMHS046289 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 28 Sep 2013 10:59:23 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r8S9xMHS046289 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1380362364; bh=oQ5rgXBtyJAGoDZLIETBEHXt7fE/aoxnz+RAE9NzpY8=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Sat,=2028=20Sep=202013=2011:59:17=20+0200|From:=20Matthew =20Seaman=20|To:=20freebsd-stable @freebsd.org|Subject:=20Re:=209.2-PRE:=20switch=20off=20that=20stu pid=20"Nakatomi=20Socrates"|References:=20<20130921123125.309f30eb @thor.walstatt.dyndns.org>=20<523D7784.30002@FreeBSD.org>=20<52460 14B.70908@gmail.com>=20<524696FA.5090609@passap.ru>|In-Reply-To:=2 0<524696FA.5090609@passap.ru>; b=JKl6pSxTWzrk8o7qz0bgtCg06WMLuI6o2mD3FHABcTMtYUOxLWEvUyuiy3gROpbrg C2zbHGzOWBd/N3p31MQwJL2AKueALteuBuXYYWHO3vVBYSo6N5LjAJcxB7oqlXDDta W9nonPaTLleXDFpl2i8FPCr8OA+Ut+NPB2x1YBx4= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host [78.133.112.70] claimed to be seedling.local Message-ID: <5246A875.8010407@infracaninophile.co.uk> Date: Sat, 28 Sep 2013 11:59:17 +0200 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <524696FA.5090609@passap.ru> In-Reply-To: <524696FA.5090609@passap.ru> X-Enigmail-Version: 1.5.2 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bLGT7VJcw5tUs7mBP5Jl3Dt2vOPRK1Scg" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,DCC_CHECK, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_XBL,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 09:59:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bLGT7VJcw5tUs7mBP5Jl3Dt2vOPRK1Scg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28/09/2013 10:44, Boris Samorodov wrote: > 28.09.2013 02:06, David Demelier =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 21.09.2013 12:40, Matthew Seaman wrote: >>> On 21/09/2013 11:31, O. Hartmann wrote: >>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>> reminds me on Linux and their childish naming schemes. >>>> >>>> It is only cosmetics, but it bothers me whenever I switch on the lap= top. >>>> >>>> I guess there is a switch already prsent to have in the bootloader >>>> config? >>> >>> It's turned off by default in more recent 9.2-STABLE >=20 > (As I understand the case) >=20 > The logo in question is (now) turned off... >=20 >>> Otherwise: >>> loader_logo=3D"orb" [*] >>> in /boot/loader.conf -- see loader.conf(5) >=20 > ... but if someone want to use it, add that[*] line to loader.conf... >=20 >> I have loader_logo=3D"orb" >=20 > ... just what you have done... >=20 >> and I still have a message at the right bottom >> with that stupid joke. >=20 > ... and actually get! >=20 > So it seems that you just misunderstood what Matthew had wrote. Actually, as Devin pointed out, I only had part of the answer. Setting 'loader_logo' will change the big ascii art graphic. The other bit is setting 'loader_version' which would suppress the 'Nakatomi Socrates' text along side it. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --bLGT7VJcw5tUs7mBP5Jl3Dt2vOPRK1Scg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJGqHpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEI1NTUyQTk2Mjc0RUQyNDg1NzM0MEVCNEYw QzhFNEU3NjBBRTkwOEMACgkQ8Mjk52CukIwOLACeNFxH3Ms+Yrya7YNKDEwaEfWP OmUAniej3L4DBk17MPmojc81F1262s5O =0zUR -----END PGP SIGNATURE----- --bLGT7VJcw5tUs7mBP5Jl3Dt2vOPRK1Scg-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 10:17:58 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 6D9DB81D for ; Sat, 28 Sep 2013 10:17:58 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12AD82225 for ; Sat, 28 Sep 2013 10:17:57 +0000 (UTC) Received: from seedling.local ([78.133.112.70]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r8SAHl0S046620 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 28 Sep 2013 11:17:48 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r8SAHl0S046620 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1380363469; bh=vS2z5EXNwgBkAlYug0CXg24rWdf+52U+YLdM0WsLMrc=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Sat,=2028=20Sep=202013=2012:17:46=20+0200|From:=20Matthew =20Seaman=20|To:=20freebsd-stable @freebsd.org|Subject:=20Re:=209.2-PRE:=20switch=20off=20that=20stu pid=20"Nakatomi=20Socrates"|References:=20<20130921123125.309f30eb @thor.walstatt.dyndns.org>=20<523D7784.30002@FreeBSD.org>=20<52460 14B.70908@gmail.com>=20<13CA24D6AB415D428143D44749F57D720FC01B09@L TCFISWMSGMB21.FNFIS.com>=20<52460D3F.304@gmail.com>=20<13CA24D6AB4 15D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com>=20<2013092 8093254.GB6008@macbook.bluepipe.net>|In-Reply-To:=20<2013092809325 4.GB6008@macbook.bluepipe.net>; b=SLPYpFkqenOmDRwf2CdbsipBxrPBKNSv6V9DezLqSNIaTXyCy/Hw4vARLz0S0RYIs cMuFyFclkIkExjbztU2zbr6jajXAXtI6pJDvLLLxSDwY1zrPA78PgrYEC5stq+Ee5K 2s7bpLNJuf8GSHf0CwvUHdjKpkDfBwy3jmPntGpc= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host [78.133.112.70] claimed to be seedling.local Message-ID: <5246ACCA.7010303@infracaninophile.co.uk> Date: Sat, 28 Sep 2013 12:17:46 +0200 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> <13CA24D6AB415D428143D44749F57D720FC02252@LTCFISWMSGMB21.FNFIS.com> <20130928093254.GB6008@macbook.bluepipe.net> In-Reply-To: <20130928093254.GB6008@macbook.bluepipe.net> X-Enigmail-Version: 1.5.2 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d4OXFJa5GikuuVaCTJbTWXND3MNlXGsXG" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,DCC_CHECK, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_XBL,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 10:17:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d4OXFJa5GikuuVaCTJbTWXND3MNlXGsXG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 28/09/2013 11:32, Phil Regnauld wrote: > To the offended poster: read the last line of tunefs(8) - there's prob= ably > many more places you could use serious time looking for deviations fro= m > corporate correctnes. There used to be a function in the shutdown utility called die_you_gravy_sucking_pig_dog() which was actually the very last function call made by shutdown(8) on a normal system shutdown. I believe humourless corporate types were instrumental in having that function renamed to something bland a few years back. However, now it's back, as of r238968: http://svnweb.freebsd.org/base/head/sbin/shutdown/shutdown.c?r1=3D235855&= r2=3D238968 This stuff comes and goes. Personally, I think the developers exhibiting a sense of humour and a spark of personality is the sort of thing that leads me to trust a lot more in a code base than their appearing as a horde of bland corporate drones. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --d4OXFJa5GikuuVaCTJbTWXND3MNlXGsXG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJGrMpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEI1NTUyQTk2Mjc0RUQyNDg1NzM0MEVCNEYw QzhFNEU3NjBBRTkwOEMACgkQ8Mjk52CukIykmACdGea4YRQDPQZ1W+dKWeKsLj3p jsMAni0FN4YIxQ++O3F6l5WcWWrHk8vd =edZY -----END PGP SIGNATURE----- --d4OXFJa5GikuuVaCTJbTWXND3MNlXGsXG-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 11:19:53 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id EC38E69F for ; Sat, 28 Sep 2013 11:19:53 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB0625AA for ; Sat, 28 Sep 2013 11:19:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id BB83A425CF for ; Sat, 28 Sep 2013 13:19:42 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=ham Authentication-Results: bouvier.get.c.bitbit.net (amavisd-new); dkim=pass (1024-bit key) header.d=getmail.no Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Fb6GBcKkIvV7 for ; Sat, 28 Sep 2013 13:19:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 61F11425D3 for ; Sat, 28 Sep 2013 13:19:42 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 bouvier.getmail.no 61F11425D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1380367182; bh=7VNVO37snr3/nLpeo2tDMNfjdIvgujVm9Q838Z6UGhE=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=RIe3OF8cJQjaPXU2Z3qMR3+MyNiVEPBdU1gs4DMUYlbjc2Ad4LXVn+8Hm3tLyfdUm QcBgzQQsArm00h4FGBDRcTEDFUaV2GOKSpDs9T0hlWxExfS043fhlG/PvXd1IYH3UH 0CqRWb6ZYYdCUUtacp2s9/MJdULKd92jG2jBxk/4= X-Virus-Scanned: amavisd-new at Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WTDMKGlgj4Gz for ; Sat, 28 Sep 2013 13:19:42 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by bouvier.getmail.no (Postfix) with ESMTPSA id 2DCF0425CF for ; Sat, 28 Sep 2013 13:19:42 +0200 (CEST) Date: Sat, 28 Sep 2013 13:19:41 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" Message-Id: <20130928131941.101980c0b01c76f4dfe5447e@getmail.no> In-Reply-To: <52463C48.4070409@freebsd.org> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <52461D08.3070806@swin.edu.au> <52463C48.4070409@freebsd.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd8.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 11:19:54 -0000 On Fri, 27 Sep 2013 19:17:44 -0700 Alfred Perlstein wrote: > On 9/27/13 7:14 PM, Freddie Cash wrote: > > > > Lighten up. Go outside, take a deep breath of fresh air. Move on. Life is > > too short for this. :) > > > Agreed. When it stop being fun, then it will see a decline in > participation. Hear, hear! Everybody should remember this! -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 15:05:17 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id AB7CC6C6 for ; Sat, 28 Sep 2013 15:05:17 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F9EF20A1 for ; Sat, 28 Sep 2013 15:05:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r8SF5AZq081979; Sat, 28 Sep 2013 09:05:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r8SF5ATT081976; Sat, 28 Sep 2013 09:05:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 28 Sep 2013 09:05:10 -0600 (MDT) From: Warren Block To: Ben Morrow Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" In-Reply-To: <20130928000930.GA42145@anubis.morrow.me.uk> Message-ID: References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <20130928000930.GA42145@anubis.morrow.me.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 28 Sep 2013 09:05:10 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:05:17 -0000 On Sat, 28 Sep 2013, Ben Morrow wrote: > Quoth David Demelier : >> >> I personally think (but you may totally disagree with) that an operating >> system *is* an operating system. And I really hate easter eggs or >> anything else not serious being integrated into the system. I think >> about a new user installing FreeBSD 9.2, I would not imagine his >> reaction front of this kind of "tribute" or whatever you call that. For >> me it stands for "that's not serious, it looks like a toy". > > Personally I thoroughly approve of a joke every now and then, as long as > it doesn't get out of hand. The problem with humor is that it's subjective. Think of a joke that lots of people found funny, but you did not. Now put that same joke somewhere you will be forced to see it and be reminded of it often. After a short time, it's not just unfunny, it's irritating. Or, as someone once put it, "there's a fine line between clever and stupid." So this kind of thing should be easily disabled. There should also be some warning, so when people see a vastly different boot screen, their first thought is not "was I hacked?". From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 15:27:28 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id C0CC5C9F for ; Sat, 28 Sep 2013 15:27:28 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B2252191 for ; Sat, 28 Sep 2013 15:27:28 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wm4so4070174obc.11 for ; Sat, 28 Sep 2013 08:27:27 -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=IfplkxtVbjkoW63EV1Oh7qQ1AiZ8vCM7DgCeYdl61/4=; b=NNv39WE/pPmxz2htQ3oUZQ46LOsTFEi/+PPQIQKpE/1Vz0Zny54s37uxewoFTElrmp gkxmUe8rzLabQk+ShscAQeSgBlw/NBi648HQAQOjYxgZs8FEQKzwzBPfLoQa3g0bRjD5 PrvrtCsrvAKUFQzWfNMQ+ZP7/nTJX+PuJ8yP2q4jWB5lgG9WsY13xIGtkzuxCbDLUFGk lbcDYZv2VK9k/lKQtrn5jBsr8UNw+nZEM2TN0eqHrF3xTJKpdAFZuT65/GO8scszqdWh zKlD7oz4tS9qNWgicEuWzfESM3TByAMxSQmJE2h6kGs8v+pBLrSn1xKKsnaqOQVYRB4U tpdw== MIME-Version: 1.0 X-Received: by 10.60.133.71 with SMTP id pa7mr1091209oeb.44.1380382047745; Sat, 28 Sep 2013 08:27:27 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Sat, 28 Sep 2013 08:27:27 -0700 (PDT) In-Reply-To: <20130928023046.GA1428@rwpc15.gfn.riverwillow.net.au> References: <20130927000728.GB19167@rwpc15.gfn.riverwillow.net.au> <20130927081221.GK41229@kib.kiev.ua> <20130928023046.GA1428@rwpc15.gfn.riverwillow.net.au> Date: Sat, 28 Sep 2013 17:27:27 +0200 Message-ID: Subject: Re: 9.2-RC4 amd64 panic: vm_page_unwire From: Oliver Pinter To: John Marshall Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:27:28 -0000 On 9/28/13, John Marshall wrote: > On Fri, 27 Sep 2013, 11:12 +0300, Konstantin Belousov wrote: >> On Fri, Sep 27, 2013 at 10:07:28AM +1000, John Marshall wrote: >> > I'm running 9.2-RC4 on a handful of desktop and server machines (both >> > i386 and amd64). I have seen three panics (all vm_page_unwire) on one >> > of those systems only (amd64 server) during the past week. > >> > The first two panics were triggered when shutting down the ntpd daemon >> > (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a >> > later release (p388) has not triggered the panic. The system panicked >> > again overnight, this time while acting as an sftp server receiving >> > large (GB) files from another system. > >> > I have made the core.txt.[0-2] files available in the following >> > directory. The directory is not browsable. >> > >> > http://www.riverwillow.net.au/~john/92rc4/ >> >> This might be fixed by r254087-r254090 on stable/9. > > Thank you. Those patches applied cleanly to releng/9.2 so I rebuilt a > patched 9.2. I double-checked and verified that the following patched > files in my releng/9.2@255904 working copy were identical to the same > files in stable/9@254090, then I removed /usr/obj/* and built a fresh > system. > > M /usr/src/sys/vm/vm_fault.c > M /usr/src/sys/vm/vm_map.c > M /usr/src/sys/vm/vm_map.h > M /usr/src/sys/vm/vm_object.c > M /usr/src/sys/vm/vm_object.h > M /usr/src/sys/vm/vm_page.c > > The system panicked as follows during shutdown after its first boot. > The corresponding core.txt.3 file is available at the same location > previously posted. > > Fri Sep 27 22:32:18 2013 +1000 > ozsrv04# kgdb kernel.debug /var/crash/vmcore.3 > ... > Unread portion of the kernel message buffer: > . > <118>Stopping watchdogd. > <118>Waiting for PIDS: 1297 > panic: vm_page_unwire: page 0xfffffe023743eb50's wire count is zero > cpuid = 1 > KDB: stack backtrace: > #0 0xffffffff80490278 at kdb_backtrace+0x68 > #1 0xffffffff8045630a at panic+0x21a > #2 0xffffffff8068bac2 at vm_page_unwire+0x102 > #3 0xffffffff80678732 at vm_fault_unwire+0xd2 > #4 0xffffffff80680851 at vm_map_delete+0x171 > #5 0xffffffff80680acf at vm_map_remove+0x5f > #6 0xffffffff80683ea9 at vmspace_exit+0xc9 > #7 0xffffffff8041f3ad at exit1+0x72d > #8 0xffffffff804203ae at sys_sys_exit+0xe > #9 0xffffffff806afc6f at amd64_syscall+0x3bf > #10 0xffffffff8069a717 at Xfast_syscall+0xf7 > Uptime: 7m24s > > I have now seen this panic on a second server as well (also amd64 but > different hardware vendor). This second (unpatched) system also > panicked during shutdown as follows. Corresponding file named > core.txt.0.system2 is available at the same location as above. > > Sat Sep 28 06:19:59 2013 +1000 > panic: vm_page_unwire: page 0xfffffe0429aa5d18's wire count is zero > cpuid = 1 > KDB: stack backtrace: > #0 0xffffffff804e7398 at kdb_backtrace+0x68 > #1 0xffffffff804ad43a at panic+0x21a > #2 0xffffffff80717d42 at vm_page_unwire+0x102 > #3 0xffffffff80704882 at vm_fault_unwire+0xd2 > #4 0xffffffff8070c9c1 at vm_map_delete+0x171 > #5 0xffffffff8070cc3f at vm_map_remove+0x5f > #6 0xffffffff80710069 at vmspace_exit+0xc9 > #7 0xffffffff804764dd at exit1+0x72d > #8 0xffffffff804774de at sys_sys_exit+0xe > #9 0xffffffff8073d7cf at amd64_syscall+0x3bf > #10 0xffffffff80728277 at Xfast_syscall+0xf7 > Uptime: 5m31s try this from 9-STABLE: https://github.com/freebsd/freebsd/commit/98362329be8e2cdefda1988e5e9d32efbc94855f > > -- > John Marshall > From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 16:00:55 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id D209F74 for ; Sat, 28 Sep 2013 16:00:55 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B212B2375 for ; Sat, 28 Sep 2013 16:00:55 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VPwgH-0000Co-SE for freebsd-stable@freebsd.org; Sat, 28 Sep 2013 08:43:42 -0700 Date: Sat, 28 Sep 2013 08:43:41 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1380383021602-5847358.post@n5.nabble.com> In-Reply-To: References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01B09@LTCFISWMSGMB21.FNFIS.com> <52460D3F.304@gmail.com> <20130928000930.GA42145@anubis.morrow.me.uk> Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 16:00:55 -0000 This thread has wonderful bike shed potential. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-2-PRE-switch-off-that-stupid-Nakatomi-Socrates-tp5845622p5847358.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 19:34:45 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id 520DC588 for ; Sat, 28 Sep 2013 19:34:45 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA71D2E54 for ; Sat, 28 Sep 2013 19:34:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r8SJYR8W035035; Sat, 28 Sep 2013 23:34:27 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 28 Sep 2013 23:34:27 +0400 (MSK) From: Dmitry Morozovsky To: Joe Holden Subject: Re: FreeBSD 9.1 ix driver vlan problem In-Reply-To: <524546ED.5010803@rewt.org.uk> Message-ID: References: <20130925164053.GB76403@lath.rinet.ru> <20130925183253.GA1315@lath.rinet.ru> <524546ED.5010803@rewt.org.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 28 Sep 2013 23:34:28 +0400 (MSK) Cc: "freebsd-stable@freebsd.org" , Jack Vogel , Rumen Telbizov , Jack Vogel , Andree Toonk , Oleg Bulyzhin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 19:34:45 -0000 On Fri, 27 Sep 2013, Joe Holden wrote: > > > Thanks for the heads-up Oleg, although not the news that I was hoping for. > > > > > > So what I am going to do right now is reinstall with 9.2 and recompile the > > > driver with your patch. > > > I'll come back to the list with my results. > > > > FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're > > welcome > > to test this on your 9 > > > > It's supposedly way too late to try to include this fix into 9.2-R, but > > maybe > > it's worth the errata notice... > > > This happens on several other intel chipsets as well, no previous errata was > ever noted (legacy em, for example) :( It's a pity then. Provided that em/igb/ixgb[e] are possibly the most frequent ethernet interfaces on modern server-related x86/amd64 hardware, the userbase affected seems pretty large... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sat Sep 28 22:15:46 2013 Return-Path: Delivered-To: freebsd-stable@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 ESMTP id E6B3443F; Sat, 28 Sep 2013 22:15:45 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B45FC259C; Sat, 28 Sep 2013 22:15:45 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r8SM0Q38004808; Sat, 28 Sep 2013 15:00:32 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r8SM0LRK004804; Sat, 28 Sep 2013 15:00:21 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 28 Sep 2013 15:00:21 -0700 (PDT) Message-ID: In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC01C3B@LTCFISWMSGMB21.FNFIS.com> References: <20130921123125.309f30eb@thor.walstatt.dyndns.org> <523D7784.30002@FreeBSD.org> <5246014B.70908@gmail.com> <13CA24D6AB415D428143D44749F57D720FC01C3B@LTCFISWMSGMB21.FNFIS.com> Date: Sat, 28 Sep 2013 15:00:21 -0700 (PDT) Subject: Re: 9.2-PRE: switch off that stupid "Nakatomi Socrates" From: "Chris H" To: "Devin Teske" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 22:15:46 -0000 > > On Sep 27, 2013, at 3:06 PM, David Demelier wrote: > >> On 21.09.2013 12:40, Matthew Seaman wrote: >>> On 21/09/2013 11:31, O. Hartmann wrote: >>>> I'd like to switch off this silly "Nakatomi Socrates" message which >>>> reminds me on Linux and their childish naming schemes. >>>> >>>> It is only cosmetics, but it bothers me whenever I switch on the laptop. >>>> >>>> I guess there is a switch already prsent to have in the bootloader >>>> config? >>> >>> It's turned off by default in more recent 9.2-STABLE >>> >>> Otherwise: >>> >>> loader_logo="orb" >>> >>> in /boot/loader.conf -- see loader.conf(5) >>> >>> Cheers, >>> >>> Matthew >>> >> >> Hi, >> >> I have loader_logo="orb" and I still have a message at the right bottom >> with that stupid joke. >> > > "Named Releases" is far from a joke. > > Maybe you'd like something a bit more boring like "9.2-RELEASE" > > The fact is... there is (and only ever will be) one iteration of FreeBSD 9.2. > > I assume that you have had no clue up until this point that there was yet > another BSD 9.2. A fictitious version of BSD in a 1980's film, named... > > Nakatomi Socrates > > Yeah, we could have decided to let the opportunity pass; to show that we're > the first BSD to ever hit 9.2 out of all the flavors, producing the first ever > non-fictitious BSD 9.2... > > But where would the fun be in that? > > Rest assured... I've not seen *any* hollywood films with a number higher > than 9.2... so our future looks pretty darn boring. > > The "name" for 10.0-RELEASE could very well be NULL or boring ol' > > 10.0-RELEASE I nominate HAL 2000 for 10-RELEASE Of course it would need to be bold red blinking text. maybe using an ASCII escape sequence for those not using Graphics Mode? -- sorry. I couldn't resist. :P --Chris > > But one thing is clear. > > There is a real tangible benefit to seeing the version on the boot screen. > > As we move to integrate BE's into the Forth boot screen, it may become > paramount to know what version of loader(8) you're using. > > So please try not to be so judge-mental about these things. > > This is a real tangible improvement and simply because you've heard > that those crazy people in Linux-land are naming their releases... > > That had zero bearing on why we did it. We may never name another release > ever again. > > I personally would like to see loader(8) set the value to include an SVN revision > so that everytime you rebuild loader(8), the version info updates; displayed > prominently in the bottom right corner (which of course... you'll again be free to > override it if you don't like it... just as you are free to completely disable the > entire menu by adding beastie_disable=YES to loader.conf(8)). > -- > Devin > > _____________ > The information contained in this message is proprietary and/or confidential. If you are not > the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, > distribute or use the message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >