From owner-freebsd-stable@FreeBSD.ORG Sun May 8 03:27:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0F23106566B for ; Sun, 8 May 2011 03:27:36 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7239F8FC13 for ; Sun, 8 May 2011 03:27:36 +0000 (UTC) Received: by vxc34 with SMTP id 34so6352539vxc.13 for ; Sat, 07 May 2011 20:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7IWlmPdZ59/R2GM5OVcsDfvBxytLJQsnjlrh19/q7Mw=; b=BOJkeYywKQ5ipFMDqUPWdqCGLzGff6AXafqb0w4LRRvEuU7ibi9oHc8CAuoHSjWdTa DmIyNuimtx/fEPSZlq7BMltkpj5dH21cM9nYMFGokJ+BHDifEqj1ENGhjv9Vbq541PCb paRRUvPeBBZX6aX9XArOAHOoZk0XU0O+GC8UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fU9O84VKLpcr1jUjHzenZjP8WFVaYZEGIbBxdR+HZO9Tb5seJv5xE+YobR6SvyuBHD iaOSdwszpow3vgIYxzeYa5dOM9QZDuxLZHBreykwUcFYFKwGQBkpEBoCxuJRNMP8DiAg hoI6NXvrByNEequQ+US+QgdCyvZlVG9iEI2l0= MIME-Version: 1.0 Received: by 10.52.99.197 with SMTP id es5mr1775401vdb.144.1304825255521; Sat, 07 May 2011 20:27:35 -0700 (PDT) Received: by 10.52.157.104 with HTTP; Sat, 7 May 2011 20:27:35 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 May 2011 23:27:35 -0400 Message-ID: From: Zaphod Beeblebrox To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Subject: Re: Intel "em" driver sleeps with non-sleepable lock. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 03:27:36 -0000 On Thu, May 5, 2011 at 4:44 PM, Jack Vogel wrote: > So, this happens EVERY time after an install of 8.2 ?? > > Give me details about the hardware please. Having had more time to experiment, it seems it happens whenever ifconfig_em0="DHCP" is in rc.conf --- which happens after using the PC-BSD installer to install FreeBSD. It also happens if you put that in there manually. NB: em0 must also have link. So... conditions: 1) FreeBSD 8.1 or 8.2 installed 2) ifconfig_em0="DHCP" 3) em0 has link. If any of those are missing, things work fine. OK... hardware again. Intel S3240HGPRX motherboard. Xeon X3440 processor. 4 "igb" chipset ethernet onboard plus one "em" chipset ethernet. The "em" chipset ethernet is "shared" with the onboard ILOM which, in this case is augmented by an RMM3 module (which provides full video console and remote mount media). The initial probe for the "em" device says: em0: port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci12 em0: Using MSIX interrupts with 3 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:15:17:e8:53:1e ... but that same port is shared with the ILOM and it uses the mac address: 00:15:17:e8:53:20 pciconf -lv says: em0@pci0:12:0:0: class=0x020000 card=0x34f28086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet I'm just actually looking at a PDF from Intel on this chip --- they talk about it having "sideband" communications with the BMC (baseboard management controller) at as much as 100 megabit (but possibly through smbus --- which is quite slow). They also talk about it having hardware timestamping of packets for more accurate timekeeping --- which is cool. Since I can reproduce this, how do I trace this other thread? From owner-freebsd-stable@FreeBSD.ORG Sun May 8 14:31:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE97B106564A for ; Sun, 8 May 2011 14:31:22 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8C18FC0C for ; Sun, 8 May 2011 14:31:21 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.0]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QJ4Z5-0000Z2-QI for freebsd-stable@freebsd.org; Sun, 08 May 2011 16:02:39 +0200 Message-ID: <4DC6A277.4030801@it4pro.pl> Date: Sun, 08 May 2011 16:02:31 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Stable X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.8 X-Spam-Score-Int: -77 X-Exim-Version: 4.75 (build at 30-Mar-2011 13:28:38) X-Date: 2011-05-08 16:02:39 X-Connected-IP: 10.66.3.0:1753 X-Message-Linecount: 115 X-Body-Linecount: 103 X-Message-Size: 3877 X-Body-Size: 3315 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 14:31:23 -0000 Hi list! I moved my 8-STABLE system from cheap AMD64 machine to Proliant DL180G6 (full ZFS send -> receive) yesterday. Operation was succesfull, system booted and everything worked fine. Still, I wanted to perform full world + kernel rebuild with updated sources and CPUTYPE (core2 instead of athlon64) and removed unused NIC drivers from kernel. New kernel panicked during boot. I rebuilt kernel again, without any CPUTYPE in make.conf, but panic was still there. Old kernel (built at 8.04.2011) is booting fine. First panic line says: panic: m_getzone: m_getjcl: invalid cluster type. I made a por quality photo of screen with stack backtrace and it's available here: http://www.picamatic.com/view/7544359_IMAG0029/ Now the funny thing: Igb driver is compiled into the kernel. If I add igb driver to loader.conf kernel complains of course: module_register: module pci/igb already exists! Module pci/igb failed to register: 17 but there's no panic! When I remove 'if_igb_load="YES"' from loader.conf, I experience panic visible above. Kernel config: http://pastebin.com/G7K0vfuJ -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Sun May 8 17:54:28 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9911065670 for ; Sun, 8 May 2011 17:54:28 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E24F98FC16 for ; Sun, 8 May 2011 17:54:27 +0000 (UTC) Received: by iyj12 with SMTP id 12so5440222iyj.13 for ; Sun, 08 May 2011 10:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :mime-version:content-type:content-disposition:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; bh=UX7Av2+YYP+QQf17pqOew04hdNVgcBk0glhbmXNY/fE=; b=lzlj0CfUis6eqmkWZ1hrLT74PudrHBu/g/NnN//EayEccKYoJ3SdX35OpCH00B1u94 TVGJOtfeJrs0yOYcbNNJ/HcBN6goKl2n2JeDl9wc2HJRS78YbCiiAYQTLKW1erPNTRqY szp7GukX1pAHzZIEGu5NIG3b7jifDcVUsZxfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; b=uRnME7Bx4iGHSDriYXStfH8fTRbqzF60jOR3zXNHwd/zRT3bzLeV2arGO/SeQg2wmM K/7mo1/V+f4Krope9xsMgYaEQmuaa20lgG9cFNp2LdpVC0MIm9WoDcsRgbPDbB0Tgnjs 4eqW62xaSAVJwmQdNJC2olHPj16xYgWYKRHXA= Received: by 10.42.1.74 with SMTP id 10mr5328649icf.86.1304877267270; Sun, 08 May 2011 10:54:27 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2268125iby.57.2011.05.08.10.54.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 10:54:22 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48HsJSO003540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 13:54:19 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48HsIIq003539; Sun, 8 May 2011 13:54:18 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 13:54:18 -0400 From: Jason Hellenthal To: hackers@FreeBSD.org, stable@FreeBSD.org, Rick Macklem Message-ID: <20110508175418.GA3527@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Subject: test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 17:54:28 -0000 hackers, Test -- Regards, (jhell) Jason Hellenthal From owner-freebsd-stable@FreeBSD.ORG Sun May 8 17:56:33 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4CA106564A for ; Sun, 8 May 2011 17:56:33 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E028A8FC13 for ; Sun, 8 May 2011 17:56:32 +0000 (UTC) Received: by iyj12 with SMTP id 12so5441394iyj.13 for ; Sun, 08 May 2011 10:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=tRMMb5oiMD9lDNIi0keVoAcV82bPPns5Izhjk3FYaQE=; b=cw2ZIF6f1dFkMfrcnVVGtFMtB629spsY4+f1S323WAtoEmMhPQUqjHHgHoTHkAcb/P 5zYHfaTCUhDdbmBUffkFtFNUvCdXuOTMKzzcB+oO5iMQ/kbmRV6jdpyYnn6Sqfsv3Ed3 nSc/tJk6ySDCHZCnJEGumFlgypXmbxVpGfsFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=g0BEWxRfEWZGbCa/BY0ppbkPPbuLuk9JcCVj468OKApVihAONTgkho4KypH2Jb3xSA XsZTRmT3aP3+84GoFEWTPXoiasS2585sHxAZnyEv6B1hqZJEMqxAJI3xp4TojTy75cKi soMig2BYhQSx1C1Im572lhJ7sF+ACOx4vKmWc= Received: by 10.42.223.4 with SMTP id ii4mr1658912icb.132.1304877392486; Sun, 08 May 2011 10:56:32 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id xe5sm2076852icb.10.2011.05.08.10.56.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 10:56:31 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48HuSiv003716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 13:56:28 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48HuRZh003715; Sun, 8 May 2011 13:56:27 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 13:56:26 -0400 From: Jason Hellenthal To: hackers@FreeBSD.org, stable@FreeBSD.org, Rick Macklem Message-ID: <20110508175626.GB3527@DataIX.net> References: <20110508175418.GA3527@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110508175418.GA3527@DataIX.net> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: Subject: Re: test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 17:56:33 -0000 hackers, On Sun, May 08, 2011 at 01:54:18PM -0400, Jason Hellenthal wrote: > > hackers, > > Test > My appologies. this message was never supposed to leave the outbox. Instead of hitting one key I hit another. Please disregard. Thanks. -- Regards, (jhell) Jason Hellenthal From owner-freebsd-stable@FreeBSD.ORG Sun May 8 18:34:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE99E1065672 for ; Sun, 8 May 2011 18:34:57 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1248FC08 for ; Sun, 8 May 2011 18:34:56 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QJ8oZ-0007W0-9B for freebsd-stable@freebsd.org; Sun, 08 May 2011 20:34:55 +0200 Message-ID: <4DC6E23B.2040207@it4pro.pl> Date: Sun, 08 May 2011 20:34:35 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Stable References: <4DC6A277.4030801@it4pro.pl> In-Reply-To: <4DC6A277.4030801@it4pro.pl> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.6 X-Spam-Score-Int: -75 X-Exim-Version: 4.75 (build at 30-Mar-2011 13:28:38) X-Date: 2011-05-08 20:34:55 X-Connected-IP: 78.8.144.74:54901 X-Message-Linecount: 213 X-Body-Linecount: 199 X-Message-Size: 6565 X-Body-Size: 5982 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 18:34:57 -0000 W dniu 2011-05-08 16:02, Bartosz Stec pisze: > Hi list! > > I moved my 8-STABLE system from cheap AMD64 machine to Proliant > DL180G6 (full ZFS send -> receive) yesterday. > Operation was succesfull, system booted and everything worked fine. > Still, I wanted to perform full world + kernel rebuild with updated > sources and CPUTYPE (core2 instead of athlon64) and removed unused NIC > drivers from kernel. > > New kernel panicked during boot. I rebuilt kernel again, without any > CPUTYPE in make.conf, but panic was still there. Old kernel (built at > 8.04.2011) is booting fine. > First panic line says: > > panic: m_getzone: m_getjcl: invalid cluster type. > > > I made a por quality photo of screen with stack backtrace and it's > available here: http://www.picamatic.com/view/7544359_IMAG0029/ > > Now the funny thing: > > Igb driver is compiled into the kernel. If I add igb driver to > loader.conf kernel complains of course: > > module_register: module pci/igb already exists! > Module pci/igb failed to register: 17 > > > but there's no panic! > > When I remove 'if_igb_load="YES"' from loader.conf, I experience panic > visible above. > > Kernel config: http://pastebin.com/G7K0vfuJ > > Picamatic seems offline now, so here's another link to backtrace photo: http://i51.tinypic.com/nyuux3.jpg Maybe make.conf will be useful too: CPUTYPE?=core2 KERNCONF=PROLIANT #MAKEOPTS=-j3 #WITH_DEBUG=yes #DEBUG_FLAGS=-g # default build settings for ports collection .if ${.CURDIR:M*/ports/*} && !defined(NOCCACHE) CFLAGS=-O2 -pipe #CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops BUILD_OPTIMIZED=YES WITH_OPENSSL=YES WITH_XCHARSET=all WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci .endif # default build settings for base system .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} && !defined(NOCCACHE) CFLAGS=-O2 -pipe COPTFLAGS=-O2 -pipe CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} .endif # added by use.perl 2011-05-08 17:13:51 PERL_VERSION=5.10.1 -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Sun May 8 19:13:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D5D106564A; Sun, 8 May 2011 19:13:42 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA2AD8FC0A; Sun, 8 May 2011 19:13:41 +0000 (UTC) Received: by iyj12 with SMTP id 12so5480542iyj.13 for ; Sun, 08 May 2011 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :reply-to:mime-version:content-type:content-disposition :x-openpgp-key-id:x-openpgp-key-fingerprint:x-openpgp-key-url; bh=oCS9kbjB84EwxUSOi2uPIJRMOVm/u+Tom1oJo5h3ZwU=; b=B8WQH+jSLbuewH0zcxA7FZGpx+SQ2cTk/xQI4vum+MxGzR3B/97f76cmhugimVK7Fm AqJCom5i/cE9mbT0oAuK3kcnOvfAA5p8PrXybMl2VOIFv3bU9uFGsrERPj3yNnSKrldF Ud+pGWhAjzKycvWd9L04baTt4DciM+yPlxMmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=rh7ZMV1S4wV/a6VCvVzD3SvCx/BpeV6fth0srGhLO+N9m3gs25+It69RQMXsRBvVPj YwCPHRRTjQXgR/RAZ6s+iwAVpi5gvtJ0aSP7B5RzxUohCfO9N76c/+A3UX17geMHKWJF qpJKlmdfqRadTrpFT8TEYoPT01GACC4MZIiW4= Received: by 10.42.134.70 with SMTP id k6mr5286097ict.488.1304882021199; Sun, 08 May 2011 12:13:41 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2297255iby.6.2011.05.08.12.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 May 2011 12:13:40 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p48JDb5F006840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 May 2011 15:13:37 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p48JDagU006839; Sun, 8 May 2011 15:13:36 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Sun, 8 May 2011 15:13:36 -0400 From: Jason Hellenthal To: freebsd-rc@freebsd.org Message-ID: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-rc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 19:13:42 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable List, - Please reply-to freebsd-rc@freebsd.org Recently I have been going over some changes in the configurations that=20 are possible with the rc subsystem and to my dismay I have found some=20 inconsistencies with in particular the way rc.conf.d directory is=20 processed and the arguments that are supplied to load_rc_config so I have= =20 patched it up... Let me explain: As determined by rc.subr load_rc_config, config's from=20 rc.conf.d are loaded by the scripts $name as an argument to load_rc_config= =20 and thus only the name being parsed is is available to be used in the=20 rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as= =20 the user has no direct way to know that a variable used by nfsd is also=20 needed by mountd or the same for various other scripts in the rc.d=20 directory. At this time these config's are explained to be available for=20 the user to utilize by rc.conf(5) but yet without much knowledge of the=20 inner workings of the rc subsystem it would be quite the feat to do. The attachment[1] keeps this functionality the same while introducing a=20 more convenient approach for the user to modularize their configuration=20 however they see fit within a couple constraints that work very well.=20 What does it do ?: As stated above, current functionality is undisturbed=20 while allowing the user to create config's by any name they so desire as=20 long as it has an extension of ".conf", also introducing the ability to=20 turn a configuration file off by using chmod(1). You can turn nfsc1.conf off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf Why ? Simple. How many times have you been bitten by disabling something=20 in the rc.conf file and left to discover what you just disabled was also=20 used by another daemon but that daemon is now not starting ? This is a way= =20 to virtualize your configuration allowing you to add multiple _enable=3D=20 lines to different configurations for different roles. For instance=20 rpcbind is used by both samba and nfs*. With this you can add=20 rpcbind_enable to both a configuration for samba and nfs and when you=20 disable one service you know that you have not disabled a dependent for=20 another. This is a small addition that fixes currently broken undesirable aspects=20 of the configuration system that deals with the rc.conf.d directory with a= =20 SysV style init approach that is just as flexible. This should apply=20 cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback= =20 has been received Ill update the manual page with any suggestions=20 regenerate the patch to accommodate and file a PR. 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Thanks --=20 Regards, (jhell) Jason Hellenthal --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxutfAAoJEJBXh4mJ2FR+anYH/jwyA3ifRH5QAivOkYcj3bSD 4jQCZB8FLDT1U7jE9hBk+YprFdkjBi+bDSPrbNYL3cOohvrVuAziB9VG811IhaRE //A9krdIy7QxXdkDFhkmP5F+z0wcmKoriFcO7onsDKVAqGjgyv+YyW+EohLjy283 rUAAmlgmlUSqcdAFNh8mJzNFDtcO9rqcXC1GVIGMY5wqoDLVQdkLwXrlmvPZc9eA Fz3++ZBPq0orRCjQDeP2h+rnAtssgBTXxaZhIM6tyS8aMBbOgl2XSaT5i5w7Soa5 8OButlT1RQ5TinqMt7ebXB07ycabgmFFLIK2JYPKS6Vp+zYOSYKlf9bO2B0dmMk= =zfmQ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-stable@FreeBSD.ORG Sun May 8 19:28:50 2011 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7F4106566B for ; Sun, 8 May 2011 19:28:50 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh1.interactivevillages.com (ca.2e.7bae.static.theplanet.com [174.123.46.202]) by mx1.freebsd.org (Postfix) with ESMTP id D6F9E8FC15 for ; Sun, 8 May 2011 19:28:49 +0000 (UTC) Received: from c-24-22-230-24.hsd1.wa.comcast.net ([24.22.230.24] helo=_HOSTNAME_) by wh1.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QJ95E-0008LM-Nd for stable@FreeBSD.org; Sun, 08 May 2011 11:51:37 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Sun, 08 May 2011 11:51:59 -0700 Date: Sun, 8 May 2011 11:51:59 -0700 From: Chip Camden To: stable@FreeBSD.org Message-ID: <20110508185159.GB3538@libertas.local.camdensoftware.com> Mail-Followup-To: stable@FreeBSD.org References: <20110508175418.GA3527@DataIX.net> <20110508175626.GB3527@DataIX.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x" Content-Disposition: inline In-Reply-To: <20110508175626.GB3527@DataIX.net> User-Agent: Mutt/1.4.2.3i Company: Camden Software Consulting URL: http://camdensoftware.com X-PGP-Key: http://pgp.mit.edu:11371/pks/lookup?search=0xD6DBAF91 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh1.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: Re: test X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2011 19:28:50 -0000 --mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoth Jason Hellenthal on Sunday, 08 May 2011: > hackers, >=20 > On Sun, May 08, 2011 at 01:54:18PM -0400, Jason Hellenthal wrote: > >=20 > > hackers, > >=20 > > Test > >=20 >=20 > My appologies. this message was never supposed to leave the outbox.=20 > Instead of hitting one key I hit another. Please disregard. >=20 Nevertheless, it's good advice. --=20 =2EO. | Sterling (Chip) Camden | http://camdensoftware.com =2E.O | sterling@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJNxuZPAAoJEIpckszW26+Rpa0IAKCDXoaFPSc0tMs+CZU47kbO ucDls6pruv+WQJRoOzgNzwKoa8Bq8kCLRiRxzFrLq6LfcC71qrBHmYidzbBkXPPp nxf7A0y4G9L3eLch14yuQ6TMY/3NHe4hyENaqYdugFb3yTdMLUno7KPTDWBBkluM X+bF+FNMnEkgZiyiRaBfsYfqVB+30oazLZ23jTVa8S3/MZaXByj+NWdUQXCHGWiK jyqUYzclO/lmr2ET3vnZDKa/6O8GcDXN87W23L2gFPF+QRacRQWWJ3zSNNdLbMro IgbeW4swJHRQ7TNKPPrLMOgmL5ovjuSp2vtKrcpCu2yigeml1ks5qtyANrkiAMQ= =Ai43 -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x-- From owner-freebsd-stable@FreeBSD.ORG Mon May 9 08:54:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64E1D106564A for ; Mon, 9 May 2011 08:54:00 +0000 (UTC) (envelope-from makc@issp.ac.ru) Received: from mail.issp.ac.ru (mail.issp.ac.ru [77.236.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 94C5F8FC18 for ; Mon, 9 May 2011 08:53:59 +0000 (UTC) Received: from [62.63.87.226] [62.63.87.226:2761] (HELO/EHLO luna.dio.ru, authenticated with PLAIN) by mail.issp.ac.ru with ESMTP/inet id p498fTDH000873 (using TLSv1/SSLv3, with cipher DHE-RSA-AES256-SHA (256 bits), verified NO) for ; Mon, 9 May 2011 12:41:29 +0400 (MSD) From: Max Brazhnikov Organization: ISSP RAS To: freebsd-stable@freebsd.org Date: Mon, 9 May 2011 12:40:56 +0400 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105091240.57785.makc@issp.ac.ru> Subject: automoc4 processes lock again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 08:54:00 -0000 Hi, After recent Qt-4.7.3 update I can't build KDE4 ports anymore (tested on 8.2-STABLE amd64 only). The problem is always reproduced with x11/kdelibs4. The build stalls with hanging automoc4 processes. Any help is appreciated. # ps | grep automoc 18636 3 IN+ 0:00.02 /usr/local/bin/automoc4 /usr/obj/usr/local/tinderbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3support/ 18640 3 IN+ 0:00.00 /usr/local/bin/automoc4 /usr/obj/usr/local/tinderbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3support/ # gdb automoc4 18636 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Attaching to program: /usr/local/bin/automoc4, process 18636 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from /usr/local/lib/qt4/libQtCore.so.4.7.3.debug...done. done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libz.so.5...done. Loaded symbols for /lib/libz.so.5 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libthr.so.3...done. [New Thread 801c0ae40 (LWP 100660/automoc4)] [New Thread 801c041c0 (LWP 100590/initial thread)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 801c0ae40 (LWP 100660/automoc4)] 0x000000080104c99c in select () at select.S:3 3 RSYSCALL(select) (gdb) bt #0 0x000000080104c99c in select () at select.S:3 #1 0x00000008008502cd in QProcessManager::run (this=0x800b196e0) at io/qprocess_unix.cpp:245 #2 0x0000000800749bde in QThreadPrivate::start (arg=0x800b196e0) at thread/qthread_unix.cpp:320 #3 0x00000008017985e1 in thread_start (curthread=0x801c0ae40) at /usr/freebsd/8/src/lib/libthr/thread/thr_create.c:288 #4 0x0000000000000000 in ?? () Error accessing memory address 0x7fffffbff000: Bad address. Current language: auto; currently asm # gdb automoc4 18640 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Attaching to program: /usr/local/bin/automoc4, process 18640 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from /usr/local/lib/qt4/libQtCore.so.4.7.3.debug...done. done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libz.so.5...done. Loaded symbols for /lib/libz.so.5 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libthr.so.3...done. Error while reading shared library symbols: Cannot get thread info: invalid key Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x00000008017a21bc in __thr_umutex_lock (mtx=0x8018a7380, id=100590) at /usr/freebsd/8/src/lib/libthr/thread/thr_umtx.c:58 #2 0x000000080179d04a in init_static (thread=0x801c041c0, mutex=0x801166c78) at thr_umtx.h:88 #3 0x000000080179d7ad in __pthread_mutex_lock (mutex=0x801166c78) at /usr/freebsd/8/src/lib/libthr/thread/thr_mutex.c:441 #4 0x000000080104b21e in _flockfile (fp=0x801166be0) at /usr/freebsd/8/src/lib/libc/stdio/_flock_stub.c:70 #5 0x0000000801021515 in fileno (fp=0x801166be0) at /usr/freebsd/8/src/lib/libc/stdio/fileno.c:52 #6 0x000000080084f109 in QProcessPrivate::execChild (this=0x801c51600, workingDir=0x0, path=0x0, argv=0x801c5b7c0, envp=0x0) at io/qprocess_unix.cpp:712 #7 0x0000000800851fc3 in QProcessPrivate::startProcess (this=0x801c51600) at io/qprocess_unix.cpp:665 #8 0x0000000800802248 in QProcess::start (this=0x7fffffffcd10, program=@0x7fffffffd8f8, arguments=@0x7fffffffcd00, mode=@0x7fffffffcd20) at io/qprocess.cpp:1960 #9 0x000000000040acd2 in AutoMoc::echoColor (this=0x7fffffffd8d0, msg=@0x7fffffffce80) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73 #10 0x000000000040517c in AutoMoc::generateMoc (this=0x7fffffffd8d0, sourceFile=@0x801c0f910, mocFileName=@0x801c0f918) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 #11 0x0000000000408011 in AutoMoc::run (this=0x7fffffffd8d0) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 #12 0x0000000000409135 in main (argc=6, argv=0x7fffffffd9a8) at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 Current language: auto; currently asm From owner-freebsd-stable@FreeBSD.ORG Mon May 9 13:02:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DCF10656D6 for ; Mon, 9 May 2011 13:02:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AB7848FC15 for ; Mon, 9 May 2011 13:02:07 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p49Cf5If056744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p49Cf5E2075217; Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p49Cf501075216; Mon, 9 May 2011 15:41:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 May 2011 15:41:05 +0300 From: Kostik Belousov To: Max Brazhnikov Message-ID: <20110509124104.GF48734@deviant.kiev.zoral.com.ua> References: <201105091240.57785.makc@issp.ac.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ylzTCAJcNegswXN2" Content-Disposition: inline In-Reply-To: <201105091240.57785.makc@issp.ac.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: automoc4 processes lock again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 13:02:08 -0000 --ylzTCAJcNegswXN2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 12:40:56PM +0400, Max Brazhnikov wrote: > Hi, >=20 > After recent Qt-4.7.3 update I can't build KDE4 ports anymore (tested on = 8.2-STABLE amd64 only). The problem is always reproduced with x11/kdelibs4.= The build stalls with hanging automoc4 processes. Any help is appreciated. >=20 > # ps | grep automoc > 18636 3 IN+ 0:00.02 /usr/local/bin/automoc4 /usr/obj/usr/local/tind= erbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3su= pport/ > 18640 3 IN+ 0:00.00 /usr/local/bin/automoc4 /usr/obj/usr/local/tind= erbox/portstrees/FreeBSD/ports/x11/kdelibs4/work/kdelibs-4.6.3/build/kde3su= pport/ >=20 > # gdb automoc4 18636 =2E.. > Reading symbols from /lib/libthr.so.3...done. > [New Thread 801c0ae40 (LWP 100660/automoc4)] > [New Thread 801c041c0 (LWP 100590/initial thread)] =2E.. > [Switching to Thread 801c0ae40 (LWP 100660/automoc4)] > 0x000000080104c99c in select () at select.S:3 > 3 RSYSCALL(select) > (gdb) bt > #0 0x000000080104c99c in select () at select.S:3 > #1 0x00000008008502cd in QProcessManager::run (this=3D0x800b196e0) at io= /qprocess_unix.cpp:245 > #2 0x0000000800749bde in QThreadPrivate::start (arg=3D0x800b196e0) at th= read/qthread_unix.cpp:320 > #3 0x00000008017985e1 in thread_start (curthread=3D0x801c0ae40) at /usr/= freebsd/8/src/lib/libthr/thread/thr_create.c:288 > #4 0x0000000000000000 in ?? () > Error accessing memory address 0x7fffffbff000: Bad address. > Current language: auto; currently asm >=20 > # gdb automoc4 18640 =2E.. > 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libthr/ar= ch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x00000008017a24cc in _umtx_op_err () at /usr/freebsd/8/src/lib/libth= r/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x00000008017a21bc in __thr_umutex_lock (mtx=3D0x8018a7380, id=3D1005= 90) at /usr/freebsd/8/src/lib/libthr/thread/thr_umtx.c:58 > #2 0x000000080179d04a in init_static (thread=3D0x801c041c0, mutex=3D0x80= 1166c78) at thr_umtx.h:88 > #3 0x000000080179d7ad in __pthread_mutex_lock (mutex=3D0x801166c78) at /= usr/freebsd/8/src/lib/libthr/thread/thr_mutex.c:441 > #4 0x000000080104b21e in _flockfile (fp=3D0x801166be0) at /usr/freebsd/8= /src/lib/libc/stdio/_flock_stub.c:70 > #5 0x0000000801021515 in fileno (fp=3D0x801166be0) at /usr/freebsd/8/src= /lib/libc/stdio/fileno.c:52 > #6 0x000000080084f109 in QProcessPrivate::execChild (this=3D0x801c51600,= workingDir=3D0x0, path=3D0x0, argv=3D0x801c5b7c0, envp=3D0x0) at io/qproce= ss_unix.cpp:712 > #7 0x0000000800851fc3 in QProcessPrivate::startProcess (this=3D0x801c516= 00) at io/qprocess_unix.cpp:665 > #8 0x0000000800802248 in QProcess::start (this=3D0x7fffffffcd10, program= =3D@0x7fffffffd8f8, arguments=3D@0x7fffffffcd00, mode=3D@0x7fffffffcd20) > at io/qprocess.cpp:1960 > #9 0x000000000040acd2 in AutoMoc::echoColor (this=3D0x7fffffffd8d0, msg= =3D@0x7fffffffce80) > at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc= .cpp:73 > #10 0x000000000040517c in AutoMoc::generateMoc (this=3D0x7fffffffd8d0, so= urceFile=3D@0x801c0f910, mocFileName=3D@0x801c0f918) > at /usr/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc= .cpp:569 > #11 0x0000000000408011 in AutoMoc::run (this=3D0x7fffffffd8d0) at /usr/ob= j/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #12 0x0000000000409135 in main (argc=3D6, argv=3D0x7fffffffd9a8) at /usr/= obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 > Current language: auto; currently asm You did not supplied enough information. Which of the processes is parent, which is child ? Note that there are other threads in the pid 18636. What does they do ? If you would allow me to make some guess, then I could assume that pid 18640 is the child. Note that the child is waiting for the pthread mutex locked which protects the stdio' FILE structure. Now, assume additionally that the parent had the FILE locked in one thread while another thread did the fork. Then, the child process would never be able to obtain the lock because the lock was acquired by the thread that exists no longer (in the child process, only the thread that called fork is duplicated). In fact, I believe that you already reported a similar problem with malloc(3) some time ago. The root of the problem would be an undefined (and permitted by POSIX) behaviour of calling non-async signal safe functions in multithreaded process after fork. For malloc(3), this can be argued to be a quality of the implementation issue, but there is no reason to specially handle random mutexes, even from libc. If the mutex was locked during the fork time, the protected data structure is arguably in the inconsistent state after the fork in the child. --ylzTCAJcNegswXN2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3H4OAACgkQC3+MBN1Mb4hmmACg0vewlw1L/I1QfdnvsDUgZEIg 4cAAoJjppVwyjVgAN2Ch9rz3kCJSvIDv =qn3v -----END PGP SIGNATURE----- --ylzTCAJcNegswXN2-- From owner-freebsd-stable@FreeBSD.ORG Mon May 9 13:35:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B0151065675 for ; Mon, 9 May 2011 13:35:30 +0000 (UTC) (envelope-from michael.hoffmann@fh-dortmund.de) Received: from fh-dortmund.de (fhdo.dvz.FH-Dortmund.DE [193.25.16.3]) by mx1.freebsd.org (Postfix) with ESMTP id A79C98FC0A for ; Mon, 9 May 2011 13:35:29 +0000 (UTC) Received: from gatekeeper.informatik.fh-dortmund.de (gatekeeper.informatik.FH-Dortmund.DE [193.25.22.84]) by fh-dortmund.de (Switch-3.3.0/Switch-3.3.0) with ESMTP id p49Cxgxi000082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 May 2011 14:59:59 +0200 (MEST) Received: from custos.hw1.fb4.fh (n43.informatik.FH-Dortmund.DE [193.25.22.43]) by gatekeeper.informatik.fh-dortmund.de (8.12.10/8.12.10) with ESMTP id p49Bad5x016313 for ; Mon, 9 May 2011 13:37:14 +0200 From: Michael Hoffmann Organization: FH Dortmund To: freebsd-stable@freebsd.org Date: Mon, 9 May 2011 13:36:39 +0200 User-Agent: KMail/1.9.10 References: <201105062037.50937.benzene@arcor.de> <4DC50918.3030100@gmx.de> In-Reply-To: <4DC50918.3030100@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105091336.39646.michael.hoffmann@fh-dortmund.de> Subject: Re: Double installation of liblzma.so.5 breaks libarchive.so.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 13:35:30 -0000 Matthias, > It's apparently not designed to do that. Does "portmaster > --check-depends" complain? It's a shell script from > ports-mgmt/portmaster, just install and run it, it's lightweight (as > opposed to portupgrade). Now there seems to be no trouble anymore. > Was your library path in csh created or suggested by pth-related ports? Hard to say. I've logged things like mergemaster by the script command. Until 7.2 I just found messages like ./etc/csh.cshrc and installed have the same CVS Id, deleting so I can't exactly track when this first appeared in csh.cshrc. (Maybe it's a good idea to trace changes of etc in a version control system from time to time.) > (Perhaps there could be something in the ports framework that warns if > port duplicates base system functionality and suggests to deinstall a > port that is no longer needed -- Would be nice. From owner-freebsd-stable@FreeBSD.ORG Mon May 9 15:39:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627621065673 for ; Mon, 9 May 2011 15:39:51 +0000 (UTC) (envelope-from makc@issp.ac.ru) Received: from mail.issp.ac.ru (mail.issp.ac.ru [77.236.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id D07F68FC15 for ; Mon, 9 May 2011 15:39:50 +0000 (UTC) Received: from [62.63.90.99] [62.63.90.99:19887] (HELO/EHLO luna.dio.ru, authenticated with PLAIN) by mail.issp.ac.ru with ESMTP/inet id p49FeID8031261 (using TLSv1/SSLv3, with cipher DHE-RSA-AES256-SHA (256 bits), verified NO) Mon, 9 May 2011 19:40:18 +0400 (MSD) From: Max Brazhnikov Organization: ISSP RAS To: Kostik Belousov Date: Mon, 9 May 2011 19:39:46 +0400 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.2; amd64; ; ) References: <201105091240.57785.makc@issp.ac.ru> <20110509124104.GF48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110509124104.GF48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105091939.47230.makc@issp.ac.ru> Cc: freebsd-stable@freebsd.org Subject: Re: automoc4 processes lock again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 15:39:51 -0000 On Mon, 9 May 2011 15:41:05 +0300, Kostik Belousov wrote: > You did not supplied enough information. > Which of the processes is parent, which is child ? > Note that there are other threads in the pid 18636. What does they do ? Here is backtraces from all threads http://people.freebsd.org/~makc/automoc4.bt 63373 is a parent now, 63374 is a child. There were no related changes in Qt4 and automoc4 sources, probably my update from 8.2-PRERELEASE to STABLE a week ago triggered the issue. > If you would allow me to make some guess, then I could assume that pid > 18640 is the child. Note that the child is waiting for the pthread > mutex locked which protects the stdio' FILE structure. Now, assume > additionally that the parent had the FILE locked in one thread while > another thread did the fork. Then, the child process would never be able > to obtain the lock because the lock was acquired by the thread that > exists no longer (in the child process, only the thread that called > fork is duplicated). > > In fact, I believe that you already reported a similar problem with > malloc(3) some time ago. The root of the problem would be an undefined > (and permitted by POSIX) behaviour of calling non-async signal safe > functions in multithreaded process after fork. > > For malloc(3), this can be argued to be a quality of the implementation > issue, but there is no reason to specially handle random mutexes, even > from libc. If the mutex was locked during the fork time, the protected > data structure is arguably in the inconsistent state after the fork in > the child. From owner-freebsd-stable@FreeBSD.ORG Mon May 9 16:59:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CDB8106564A for ; Mon, 9 May 2011 16:59:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA238FC0A for ; Mon, 9 May 2011 16:59:11 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p49GwwHj075713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 19:58:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p49GwweB076272; Mon, 9 May 2011 19:58:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p49GwwSd076271; Mon, 9 May 2011 19:58:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 May 2011 19:58:58 +0300 From: Kostik Belousov To: Max Brazhnikov Message-ID: <20110509165858.GG48734@deviant.kiev.zoral.com.ua> References: <201105091240.57785.makc@issp.ac.ru> <20110509124104.GF48734@deviant.kiev.zoral.com.ua> <201105091939.47230.makc@issp.ac.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wthRHICJPcnPKmvQ" Content-Disposition: inline In-Reply-To: <201105091939.47230.makc@issp.ac.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: automoc4 processes lock again X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 16:59:12 -0000 --wthRHICJPcnPKmvQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 09, 2011 at 07:39:46PM +0400, Max Brazhnikov wrote: > On Mon, 9 May 2011 15:41:05 +0300, Kostik Belousov wrote: > > You did not supplied enough information. > > Which of the processes is parent, which is child ? > > Note that there are other threads in the pid 18636. What does they do ? >=20 > Here is backtraces from all threads http://people.freebsd.org/~makc/autom= oc4.bt > 63373 is a parent now, 63374 is a child. >=20 > There were no related changes in Qt4 and automoc4 sources, probably my up= date from 8.2-PRERELEASE to STABLE a week ago triggered the issue. It is obviously application bug, yes, I think my guess was right. Thou shalt not call non-async safe functions in thy child of multithreaded process. Since it is a race, I see it more curious that it did not manifested itself prevously. >=20 > > If you would allow me to make some guess, then I could assume that pid > > 18640 is the child. Note that the child is waiting for the pthread > > mutex locked which protects the stdio' FILE structure. Now, assume > > additionally that the parent had the FILE locked in one thread while > > another thread did the fork. Then, the child process would never be able > > to obtain the lock because the lock was acquired by the thread that > > exists no longer (in the child process, only the thread that called > > fork is duplicated). > >=20 > > In fact, I believe that you already reported a similar problem with > > malloc(3) some time ago. The root of the problem would be an undefined > > (and permitted by POSIX) behaviour of calling non-async signal safe > > functions in multithreaded process after fork. > >=20 > > For malloc(3), this can be argued to be a quality of the implementation > > issue, but there is no reason to specially handle random mutexes, even > > from libc. If the mutex was locked during the fork time, the protected > > data structure is arguably in the inconsistent state after the fork in > > the child. --wthRHICJPcnPKmvQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3IHVEACgkQC3+MBN1Mb4hkfwCdHFLpK//7Je2urHljp+3BmO73 +9gAnR9EuW0Ux0+JOnH761vtanXJvAf+ =7fg5 -----END PGP SIGNATURE----- --wthRHICJPcnPKmvQ-- From owner-freebsd-stable@FreeBSD.ORG Mon May 9 17:02:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C6AC106566B for ; Mon, 9 May 2011 17:02:51 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3A18FC0C for ; Mon, 9 May 2011 17:02:50 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QJTqv-000LzP-Vl for freebsd-stable@freebsd.org; Mon, 09 May 2011 19:02:49 +0200 Message-ID: <4DC81E22.5030806@it4pro.pl> Date: Mon, 09 May 2011 19:02:26 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Stable References: <4DC6A277.4030801@it4pro.pl> <4DC6E23B.2040207@it4pro.pl> In-Reply-To: <4DC6E23B.2040207@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.8 X-Spam-Score-Int: -77 X-Exim-Version: 4.75 (build at 30-Mar-2011 13:28:38) X-Date: 2011-05-09 19:02:49 X-Connected-IP: 78.8.144.74:62697 X-Message-Linecount: 103 X-Body-Linecount: 89 X-Message-Size: 3120 X-Body-Size: 2507 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 17:02:51 -0000 W dniu 2011-05-08 20:34, Bartosz Stec pisze: > W dniu 2011-05-08 16:02, Bartosz Stec pisze: >> Hi list! >> >> I moved my 8-STABLE system from cheap AMD64 machine to Proliant >> DL180G6 (full ZFS send -> receive) yesterday. >> Operation was succesfull, system booted and everything worked fine. >> Still, I wanted to perform full world + kernel rebuild with updated >> sources and CPUTYPE (core2 instead of athlon64) and removed unused >> NIC drivers from kernel. >> >> New kernel panicked during boot. I rebuilt kernel again, without any >> CPUTYPE in make.conf, but panic was still there. Old kernel (built at >> 8.04.2011) is booting fine. >> First panic line says: >> >> panic: m_getzone: m_getjcl: invalid cluster type. >> >> >> I made a por quality photo of screen with stack backtrace and it's >> available here: http://www.picamatic.com/view/7544359_IMAG0029/ >> >> Now the funny thing: >> >> Igb driver is compiled into the kernel. If I add igb driver to >> loader.conf kernel complains of course: >> >> module_register: module pci/igb already exists! >> Module pci/igb failed to register: 17 >> >> >> but there's no panic! >> >> When I remove 'if_igb_load="YES"' from loader.conf, I experience >> panic visible above. >> >> Kernel config: http://pastebin.com/G7K0vfuJ >> >> > Picamatic seems offline now, so here's another link to backtrace > photo: http://i51.tinypic.com/nyuux3.jpg > > Maybe make.conf will be useful too: > > CPUTYPE?=core2 > KERNCONF=PROLIANT > #MAKEOPTS=-j3 > #WITH_DEBUG=yes > #DEBUG_FLAGS=-g > > # default build settings for ports collection > .if ${.CURDIR:M*/ports/*} && !defined(NOCCACHE) > CFLAGS=-O2 -pipe > #CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops > BUILD_OPTIMIZED=YES > WITH_OPENSSL=YES > WITH_XCHARSET=all > WITH_CHARSET=utf8 > WITH_COLLATION=utf8_general_ci > .endif > > # default build settings for base system > .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} && > !defined(NOCCACHE) > > CFLAGS=-O2 -pipe > COPTFLAGS=-O2 -pipe > > CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1} > CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} > > .endif > > # added by use.perl 2011-05-08 17:13:51 > PERL_VERSION=5.10.1 > > > Dear list, shoud I provide some additional data to help find a problem, or just fill a PR :)? Maybe full dmesg output will help?: http://pastebin.com/Es0CKD64 It's from kernel which is panicking. -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Mon May 9 21:32:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49C5E106567B for ; Mon, 9 May 2011 21:32:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id EB1A88FC12 for ; Mon, 9 May 2011 21:32:12 +0000 (UTC) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id hZXF1g0011c6gX85AZYCpV; Mon, 09 May 2011 21:32:12 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.westchester.pa.mail.comcast.net with comcast id hZY41g00K1t3BNj3jZY81r; Mon, 09 May 2011 21:32:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AC27E102C19; Mon, 9 May 2011 14:32:02 -0700 (PDT) Date: Mon, 9 May 2011 14:32:02 -0700 From: Jeremy Chadwick To: Michael Hoffmann Message-ID: <20110509213202.GA67855@icarus.home.lan> References: <201105062037.50937.benzene@arcor.de> <4DC50918.3030100@gmx.de> <201105091336.39646.michael.hoffmann@fh-dortmund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105091336.39646.michael.hoffmann@fh-dortmund.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Double installation of liblzma.so.5 breaks libarchive.so.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 May 2011 21:32:13 -0000 On Mon, May 09, 2011 at 01:36:39PM +0200, Michael Hoffmann wrote: > > Was your library path in csh created or suggested by pth-related ports? > > Hard to say. I've logged things like mergemaster by the script command. Until > 7.2 I just found messages like > > ./etc/csh.cshrc and installed have the same CVS Id, deleting > > so I can't exactly track when this first appeared in csh.cshrc. (Maybe it's a > good idea to trace changes of etc in a version control system from time to > time.) You can see commits for this file on all branches (specifically RELENG_7 and RELENG_8) here: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/csh.cshrc I spent some time looking through all the annotations during each commit: I see no evidence that an LD_LIBRARY_PATH override was ever added to that file at any time. Furthermore, on FreeBSD, system-wide changes like this tend to get applied in a much more reliable way (global yet shell-independent): via ldconfig(8). I have no explanation for how said line got added to /etc/csh.cshrc or src/etc/csh.cshrc for you. Possibly a port, or a mistake by an administrator, did this. And if a port did it, it shouldn't have; it should have used ldconfig(8) to do things correctly. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue May 10 12:52:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5437106564A for ; Tue, 10 May 2011 12:52:25 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 66FC38FC15 for ; Tue, 10 May 2011 12:52:24 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 26F373982B; Tue, 10 May 2011 14:52:20 +0200 (SAST) Date: Tue, 10 May 2011 14:52:20 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20110510125220.GA88338@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: MCA: CPU 0 UNCOR PCC DTLB L1 error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 May 2011 12:52:26 -0000 Hi, I have seen this panic a few times on a Gigabyte E350N-USB3 running 8-STABLE. I have only seen it while in X, but then the machine is always in X. At first, I just got these hangs, so bought a PCI-express RS232 card and could see these at last. For some reason it does not go past this, so I have not been able to get a dump yet. Have anybody an idea of why this is or how to debug it further? I searched the archives and found something similar about a year ago, but it looks like it was solved with a fix that got committed. http://www.freebsd.org/cgi/query-pr.cgi?pr=140338 I have now disabled mca in loader.conf with 'hw.mca.enabled="0"' and I have not seen that panic again. I do occasionally see a panic in devfs_open(), but I guess that should be handled in another thread. The kernel is basically a GENERIC kernel with puc uncommented and the following in loader.conf vm.kmem_size="12G" hw.mca.enabled="0" zfs_load="YES" ahci_load="YES" xhci_load="YES" amdtemp_load="YES" ng_ubt_load="YES" uplcom_load="YES" Here is the panic message and after that dmesg. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org #################################################### MCA: Bank 0, Status 0xb600000000010015 MCA: Global Cap 0x0000000000000106, Status 0x0000000000000004 MCA: Vendor "AuthenticAMD", ID 0x500f10, APIC ID 0 MCA: CPU 0 UNCOR PCC DTLB L1 error MCA: Address 0x8016c4000 Fatal trap 28: machine check trap while in user mode cpuid = 0; apic id = 00 instruction pointer = 0x43:0x80156af85 stack pointer = 0x3b:0x7fffffffcb18 frame pointer = 0x3b:0x80fe87800 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 2484 (initial thread) trap number = 28 panic: machine check trap cpuid = 0 KDB: stack backtrace: #0 0xffffffff80608d5e at kdb_backtrace+0x5e #1 0xffffffff805d6707 at panic+0x187 #2 0xffffffff808bf4c0 at trap_fatal+0x290 #3 0xffffffff808bfaa9 at trap+0x109 #4 0xffffffff808a7d94 at calltrap+0x8 #################################################### Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #1: Fri Apr 29 10:14:26 SAST 2011 jhay@angel.cids.org.za:/usr/obj/usr/src/sys/ANGEL amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD E-350 Processor (1600.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f10 Family = 14 Model = 1 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 7841800192 (7478 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfcf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf800-0xf8ff mem 0xd0000000-0xdfffffff,0xfdfc0000-0xfdffffff irq 18 at device 1.0 on pci0 pci0: at device 1.1 (no driver attached) pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 puc0: port 0xef00-0xef1f,0xee00-0xee0f irq 16 at device 8.0 on pci2 puc0: [FILTER] uart0: <16950 or compatible> on puc0 uart0: [FILTER] uart1: <16950 or compatible> on puc0 uart1: [FILTER] ahci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 19 at device 17.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 4 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 18 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe02d000-0xfe02d0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 ohci1: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0xfe02b000-0xfe02b0ff irq 17 at device 19.2 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 ACPI Warning: For \\_SB_.PCI0.P2P_._PRT: Return Package has no elements (empty) (20101013/nspredef-572) pci3: on pcib3 ohci2: mem 0xfe02a000-0xfe02afff irq 18 at device 20.5 on pci0 ohci2: [ITHREAD] usbus4: on ohci2 pcib4: at device 21.0 on pci0 pci4: on pcib4 re0: port 0xce00-0xceff mem 0xfdbff000-0xfdbfffff,0xfdbf8000-0xfdbfbfff irq 17 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 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: 1c:6f:65:c2:00:a7 re0: [ITHREAD] pcib5: at device 21.1 on pci0 pci5: on pcib5 xhci0: mem 0xfdafe000-0xfdafffff irq 17 at device 0.0 on pci5 xhci0: [ITHREAD] xhci0: 32 byte context size. usbus5 on xhci0 ohci3: mem 0xfe029000-0xfe029fff irq 18 at device 22.0 on pci0 ohci3: [ITHREAD] usbus6: on ohci3 ehci2: mem 0xfe028000-0xfe0280ff irq 17 at device 22.2 on pci0 ehci2: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci2 amdtemp0: on hostb4 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: port 0x70-0x73 irq 8 on acpi0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range hwpstate0: on cpu0 ZFS filesystem version 4 ZFS storage pool version 15 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 5.0Gbps Super Speed USB v3.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: <0x1033> at usbus5 uhub5: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! uhub4: 2 ports with 2 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub0: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub5: 4 ports with 4 removable, self powered Root mount waiting for: usbus7 usbus3 usbus1 Root mount waiting for: usbus7 usbus3 usbus1 uhub7: 4 ports with 4 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered Root mount waiting for: usbus3 usbus1 Trying to mount root from zfs:dam/ROOT/amd64 ugen2.2: at usbus2 ugen0.2: at usbus0 uplcom0: on usbus0 ukbd0: on usbus2 kbd2 at ukbd0 ums0: on usbus2 ums0: 18 buttons and [XYZT] coordinates ID=2 ugen2.3: at usbus2 ubt0: on usbus2 ugen0.3: at usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() ubt0: ubt_ctrl_write_callback:667: control transfer failed: USB_ERR_TIMEOUT ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout From owner-freebsd-stable@FreeBSD.ORG Tue May 10 14:56:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3FBE1065672 for ; Tue, 10 May 2011 14:56:41 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 498858FC23 for ; Tue, 10 May 2011 14:56:40 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p4AEuUmG042928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 May 2011 17:56:36 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4DC9521E.3060503@digsys.bg> Date: Tue, 10 May 2011 17:56:30 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110430211927.GA67374@nargothrond.kdm.org> <20110503034737.GA52416@nargothrond.kdm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: mps driver instability under stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 May 2011 14:56:41 -0000 On 03.05.11 20:28, Dmitry Morozovsky wrote: > Well, using > http://kb.lsi.com/KnowledgebaseArticle16414.aspx > I downgraded to version 8-fixed, and at least topology errors disappear. > Would this work with the Supermicro integrated LSI2008, like in X8DTH-6F? Mine came with firmware version 7, is there instability to be expected? Daniel From owner-freebsd-stable@FreeBSD.ORG Tue May 10 20:16:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FAD106572B for ; Tue, 10 May 2011 20:16:28 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DAC988FC0A for ; Tue, 10 May 2011 20:16:27 +0000 (UTC) Received: by iwn33 with SMTP id 33so7828078iwn.13 for ; Tue, 10 May 2011 13:16:27 -0700 (PDT) Received: by 10.42.154.130 with SMTP id q2mr8154768icw.4.1305058587212; Tue, 10 May 2011 13:16:27 -0700 (PDT) Received: from tech304 (supranet-tech.secure-on.net [66.170.8.18]) by mx.google.com with ESMTPS id d9sm3222151ibb.36.2011.05.10.13.16.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 13:16:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: Date: Tue, 10 May 2011 15:16:24 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (FreeBSD) Subject: Re: df -t is broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 May 2011 20:16:28 -0000 Here's what happens when I try to truss a df -t http://paste.feld.me/3jb4c@raw Regards, Mark From owner-freebsd-stable@FreeBSD.ORG Tue May 10 20:26:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720E4106567D for ; Tue, 10 May 2011 20:26:43 +0000 (UTC) (envelope-from feld@feld.me) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 478538FC1A for ; Tue, 10 May 2011 20:26:42 +0000 (UTC) Received: by iyj12 with SMTP id 12so7884618iyj.13 for ; Tue, 10 May 2011 13:26:42 -0700 (PDT) Received: by 10.231.207.71 with SMTP id fx7mr5669549ibb.168.1305057456669; Tue, 10 May 2011 12:57:36 -0700 (PDT) Received: from tech304 (supranet-tech.secure-on.net [66.170.8.18]) by mx.google.com with ESMTPS id d9sm3216407ibb.53.2011.05.10.12.57.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 12:57:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Tue, 10 May 2011 14:57:33 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: User-Agent: Opera Mail/11.50 (FreeBSD) Subject: df -t is broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 May 2011 20:26:43 -0000 Ok, not sure if this really belongs on the STABLE mailing list but we'll see if you can help: - I was originally running FreeBSD 8.2-RELEASE - I patched my 8.2 source with the patches here: http://blog.vx.sk/archives/24-Backported-patches-for-FreeBSD-82-RELEASE.html - I built my system with "make buildworld && make buildkernel" and then installed both; rebooted. I know this isn't the norm, but I'm still running 8.2-RELEASE except these specific bugfixes so there really is no need for mergemaster - Now df -t doesn't work I noticed weird processes hanging and a few other things not running normally (monitoring). Turns out that anything that uses df -t just hangs (xymon, periodic, crons, find seems to hang when excluding filesystems)... doesn't matter what parameters you give it, it just hangs. Any thoughts on this? Regular df -h, etc work fine.... Thanks, Mark From owner-freebsd-stable@FreeBSD.ORG Tue May 10 21:38:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5279106566C for ; Tue, 10 May 2011 21:38:50 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 42CD08FC15 for ; Tue, 10 May 2011 21:38:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id p4ALcgB6084788; Wed, 11 May 2011 01:38:42 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 11 May 2011 01:38:42 +0400 (MSD) From: Dmitry Morozovsky To: Daniel Kalchev In-Reply-To: <4DC9521E.3060503@digsys.bg> Message-ID: References: <20110430211927.GA67374@nargothrond.kdm.org> <20110503034737.GA52416@nargothrond.kdm.org> <4DC9521E.3060503@digsys.bg> 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.2.6 (woozle.rinet.ru [0.0.0.0]); Wed, 11 May 2011 01:38:42 +0400 (MSD) Cc: freebsd-stable@freebsd.org Subject: Re: mps driver instability under stable/8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 May 2011 21:38:50 -0000 On Tue, 10 May 2011, Daniel Kalchev wrote: DK> > Well, using DK> > http://kb.lsi.com/KnowledgebaseArticle16414.aspx DK> > I downgraded to version 8-fixed, and at least topology errors disappear. DK> > DK> Would this work with the Supermicro integrated LSI2008, like in X8DTH-6F? DK> Mine came with firmware version 7, is there instability to be expected? I suppose you can upgrade to "fixed" firmware from the URL above; at least, I'd been in mostly the same situation: SM server with onboard LSI and LSI expander, and so far flashing 8-fixed firmware is good for me, at least machine did not hang in find-related tasks as it were before... -- 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 Wed May 11 07:29:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D3131065670 for ; Wed, 11 May 2011 07:29:07 +0000 (UTC) (envelope-from surii@snafu.de) Received: from waikiki.ops.eusc.inter.net (waikiki.ops.eusc.inter.net [84.23.254.155]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB6A8FC17 for ; Wed, 11 May 2011 07:29:07 +0000 (UTC) X-Trace: 507c73757269697c37382e35322e3234312e3134367c31514b3357472d30303041 6b562d49717c31333035303937363630 Received: from waikiki.ops.eusc.inter.net ([10.155.10.19] helo=localhost) by waikiki.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QK3WG-000AkV-Iq for freebsd-stable@freebsd.org; Wed, 11 May 2011 09:07:40 +0200 Message-ID: <4DCA35BB.5050402@snafu.de> Date: Wed, 11 May 2011 09:07:39 +0200 From: suri User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 78.52.241.146 X-SA-Exim-Mail-From: surii@snafu.de X-SA-Exim-Scanned: No (on waikiki.ops.eusc.inter.net); SAEximRunCond expanded to false Subject: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 07:29:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey List, i have problems with install/ update the port archivers/libzip. When i delete libzip-0.9.3 and then type make in the port directoty comes this: ===> Building for libzip-0.10 make all-recursive Making all in lib make all-am /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc - -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c -o zip_add.lo zip_add.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe - -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c zip_add.c -fPIC -DPIC -o .libs/zip_add.o *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10. *** Error code 1 Stop in /usr/ports/archivers/libzip. When i install libzip-0.9.3 as package and then try portmaster comes the same error. Have anyone the same problem or any idea. Thanks for help. Best Regards Jörg Surmann -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3KNbsACgkQ/RBh88nqFUXnFwCglo5fcaOMj/lxnDKwX1Uz+oV2 AL8Anj2t7gQccSDIYNQfMhQdJ/KaOKnz =XLbV -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed May 11 08:49:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 319BB106566C for ; Wed, 11 May 2011 08:49:15 +0000 (UTC) (envelope-from laa@cemu.ru) Received: from m.cemu.ru (m.cemu.ru [194.186.216.68]) by mx1.freebsd.org (Postfix) with ESMTP id D95468FC18 for ; Wed, 11 May 2011 08:49:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=laa.zp.ua; s=dkim; h=Sender:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=6g4pWAa4jGquYNGE7VGKLxx70E1fKbmEAgS8vcbkyME=; b=RaPSLzzNxBiyU0kt/Tb9p5yyLegOUMWGPVBznF/MnWZANPvkJl6sBA94kMn8Fb1Ju0U9279+l3j0CUdShw6b1ypYJk8RFffO2jOWLgKN5l+BUykPBiaFYvWhJbqkQChzImneBHQZrhfOuIwss2MXwzqJ3XlOwSoLYHfRjn/w9pE=; Received: by m.cemu.ru with local (Exim) (envelope-from ) id 1QK56X-0004Uh-7M for freebsd-stable@freebsd.org; Wed, 11 May 2011 12:49:13 +0400 Date: Wed, 11 May 2011 12:49:13 +0400 From: Lystopad Olexandr To: freebsd-stable@freebsd.org Message-ID: <20110511084913.GG96423@laa.zp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: laa Subject: wi0 and adhoc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 08:49:15 -0000 Hi! I have two freebsd boxes with 4.11 (yes, really!). They both serve wifi adhoc link (wi0 + pcic0: ) during many years with no problems. One box has died, and I change it to new one with 8.0-rel. New box have cbb0 and same wi0 card. So, now I have two boxes 4.11 and 8.0. Both with wi0 devices detected. Configs: 4.11 freebsd: wi0: flags=8843 mtu 1500 inet 192.168.197.1 netmask 0xfffffffc broadcast 192.168.197.3 ether 00:02:2d:05:77:1e media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps ) status: associated ssid IBSS 1:NT stationname sta1 channel 12 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 8.0 freebsd: wi0: flags=8843 metric 0 mtu 2290 ether 00:60:1d:f6:bf:a4 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: running wlan0: flags=8843 metric 0 mtu 1500 ether 00:60:1d:f6:bf:a4 inet 192.168.197.2 netmask 0xfffffffc broadcast 192.168.197.3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: running ssid IBSS channel 12 (2467 Mhz 11b) bssid 5e:b2:ec:5c:c1:8c country US authmode OPEN privacy OFF txpower 0 scanvalid 60 # ifconfig wlan0 list caps drivercaps=10301 cryptocaps=1 pciconf -lvc: ... cbb0@pci0:2:9:0: class=0x060700 card=0x14101524 chip=0x14101524 rev=0x01 hdr=0x02 vendor = 'ENE Technology Inc' device = 'CardBus Controller (CB-1420)' class = bridge subclass = PCI-CardBus cap 01[a0] = powerspec 1 supports D0 D1 D2 D3 current D0 ... dmesg: wi0: at port 0x100-0x13f irq 17 function 0 config 1 on pccard0 wi0: [ITHREAD] wi0: device timeout wi0: device timeout wi0: record read mismatch, rid=fd44, got=fc80 wi0: device timeout .... my questions are: 1. why txpower 0 in 8.0 box? 2. why too many ``device timeout'' messages in dmesg on 8.0 box? 3. why all pings lost in that link? thanks. -- Lystopad Olexandr From owner-freebsd-stable@FreeBSD.ORG Wed May 11 09:42:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2ADB10657C2 for ; Wed, 11 May 2011 09:42:49 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 04A328FC20 for ; Wed, 11 May 2011 09:42:48 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7cb]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id p4B9ES98029828 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 11 May 2011 15:14:29 +0600 (YEKST) (envelope-from eugene@zhegan.in) Message-ID: <4DCA5374.2020306@zhegan.in> Date: Wed, 11 May 2011 15:14:28 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110325 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Wed, 11 May 2011 15:14:29 +0600 (YEKST) X-Callback: Sender verified by milter-callback 1.5.14 at elf.hq.norma.perm.ru. X-Callback-Status: relay [] found in white list. X-Callback-Envelope-From: eugene@zhegan.in X-Spam-Status: No hits=0.8 bayes=0.5 testhits RDNS_NONE=0.793 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: a bunch of dumb questions about freebsd installing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 09:42:49 -0000 Hi. I have an IBM xSeries server, its ip-kvm and different FreeBSD images. The goal is to perform a remote installation of FreeBSD using server ip-kvm and USB devices it emulates. I can perform a non-remote installation in a wariety of ways but this post is about a remote one. 1) Since USB gives an cd(4) device, it's possible to boot from installation media, but impossible to use it for installation, because sysinstall wants acd0. Is there any way ? I cannot figure one, except using NFS or FTP install, which is not quite acceptable. Pure fixit sheel seems to be missing everything needed, at least I didn't succeeded at guessing where is mount for cd9660 and ls. 2) I downloaded a usb-key media, which is an .img file. This question does sound silly, and it really makes me look like a newbie and firsttimer (which, by the way, I am not, I'm installing FreeBSD for the second time :)) - but - anyway - what is exactly this .img and what is exactly an USB-key ? I used to think that, aside from it's internal design, this is the same think, but it appears that I'm wrong. Google didn't help much. 3) Why dd, reading an .img file and writing it to some /dev/da0 (as it's explained in handbook), which means it's not neither sliced nor partitioned (it also means that both loaders are presemt in image), makes a bootable media, and .img itself is not, because giving an .img file directly to the ip-kvm (and telling server to boot from it) produces 'No operating system installed' message ? Is there a way to produce a bootable image from such .img, without actual writing to the physical media, or at least using md(4) ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Wed May 11 09:50:25 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD8EA106564A for ; Wed, 11 May 2011 09:50:25 +0000 (UTC) (envelope-from eugene@zhegan.in) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id 182568FC22 for ; Wed, 11 May 2011 09:50:24 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7cb]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id p4B9o9jn032334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 11 May 2011 15:50:10 +0600 (YEKST) (envelope-from eugene@zhegan.in) Message-ID: <4DCA5BD1.9080402@zhegan.in> Date: Wed, 11 May 2011 15:50:09 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110325 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DCA5374.2020306@zhegan.in> In-Reply-To: <4DCA5374.2020306@zhegan.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Wed, 11 May 2011 15:50:10 +0600 (YEKST) X-Callback: Sender verified by milter-callback 1.5.14 at elf.hq.norma.perm.ru. X-Callback-Status: relay [] found in white list. X-Callback-Envelope-From: eugene@zhegan.in X-Spam-Status: No hits=0.8 bayes=0.5 testhits RDNS_NONE=0.793 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Subject: Re: a bunch of dumb questions about freebsd installing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 09:50:25 -0000 On 11.05.2011 15:14, Eugene M. Zheganin wrote: > Hi. > > I have an IBM xSeries server, its ip-kvm and different FreeBSD images. > The goal is to perform a remote installation of FreeBSD using server > ip-kvm and USB devices it emulates. > I can perform a non-remote installation in a wariety of ways but this > post is about a remote one. > > 1) Since USB gives an cd(4) device, it's possible to boot from > installation media, but impossible to use it for installation, because > sysinstall wants acd0. Is there any way ? I cannot figure one, except > using NFS or FTP install, which is not quite acceptable. Pure fixit > sheel seems to be missing everything needed, at least I didn't > succeeded at guessing where is mount for cd9660 and ls. > > 2) I downloaded a usb-key media, which is an .img file. This question > does sound silly, and it really makes me look like a newbie and > firsttimer (which, by the way, I am not, I'm installing FreeBSD for > the second time :)) - but - anyway - what is exactly this .img and > what is exactly an USB-key ? * " and what is exactly an USB-HDD ?" ATM I've read that these are different mass-storage classes. > I used to think that, aside from it's internal design, this is the > same think, but it appears that I'm wrong. Google didn't help much. > > 3) Why dd, reading an .img file and writing it to some /dev/da0 (as > it's explained in handbook), which means it's not neither sliced nor > partitioned (it also means that both loaders are presemt in image), > makes a bootable media, and .img itself is not, because giving an .img > file directly to the ip-kvm (and telling server to boot from it) > produces 'No operating system installed' message ? Is there a way to > produce a bootable image from such .img, without actual writing to the > physical media, or at least using md(4) ? > Please ignore two last questions. Seems like FreeBSD tracker is seeding a corrupted memstick image - some of the first megabytes are plain zeroes, and the md5 is not the md5 from ftp. Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Wed May 11 10:26:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6569106564A for ; Wed, 11 May 2011 10:26:52 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 160B18FC0C for ; Wed, 11 May 2011 10:26:51 +0000 (UTC) Received: by bwz12 with SMTP id 12so431097bwz.13 for ; Wed, 11 May 2011 03:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-authentication-warning:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=+LYFBwLnQPr0amN5qkAJ1e7FDLyDAYxx7QGphlc1qPI=; b=qzlRobfFjt5SMI3X3hn09RhPPu9VVX3DMmm+m4H60N47dKJ2VPRmRGWrpvPVY/4EFc DjEXkgwwweEDEAz2Z9yISvgTlBVAqrG5a0kn6FMounrxZO2ONayeh1d1l8G/GqxwM1b3 X33foyVq5zbRBox+xH742uXnI8F8ta5NTq5ho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=aViH0CsWs/UGDsPjalRbFDa1lHmZSczpUYNzbY1czO2HtpzhYvSp/fmZlE7DDcDEmk CAawuwFTGM0nKqpGP4YYiJ7m6rY3LKWQxT6wxKTNSQOhS4x3gv7nC81IrIHEFfRFfoUr 7FY5sfhCVZiMUeM7HEzLzAHj/20ZFO5jzKROs= Received: by 10.204.20.66 with SMTP id e2mr5733378bkb.141.1305108039606; Wed, 11 May 2011 03:00:39 -0700 (PDT) Received: from procyon.xvoid.org ([213.132.76.142]) by mx.google.com with ESMTPS id x6sm4836728bkv.12.2011.05.11.03.00.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 03:00:38 -0700 (PDT) Received: from procyon.xvoid.org (yuri@procyon.xvoid.org [IPv6:::1]) by procyon.xvoid.org (8.14.4/8.14.4) with ESMTP id p4BA0ZxC014865; Wed, 11 May 2011 14:00:35 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by procyon.xvoid.org (8.14.4/8.14.4/Submit) id p4BA0ZBW014864; Wed, 11 May 2011 14:00:35 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: procyon.xvoid.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Wed, 11 May 2011 14:00:35 +0400 From: Yuri Pankov To: "Eugene M. Zheganin" Message-ID: <20110511100035.GB1319@procyon.xvoid.org> References: <4DCA5374.2020306@zhegan.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCA5374.2020306@zhegan.in> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: a bunch of dumb questions about freebsd installing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 10:26:52 -0000 On Wed, May 11, 2011 at 03:14:28PM +0600, Eugene M. Zheganin wrote: > Hi. > > I have an IBM xSeries server, its ip-kvm and different FreeBSD images. > The goal is to perform a remote installation of FreeBSD using server > ip-kvm and USB devices it emulates. > I can perform a non-remote installation in a wariety of ways but this > post is about a remote one. > > 1) Since USB gives an cd(4) device, it's possible to boot from > installation media, but impossible to use it for installation, because > sysinstall wants acd0. Is there any way ? I cannot figure one, except > using NFS or FTP install, which is not quite acceptable. Pure fixit > sheel seems to be missing everything needed, at least I didn't succeeded > at guessing where is mount for cd9660 and ls. Try using Options -> Re-scan Devices, helped here with USB CD drive. [...] Yuri From owner-freebsd-stable@FreeBSD.ORG Wed May 11 10:30:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20203106564A for ; Wed, 11 May 2011 10:30:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id C14928FC23 for ; Wed, 11 May 2011 10:30:56 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id iAUD1g0031swQuc56AWxhi; Wed, 11 May 2011 10:30:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id iAWv1g00E1t3BNj3bAWvmB; Wed, 11 May 2011 10:30:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D8260102C36; Wed, 11 May 2011 03:30:53 -0700 (PDT) Date: Wed, 11 May 2011 03:30:53 -0700 From: Jeremy Chadwick To: "Eugene M. Zheganin" Message-ID: <20110511103053.GA36021@icarus.home.lan> References: <4DCA5374.2020306@zhegan.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCA5374.2020306@zhegan.in> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: a bunch of dumb questions about freebsd installing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 10:30:57 -0000 On Wed, May 11, 2011 at 03:14:28PM +0600, Eugene M. Zheganin wrote: > I have an IBM xSeries server, its ip-kvm and different FreeBSD images. > The goal is to perform a remote installation of FreeBSD using server > ip-kvm and USB devices it emulates. > I can perform a non-remote installation in a wariety of ways but > this post is about a remote one. > > 1) Since USB gives an cd(4) device, it's possible to boot from > installation media, but impossible to use it for installation, > because sysinstall wants acd0. Is there any way ? I cannot figure > one, except using NFS or FTP install, which is not quite acceptable. > Pure fixit sheel seems to be missing everything needed, at least I > didn't succeeded at guessing where is mount for cd9660 and ls. The FreeBSD installer can in fact detect this situation. USB CDROM drives are emulated via SCSI, so they show up under the cd(4) driver. /dev/cd* is indeed examined during the "CDROM" installation medium detection phase of sysinstall(8). The problem almost certainly stems from how the IP KVM "virtual media" feature works or how it implements support for its "virtual CD" media, or in some cases "translation media" (e.g. you burn a FreeBSD ISO to a physical CD, insert the CD into your laptop, then use the IP KVM software (via Java or a native client) to "connect" the USB CDROM IP KVM layer to your laptop's CDROM drive). The issue is not specific to USB CD drives either: the same has happened to people using classic ATA CDROM drives who have burnt an ISO using unreliable or "strange" burning software. This then gets into a discussion about how the CD devices are "probed" during sysinstall. It's been a while since I've looked at that code, but I remember explicitly that very specific "slices" have to exist for the installation to be detected correctly, e.g. some systems will show a /dev/da0 but not a /dev/da0a, which is what the installer may look for. Please keep reading for further comments about IP KVM "virtual media". > 2) I downloaded a usb-key media, which is an .img file. This > question does sound silly, and it really makes me look like a newbie > and firsttimer (which, by the way, I am not, I'm installing FreeBSD > for the second time :)) - but - anyway - what is exactly this .img > and what is exactly an USB-key ? I used to think that, aside from > it's internal design, this is the same think, but it appears that > I'm wrong. Google didn't help much. A USB key is a USB flash drive, sometimes known as "pen drive" or "memory stick". The .img file is something that you can literally dd directly to the USB flash drive as so: dd if=FreeBSD-8.2-RELEASE-amd64-memstick.img of=/dev/da0 bs=64k The .img file is fully bootable when installed on a USB flash-based medium. I have read on some forums that people seem to think it's an ISO image, but to my knowledge it isn't. > 3) Why dd, reading an .img file and writing it to some /dev/da0 (as > it's explained in handbook), which means it's not neither sliced nor > partitioned (it also means that both loaders are presemt in image), > makes a bootable media, and .img itself is not, because giving an > .img file directly to the ip-kvm (and telling server to boot from > it) produces 'No operating system installed' message ? Is there a > way to produce a bootable image from such .img, without actual > writing to the physical media, or at least using md(4) ? The .img file **is** bootable. Think of it as a "raw hard disk" image, so it includes the bootloader located at LBA 0 (sector 0), etc... You can boot directly from it. I can absolutely assure you of this with 100% reliability, because all of our servers get built/installed via USB flash drives. If your "IP KVM" virtual media cannot boot from it, that is a separate problem and likely pertains to "USB device emulation" issues. There are numerous "emulation modes" available (floppy, hard disk, flash drive, ZIP drive, JAZ drive, and many others). Which your vendor chose to implement, or how to make it work how you need it to, is unknown to me; please discuss this with your IP KVM vendor. Bottom line: IP KVM's "virtual media" feature sounds great on paper, but every time I've seen it implemented it's wonky. I've seen it work, and it's pretty awesome when it does, but I'm not surprised at the complexities you're going through. I have the same opinion of IPMI. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed May 11 11:25:32 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A127F1065670 for ; Wed, 11 May 2011 11:25:32 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECD68FC19 for ; Wed, 11 May 2011 11:25:31 +0000 (UTC) Received: (qmail 87311 invoked by uid 89); 11 May 2011 12:58:50 +0200 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 11 May 2011 12:58:50 +0200 Message-ID: <4DCA6BEA.4060605@bytecamp.net> Date: Wed, 11 May 2011 12:58:50 +0200 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: 8-STABLE and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 11:25:32 -0000 We are running 8-STABLE (csupped at 20110504) on a NFS fileserver. It has 32 GB RAM and uses ZFS: home ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 logs mirror ONLINE 0 0 0 da12 ONLINE 0 0 0 da13 ONLINE 0 0 0 cache ad4 ONLINE 0 0 0 ad8 ONLINE 0 0 0 Before upgrading from 8.0, the machine never used the whole system memory, it left about 10 GB free even after about 100 days uptime. Now, it eats RAM insanely (wired is between 29 GB and 30 GB), which is quite good I think, but after about 3 days uptime, we now have 106 MB swapped out. Both L2ARC SSDs are ~74 GB in size, arc_summary prints the following values: ARC Size: Current Size: 76.21% 23440.22M (arcsize) Target Size: (Adaptive) 76.52% 23535.40M (c) Min Size (Hard Limit): 12.50% 3844.77M (c_min) Max Size (High Water): ~8:1 30758.16M (c_max) L2 ARC Size: Current Size: (Adaptive) 88466.19M Header Size: 0.29% 259.21M The following sysctls were set: security.bsd.see_other_uids=0 kern.maxvnodes=400000 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=1024000 net.inet.udp.maxdgram=57344 vfs.ufs.dirhash_maxmem=25165824 My question now: why does the machine swap, is this normal behaviour? Why is wired at about 30 GB if ARC=23 GB and L2ARC-header=259 MB? with kind regards, Robert Schulze From owner-freebsd-stable@FreeBSD.ORG Wed May 11 11:55:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B3AA1065670 for ; Wed, 11 May 2011 11:55:53 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [IPv6:2001:470:28:38a::1]) by mx1.freebsd.org (Postfix) with ESMTP id D51158FC0A for ; Wed, 11 May 2011 11:55:52 +0000 (UTC) Received: from www.liukuma.net (localhost [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 870EF1CC8D; Wed, 11 May 2011 14:55:51 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 870EF1CC8D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=liukuma.net; s=liukudkim; t=1305114951; bh=t/kCFtEM8Pvg+1QaO4Fz+tJo5aI+MMSrquwuGJ3J2OE=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cRL4+0+AmM33rN+rtS6zaoJvhqNI1MXXxPPunj/Ppt8X6Dmt21u2YmmAIJyneHZp7 aUK4z8WxSFscfahU/NpQqCCtv3X+7L8jtjYezXb19gD4IfpR+zC1A8f3bvbHFXvs5G 6R9shfd8qmK5BLNhE8uD/BDdZUhnAoz328EqwYVY= X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by www.liukuma.net (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0TMMwUREo4AB; Wed, 11 May 2011 14:55:48 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 714311CC8B; Wed, 11 May 2011 14:55:45 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.8.3 www.liukuma.net 714311CC8B Message-ID: <253BF9B4CB974E538DEBA3044ED8AF44@rivendell> From: "Reko Turja" To: "Robert Schulze" , References: <4DCA6BEA.4060605@bytecamp.net> In-Reply-To: <4DCA6BEA.4060605@bytecamp.net> Date: Wed, 11 May 2011 14:55:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Cc: Subject: Re: 8-STABLE and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 11:55:53 -0000 > My question now: why does the machine swap, is this normal=20 > behaviour? > Why is wired at about 30 GB if ARC=3D23 GB and L2ARC-header=3D259 MB? If I've understood it right from the mailing lists, ZFS returns memory=20 back to the OS from caches somewhat lazily, so in times of high memory=20 load ZFS system can cause some swapping. Of course, once the situation with memory load is over, swap will=20 still continue to show the max amount swapped ever, even if everything=20 is again back in real memory. So nothing to worry about I'd say. -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Wed May 11 12:00:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC17E106566C for ; Wed, 11 May 2011 12:00:57 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 031098FC16 for ; Wed, 11 May 2011 12:00:56 +0000 (UTC) Received: (qmail 43979 invoked by uid 89); 11 May 2011 14:00:55 +0200 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 11 May 2011 14:00:55 +0200 Message-ID: <4DCA7A77.2050700@bytecamp.net> Date: Wed, 11 May 2011 14:00:55 +0200 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DCA6BEA.4060605@bytecamp.net> <253BF9B4CB974E538DEBA3044ED8AF44@rivendell> In-Reply-To: <253BF9B4CB974E538DEBA3044ED8AF44@rivendell> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8-STABLE and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 12:00:57 -0000 Hi, Am 11.05.2011 13:55, schrieb Reko Turja: > > Of course, once the situation with memory load is over, swap will still > continue to show the max amount swapped ever, even if everything is > again back in real memory. the swap increases almost linearly at about 1 MB/hour. with kind regards, Robert Schulze From owner-freebsd-stable@FreeBSD.ORG Wed May 11 12:16:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB331065674 for ; Wed, 11 May 2011 12:16:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id EDD068FC08 for ; Wed, 11 May 2011 12:16:38 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id iC341g0021ei1Bg52CGfoG; Wed, 11 May 2011 12:16:39 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.westchester.pa.mail.comcast.net with comcast id iCGd1g0071t3BNj3kCGdjk; Wed, 11 May 2011 12:16:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C1A9E102C36; Wed, 11 May 2011 05:16:35 -0700 (PDT) Date: Wed, 11 May 2011 05:16:35 -0700 From: Jeremy Chadwick To: Robert Schulze Message-ID: <20110511121635.GA38052@icarus.home.lan> References: <4DCA6BEA.4060605@bytecamp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCA6BEA.4060605@bytecamp.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 8-STABLE and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 12:16:39 -0000 On Wed, May 11, 2011 at 12:58:50PM +0200, Robert Schulze wrote: > We are running 8-STABLE (csupped at 20110504) on a NFS fileserver. > It has 32 GB RAM and uses ZFS: > > home ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > logs > mirror ONLINE 0 0 0 > da12 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > cache > ad4 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > > Before upgrading from 8.0, the machine never used the whole system > memory, it left about 10 GB free even after about 100 days uptime. > Now, it eats RAM insanely (wired is between 29 GB and 30 GB), which > is quite good I think, but after about 3 days uptime, we now have > 106 MB swapped out. Both L2ARC SSDs are ~74 GB in size, arc_summary > prints the following values: > > ARC Size: > Current Size: 76.21% 23440.22M (arcsize) > Target Size: (Adaptive) 76.52% 23535.40M (c) > Min Size (Hard Limit): 12.50% 3844.77M (c_min) > Max Size (High Water): ~8:1 30758.16M (c_max) > > L2 ARC Size: > Current Size: (Adaptive) 88466.19M > Header Size: 0.29% 259.21M > > > The following sysctls were set: > > security.bsd.see_other_uids=0 > kern.maxvnodes=400000 > kern.ipc.somaxconn=8192 > kern.ipc.maxsockbuf=1024000 > net.inet.udp.maxdgram=57344 > vfs.ufs.dirhash_maxmem=25165824 > > My question now: why does the machine swap, is this normal behaviour? > Why is wired at about 30 GB if ARC=23 GB and L2ARC-header=259 MB? I'm not really all that familiar with L2ARC at this point (conceptually yes, real-world use no), but the delta (23GB vs. 30GB wired) is probably explainable. The most common reason, as I understand it, is that memory becomes fragmented in such a way that there are unoptimised/non-optimal page layouts in memory resulting in a waste. I tend not to use the "arcstats" script and instead look at the sysctl data from "sysctl -a kstat.zfs.misc.arcstats". I guess I'm used to looking at it by now. Anyway, for example, on my 8GB machine with vfs.zfs.arc_max="6144M" set in /boot/loader.conf, running 8.2-STABLE dated May 6th, "Wired" on my machine has occasionally reached 6.8GBytes. How much of this was ZFS? About 6.4GBytes -- the remaining 0.4GBytes? mysqld. What you're looking for is something very low-level that gives a complete and total kernel-level memory map to show you exactly where everything is going. I believe "vmstat -z" provides that. So basically what I'm trying to say here is that you're running top, looking at Wired, and saying "all of this is ZFS" when that's definitely not what Wired represents exclusively. If you're worried about swap usage, try limiting the ARC size more using /boot/loader.conf. You do not need to adjust vm.kmem_size or vm.kmem_size_max if the machine is running 8.2-RELEASE or newer. I only mention this because all the online docs you'll find mention tuning one or both of those two; that only applies to older FreeBSD releases. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed May 11 19:49:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05FD8106566B for ; Wed, 11 May 2011 19:49:44 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by mx1.freebsd.org (Postfix) with ESMTP id CEDE28FC13 for ; Wed, 11 May 2011 19:49:43 +0000 (UTC) Received: (qmail 9471 invoked from network); 11 May 2011 19:04:07 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 May 2011 19:04:07 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.8]) by be-well.ilk.org (Postfix) with ESMTP id 6094450824; Wed, 11 May 2011 15:04:01 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id F132239822; Wed, 11 May 2011 15:04:00 -0400 (EDT) From: Lowell Gilbert To: suri References: <4DCA35BB.5050402@snafu.de> Date: Wed, 11 May 2011 15:04:00 -0400 In-Reply-To: <4DCA35BB.5050402@snafu.de> (suri's message of "Wed, 11 May 2011 09:07:39 +0200") Message-ID: <44hb91ys7z.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 11 May 2011 19:49:44 -0000 suri writes: > Hey List, > > i have problems with install/ update the port archivers/libzip. > When i delete libzip-0.9.3 and then type make in the port directoty > comes this: > > ===> Building for libzip-0.10 > make all-recursive > Making all in lib > make all-am > /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc > -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fno-strict-aliasing -MT > zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c -o zip_add.lo zip_add.c > libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe > -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c > zip_add.c -fPIC -DPIC -o .libs/zip_add.o > *** Error code 1 > Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. > *** Error code 1 > > Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. > *** Error code 1 > > Stop in /usr/ports/archivers/libzip/work/libzip-0.10. > *** Error code 1 > > Stop in /usr/ports/archivers/libzip/work/libzip-0.10. > *** Error code 1 > > Stop in /usr/ports/archivers/libzip. > > When i install libzip-0.9.3 as package and then try portmaster comes the > same error. > Have anyone the same problem or any idea. I'm certainly not seeing the same thing on RELENG_8 (which I assume you are running based on the list you posted this to). Did you cut and paste this output? [I would expect an error message just after the libtool line.] Did you try rebuilding libtool? From owner-freebsd-stable@FreeBSD.ORG Wed May 11 21:19:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D99EE1065670 for ; Wed, 11 May 2011 21:19:21 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from waikiki.ops.eusc.inter.net (waikiki.ops.eusc.inter.net [84.23.254.155]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5758FC08 for ; Wed, 11 May 2011 21:19:21 +0000 (UTC) X-Trace: 507c73757269697c38352e3137392e3134312e3136327c31514b4753372d303030 4f6b442d52657c31333035313437333736 Received: from waikiki.ops.eusc.inter.net ([10.155.10.19] helo=localhost) by waikiki.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QKGS7-000OkD-Re for freebsd-stable@freebsd.org; Wed, 11 May 2011 22:56:16 +0200 Message-ID: <4DCAF7EF.6050106@snafu.de> Date: Wed, 11 May 2011 22:56:15 +0200 From: joerg_surmann User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.17) Gecko/20110430 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4DCA35BB.5050402@snafu.de> <44hb91ys7z.fsf@lowell-desk.lan> In-Reply-To: <44hb91ys7z.fsf@lowell-desk.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 85.179.141.162 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on waikiki.ops.eusc.inter.net); SAEximRunCond expanded to false Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 21:19:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Lowell, Thank's for reply. I'm running FreeBSD-8.2 amd 64. I have rebuild libtool - same rsult. Here the complete compiler-message: =3D=3D=3D> Building for libzip-0.10 make all-recursive Making all in lib make all-am /bin/sh /usr/local/bin/libtool --tag=3DCC --mode=3Dcompile cc - -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c -o zip_add.lo zip_add.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe - -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c zip_add.c -fPIC -DPIC -o .libs/zip_add.o In file included from zip.h:51, from zipint.h:45, from zip_add.c:36: =2E/zipconf.h:22:13: warning: missing whitespace after the macro name In file included from zip.h:51, from zipint.h:45, from zip_add.c:36: =2E/zipconf.h:24: error: stray '\337' in program =2E/zipconf.h:24: error: expected '=3D', ',', ';', 'asm' or '__attribute__' before 'int16_t' =2E/zipconf.h:28: error: stray '\337' in program =2E/zipconf.h:28: error: expected '=3D', ',', ';', 'asm' or '__attribute__' before 'uint16_t' =2E/zipconf.h:29:13: warning: missing whitespace after the macro name =2E/zipconf.h:29:1: warning: "ZIP_" redefined =2E/zipconf.h:22:1: warning: this is the location of the previous definit= ion =2E/zipconf.h:31: error: stray '\337' in program =2E/zipconf.h:31: error: expected '=3D', ',', ';', 'asm' or '__attribute__' before 'int32_t' =2E/zipconf.h:35: error: stray '\337' in program =2E/zipconf.h:35: error: expected '=3D', ',', ';', 'asm' or '__attribute__' before 'uint32_t' =2E/zipconf.h:36:13: warning: missing whitespace after the macro name =2E/zipconf.h:36:1: warning: "ZIP_" redefined =2E/zipconf.h:29:1: warning: this is the location of the previous definit= ion =2E/zipconf.h:43:13: warning: missing whitespace after the macro name =2E/zipconf.h:43:1: warning: "ZIP_" redefined =2E/zipconf.h:36:1: warning: this is the location of the previous definit= ion In file included from zipint.h:45, from zip_add.c:36: zip.h:187: error: expected specifier-qualifier-list before 'zip_uint64_t'= zip.h:203: error: expected declaration specifiers or '...' before '*' token zip.h:203: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:204: error: 'zip_int64_t' declared as function returning a function= zip.h:208: error: 'zip_add' declared as function returning a function zip.h:209: error: 'zip_add_dir' declared as function returning a function= zip.h:211: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:215: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:224: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:226: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:228: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:228: error: 'zip_fread' declared as function returning a function zip.h:231: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:233: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:235: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:236: error: expected '=3D', ',', ';', 'asm' or '__attribute__' before 'zip_get_num_entries' zip.h:240: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:241: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:245: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:247: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:250: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:252: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:254: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:257: error: expected declaration specifiers or '...' before 'zip_source_callback' zip.h:259: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:260: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:262: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip.h:266: error: expected declaration specifiers or '...' before 'zip_uint64_t' In file included from zip_add.c:36: zipint.h:122: error: expected declaration specifiers or '...' before 'zip_uint16_t' zipint.h:125: error: expected declaration specifiers or '...' before 'zip_uint16_t' zipint.h:129: warning: parameter names (without types) in function declaration zipint.h:131: warning: parameter names (without types) in function declaration zipint.h:141: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:142: error: 'zip_source_layered_callback' declared as function returning a function zipint.h:149: error: expected declaration specifiers or '...' before 'zip_uint16_t' zipint.h:158: error: expected declaration specifiers or '...' before 'zip_uint16_t' zipint.h:161: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:161: error: 'zip_source_read' declared as function returning a function zipint.h:212: error: expected specifier-qualifier-list before 'zip_uint64_t' zipint.h:269: error: expected specifier-qualifier-list before 'zip_source_callback' zipint.h:314: error: expected declaration specifiers or '...' before 'zip_uint32_t' zipint.h:339: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:345: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:352: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:353: error: '_zip_replace' declared as function returning a function zipint.h:354: error: expected declaration specifiers or '...' before 'zip_uint64_t' zipint.h:356: error: expected declaration specifiers or '...' before 'zip_uint64_t' zip_add.c:49: error: 'zip_add' declared as function returning a function zip_add.c: In function 'zip_add': zip_add.c:55: error: 'ZIP_UINT64_MAX' undeclared (first use in this function) zip_add.c:55: error: (Each undeclared identifier is reported only once zip_add.c:55: error: for each function it appears in.) zip_add.c:55: warning: passing argument 3 of '_zip_replace' from incompatible pointer type zip_add.c:55: error: too many arguments to function '_zip_replace' *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10. *** Error code 1 Stop in /usr/ports/archivers/libzip/work/libzip-0.10. *** Error code 1 Stop in /usr/ports/archivers/libzip. *** Error code 1 Stop in /usr/ports/archivers/libzip. Am 11.05.2011 21:04, schrieb Lowell Gilbert: > suri writes: > >> Hey List, >> >> i have problems with install/ update the port archivers/libzip. >> When i delete libzip-0.9.3 and then type make in the port directoty >> comes this: >> >> =3D=3D=3D> Building for libzip-0.10 >> make all-recursive >> Making all in lib >> make all-am >> /bin/sh /usr/local/bin/libtool --tag=3DCC --mode=3Dcompile cc >> -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fno-strict-aliasing -MT >> zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c -o zip_add.lo zip_add.c >> libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe >> -fno-strict-aliasing -MT zip_add.lo -MD -MP -MF .deps/zip_add.Tpo -c >> zip_add.c -fPIC -DPIC -o .libs/zip_add.o >> *** Error code 1 >> Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. >> *** Error code 1 >> >> Stop in /usr/ports/archivers/libzip/work/libzip-0.10/lib. >> *** Error code 1 >> >> Stop in /usr/ports/archivers/libzip/work/libzip-0.10. >> *** Error code 1 >> >> Stop in /usr/ports/archivers/libzip/work/libzip-0.10. >> *** Error code 1 >> >> Stop in /usr/ports/archivers/libzip. >> >> When i install libzip-0.9.3 as package and then try portmaster comes t= he >> same error. >> Have anyone the same problem or any idea. > > I'm certainly not seeing the same thing on RELENG_8 (which I assume you= > are running based on the list you posted this to). > > Did you cut and paste this output? [I would expect an error message jus= t > after the libtool line.] Did you try rebuilding libtool? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3K9+4ACgkQcEHvP2uxrTMcEACcCCbzBSqskCwbsIloaKCPAME3 IioAmweX43BUkgOt1IfoATWWT6cWP2jM =3Dyf8U -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed May 11 22:12:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE36D106566B for ; Wed, 11 May 2011 22:12:47 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1328FC17 for ; Wed, 11 May 2011 22:12:47 +0000 (UTC) Received: from [188.108.93.254] (helo=michael-think) by www81.your-server.de with esmtpa (Exim 4.72) (envelope-from ) id 1QKHL7-0000hD-Nc; Wed, 11 May 2011 23:53:06 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, joerg_surmann References: <4DCA35BB.5050402@snafu.de> <44hb91ys7z.fsf@lowell-desk.lan> <4DCAF7EF.6050106@snafu.de> Date: Wed, 11 May 2011 23:52:59 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <4DCAF7EF.6050106@snafu.de> User-Agent: Opera Mail/11.10 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97/13072/Wed May 11 22:11:38 2011) Cc: Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 May 2011 22:12:47 -0000 Am 11.05.2011, 22:56 Uhr, schrieb joerg_surmann : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey Lowell, > > Thank's for reply. > I'm running FreeBSD-8.2 amd 64. > I have rebuild libtool - same rsult. > Here the complete compiler-message: > [snip] I can confirm this error for 8.2-STABLE amd64, freshly cvsupped ports, libtool rebuilt. Regards, Michael From owner-freebsd-stable@FreeBSD.ORG Wed May 11 22:58:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492A6106566B for ; Wed, 11 May 2011 22:58:28 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4F08FC0A for ; Wed, 11 May 2011 22:58:27 +0000 (UTC) Received: by iwn33 with SMTP id 33so1301172iwn.13 for ; Wed, 11 May 2011 15:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bG3f/drNaW7ADvgz3rTpPVZ5QT0gzFMbmZbl+bNuuuo=; b=vno+tCpnx30N++4rOWRdLP9Cpx/ugJbJ9j4CS7g5rrkmptwwgk7DlzbsJmi+Z9OeCI EgPU+QjVKO1F1WmlQyxjsqGA8Ver1e1cISR+iWbSBYacH6cCQa04EsG2YyEX3iGUz3Y8 3v7wb2PVRxmK29cvxoOOpLgfa7L3YAURsc33w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=lXeIR2oiwOCfmh5D5Vqk95uRCG3IijqR0xKkC9zzk1MNQW9rdGT0ktvLzsgbSNP6ZU vMJxAmf/7G3wAlj3frERAXCPIubYVr1he7iLHdOnEtmyIdsmWfNM8SMhWEnCnjG07/L3 8fULFukVuRn86NjJPzthub1Toseo9CRi5iSMo= MIME-Version: 1.0 Received: by 10.42.4.134 with SMTP id 6mr10520842ics.513.1305152810806; Wed, 11 May 2011 15:26:50 -0700 (PDT) Received: by 10.42.165.5 with HTTP; Wed, 11 May 2011 15:26:50 -0700 (PDT) In-Reply-To: <20110510125220.GA88338@zibbi.meraka.csir.co.za> References: <20110510125220.GA88338@zibbi.meraka.csir.co.za> Date: Wed, 11 May 2011 17:26:50 -0500 Message-ID: From: Alan Cox To: John Hay Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: MCA: CPU 0 UNCOR PCC DTLB L1 error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 22:58:28 -0000 On Tue, May 10, 2011 at 7:52 AM, John Hay wrote: > Hi, > > I have seen this panic a few times on a Gigabyte E350N-USB3 running > 8-STABLE. > I have only seen it while in X, but then the machine is always in X. At > first, > I just got these hangs, so bought a PCI-express RS232 card and could see > these > at last. For some reason it does not go past this, so I have not been able > to > get a dump yet. > > Have anybody an idea of why this is or how to debug it further? I searched > the archives and found something similar about a year ago, but it looks > like it was solved with a fix that got committed. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=140338 > > I have now disabled mca in loader.conf with 'hw.mca.enabled="0"' and I have > not seen that panic again. I do occasionally see a panic in devfs_open(), > but I guess that should be handled in another thread. > > The kernel is basically a GENERIC kernel with puc uncommented and the > following in loader.conf > > vm.kmem_size="12G" > hw.mca.enabled="0" > zfs_load="YES" > ahci_load="YES" > xhci_load="YES" > amdtemp_load="YES" > ng_ubt_load="YES" > uplcom_load="YES" > > Here is the panic message and after that dmesg. > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > > #################################################### > MCA: Bank 0, Status 0xb600000000010015 > MCA: Global Cap 0x0000000000000106, Status 0x0000000000000004 > MCA: Vendor "AuthenticAMD", ID 0x500f10, APIC ID 0 > MCA: CPU 0 UNCOR PCC DTLB L1 error > MCA: Address 0x8016c4000 > > > Fatal trap 28: machine check trap while in user mode > cpuid = 0; apic id = 00 > instruction pointer = 0x43:0x80156af85 > stack pointer = 0x3b:0x7fffffffcb18 > frame pointer = 0x3b:0x80fe87800 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 3, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 2484 (initial thread) > trap number = 28 > panic: machine check trap > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff80608d5e at kdb_backtrace+0x5e > #1 0xffffffff805d6707 at panic+0x187 > #2 0xffffffff808bf4c0 at trap_fatal+0x290 > #3 0xffffffff808bfaa9 at trap+0x109 > #4 0xffffffff808a7d94 at calltrap+0x8 > #################################################### > > Please try the following patch: Index: x86/x86/mca.c =================================================================== --- x86/x86/mca.c (revision 219060) +++ x86/x86/mca.c (working copy) @@ -665,7 +665,8 @@ mca_setup(uint64_t mcg_cap) * for Erratum 383. */ if (cpu_vendor_id == CPU_VENDOR_AMD && - CPUID_TO_FAMILY(cpu_id) == 0x10 && amd10h_L1TP) + (CPUID_TO_FAMILY(cpu_id) == 0x10 || + CPUID_TO_FAMILY(cpu_id) == 0x14) && amd10h_L1TP) workaround_erratum383 = 1; mtx_init(&mca_lock, "mca", NULL, MTX_SPIN); Index: i386/i386/pmap.c =================================================================== --- i386/i386/pmap.c (revision 219060) +++ i386/i386/pmap.c (working copy) @@ -758,7 +758,8 @@ pmap_init(void) * machine monitor. */ if (vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD && - CPUID_TO_FAMILY(cpu_id) == 0x10) + (CPUID_TO_FAMILY(cpu_id) == 0x10 || + CPUID_TO_FAMILY(cpu_id) == 0x14)) workaround_erratum383 = 1; /* Index: amd64/amd64/pmap.c =================================================================== --- amd64/amd64/pmap.c (revision 219060) +++ amd64/amd64/pmap.c (working copy) @@ -727,7 +727,8 @@ pmap_init(void) * machine monitor. */ if (vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD && - CPUID_TO_FAMILY(cpu_id) == 0x10) + (CPUID_TO_FAMILY(cpu_id) == 0x10 || + CPUID_TO_FAMILY(cpu_id) == 0x14)) workaround_erratum383 = 1; /* From owner-freebsd-stable@FreeBSD.ORG Thu May 12 03:07:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 582A61065670 for ; Thu, 12 May 2011 03:07:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D78B8FC16 for ; Thu, 12 May 2011 03:07:09 +0000 (UTC) Received: by ywf7 with SMTP id 7so496704ywf.13 for ; Wed, 11 May 2011 20:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2nVpREV066XI/PBctLNNJpFY4vYbRbq2pgJ9XoIvxro=; b=Aq8j3FKbWc71AOW7vmoUNHLNi0lwwK7FTnqoKd0HZXzttUJDPEHHRmATyTIecDJtyR cgbzEg+b8SyQXDVB9PBRVDuS3Zk06BWrop1SdfaPSeBEGosw+92RUdY5Fl68wGvrJsx0 eZMHiSxkp/mYFnar6eMJBmMnBUctZk4a/x/nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CDE+uPtjt1VolH3/ifs6ySvHIZ3vL9usLsZU8Ecv0YSCXyJevKLl0cgAWEGYANmVDK BGTfKe0nF6tXrAdm8T16g6IkW7gFzXYSuHx7P3YZrVaZagm556eq15gKzPtWUDnt3ItB JTTr6H3HCEIp+yfLfta/5ZvQeM42U4oSTLb9A= MIME-Version: 1.0 Received: by 10.150.68.40 with SMTP id q40mr9107004yba.68.1305167839482; Wed, 11 May 2011 19:37:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Wed, 11 May 2011 19:37:19 -0700 (PDT) In-Reply-To: <20110511084913.GG96423@laa.zp.ua> References: <20110511084913.GG96423@laa.zp.ua> Date: Thu, 12 May 2011 10:37:19 +0800 X-Google-Sender-Auth: oQGCMxlNTUmL8LSSGX9hhyEs7_0 Message-ID: From: Adrian Chadd To: Lystopad Olexandr Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: wi0 and adhoc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 03:07:10 -0000 2011/5/11 Lystopad Olexandr : > Hi! > > I have two freebsd boxes with 4.11 (yes, really!). They both > serve wifi adhoc link (wi0 + pcic0: ) during many > years with no problems. One box has died, and I change it to > new one with 8.0-rel. New box have cbb0 and same wi0 card. So, > now I have two boxes 4.11 and 8.0. Both with wi0 devices detected. [snip] > dmesg: > wi0: at port 0x100-0x13f irq 17 function 0 config 1 on pccard0 > wi0: [ITHREAD] > wi0: device timeout > wi0: device timeout > wi0: record read mismatch, rid=fd44, got=fc80 > wi0: device timeout > .... > > my questions are: > 1. why txpower 0 in 8.0 box? > 2. why too many ``device timeout'' messages in dmesg on 8.0 box? > 3. why all pings lost in that link? Because noone has kept the wavelan driver up to date? :/ I'm happy to commit any fixes people have for the wavelan driver. Adrian From owner-freebsd-stable@FreeBSD.ORG Thu May 12 06:08:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F61106566B for ; Thu, 12 May 2011 06:08:36 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from waikiki.ops.eusc.inter.net (waikiki.ops.eusc.inter.net [84.23.254.155]) by mx1.freebsd.org (Postfix) with ESMTP id 566EE8FC14 for ; Thu, 12 May 2011 06:08:36 +0000 (UTC) X-Trace: 507c73757269697c38352e3137392e3134312e3136327c31514b5034632d303030 4557492d4d5a7c31333035313830353134 Received: from waikiki.ops.eusc.inter.net ([10.155.10.19] helo=localhost) by waikiki.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QKP4c-000EWI-MZ for freebsd-stable@freebsd.org; Thu, 12 May 2011 08:08:34 +0200 Message-ID: <4DCB7962.6090706@snafu.de> Date: Thu, 12 May 2011 08:08:34 +0200 From: joerg_surmann User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.17) Gecko/20110430 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 X-SA-Exim-Connect-IP: 85.179.141.162 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on waikiki.ops.eusc.inter.net); SAEximRunCond expanded to false Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 06:08:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've cvsupped my ports and rebuild libtool. Same result. Don't no what the problem is. Thank's Michael another idea? Regards Suri Am 11.05.2011 23:52, schrieb Michael Ross: > Am 11.05.2011, 22:56 Uhr, schrieb joerg_surmann > : > >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Hey Lowell, >> >> Thank's for reply. I'm running FreeBSD-8.2 amd 64. I have rebuild >> libtool - same rsult. Here the complete compiler-message: >> > > [snip] > > I can confirm this error for 8.2-STABLE amd64, freshly cvsupped > ports, libtool rebuilt. > > > > Regards, > > Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3LeWEACgkQcEHvP2uxrTPdzgCfXWxB3OVnyQKjTr4K4gvyiKmi qPIAnAz71wBoQYlJ7b5xl6brYHBuX+oo =B10r -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 06:13:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB27106566B for ; Thu, 12 May 2011 06:13:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF858FC17 for ; Thu, 12 May 2011 06:13:14 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta14.westchester.pa.mail.comcast.net with comcast id iWCp1g0011YDfWL5EWDFwq; Thu, 12 May 2011 06:13:15 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.westchester.pa.mail.comcast.net with comcast id iWDE1g0061t3BNj3gWDEx4; Thu, 12 May 2011 06:13:15 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A915D102C36; Wed, 11 May 2011 23:13:12 -0700 (PDT) Date: Wed, 11 May 2011 23:13:12 -0700 From: Jeremy Chadwick To: joerg_surmann Message-ID: <20110512061312.GA54574@icarus.home.lan> References: <4DCB7962.6090706@snafu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCB7962.6090706@snafu.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 06:13:15 -0000 On Thu, May 12, 2011 at 08:08:34AM +0200, joerg_surmann wrote: > I've cvsupped my ports and rebuild libtool. > Same result. > Don't no what the problem is. > > Thank's Michael another idea? Something is wrong with the actual build of the software. Look very closely at the compiler error: > In file included from zip.h:51, > from zipint.h:45, > from zip_add.c:36: > ./zipconf.h:22:13: warning: missing whitespace after the macro name Can you please provide the contents of this file somewhere? It will be located somewhere within the "work" directory of the port itself. E.g. 'find work -name "zipconf.h"' will find you the file. Please note that I've noticed your Emails are formatted very badly (extraneous whitespace, newlines, etc.) -- please do not copy/paste the file contents, because chances are it'll look broken/messed up given whatever your Email client is doing. Please put the file up on the web somewhere or attach it in an Email response. I have a feeling something is wonky with your /etc/make.conf or some other part of your system (possibly conflicting ports, or a GNU autoconf script that is detecting something incorrectly). Thank you. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu May 12 06:15:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 079E81065670 for ; Thu, 12 May 2011 06:15:17 +0000 (UTC) (envelope-from rickvanderzwet@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C463B8FC0C for ; Thu, 12 May 2011 06:15:16 +0000 (UTC) Received: by iyj12 with SMTP id 12so1349996iyj.13 for ; Wed, 11 May 2011 23:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YSLSJYc1JliYctyZHI7foanxn12m0ukTk0ffz1/fn+4=; b=ZRRr2tc6qCpjHAqRc0DDyEHgtgkAvRTKHkW0QgVUh8V+4qhzULUtf3vTDczHFSuPmY RJ3MfFL84fLitF54GiB/Id0wu852un5bgGRV/NuE4uo60o/IhR1jI0lHsyuOswwiJXhN Bk8CFqTcdO7JtXwPYVKi4blYbFWjilEpjtODA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=O16ZWYBJjPwmilOp9NH9YBu5RANf9Hg6Fl8lLkiYKxmk0lhOSRAcNpg9QlIdUpxWZv oyhF3ZpDWsqUwit/fVzM0QvP4LiPN3Srxx6PnnFoHJJESiVztShZU/v4zFTgK2kFGRVh bwo1O3KEs6j0HPiQxhHx4r+acHQB7ctk4i26M= MIME-Version: 1.0 Received: by 10.43.131.130 with SMTP id hq2mr1739704icc.90.1305179197290; Wed, 11 May 2011 22:46:37 -0700 (PDT) Sender: rickvanderzwet@gmail.com Received: by 10.231.146.211 with HTTP; Wed, 11 May 2011 22:46:37 -0700 (PDT) In-Reply-To: <20110511084913.GG96423@laa.zp.ua> References: <20110511084913.GG96423@laa.zp.ua> Date: Thu, 12 May 2011 07:46:37 +0200 X-Google-Sender-Auth: 3nZKoHJHTeid6_QA9wioZdYqf6Q Message-ID: From: Rick van der Zwet To: Lystopad Olexandr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: wi0 and adhoc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 06:15:17 -0000 2011/5/11 Lystopad Olexandr : > I have two freebsd boxes with 4.11 (yes, really!). They both > serve wifi adhoc link (wi0 + pcic0: ) during many > years with no problems. One box has died, and I change it to > new one with 8.0-rel. New box have cbb0 and same wi0 card. So, > now I have two boxes 4.11 and 8.0. Both with wi0 devices detected. [snip: ifconfig] > # ifconfig wlan0 list caps > drivercaps=3D10301 > cryptocaps=3D1 > > pciconf -lvc: > ... > cbb0@pci0:2:9:0: =A0 =A0 =A0 =A0class=3D0x060700 card=3D0x14101524 chip= =3D0x14101524 rev=3D0x01 hdr=3D0x02 > =A0 =A0vendor =A0 =A0 =3D 'ENE Technology Inc' > =A0 =A0device =A0 =A0 =3D 'CardBus Controller (CB-1420)' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D PCI-CardBus > =A0 =A0cap 01[a0] =3D powerspec 1 =A0supports D0 D1 D2 D3 =A0current D0 > ... > > dmesg: > wi0: at port 0x100-0x13f irq 17 functi= on 0 config 1 on pccard0 > wi0: [ITHREAD] > wi0: device timeout > wi0: device timeout > wi0: record read mismatch, rid=3Dfd44, got=3Dfc80 > wi0: device timeout > .... Interesting it does not seems to be able to fetch the firmware information of the card. As it would normally list something like: wi0: mem 0xa0000000-0xa0000fff irq 10 at device 16.0 on= pci0 wi0: [ITHREAD] wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.1), Station (1.8.2) wi0: Ethernet address: 00:02:6f:4a:cd:f5 > my questions are: > 1. why txpower 0 in 8.0 box? > 2. why too many ``device timeout'' messages in dmesg on 8.0 box? > 3. why all pings lost in that link? Usually the firmware on the card is this biggest issue, causing the card not getting detected, generating all the device timeout messages. Running new firmware seems to fix it for a while. ```man 4 wi''' lists the minimum required versions. Some firmware upgrade hints are listed over here: http://www.wirelessleiden.nl/projects/nodefactory/ticket/23 We had 200+ wi(4) cards running in our Wireless Metropolitan Network and where running into the same walls as you did, every new release issued more problems with those wi(4) cards. By the end we desired to replace them all by ath(4) based cards (active development on the driver :-)). Br. /Rick --=20 http://wirelessleiden.nl From owner-freebsd-stable@FreeBSD.ORG Thu May 12 06:45:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FC61106566C for ; Thu, 12 May 2011 06:45:07 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from sour.ops.eusc.inter.net (sour.ops.eusc.inter.net [84.23.254.154]) by mx1.freebsd.org (Postfix) with ESMTP id CF6B58FC23 for ; Thu, 12 May 2011 06:45:06 +0000 (UTC) X-Trace: 507c73757269697c38352e3137392e3134312e3136327c31514b5064772d303030 3044512d48307c31333035313832373034 Received: from sour.ops.eusc.inter.net ([10.154.10.19] helo=localhost) by sour.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QKPdw-0000DQ-H0; Thu, 12 May 2011 08:45:04 +0200 Message-ID: <4DCB81EF.2080104@snafu.de> Date: Thu, 12 May 2011 08:45:03 +0200 From: joerg_surmann User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.17) Gecko/20110430 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> In-Reply-To: <20110512061312.GA54574@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/mixed; boundary="------------070906000505020105050500" X-SA-Exim-Connect-IP: 85.179.141.162 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on sour.ops.eusc.inter.net); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 06:45:07 -0000 This is a multi-part message in MIME format. --------------070906000505020105050500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Jeremy, Ok i'll put the files in a attachment on the end from this email. Thanks for your help. Am 12.05.2011 08:13, schrieb Jeremy Chadwick: > On Thu, May 12, 2011 at 08:08:34AM +0200, joerg_surmann wrote: >> I've cvsupped my ports and rebuild libtool. Same result. Don't no >> what the problem is. >> >> Thank's Michael another idea? > > Something is wrong with the actual build of the software. Look > very closely at the compiler error: > >> In file included from zip.h:51, from zipint.h:45, from >> zip_add.c:36: ./zipconf.h:22:13: warning: missing whitespace >> after the macro name > > Can you please provide the contents of this file somewhere? It > will be located somewhere within the "work" directory of the port > itself. E.g. 'find work -name "zipconf.h"' will find you the file. > > Please note that I've noticed your Emails are formatted very badly > (extraneous whitespace, newlines, etc.) -- please do not copy/paste > the file contents, because chances are it'll look broken/messed up > given whatever your Email client is doing. Please put the file up > on the web somewhere or attach it in an Email response. > > I have a feeling something is wonky with your /etc/make.conf or > some other part of your system (possibly conflicting ports, or a > GNU autoconf script that is detecting something incorrectly). > > Thank you. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3Lge4ACgkQcEHvP2uxrTP//gCfS8J2HVrshod6Dad9RciX9tj6 TT0AoJiuXLPB4btLlToD2VHmNvD9i5xx =3DHbA8 -----END PGP SIGNATURE----- --------------070906000505020105050500 Content-Type: text/plain; name="zip.h" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zip.h" #ifndef _HAD_ZIP_H #define _HAD_ZIP_H /* zip.h -- exported declarations. Copyright (C) 1999-2011 Dieter Baron and Thomas Klausner This file is part of libzip, a library to manipulate ZIP archives. The authors can be contacted at Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of the authors may not be used to endorse or promote products derived from this software without specific prior written permission. =20 THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ =0C #ifndef ZIP_EXTERN #ifdef _WIN32 #define ZIP_EXTERN __declspec(dllimport) #else #define ZIP_EXTERN #endif #endif #ifdef __cplusplus extern "C" { #endif #include #include #include #include /* flags for zip_open */ #define ZIP_CREATE 1 #define ZIP_EXCL 2 #define ZIP_CHECKCONS 4 /* flags for zip_name_locate, zip_fopen, zip_stat, ... */ #define ZIP_FL_NOCASE 1 /* ignore case on name lookup */ #define ZIP_FL_NODIR 2 /* ignore directory component */ #define ZIP_FL_COMPRESSED 4 /* read compressed data */ #define ZIP_FL_UNCHANGED 8 /* use original data, ignoring changes */ #define ZIP_FL_RECOMPRESS 16 /* force recompression of data */ #define ZIP_FL_ENCRYPTED 32 /* read encrypted data (implies ZIP_FL_COMPRESSED) */ /* archive global flags flags */ #define ZIP_AFL_TORRENT 1 /* torrent zipped */ #define ZIP_AFL_RDONLY 2 /* read only -- cannot be cleared */ /* flags for compression and encryption sources */ #define ZIP_CODEC_ENCODE 1 /* compress/encrypt */ /* libzip error codes */ #define ZIP_ER_OK 0 /* N No error */ #define ZIP_ER_MULTIDISK 1 /* N Multi-disk zip archives not support= ed */ #define ZIP_ER_RENAME 2 /* S Renaming temporary file failed */ #define ZIP_ER_CLOSE 3 /* S Closing zip archive failed */ #define ZIP_ER_SEEK 4 /* S Seek error */ #define ZIP_ER_READ 5 /* S Read error */ #define ZIP_ER_WRITE 6 /* S Write error */ #define ZIP_ER_CRC 7 /* N CRC error */ #define ZIP_ER_ZIPCLOSED 8 /* N Containing zip archive was closed *= / #define ZIP_ER_NOENT 9 /* N No such file */ #define ZIP_ER_EXISTS 10 /* N File already exists */ #define ZIP_ER_OPEN 11 /* S Can't open file */ #define ZIP_ER_TMPOPEN 12 /* S Failure to create temporary file */= #define ZIP_ER_ZLIB 13 /* Z Zlib error */ #define ZIP_ER_MEMORY 14 /* N Malloc failure */ #define ZIP_ER_CHANGED 15 /* N Entry has been changed */ #define ZIP_ER_COMPNOTSUPP 16 /* N Compression method not supported */= #define ZIP_ER_EOF 17 /* N Premature EOF */ #define ZIP_ER_INVAL 18 /* N Invalid argument */ #define ZIP_ER_NOZIP 19 /* N Not a zip archive */ #define ZIP_ER_INTERNAL 20 /* N Internal error */ #define ZIP_ER_INCONS 21 /* N Zip archive inconsistent */ #define ZIP_ER_REMOVE 22 /* S Can't remove file */ #define ZIP_ER_DELETED 23 /* N Entry has been deleted */ #define ZIP_ER_ENCRNOTSUPP 24 /* N Encryption method not supported */ #define ZIP_ER_RDONLY 25 /* N Read-only archive */=20 #define ZIP_ER_NOPASSWD 26 /* N No password provided */ #define ZIP_ER_WRONGPASSWD 27 /* N Wrong password provided */ /* type of system error value */ #define ZIP_ET_NONE 0 /* sys_err unused */ #define ZIP_ET_SYS 1 /* sys_err is errno */ #define ZIP_ET_ZLIB 2 /* sys_err is zlib error code */ /* compression methods */ #define ZIP_CM_DEFAULT -1 /* better of deflate or store */ #define ZIP_CM_STORE 0 /* stored (uncompressed) */ #define ZIP_CM_SHRINK 1 /* shrunk */ #define ZIP_CM_REDUCE_1 2 /* reduced with factor 1 */ #define ZIP_CM_REDUCE_2 3 /* reduced with factor 2 */ #define ZIP_CM_REDUCE_3 4 /* reduced with factor 3 */ #define ZIP_CM_REDUCE_4 5 /* reduced with factor 4 */ #define ZIP_CM_IMPLODE 6 /* imploded */ /* 7 - Reserved for Tokenizing compression algorithm */ #define ZIP_CM_DEFLATE 8 /* deflated */ #define ZIP_CM_DEFLATE64 9 /* deflate64 */ #define ZIP_CM_PKWARE_IMPLODE 10 /* PKWARE imploding */ /* 11 - Reserved by PKWARE */ #define ZIP_CM_BZIP2 12 /* compressed using BZIP2 algorithm */ /* 13 - Reserved by PKWARE */ #define ZIP_CM_LZMA 14 /* LZMA (EFS) */ /* 15-17 - Reserved by PKWARE */ #define ZIP_CM_TERSE 18 /* compressed using IBM TERSE (new) */ #define ZIP_CM_LZ77 19 /* IBM LZ77 z Architecture (PFS) */ #define ZIP_CM_WAVPACK 97 /* WavPack compressed data */ #define ZIP_CM_PPMD 98 /* PPMd version I, Rev 1 */ /* encryption methods */ #define ZIP_EM_NONE 0 /* not encrypted */ #define ZIP_EM_TRAD_PKWARE 1 /* traditional PKWARE encryption */ #if 0 /* Strong Encryption Header not parsed yet */ #define ZIP_EM_DES 0x6601 /* strong encryption: DES */ #define ZIP_EM_RC2_OLD 0x6602 /* strong encryption: RC2, version < 5.= 2 */ #define ZIP_EM_3DES_168 0x6603 #define ZIP_EM_3DES_112 0x6609 #define ZIP_EM_AES_128 0x660e #define ZIP_EM_AES_192 0x660f #define ZIP_EM_AES_256 0x6610 #define ZIP_EM_RC2 0x6702 /* strong encryption: RC2, version >=3D= 5.2 */ #define ZIP_EM_RC4 0x6801 #endif #define ZIP_EM_UNKNOWN 0xffff /* unknown algorithm */ =0C enum zip_source_cmd { ZIP_SOURCE_OPEN, /* prepare for reading */ ZIP_SOURCE_READ, /* read data */ ZIP_SOURCE_CLOSE, /* reading is done */ ZIP_SOURCE_STAT, /* get meta information */ ZIP_SOURCE_ERROR, /* get error information */ ZIP_SOURCE_FREE /* cleanup and free resources */ }; #define ZIP_SOURCE_ERR_LOWER -2 #define ZIP_STAT_NAME 0x0001 #define ZIP_STAT_INDEX 0x0002 #define ZIP_STAT_SIZE 0x0004 #define ZIP_STAT_COMP_SIZE 0x0008 #define ZIP_STAT_MTIME 0x0010 #define ZIP_STAT_CRC 0x0020 #define ZIP_STAT_COMP_METHOD 0x0040 #define ZIP_STAT_ENCRYPTION_METHOD 0x0080 #define ZIP_STAT_FLAGS 0x0100 struct zip_stat { zip_uint64_t valid; /* which fields have valid values */ const char *name; /* name of the file */ zip_uint64_t index; /* index within archive */ zip_uint64_t size; /* size of file (uncompressed) */ zip_uint64_t comp_size; /* size of file (compressed) */ time_t mtime; /* modification time */ zip_uint32_t crc; /* crc of file data */ zip_uint16_t comp_method; /* compression method used */ zip_uint16_t encryption_method; /* encryption method used */ zip_uint32_t flags; /* reserved for future use */ }; struct zip; struct zip_file; struct zip_source; typedef zip_int64_t (*zip_source_callback)(void *, void *, zip_uint64_t, enum zip_source_cmd); =0C ZIP_EXTERN zip_int64_t zip_add(struct zip *, const char *, struct zip_sou= rce *); ZIP_EXTERN zip_int64_t zip_add_dir(struct zip *, const char *); ZIP_EXTERN int zip_close(struct zip *); ZIP_EXTERN int zip_delete(struct zip *, zip_uint64_t); ZIP_EXTERN void zip_error_clear(struct zip *); ZIP_EXTERN void zip_error_get(struct zip *, int *, int *); ZIP_EXTERN int zip_error_get_sys_type(int); ZIP_EXTERN int zip_error_to_str(char *, zip_uint64_t, int, int); ZIP_EXTERN int zip_fclose(struct zip_file *); ZIP_EXTERN struct zip *zip_fdopen(int, int, int *); ZIP_EXTERN void zip_file_error_clear(struct zip_file *); ZIP_EXTERN void zip_file_error_get(struct zip_file *, int *, int *); ZIP_EXTERN const char *zip_file_strerror(struct zip_file *); ZIP_EXTERN struct zip_file *zip_fopen(struct zip *, const char *, int); ZIP_EXTERN struct zip_file *zip_fopen_encrypted(struct zip *, const char = *, int, const char *); ZIP_EXTERN struct zip_file *zip_fopen_index(struct zip *, zip_uint64_t, i= nt); ZIP_EXTERN struct zip_file *zip_fopen_index_encrypted(struct zip *, zip_uint64_t, int, const char *); ZIP_EXTERN zip_int64_t zip_fread(struct zip_file *, void *, zip_uint64_t)= ; ZIP_EXTERN const char *zip_get_archive_comment(struct zip *, int *, int);= ZIP_EXTERN int zip_get_archive_flag(struct zip *, int, int); ZIP_EXTERN const char *zip_get_file_comment(struct zip *, zip_uint64_t, int *, int); ZIP_EXTERN const char *zip_get_file_extra(struct zip *, zip_uint64_t, int *, int); ZIP_EXTERN const char *zip_get_name(struct zip *, zip_uint64_t, int); ZIP_EXTERN zip_uint64_t zip_get_num_entries(struct zip *, int); ZIP_EXTERN int zip_get_num_files(struct zip *); /* deprecated, use zip_g= et_num_entries instead */ ZIP_EXTERN int zip_name_locate(struct zip *, const char *, int); ZIP_EXTERN struct zip *zip_open(const char *, int, int *); ZIP_EXTERN int zip_rename(struct zip *, zip_uint64_t, const char *); ZIP_EXTERN int zip_replace(struct zip *, zip_uint64_t, struct zip_source = *); ZIP_EXTERN int zip_set_archive_comment(struct zip *, const char *, int); ZIP_EXTERN int zip_set_archive_flag(struct zip *, int, int); ZIP_EXTERN int zip_set_default_password(struct zip *, const char *); ZIP_EXTERN int zip_set_file_comment(struct zip *, zip_uint64_t, const char *, int); ZIP_EXTERN int zip_set_file_extra(struct zip *, zip_uint64_t, const char *, int); ZIP_EXTERN struct zip_source *zip_source_buffer(struct zip *, const void = *, zip_uint64_t, int); ZIP_EXTERN struct zip_source *zip_source_file(struct zip *, const char *,= zip_uint64_t, zip_int64_t); ZIP_EXTERN struct zip_source *zip_source_filep(struct zip *, FILE *, zip_uint64_t, zip_int64_t); ZIP_EXTERN void zip_source_free(struct zip_source *); ZIP_EXTERN struct zip_source *zip_source_function(struct zip *, zip_source_callback, void *); ZIP_EXTERN struct zip_source *zip_source_zip(struct zip *, struct zip *, zip_uint64_t, int, zip_uint64_t, zip_int64_t); ZIP_EXTERN int zip_stat(struct zip *, const char *, int, struct zip_stat = *); ZIP_EXTERN int zip_stat_index(struct zip *, zip_uint64_t, int, struct zip_stat *); ZIP_EXTERN void zip_stat_init(struct zip_stat *); ZIP_EXTERN const char *zip_strerror(struct zip *); ZIP_EXTERN int zip_unchange(struct zip *, zip_uint64_t); ZIP_EXTERN int zip_unchange_all(struct zip *); ZIP_EXTERN int zip_unchange_archive(struct zip *); #ifdef __cplusplus } #endif #endif /* _HAD_ZIP_H */ --------------070906000505020105050500 Content-Type: text/plain; name="zip_add.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zip_add.c" /* zip_add.c -- add file via callback function Copyright (C) 1999-2007 Dieter Baron and Thomas Klausner This file is part of libzip, a library to manipulate ZIP archives. The authors can be contacted at Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of the authors may not be used to endorse or promote products derived from this software without specific prior written permission. =20 THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ =0C #include "zipint.h" =0C /* NOTE: Return type is signed so we can return -1 on error. The index can not be larger than ZIP_INT64_MAX since the size of the central directory cannot be larger than ZIP_UINT64_MAX, and each entry is larger than 2 bytes. */ ZIP_EXTERN zip_int64_t zip_add(struct zip *za, const char *name, struct zip_source *source) { if (name =3D=3D NULL || source =3D=3D NULL) { _zip_error_set(&za->error, ZIP_ER_INVAL, 0); return -1; } =09 return _zip_replace(za, ZIP_UINT64_MAX, name, source); } --------------070906000505020105050500 Content-Type: text/plain; name="zipconf.h" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zipconf.h" #ifndef _HAD_ZIPCONF_H #define _HAD_ZIPCONF_H /* zipconf.h -- platform specific include file This file was generated automatically by ./make_zipconf.sh based on ../config.h. */ #define LIBZIP_VERSION "0.10" #define LIBZIP_VERSION_MAJOR 0 #define LIBZIP_VERSION_MINOR 10 #define LIBZIP_VERSION_MICRO 0 #include typedef signed char int8_t; #define ZIP_INU8_MAX SCHAR_MAX typedef unsigned char uint8_t; #define ZIP_=DAINU8_MAX =DACHAR_MAX typedef shor=DF int16_t; #define ZIP_INU16_MIN =DACHAR_MIN #define ZIP_INU16_MAX =DACHAR_MAX typedef unsigned shor=DF uint16_t; #define ZIP_=DAINU16_MAX =DACHAR_MAX typedef in=DF int32_t; #define ZIP_INU32_MIN =DACHAR_MIN #define ZIP_INU32_MAX =DACHAR_MAX typedef unsigned in=DF uint32_t; #define ZIP_=DAINU32_MAX =DACHAR_MAX typedef long int64_t; #define ZIP_INU64_MIN SLONG_MIN #define ZIP_INU64_MAX SLONG_MAX typedef unsigned long uint64_t; #define ZIP_=DAINU64_MAX =DALONG_MAX #endif /* zipconf.h */ --------------070906000505020105050500 Content-Type: text/plain; name="zipint.h" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zipint.h" #ifndef _HAD_ZIPINT_H #define _HAD_ZIPINT_H /* zipint.h -- internal declarations. Copyright (C) 1999-2011 Dieter Baron and Thomas Klausner This file is part of libzip, a library to manipulate ZIP archives. The authors can be contacted at Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of the authors may not be used to endorse or promote products derived from this software without specific prior written permission. =20 THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include #ifdef _WIN32 #define ZIP_EXTERN __declspec(dllexport) /* for dup(), close(), etc. */ #include #endif #include "zip.h" #include "config.h" #ifndef HAVE_FSEEKO #define fseeko(s, o, w) (fseek((s), (long int)(o), (w))) #endif #ifndef HAVE_FTELLO #define ftello(s) ((long)ftell((s))) #endif #ifndef HAVE_MKSTEMP int _zip_mkstemp(char *); #define mkstemp _zip_mkstemp #endif #ifdef HAVE_MOVEFILEEXA #include #define _zip_rename(s, t) \ (!MoveFileExA((s), (t), \ MOVEFILE_COPY_ALLOWED|MOVEFILE_REPLACE_EXISTING)) #else #define _zip_rename rename #endif /* Windows' open() doesn't understand Unix permissions */ #if !defined(HAVE_OPEN) #if defined(HAVE__OPEN) #define open(a, b, c) _open((a), (b)) #endif #endif #if !defined(HAVE_SNPRINTF) #if defined(HAVE__SNPRINTF) #define snprintf _snprintf #endif #endif #if !defined(HAVE_STRCASECMP) #if defined(HAVE__STRCMPI) #define strcasecmp _strcmpi #elif defined(HAVE__STRICMP) #define strcasecmp _stricmp #endif #endif #if !defined(HAVE_STRDUP) #if defined(HAVE__STRDUP) #define strdup _strdup #endif #endif =0C #define CENTRAL_MAGIC "PK\1\2" #define LOCAL_MAGIC "PK\3\4" #define EOCD_MAGIC "PK\5\6" #define DATADES_MAGIC "PK\7\8" #define TORRENT_SIG "TORRENTZIPPED-" #define TORRENT_SIG_LEN 14 #define TORRENT_CRC_LEN 8 #define TORRENT_MEM_LEVEL 8 #define CDENTRYSIZE 46u #define LENTRYSIZE 30 #define MAXCOMLEN 65536 #define MAXEXTLEN 65536 #define EOCDLEN 22 #define CDBUFSIZE (MAXCOMLEN+EOCDLEN) #define BUFSIZE 8192 =0C /* This section contains API that won't materialize like this. It's placed in the internal section, pending cleanup. */ typedef struct zip_source *(*zip_compression_implementation)(struct zip *= , struct zip_source *, zip_uint16_t, int); typedef struct zip_source *(*zip_encryption_implementation)(struct zip *,= struct zip_source *, zip_uint16_t, int, const char *); ZIP_EXTERN zip_compression_implementation zip_get_compression_implementat= ion( zip_uint16_t); ZIP_EXTERN zip_encryption_implementation zip_get_encryption_implementatio= n( zip_uint16_t); =0C /* This section contains API that is of limited use until support for user-supplied compression/encryption implementation is finished. Thus we will keep it private for now. */ typedef zip_int64_t (*zip_source_layered_callback)(struct zip_source *, v= oid *, void *, zip_uint64_t, enum zip_source_cmd); ZIP_EXTERN void zip_source_close(struct zip_source *); ZIP_EXTERN struct zip_source *zip_source_crc(struct zip *, struct zip_sou= rce *, int); ZIP_EXTERN struct zip_source *zip_source_deflate(struct zip *, struct zip_source *, zip_uint16_t, int); ZIP_EXTERN void zip_source_error(struct zip_source *, int *, int *); ZIP_EXTERN struct zip_source *zip_source_layered(struct zip *, struct zip_source *, zip_source_layered_callback, void *); ZIP_EXTERN int zip_source_open(struct zip_source *); ZIP_EXTERN struct zip_source *zip_source_pkware(struct zip *, struct zip_source *, zip_uint16_t, int, const char *); ZIP_EXTERN zip_int64_t zip_source_read(struct zip_source *, void *, zip_uint64_t); ZIP_EXTERN int zip_source_stat(struct zip_source *, struct zip_stat *); /* This function will probably remain private. It is not needed to implement compression/encryption routines. (We should probably rename it to _zip_source_pop.) */ ZIP_EXTERN struct zip_source *zip_source_pop(struct zip_source *); =0C /* state of change of a file in zip archive */ enum zip_state { ZIP_ST_UNCHANGED, ZIP_ST_DELETED, ZIP_ST_REPLACED, ZIP_ST_ADDED, ZIP_ST_RENAMED }; /* error source for layered sources */ enum zip_les { ZIP_LES_NONE, ZIP_LES_UPPER, ZIP_LES_LOWER, ZIP_LES_INVAL = }; /* directory entry: general purpose bit flags */ #define ZIP_GPBF_ENCRYPTED 0x0001 /* is encrypted */ #define ZIP_GPBF_DATA_DESCRIPTOR 0x0008 /* crc/size after file data */ #define ZIP_GPBF_STRONG_ENCRYPTION 0x0040 /* uses strong encryption */ /* error information */ struct zip_error { int zip_err; /* libzip error code (ZIP_ER_*) */ int sys_err; /* copy of errno (E*) or zlib error code */ char *str; /* string representation or NULL */ }; /* zip archive, part of API */ struct zip { char *zn; /* file name */ FILE *zp; /* file */ struct zip_error error; /* error information */ unsigned int flags; /* archive global flags */ unsigned int ch_flags; /* changed archive global flags */ char *default_password; /* password used when no other supplied */ struct zip_cdir *cdir; /* central directory */ char *ch_comment; /* changed archive comment */ int ch_comment_len; /* length of changed zip archive * comment, -1 if unchanged */ zip_uint64_t nentry; /* number of entries */ zip_uint64_t nentry_alloc; /* number of entries allocated */ struct zip_entry *entry; /* entries */ int nfile; /* number of opened files within archive */ int nfile_alloc; /* number of files allocated */ struct zip_file **file; /* opened files within archive */ }; /* file in zip archive, part of API */ struct zip_file { struct zip *za; /* zip archive containing this file */ struct zip_error error; /* error information */ int eof; struct zip_source *src; /* data source */ }; /* zip archive directory entry (central or local) */ struct zip_dirent { unsigned short version_madeby; /* (c) version of creator */ unsigned short version_needed; /* (cl) version needed to extract */ unsigned short bitflags; /* (cl) general purpose bit flag */ unsigned short comp_method; /* (cl) compression method used */ time_t last_mod; /* (cl) time of last modification */ unsigned int crc; /* (cl) CRC-32 of uncompressed data */ unsigned int comp_size; /* (cl) size of commpressed data */ unsigned int uncomp_size; /* (cl) size of uncommpressed data */ char *filename; /* (cl) file name (NUL-terminated) */ unsigned short filename_len; /* (cl) length of filename (w/o NUL) */ char *extrafield; /* (cl) extra field */ unsigned short extrafield_len; /* (cl) length of extra field */ char *comment; /* (c) file comment */ unsigned short comment_len; /* (c) length of file comment */ unsigned short disk_number; /* (c) disk number start */ unsigned short int_attrib; /* (c) internal file attributes */ unsigned int ext_attrib; /* (c) external file attributes */ unsigned int offset; /* (c) offset of local header */ }; /* zip archive central directory */ struct zip_cdir { struct zip_dirent *entry; /* directory entries */ int nentry; /* number of entries */ unsigned int size; /* size of central direcotry */ unsigned int offset; /* offset of central directory in file */ char *comment; /* zip archive comment */ unsigned short comment_len; /* length of zip archive comment */ }; =0C struct zip_source { struct zip_source *src; union { zip_source_callback f; zip_source_layered_callback l; } cb; void *ud; enum zip_les error_source; int is_open; }; /* entry in zip archive directory */ struct zip_entry { enum zip_state state; struct zip_source *source; char *ch_filename; char *ch_extra; int ch_extra_len; char *ch_comment; int ch_comment_len; }; =0C extern const char * const _zip_err_str[]; extern const int _zip_nerr_str; extern const int _zip_err_type[]; =0C #define ZIP_ENTRY_DATA_CHANGED(x) \ ((x)->state =3D=3D ZIP_ST_REPLACED \ || (x)->state =3D=3D ZIP_ST_ADDED) #define ZIP_IS_RDONLY(za) ((za)->ch_flags & ZIP_AFL_RDONLY) =0C int _zip_cdir_compute_crc(struct zip *, uLong *); void _zip_cdir_free(struct zip_cdir *); int _zip_cdir_grow(struct zip_cdir *, int, struct zip_error *); struct zip_cdir *_zip_cdir_new(int, struct zip_error *); int _zip_cdir_write(struct zip_cdir *, FILE *, struct zip_error *); void _zip_dirent_finalize(struct zip_dirent *); void _zip_dirent_init(struct zip_dirent *); int _zip_dirent_read(struct zip_dirent *, FILE *, unsigned char **, zip_uint32_t *, int, struct zip_error *); void _zip_dirent_torrent_normalize(struct zip_dirent *); int _zip_dirent_write(struct zip_dirent *, FILE *, int, struct zip_error = *); void _zip_entry_free(struct zip_entry *); void _zip_entry_init(struct zip *, int); struct zip_entry *_zip_entry_new(struct zip *); void _zip_error_clear(struct zip_error *); void _zip_error_copy(struct zip_error *, struct zip_error *); void _zip_error_fini(struct zip_error *); void _zip_error_get(struct zip_error *, int *, int *); void _zip_error_init(struct zip_error *); void _zip_error_set(struct zip_error *, int, int); void _zip_error_set_from_source(struct zip_error *, struct zip_source *);= const char *_zip_error_strerror(struct zip_error *); int _zip_file_fillbuf(void *, size_t, struct zip_file *); unsigned int _zip_file_get_offset(struct zip *, int); int _zip_filerange_crc(FILE *, off_t, off_t, uLong *, struct zip_error *)= ; struct zip *_zip_open(const char *, FILE *, int, int, int *); struct zip_source *_zip_source_file_or_p(struct zip *, const char *, FILE= *, zip_uint64_t, zip_int64_t, int, const struct zip_stat *); struct zip_source *_zip_source_new(struct zip *); int _zip_changed(struct zip *, int *); void _zip_free(struct zip *); const char *_zip_get_name(struct zip *, zip_uint64_t, int, struct zip_err= or *); int _zip_local_header_read(struct zip *, int); void *_zip_memdup(const void *, size_t, struct zip_error *); int _zip_name_locate(struct zip *, const char *, int, struct zip_error *)= ; struct zip *_zip_new(struct zip_error *); unsigned short _zip_read2(unsigned char **); unsigned int _zip_read4(unsigned char **); zip_int64_t _zip_replace(struct zip *, zip_uint64_t, const char *, struct zip_source *); int _zip_set_name(struct zip *, zip_uint64_t, const char *); void _zip_u2d_time(time_t, unsigned short *, unsigned short *); int _zip_unchange(struct zip *, zip_uint64_t, int); void _zip_unchange_data(struct zip_entry *); #endif /* zipint.h */ --------------070906000505020105050500 Content-Type: text/plain; name="make.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="make.conf" WITHOUT_KOFFICE=3D"YES" WITH_CUPS=3D"YES" NO_LPR=3D"YES" CUPS_OVERRIDE_BASE=3D"YES" OVERRIDE_LINUX_BASE_PORT=3Df10 OVERRIDE_LINUX_NONBASE_PORTS=3Df10 #WITHOUT_redland=3D"YES" #DISABLE_VULNERABILITIES=3D"YES" PYTHON_DEFAULT_VERSION=3D2.7 # added by use.perl 2011-04-08 22:06:53 PERL_VERSION=3D5.10.1 --------------070906000505020105050500-- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 06:59:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BC5106564A for ; Thu, 12 May 2011 06:59:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 56BA08FC0A for ; Thu, 12 May 2011 06:59:49 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id iWyH1g0061Y3wxoA3WzoHi; Thu, 12 May 2011 06:59:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id iWzm1g0021t3BNj8bWzm8r; Thu, 12 May 2011 06:59:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 03218102C36; Wed, 11 May 2011 23:59:46 -0700 (PDT) Date: Wed, 11 May 2011 23:59:45 -0700 From: Jeremy Chadwick To: joerg_surmann Message-ID: <20110512065945.GA55199@icarus.home.lan> References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> <4DCB81EF.2080104@snafu.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <4DCB81EF.2080104@snafu.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 06:59:49 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 12, 2011 at 08:45:03AM +0200, joerg_surmann wrote: > Hey Jeremy, > > Ok i'll put the files in a attachment > on the end from this email. [...snip...] [attachment: zipconf.h] Oh dear. I'm not sure what to make of this: > #ifndef _HAD_ZIPCONF_H > #define _HAD_ZIPCONF_H > > /* > zipconf.h -- platform specific include file > > This file was generated automatically by ./make_zipconf.sh > based on ../config.h. > */ > > #define LIBZIP_VERSION "0.10" > #define LIBZIP_VERSION_MAJOR 0 > #define LIBZIP_VERSION_MINOR 10 > #define LIBZIP_VERSION_MICRO 0 > > #include > > typedef signed char int8_t; > #define ZIP_INU8_MAX SCHAR_MAX > > typedef unsigned char uint8_t; > #define ZIP_?INU8_MAX ?CHAR_MAX > > typedef shor? int16_t; > #define ZIP_INU16_MIN ?CHAR_MIN > #define ZIP_INU16_MAX ?CHAR_MAX > > typedef unsigned shor? uint16_t; > #define ZIP_?INU16_MAX ?CHAR_MAX > > typedef in? int32_t; > #define ZIP_INU32_MIN ?CHAR_MIN > #define ZIP_INU32_MAX ?CHAR_MAX > > typedef unsigned in? uint32_t; > #define ZIP_?INU32_MAX ?CHAR_MAX > > typedef long int64_t; > #define ZIP_INU64_MIN SLONG_MIN > #define ZIP_INU64_MAX SLONG_MAX > > typedef unsigned long uint64_t; > #define ZIP_?INU64_MAX ?LONG_MAX > > > #endif /* zipconf.h */ All of these values have a "?" injected in them, at seemingly randomly places. This is the problem, and why the C compiler is throwing errors. I don't know how or why this is happening. There could be many things going on that might explain it. Worst case would be odd/awkward hardware failure (bad RAM would show something like this), corrupt filesystem, a disk going bad silently ("bit rot"), etc.. My initial guess -- because this port uses a GNU autoconf script -- is that it's obtaining the types for things incorrectly. Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that gets propagated to the root environment (during su, sudo, etc.)? I see that you're in .de which is why I ask. I've attached a zipconf.h file from my system. You can compare the differences; it should be obvious. My system does not have "?" characters injected into the typedefs, but more importantly (and this is indeed important!), the types it detects/uses are completely different. I'm not sure what's going on with your system, but it almost implies that you have a separate set of include files that are "trumping" or "overriding" the FreeBSD base system defaults. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | --FCuugMFkClbJLl1L-- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 07:13:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8A86106566B for ; Thu, 12 May 2011 07:13:24 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 594F68FC1E for ; Thu, 12 May 2011 07:13:24 +0000 (UTC) Received: by wyf23 with SMTP id 23so1260263wyf.13 for ; Thu, 12 May 2011 00:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=VSbUS3phZRpNGxITrsuqdWa/hyZC/ttETeiZApSk0aE=; b=vpripD4HxX15fhWfrsCoUXD48VzYxQB91EnzQytgdHssffDbRaBtwcsc8j6yjeTKA0 0qehAm0xvOC6M8zeWEmgbG3lOYzazQe2wKY10KS/jGSHO+iEZRgT4qnCsMFITjB8Zl9p u1SZOYkvXgUvyWCfSo4oovgIcu5hIBRRHGNGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=W5uRb+8D+3ikucHgGbd5SPqsua1PP4WQH603kjTgMleP0g7WB/B/kWsrVHIZxweiyF gAub/2OhfnWhbQLwlrGrfrFyDXl2l/Iz1/9rGyGivg/paITlDQEOrjxBkg3mWG5USb8/ jLGZGu1U3YzimhPNZPQJ6bfJPcVnq2dzBi5Is= Received: by 10.227.58.82 with SMTP id f18mr7863592wbh.45.1305182792192; Wed, 11 May 2011 23:46:32 -0700 (PDT) Received: from Groseille.malikania.fr (65.21.102.84.rev.sfr.net [84.102.21.65]) by mx.google.com with ESMTPS id y29sm540368wbd.21.2011.05.11.23.46.30 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 23:46:31 -0700 (PDT) Message-ID: <4DCB8271.3070707@gmail.com> Date: Thu, 12 May 2011 08:47:13 +0200 From: David Demelier User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: snd_hda : sometimes sound sometimes not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 07:13:24 -0000 Hello, I don't know if there is a lot of changes in the snd_hda driver in the -STABLE branch but since I upgraded to it sometimes I have sound and sometimes not. The mixer are exactly the same when these event occurs. This happened this morning. After booting I do not have any sound. I rebooted and suddenly I've got sound again... I only tweak snd_hda(4) for a pin sense on the front panel (it has no sound neither) So I added in /boot/devices.hints : hint.hdac.1.cad0.nid27.config="as=1 seq=15" And there's the both dmesg ok.txt when sound is here and not.txt when there isn't as you can see there is no difference related to the hda driver. http://markand.malikania.fr/ok.txt http://markand.malikania.fr/nok.txt I'm guessing something. My laptop has a mute shortcut, if I press it at the BIOS stage I will not have sound neither thus is it possible that my chipset is muted from anything? Cheers, -- David Demelier From owner-freebsd-stable@FreeBSD.ORG Thu May 12 08:20:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427611065670 for ; Thu, 12 May 2011 08:20:54 +0000 (UTC) (envelope-from michael.ross@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 89F1F8FC12 for ; Thu, 12 May 2011 08:20:53 +0000 (UTC) Received: (qmail invoked by alias); 12 May 2011 07:54:11 -0000 Received: from dslb-188-108-093-254.pools.arcor-ip.net (EHLO michael-think) [188.108.93.254] by mail.gmx.net (mp025) with SMTP; 12 May 2011 09:54:11 +0200 X-Authenticated: #11429267 X-Provags-ID: V01U2FsdGVkX19bqmkEni5bAvP2h33OkzpPJsjSYTIDLUZF/RNlHk KyteYsBKdUvlzl Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: joerg_surmann , "Jeremy Chadwick" References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> <4DCB81EF.2080104@snafu.de> <20110512065945.GA55199@icarus.home.lan> Date: Thu, 12 May 2011 09:54:06 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Michael Ross" Message-ID: In-Reply-To: <20110512065945.GA55199@icarus.home.lan> User-Agent: Opera Mail/11.10 (Win32) X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 08:20:54 -0000 Am 12.05.2011, 08:59 Uhr, schrieb Jeremy Chadwick : > > Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that > gets propagated to the root environment (during su, sudo, etc.)? I see > that you're in .de which is why I ask. I have :lang=de_DE.ISO8859-1:\ in /etc/login.conf. Soon as I remove this, libzip compiles without error. Generated zipconf.h: http://pastebin.com/n8YKaNQ8 For comparison, with lang=de, completelty different types detected and used, erroneous zipconf.h: http://pastebin.com/yTw77zgt > I've attached a zipconf.h file from my system. You can compare the > differences; it should be obvious. My system does not have "?" > characters injected into the typedefs, but more importantly (and this is > indeed important!), the types it detects/uses are completely different. > > I'm not sure what's going on with your system, but it almost implies > that you have a separate set of include files that are "trumping" or > "overriding" the FreeBSD base system defaults. From owner-freebsd-stable@FreeBSD.ORG Thu May 12 08:45:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A3B6106564A for ; Thu, 12 May 2011 08:45:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id C8E458FC1A for ; Thu, 12 May 2011 08:45:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p4C8jMpj082562; Thu, 12 May 2011 18:45:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 12 May 2011 18:45:22 +1000 (EST) From: Ian Smith To: Jeremy Chadwick In-Reply-To: <20110512065945.GA55199@icarus.home.lan> Message-ID: <20110512180918.W58178@sola.nimnet.asn.au> References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> <4DCB81EF.2080104@snafu.de> <20110512065945.GA55199@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, joerg_surmann Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 08:45:26 -0000 On Wed, 11 May 2011, Jeremy Chadwick wrote: > On Thu, May 12, 2011 at 08:45:03AM +0200, joerg_surmann wrote: > > Hey Jeremy, > > > > Ok i'll put the files in a attachment > > on the end from this email. > > [...snip...] > [attachment: zipconf.h] > > Oh dear. I'm not sure what to make of this: > > > #ifndef _HAD_ZIPCONF_H > > #define _HAD_ZIPCONF_H > > > > /* > > zipconf.h -- platform specific include file > > > > This file was generated automatically by ./make_zipconf.sh > > based on ../config.h. > > */ > > > > #define LIBZIP_VERSION "0.10" > > #define LIBZIP_VERSION_MAJOR 0 > > #define LIBZIP_VERSION_MINOR 10 > > #define LIBZIP_VERSION_MICRO 0 > > > > #include > > > > typedef signed char int8_t; > > #define ZIP_INU8_MAX SCHAR_MAX > > > > typedef unsigned char uint8_t; > > #define ZIP_?INU8_MAX ?CHAR_MAX > > > > typedef shor? int16_t; > > #define ZIP_INU16_MIN ?CHAR_MIN > > #define ZIP_INU16_MAX ?CHAR_MAX > > > > typedef unsigned shor? uint16_t; > > #define ZIP_?INU16_MAX ?CHAR_MAX > > > > typedef in? int32_t; > > #define ZIP_INU32_MIN ?CHAR_MIN > > #define ZIP_INU32_MAX ?CHAR_MAX > > > > typedef unsigned in? uint32_t; > > #define ZIP_?INU32_MAX ?CHAR_MAX > > > > typedef long int64_t; > > #define ZIP_INU64_MIN SLONG_MIN > > #define ZIP_INU64_MAX SLONG_MAX > > > > typedef unsigned long uint64_t; > > #define ZIP_?INU64_MAX ?LONG_MAX > > > > > > #endif /* zipconf.h */ > > All of these values have a "?" injected in them, at seemingly randomly > places. This is the problem, and why the C compiler is throwing errors. Indeed, but not really '?' and not so random. Viewing zipconf.h in less shows control characters as for the section of concern: ======= typedef unsigned char uint8_t; #define ZIP_INU8_MAX CHAR_MAX typedef shor int16_t; #define ZIP_INU16_MIN CHAR_MIN #define ZIP_INU16_MAX CHAR_MAX typedef unsigned shor uint16_t; #define ZIP_INU16_MAX CHAR_MAX typedef in int32_t; #define ZIP_INU32_MIN CHAR_MIN #define ZIP_INU32_MAX CHAR_MAX typedef unsigned in uint32_t; #define ZIP_INU32_MAX CHAR_MAX typedef long int64_t; #define ZIP_INU64_MIN SLONG_MIN #define ZIP_INU64_MAX SLONG_MAX typedef unsigned long uint64_t; #define ZIP_INU64_MAX LONG_MAX ======= In ISO-8859-1 at least, is that German character that looks rather like a capital B in running writing (perhaps it's some sort of 't', as in short and int?), and the looks like a capital U with a single dot above, initially not easy to distinguish from cap U (appearing so alike to eg 'ULONG*' or 'UCHAR*' that I missed it on first glance) > I don't know how or why this is happening. There could be many things > going on that might explain it. Worst case would be odd/awkward > hardware failure (bad RAM would show something like this), corrupt > filesystem, a disk going bad silently ("bit rot"), etc.. This one seems far too non-random to be a hardware issue artifact. > My initial guess -- because this port uses a GNU autoconf script -- is > that it's obtaining the types for things incorrectly. > > Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that > gets propagated to the root environment (during su, sudo, etc.)? I see > that you're in .de which is why I ask. I expect that's likely much closer to the mark. > I've attached a zipconf.h file from my system. You can compare the > differences; it should be obvious. My system does not have "?" > characters injected into the typedefs, but more importantly (and this is > indeed important!), the types it detects/uses are completely different. > > I'm not sure what's going on with your system, but it almost implies > that you have a separate set of include files that are "trumping" or > "overriding" the FreeBSD base system defaults. Quite likely language related, but I've no idea HOW that could happen? cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu May 12 08:50:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC87106566C for ; Thu, 12 May 2011 08:50:08 +0000 (UTC) (envelope-from makc@issp.ac.ru) Received: from mail.issp.ac.ru (mail.issp.ac.ru [77.236.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 072808FC2A for ; Thu, 12 May 2011 08:50:07 +0000 (UTC) Received: from [62.63.85.2] [62.63.85.2:31182] (HELO/EHLO luna.dio.ru, authenticated with PLAIN) by mail.issp.ac.ru with ESMTP/inet id p4C8oacx009868 (using TLSv1/SSLv3, with cipher DHE-RSA-AES256-SHA (256 bits), verified NO) Thu, 12 May 2011 12:50:36 +0400 (MSD) From: Max Brazhnikov Organization: ISSP RAS To: freebsd-stable@freebsd.org Date: Thu, 12 May 2011 12:50:04 +0400 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.3; amd64; ; ) References: <4DCB7962.6090706@snafu.de> <20110512065945.GA55199@icarus.home.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201105121250.05385.makc@issp.ac.ru> Cc: Jeremy Chadwick , joerg_surmann , Michael Ross Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 08:50:08 -0000 On Thu, 12 May 2011 09:54:06 +0200, Michael Ross wrote: > Am 12.05.2011, 08:59 Uhr, schrieb Jeremy Chadwick > : > > > > > Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that > > gets propagated to the root environment (during su, sudo, etc.)? I see > > that you're in .de which is why I ask. > > I have > > :lang=de_DE.ISO8859-1:\ > > in /etc/login.conf. > > Soon as I remove this, libzip compiles without error. > > Generated zipconf.h: http://pastebin.com/n8YKaNQ8 > > > For comparison, with lang=de, > completelty different types detected and used, > erroneous zipconf.h: http://pastebin.com/yTw77zgt Thank you all, I've just fixed lipzip port. Max From owner-freebsd-stable@FreeBSD.ORG Thu May 12 19:13:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733961065674 for ; Thu, 12 May 2011 19:13:30 +0000 (UTC) (envelope-from joerg_surmann@snafu.de) Received: from waikiki.ops.eusc.inter.net (waikiki.ops.eusc.inter.net [84.23.254.155]) by mx1.freebsd.org (Postfix) with ESMTP id 34DB78FC2D for ; Thu, 12 May 2011 19:13:29 +0000 (UTC) X-Trace: 507c73757269697c37382e35322e3234332e34307c31514b624b422d303030386a 442d4b737c31333035323237363037 Received: from waikiki.ops.eusc.inter.net ([10.155.10.19] helo=localhost) by waikiki.ops.eusc.inter.net with esmtpsa (Exim 4.72) id 1QKbKB-0008jD-Ks for freebsd-stable@freebsd.org; Thu, 12 May 2011 21:13:27 +0200 Message-ID: <4DCC3156.4020304@snafu.de> Date: Thu, 12 May 2011 21:13:26 +0200 From: joerg_surmann User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.17) Gecko/20110430 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 78.52.243.40 X-SA-Exim-Mail-From: joerg_surmann@snafu.de X-SA-Exim-Scanned: No (on waikiki.ops.eusc.inter.net); SAEximRunCond expanded to false Subject: Re: can't update libzip-0.9.3 to libzip-0.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 19:13:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes i've lang=de_DE.ISO8859-15:\ in my /etc/login.conf. WITH_LANG=de was the point. libzip compiles corect. Thank you all. Suri Am 12.05.2011 10:50, schrieb Max Brazhnikov: > > On Thu, 12 May 2011 09:54:06 +0200, Michael Ross wrote: >> >> Am 12.05.2011, 08:59 Uhr, schrieb Jeremy Chadwick >> >> : >> >> >>> >>> >>> >>> Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that >>> >>> gets propagated to the root environment (during su, sudo, etc.)? I see >>> >>> that you're in .de which is why I ask. >> >> >> >> I have >> >> >> >> :lang=de_DE.ISO8859-1:\ >> >> >> >> in /etc/login.conf. >> >> >> >> Soon as I remove this, libzip compiles without error. >> >> >> >> Generated zipconf.h: http://pastebin.com/n8YKaNQ8 >> >> >> >> >> >> For comparison, with lang=de, >> >> completelty different types detected and used, >> >> erroneous zipconf.h: http://pastebin.com/yTw77zgt > > > > Thank you all, I've just fixed lipzip port. > > > > Max -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3MMVYACgkQcEHvP2uxrTMPUwCdFr6hO69RHthgoW8nx5G8OawT 5GoAnRzSjjP3WF56Eafun6Ult8+sQ9VW =xRoX -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 19:44:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68F321065670 for ; Thu, 12 May 2011 19:44:28 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7C98FC0A for ; Thu, 12 May 2011 19:44:27 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QKbmz-0000cn-Ix for freebsd-stable@freebsd.org; Thu, 12 May 2011 21:44:27 +0200 Message-ID: <4DCC3844.6070008@it4pro.pl> Date: Thu, 12 May 2011 21:43:00 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: FreeBSD Stable References: <4DC6A277.4030801@it4pro.pl> <4DC6E23B.2040207@it4pro.pl> <4DC81E22.5030806@it4pro.pl> In-Reply-To: <4DC81E22.5030806@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.76 (build at 12-May-2011 10:41:54) X-Date: 2011-05-12 21:44:27 X-Connected-IP: 78.8.144.74:61491 X-Message-Linecount: 21 X-Body-Linecount: 7 X-Message-Size: 749 X-Body-Size: 107 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 19:44:28 -0000 Allright, if anyone want to follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=156974 -- Bartosz Stec From owner-freebsd-stable@FreeBSD.ORG Thu May 12 19:59:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 964AF106566C for ; Thu, 12 May 2011 19:59:24 +0000 (UTC) (envelope-from dillinsmith@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC2408FC18 for ; Thu, 12 May 2011 19:59:23 +0000 (UTC) Received: by eyg7 with SMTP id 7so735828eyg.13 for ; Thu, 12 May 2011 12:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=HlTziqJkgNxLMUQsBP/RyVu2bB56aepz4FN7fNINqgo=; b=mdvJtlQiY7aQP0wLIsDb/ZcieaWpfumaXNK4wLaX9R4ldOhiyS+t8TuXXEsD5dNufs 266d5/8yQQN3vGuFr5AyL3DfTZe1+5tHjblhd20BIPV02RIP96TgDo+vVUrpA1hRVZvU PpOuRfASPe6jGmJyMZsj3vWN0U61wY2+qjlaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=VjIqQdfoLmMyWpYxm9aPmF5B9wV6yk70QYLh50DY0oEuXHQPRiNHd7rMpmzkKS6/fq HOaMfLHQTfTmEJs9WcnZPJjSoOmPt+TIa3XPOhREzIvAQ60GoYTlCkSW9aPKUlCaLEZt wZenRtEcF/VnznDEBh3Jl3wQKagyXJQPRDN0I= Received: by 10.213.9.132 with SMTP id l4mr401304ebl.62.1305228880267; Thu, 12 May 2011 12:34:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.108.202 with HTTP; Thu, 12 May 2011 12:34:20 -0700 (PDT) In-Reply-To: References: From: Dillin Smith Date: Thu, 12 May 2011 15:34:20 -0400 Message-ID: To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=001517494564c24ab004a31947d7 X-Mailman-Approved-At: Thu, 12 May 2011 20:18:45 +0000 Subject: Fwd: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 19:59:24 -0000 --001517494564c24ab004a31947d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, =A0 I'm having an issue getting my installation of FreeBSD to detect all the drives in the system. It has 48 total, 46 2TB, and 2 250GB. The system consists of six controllers, with eight drives on each. The two 250GB hard drives are the first drives on controllers 0 and 1. =A0 There are two of these machines with the exact same configurations, having the same problem. A very odd thing is that every time the systems are rebooted, the drives that go undetected vary. Also, when the systems were full of 250GB drives, all were detected. All drives are detected in the BIOS of the controllers, just not by FreeBSD. Any and all help is greatly appreciated. (output of dmesg attached) -- ds --001517494564c24ab004a31947d7 Content-Type: application/octet-stream; name="dmesg.out" Content-Disposition: attachment; filename="dmesg.out" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gnlpiaaj0 Q29weXJpZ2h0IChjKSAxOTkyLTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjItU1RBQkxFICMwOiBXZWQgTWF5IDExIDE2OjEw OjA4IEVEVCAyMDExCiAgICByb290QGJvYm8uZWFybGhhbS5lZHU6L3Vzci9vYmovdXNyL3NyYy9z eXMvR0VORVJJQyBhbWQ2NApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 IHF1YWxpdHkgMApDUFU6IFF1YWQtQ29yZSBBTUQgT3B0ZXJvbih0bSkgUHJvY2Vzc29yIDIzNTYg KDIzMDAuMTEtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQg PSAweDEwMGYyMyAgRmFtaWx5ID0gMTAgIE1vZGVsID0gMiAgU3RlcHBpbmcgPSAzCiAgRmVhdHVy ZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQ LE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhU VD4KICBGZWF0dXJlczI9MHg4MDIwMDk8U1NFMyxNT04sQ1gxNixQT1BDTlQ+CiAgQU1EIEZlYXR1 cmVzPTB4ZWU1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFBhZ2UxR0IsUkRUU0NQLExNLDNE Tm93ISssM0ROb3chPgogIEFNRCBGZWF0dXJlczI9MHg3ZmY8TEFIRixDTVAsU1ZNLEV4dEFQSUMs Q1I4LEFCTSxTU0U0QSxNQVMsUHJlZmV0Y2gsT1NWVyxJQlM+CiAgVFNDOiBQLXN0YXRlIGludmFy aWFudApyZWFsIG1lbW9yeSAgPSAzNDM1OTczODM2OCAoMzI3NjggTUIpCmF2YWlsIG1lbW9yeSA9 IDMzMTEwNDE3NDA4ICgzMTU3NiBNQikKQUNQSSBBUElDIFRhYmxlOiA8U1VOICAgIFg0NTQwICAg PgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA4IENQVXMKRnJl ZUJTRC9TTVA6IDIgcGFja2FnZShzKSB4IDQgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDog IDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNwdTMg KEFQKTogQVBJQyBJRDogIDMKIGNwdTQgKEFQKTogQVBJQyBJRDogIDQKIGNwdTUgKEFQKTogQVBJ QyBJRDogIDUKIGNwdTYgKEFQKTogQVBJQyBJRDogIDYKIGNwdTcgKEFQKTogQVBJQyBJRDogIDcK aW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxW ZXJzaW9uIDEuMT4gaXJxcyAyNC00NyBvbiBtb3RoZXJib2FyZAppb2FwaWMyIDxWZXJzaW9uIDEu MT4gaXJxcyA0OC03MSBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNwaTA6IDxTVU4g WDQ1NDA+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRv biAoZml4ZWQpCnVua25vd246IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkCmFjcGkwOiByZXNlcnZh dGlvbiBvZiBmZWMwMDAwMCwgMTAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBm ZWUwMDAwMCwgMTAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAo MykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAxMDAwMDAsIGRkZjAwMDAwICgzKSBmYWls ZWQKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAx MDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ZTAw OC0weGUwMGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUxOiA8QUNQSSBD UFU+IG9uIGFjcGkwCmNwdTI6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MzogPEFDUEkgQ1BVPiBv biBhY3BpMApjcHU0OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTU6IDxBQ1BJIENQVT4gb24gYWNw aTAKY3B1NjogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU3OiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBj aWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2Ug MC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IHBvcnQgMHhl ZjAwLTB4ZWY3ZiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIw CnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDEuMSAobm8gZHJpdmVyIGF0dGFj aGVkKQpvaGNpMDogPG5WaWRpYSBuRm9yY2UgTUNQNTUgVVNCIENvbnRyb2xsZXI+IG1lbSAweGRl N2ZmMDAwLTB4ZGU3ZmZmZmYgaXJxIDIxIGF0IGRldmljZSAyLjAgb24gcGNpMApvaGNpMDogW0lU SFJFQURdCnVzYnVzMDogPG5WaWRpYSBuRm9yY2UgTUNQNTUgVVNCIENvbnRyb2xsZXI+IG9uIG9o Y2kwCmVoY2kwOiA8TlZJRElBIG5Gb3JjZSBNQ1A1NSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAw eGRlN2ZlYzAwLTB4ZGU3ZmVjZmYgaXJxIDIyIGF0IGRldmljZSAyLjEgb24gcGNpMAplaGNpMDog W0lUSFJFQURdCnVzYnVzMTogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czE6IDxOVklESUEgbkZvcmNl IE1DUDU1IFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhhYzAwLTB4YWM3ZiBt ZW0gMHhkZTgwMDAwMC0weGRlZmZmZmZmLDB4ZGYzZTAwMDAtMHhkZjNmZmZmZiBpcnEgMTYgYXQg ZGV2aWNlIDUuMCBvbiBwY2kxCm5mZTA6IDxOVklESUEgbkZvcmNlIE1DUDU1IE5ldHdvcmtpbmcg QWRhcHRlcj4gcG9ydCAweDk0ODAtMHg5NDg3IG1lbSAweGRlN2ZkMDAwLTB4ZGU3ZmRmZmYsMHhk ZTdmZTgwMC0weGRlN2ZlOGZmLDB4ZGU3ZmU0MDAtMHhkZTdmZTQwZiBpcnEgMjMgYXQgZGV2aWNl IDguMCBvbiBwY2kwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBuZmUwCmUxMDAwcGh5MDogPE1hcnZl bGwgODhFMTE0OSBHaWdhYml0IFBIWT4gUEhZIDIgb24gbWlpYnVzMAplMTAwMHBoeTA6ICAxMGJh c2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEw MDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRv LCBhdXRvLWZsb3cKbmZlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTQ6NGY6ZjI6YTY6OTAKbmZl MDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0K bmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRFUl0KbmZlMDogW0ZJTFRF Ul0KbmZlMTogPE5WSURJQSBuRm9yY2UgTUNQNTUgTmV0d29ya2luZyBBZGFwdGVyPiBwb3J0IDB4 OTQwMC0weDk0MDcgbWVtIDB4ZGU3ZmMwMDAtMHhkZTdmY2ZmZiwweGRlN2ZlMDAwLTB4ZGU3ZmUw ZmYsMHhkZTdmN2MwMC0weGRlN2Y3YzBmIGlycSAyMCBhdCBkZXZpY2UgOS4wIG9uIHBjaTAKbWlp YnVzMTogPE1JSSBidXM+IG9uIG5mZTEKZTEwMDBwaHkxOiA8TWFydmVsbCA4OEUxMTQ5IEdpZ2Fi aXQgUEhZPiBQSFkgMyBvbiBtaWlidXMxCmUxMDAwcGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3Rlciwg MTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdwpuZmUx OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxNDo0ZjpmMjphNjo5MQpuZmUxOiBbRklMVEVSXQpuZmUx OiBbRklMVEVSXQpuZmUxOiBbRklMVEVSXQpuZmUxOiBbRklMVEVSXQpuZmUxOiBbRklMVEVSXQpu ZmUxOiBbRklMVEVSXQpuZmUxOiBbRklMVEVSXQpuZmUxOiBbRklMVEVSXQpwY2liMjogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjIKbXB0MDogPExTSUxvZ2ljIFNBUy9TQVRBIEFkYXB0ZXI+IHBvcnQgMHhiODAw LTB4YjhmZiBtZW0gMHhkZjdmYzAwMC0weGRmN2ZmZmZmLDB4ZGY3ZTAwMDAtMHhkZjdlZmZmZiBp cnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCm1wdDA6IFtJVEhSRUFEXQptcHQwOiBNUEkgVmVy c2lvbj0xLjUuMTYuMApwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxMS4w IG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKbXB0MTogPExTSUxvZ2ljIFNB Uy9TQVRBIEFkYXB0ZXI+IHBvcnQgMHhjODAwLTB4YzhmZiBtZW0gMHhkZmJmYzAwMC0weGRmYmZm ZmZmLDB4ZGZiZTAwMDAtMHhkZmJlZmZmZiBpcnEgMTggYXQgZGV2aWNlIDAuMCBvbiBwY2kzCm1w dDE6IFtJVEhSRUFEXQptcHQxOiBNUEkgVmVyc2lvbj0xLjUuMTYuMApwY2liNDogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNS4wIG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjQKbXB0MjogPExTSUxvZ2ljIFNBUy9TQVRBIEFkYXB0ZXI+IHBvcnQgMHhkODAwLTB4 ZDhmZiBtZW0gMHhkZmZmYzAwMC0weGRmZmZmZmZmLDB4ZGZmZTAwMDAtMHhkZmZlZmZmZiBpcnEg MTggYXQgZGV2aWNlIDAuMCBvbiBwY2k0Cm1wdDI6IFtJVEhSRUFEXQptcHQyOiBNUEkgVmVyc2lv bj0xLjUuMTYuMApwY2liNTogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMApwY2k2NDog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpNjQ6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAu MCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2k2NDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMS4w IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTY0OiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmlj ZSAxLjEgKG5vIGRyaXZlciBhdHRhY2hlZCkKbmZlMjogPE5WSURJQSBuRm9yY2UgTUNQNTUgTmV0 d29ya2luZyBBZGFwdGVyPiBwb3J0IDB4NTQwMC0weDU0MDcgbWVtIDB4ZGQzZmUwMDAtMHhkZDNm ZWZmZiwweGRkM2ZkYzAwLTB4ZGQzZmRjZmYsMHhkZDNmZDgwMC0weGRkM2ZkODBmIGlycSA0NSBh dCBkZXZpY2UgOC4wIG9uIHBjaTY0Cm1paWJ1czI6IDxNSUkgYnVzPiBvbiBuZmUyCmUxMDAwcGh5 MjogPE1hcnZlbGwgODhFMTE0OSBHaWdhYml0IFBIWT4gUEhZIDIgb24gbWlpYnVzMgplMTAwMHBo eTI6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAw YmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFz dGVyLCBhdXRvLCBhdXRvLWZsb3cKbmZlMjogRXRoZXJuZXQgYWRkcmVzczogMDA6MTQ6NGY6ZjI6 YTY6OTIKbmZlMjogW0ZJTFRFUl0KbmZlMjogW0ZJTFRFUl0KbmZlMjogW0ZJTFRFUl0KbmZlMjog W0ZJTFRFUl0KbmZlMjogW0ZJTFRFUl0KbmZlMjogW0ZJTFRFUl0KbmZlMjogW0ZJTFRFUl0KbmZl MjogW0ZJTFRFUl0KbmZlMzogPE5WSURJQSBuRm9yY2UgTUNQNTUgTmV0d29ya2luZyBBZGFwdGVy PiBwb3J0IDB4NTA4MC0weDUwODcgbWVtIDB4ZGQzZmMwMDAtMHhkZDNmY2ZmZiwweGRkM2ZkNDAw LTB4ZGQzZmQ0ZmYsMHhkZDNmZDAwMC0weGRkM2ZkMDBmIGlycSA0NiBhdCBkZXZpY2UgOS4wIG9u IHBjaTY0Cm1paWJ1czM6IDxNSUkgYnVzPiBvbiBuZmUzCmUxMDAwcGh5MzogPE1hcnZlbGwgODhF MTE0OSBHaWdhYml0IFBIWT4gUEhZIDMgb24gbWlpYnVzMwplMTAwMHBoeTM6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNl VC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRv LWZsb3cKbmZlMzogRXRoZXJuZXQgYWRkcmVzczogMDA6MTQ6NGY6ZjI6YTY6OTMKbmZlMzogW0ZJ TFRFUl0KbmZlMzogW0ZJTFRFUl0KbmZlMzogW0ZJTFRFUl0KbmZlMzogW0ZJTFRFUl0KbmZlMzog W0ZJTFRFUl0KbmZlMzogW0ZJTFRFUl0KbmZlMzogW0ZJTFRFUl0KbmZlMzogW0ZJTFRFUl0KcGNp YjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTAuMCBvbiBwY2k2NApwY2k2NTog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjYKbXB0MzogPExTSUxvZ2ljIFNBUy9TQVRBIEFkYXB0ZXI+ IHBvcnQgMHg2ODAwLTB4NjhmZiBtZW0gMHhkZDdmYzAwMC0weGRkN2ZmZmZmLDB4ZGQ3ZTAwMDAt MHhkZDdlZmZmZiBpcnEgNDAgYXQgZGV2aWNlIDAuMCBvbiBwY2k2NQptcHQzOiBbSVRIUkVBRF0K bXB0MzogTVBJIFZlcnNpb249MS41LjE2LjAKcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMTEuMCBvbiBwY2k2NApwY2k2NjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKbXB0 NDogPExTSUxvZ2ljIFNBUy9TQVRBIEFkYXB0ZXI+IHBvcnQgMHg3ODAwLTB4NzhmZiBtZW0gMHhk ZGJmYzAwMC0weGRkYmZmZmZmLDB4ZGRiZTAwMDAtMHhkZGJlZmZmZiBpcnEgNDEgYXQgZGV2aWNl IDAuMCBvbiBwY2k2NgptcHQ0OiBbSVRIUkVBRF0KbXB0NDogTVBJIFZlcnNpb249MS41LjE2LjAK cGNpYjg6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTUuMCBvbiBwY2k2NApwY2k2 NzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgKbXB0NTogPExTSUxvZ2ljIFNBUy9TQVRBIEFkYXB0 ZXI+IHBvcnQgMHg4ODAwLTB4ODhmZiBtZW0gMHhkZGZmYzAwMC0weGRkZmZmZmZmLDB4ZGRmZTAw MDAtMHhkZGZlZmZmZiBpcnEgNDEgYXQgZGV2aWNlIDAuMCBvbiBwY2k2NwptcHQ1OiBbSVRIUkVB RF0KbXB0NTogTVBJIFZlcnNpb249MS41LjE2LjAKcGNpYjk6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gb24gYWNwaTAKcGNpMTI4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQpwY2kxMjg6IDxtZW1v cnksIFJBTT4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kxMjg6IDxtZW1v cnksIFJBTT4gYXQgZGV2aWNlIDEuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kxMjg6IDxzZXJp YWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDEuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMTA6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTAuMCBvbiBwY2kxMjgKcGNpMTI5OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTAKcGNpYjExOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDExLjAgb24gcGNpMTI4CnBjaTEzMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjExCnBj aWIxMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxNS4wIG9uIHBjaTEyOApwY2kx MzE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMgphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+ IG9uIGFjcGkwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MSBpcnEg OCBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVt IDB4ZmVkMDAwMDAtMHhmZWQwMGZmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVl bmN5IDI1MDAwMDAwIEh6IHF1YWxpdHkgOTAwCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4g cG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnVhcnQwOiBbRklMVEVS XQpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhjZTAw MC0weGNmN2ZmIG9uIGlzYTAKYXRrYmQ6IHVuYWJsZSB0byBzZXQgdGhlIGNvbW1hbmQgYnl0ZS4K c2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBDR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2QwLTB4M2RiIGlvbWVtIDB4YjgwMDAtMHhiZmZmZiBvbiBpc2EwCmF0a2JkYzA6 IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAK YXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiB1bmFibGUgdG8gc2V0 IHRoZSBjb21tYW5kIGJ5dGUuCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCmh3 cHN0YXRlMDogPENvb2xgbidRdWlldCAyLjA+IG9uIGNwdTAKVGltZWNvdW50ZXJzIHRpY2sgZXZl cnkgMS4wMDAgbXNlYwp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTog NDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW4wLjE6IDxuVmlkaWE+IGF0IHVzYnVzMAp1 aHViMDogPG5WaWRpYSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxuVmlkaWE+IGF0IHVzYnVzMQp1aHViMTogPG5WaWRp YSBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMxCnVodWIwOiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmRhMCBh dCBtcHQwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxBVEEgU0VBR0FURSBTVDMy NTAyTiBTVTBEPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMDogMzAwLjAw ME1CL3MgdHJhbnNmZXJzCmRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMDogMjM4NDcx TUIgKDQ4ODM5MDYyNSA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDMwNDAwQykKZGExIGF0 IG1wdDAgYnVzIDAgc2NidXMwIHRhcmdldCAxIGx1biAwCmRhMTogPEFUQSBIaXRhY2hpIEhEUzcy MzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGExOiAzMDAuMDAw TUIvcyB0cmFuc2ZlcnMKZGExOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGExOiAxOTA3NzI5 TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTIg YXQgbXB0MCBidXMgMCBzY2J1czAgdGFyZ2V0IDIgbHVuIDAKZGEyOiA8QVRBIEhpdGFjaGkgSERT NzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTI6IDMwMC4w MDBNQi9zIHRyYW5zZmVycwpkYTI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTI6IDE5MDc3 MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRh MyBhdCBtcHQwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMyBsdW4gMApkYTM6IDxBVEEgSGl0YWNoaSBI RFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMzogMzAw LjAwME1CL3MgdHJhbnNmZXJzCmRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMzogMTkw NzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykK ZGE3IGF0IG1wdDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCmRhNzogPEFUQSBTRUFHQVRF IFNUMzI1MDJOIFNVMEQ+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGE3OiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE3OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGE3OiAy Mzg0NzFNQiAoNDg4MzkwNjI1IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMzA0MDBDKQpk YTQgYXQgbXB0MCBidXMgMCBzY2J1czAgdGFyZ2V0IDQgbHVuIDAKZGE0OiA8QVRBIEhpdGFjaGkg SERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTQ6IDMw MC4wMDBNQi9zIHRyYW5zZmVycwpkYTQ6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTQ6IDE5 MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMp CmRhNSBhdCBtcHQwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgNSBsdW4gMApkYTU6IDxBVEEgSGl0YWNo aSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhNTog MzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhNTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhNTog MTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAx QykKZGE2IGF0IG1wdDAgYnVzIDAgc2NidXMwIHRhcmdldCA2IGx1biAwCmRhNjogPEFUQSBIaXRh Y2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGE2 OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE2OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGE2 OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMy MDFDKQpkYTggYXQgbXB0MSBidXMgMCBzY2J1czEgdGFyZ2V0IDEgbHVuIDAKZGE4OiA8QVRBIEhp dGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApk YTg6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApk YTg6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0 MzIwMUMpCmRhOSBhdCBtcHQxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMiBsdW4gMApkYTk6IDxBVEEg SGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2Ug CmRhOTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhOTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk CmRhOTogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1Qg MjQzMjAxQykKZGExMCBhdCBtcHQxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMyBsdW4gMApkYTEwOiA8 QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2 aWNlIApkYTEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExMDogQ29tbWFuZCBRdWV1ZWluZyBl bmFibGVkCmRhMTA6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDI0MzIwMUMpCmRhMTEgYXQgbXB0MSBidXMgMCBzY2J1czEgdGFyZ2V0IDQgbHVuIDAK ZGExMTogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NT SS01IGRldmljZSAKZGExMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTE6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZApkYTExOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTEyIGF0IG1wdDEgYnVzIDAgc2NidXMxIHRhcmdldCA1 IGx1biAwCmRhMTI6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNj ZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTEyOiBDb21t YW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGExMjogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRl IHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKZGExMyBhdCBtcHQxIGJ1cyAwIHNjYnVzMSB0 YXJnZXQgNiBsdW4gMApkYTEzOiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGly ZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEx MzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMTM6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1 MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMTQgYXQgbXB0MSBidXMgMCBz Y2J1czEgdGFyZ2V0IDcgbHVuIDAKZGExNDogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZp eGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGExNDogMzAwLjAwME1CL3MgdHJhbnNm ZXJzCmRhMTQ6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTE0OiAxOTA3NzI5TUIgKDM5MDcw MjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTE1IGF0IG1wdDIg YnVzIDAgc2NidXMyIHRhcmdldCAyIGx1biAwCmRhMTU6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBB MTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMTU6IDMwMC4wMDBNQi9z IHRyYW5zZmVycwpkYTE1OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGExNTogMTkwNzcyOU1C ICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKZGExNiBh dCBtcHQyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMyBsdW4gMApkYTE2OiA8QVRBIEhpdGFjaGkgSERT NzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTE2OiAzMDAu MDAwTUIvcyB0cmFuc2ZlcnMKZGExNjogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMTY6IDE5 MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMp CmRhMTcgYXQgbXB0MiBidXMgMCBzY2J1czIgdGFyZ2V0IDQgbHVuIDAKZGExNzogPEFUQSBIaXRh Y2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEx NzogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTc6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApk YTE3OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAy NDMyMDFDKQpkYTE4IGF0IG1wdDIgYnVzIDAgc2NidXMyIHRhcmdldCA1IGx1biAwCmRhMTg6IDxB VEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZp Y2UgCmRhMTg6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTE4OiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKZGExODogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUgg NjNTL1QgMjQzMjAxQykKZGExOSBhdCBtcHQyIGJ1cyAwIHNjYnVzMiB0YXJnZXQgNiBsdW4gMApk YTE5OiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJ LTUgZGV2aWNlIApkYTE5OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGExOTogQ29tbWFuZCBRdWV1 ZWluZyBlbmFibGVkCmRhMTk6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3Jz OiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMjEgYXQgbXB0MyBidXMgMCBzY2J1czMgdGFyZ2V0IDAg bHVuIDAKZGEyMTogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nl c3MgU0NTSS01IGRldmljZSAKZGEyMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMjE6IENvbW1h bmQgUXVldWVpbmcgZW5hYmxlZApkYTIxOiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUg c2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTIyIGF0IG1wdDMgYnVzIDAgc2NidXMzIHRh cmdldCAxIGx1biAwCmRhMjI6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJl Y3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMjI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTIy OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEyMjogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUx MiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKZGEyMCBhdCBtcHQyIGJ1cyAwIHNj YnVzMiB0YXJnZXQgNyBsdW4gMApkYTIwOiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTIwOiAzMDAuMDAwTUIvcyB0cmFuc2Zl cnMKZGEyMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMjA6IDE5MDc3MjlNQiAoMzkwNzAy OTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMjMgYXQgbXB0MyBi dXMgMCBzY2J1czMgdGFyZ2V0IDIgbHVuIDAKZGEyMzogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEEx ODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEyMzogMzAwLjAwME1CL3Mg dHJhbnNmZXJzCmRhMjM6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTIzOiAxOTA3NzI5TUIg KDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTI0IGF0 IG1wdDMgYnVzIDAgc2NidXMzIHRhcmdldCAzIGx1biAwCmRhMjQ6IDxBVEEgSGl0YWNoaSBIRFM3 MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMjQ6IDMwMC4w MDBNQi9zIHRyYW5zZmVycwpkYTI0OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEyNDogMTkw NzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykK ZGEyNSBhdCBtcHQzIGJ1cyAwIHNjYnVzMyB0YXJnZXQgNCBsdW4gMApkYTI1OiA8QVRBIEhpdGFj aGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTI1 OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEyNTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRh MjU6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0 MzIwMUMpCmRhMjYgYXQgbXB0MyBidXMgMCBzY2J1czMgdGFyZ2V0IDUgbHVuIDAKZGEyNjogPEFU QSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmlj ZSAKZGEyNjogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMjY6IENvbW1hbmQgUXVldWVpbmcgZW5h YmxlZApkYTI2OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCAyNDMyMDFDKQpkYTI3IGF0IG1wdDMgYnVzIDAgc2NidXMzIHRhcmdldCA2IGx1biAwCmRh Mjc6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0kt NSBkZXZpY2UgCmRhMjc6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTI3OiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKZGEyNzogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6 IDI1NUggNjNTL1QgMjQzMjAxQykKZGEyOCBhdCBtcHQ0IGJ1cyAwIHNjYnVzNCB0YXJnZXQgMCBs dW4gMApkYTI4OiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2Vz cyBTQ1NJLTUgZGV2aWNlIApkYTI4OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEyODogQ29tbWFu ZCBRdWV1ZWluZyBlbmFibGVkCmRhMjg6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBz ZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMjkgYXQgbXB0NCBidXMgMCBzY2J1czQgdGFy Z2V0IDIgbHVuIDAKZGEyOTogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVj dCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEyOTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMjk6 IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTI5OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEy IGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTMwIGF0IG1wdDQgYnVzIDAgc2Ni dXM0IHRhcmdldCAzIGx1biAwCmRhMzA6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhl ZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMzA6IDMwMC4wMDBNQi9zIHRyYW5zZmVy cwpkYTMwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEzMDogMTkwNzcyOU1CICgzOTA3MDI5 MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKZGEzMSBhdCBtcHQ0IGJ1 cyAwIHNjYnVzNCB0YXJnZXQgNCBsdW4gMApkYTMxOiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4 MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTMxOiAzMDAuMDAwTUIvcyB0 cmFuc2ZlcnMKZGEzMTogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMzE6IDE5MDc3MjlNQiAo MzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMzIgYXQg bXB0NCBidXMgMCBzY2J1czQgdGFyZ2V0IDUgbHVuIDAKZGEzMjogPEFUQSBIaXRhY2hpIEhEUzcy MzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEzMjogMzAwLjAw ME1CL3MgdHJhbnNmZXJzCmRhMzI6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTMyOiAxOTA3 NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpk YTMzIGF0IG1wdDQgYnVzIDAgc2NidXM0IHRhcmdldCA2IGx1biAwCmRhMzM6IDxBVEEgSGl0YWNo aSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMzM6 IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTMzOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEz MzogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQz MjAxQykKZGEzNCBhdCBtcHQ0IGJ1cyAwIHNjYnVzNCB0YXJnZXQgNyBsdW4gMApkYTM0OiA8QVRB IEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTUgZGV2aWNl IApkYTM0OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEzNDogQ29tbWFuZCBRdWV1ZWluZyBlbmFi bGVkCmRhMzQ6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYz Uy9UIDI0MzIwMUMpCmRhMzUgYXQgbXB0NSBidXMgMCBzY2J1czUgdGFyZ2V0IDAgbHVuIDAKZGEz NTogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01 IGRldmljZSAKZGEzNTogMzAwLjAwME1CL3MgdHJhbnNmZXJzCmRhMzU6IENvbW1hbmQgUXVldWVp bmcgZW5hYmxlZApkYTM1OiAxOTA3NzI5TUIgKDM5MDcwMjkxNjggNTEyIGJ5dGUgc2VjdG9yczog MjU1SCA2M1MvVCAyNDMyMDFDKQpkYTM2IGF0IG1wdDUgYnVzIDAgc2NidXM1IHRhcmdldCAxIGx1 biAwCmRhMzY6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgwPiBGaXhlZCBEaXJlY3QgQWNjZXNz IFNDU0ktNSBkZXZpY2UgCmRhMzY6IDMwMC4wMDBNQi9zIHRyYW5zZmVycwpkYTM2OiBDb21tYW5k IFF1ZXVlaW5nIGVuYWJsZWQKZGEzNjogMTkwNzcyOU1CICgzOTA3MDI5MTY4IDUxMiBieXRlIHNl Y3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKZGEzNyBhdCBtcHQ1IGJ1cyAwIHNjYnVzNSB0YXJn ZXQgMiBsdW4gMApkYTM3OiA8QVRBIEhpdGFjaGkgSERTNzIzMDIgQTE4MD4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTUgZGV2aWNlIApkYTM3OiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEzNzog Q29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmRhMzc6IDE5MDc3MjlNQiAoMzkwNzAyOTE2OCA1MTIg Ynl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDI0MzIwMUMpCmRhMzggYXQgbXB0NSBidXMgMCBzY2J1 czUgdGFyZ2V0IDQgbHVuIDAKZGEzODogPEFUQSBIaXRhY2hpIEhEUzcyMzAyIEExODA+IEZpeGVk IERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmljZSAKZGEzODogMzAwLjAwME1CL3MgdHJhbnNmZXJz CmRhMzg6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZApkYTM4OiAxOTA3NzI5TUIgKDM5MDcwMjkx NjggNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyNDMyMDFDKQpkYTM5IGF0IG1wdDUgYnVz IDAgc2NidXM1IHRhcmdldCA2IGx1biAwCmRhMzk6IDxBVEEgSGl0YWNoaSBIRFM3MjMwMiBBMTgw PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktNSBkZXZpY2UgCmRhMzk6IDMwMC4wMDBNQi9zIHRy YW5zZmVycwpkYTM5OiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEzOTogMTkwNzcyOU1CICgz OTA3MDI5MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMjQzMjAxQykKU01QOiBBUCBD UFUgIzQgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMiBM YXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM2IExhdW5jaGVk IQpTTVA6IEFQIENQVSAjNyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhCnVodWIx OiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW4wLjI6IDxEZWxs PiBhdCB1c2J1czAKdWh1YjI6IDxEZWxsIFVTQiBLZXlib2FyZCBIdWI+IG9uIHVzYnVzMAp1Z2Vu MS4yOiA8dmVuZG9yIDB4MDRiND4gYXQgdXNidXMxCnVodWIzOiA8dmVuZG9yIDB4MDRiNCBwcm9k dWN0IDB4NjU2MCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjBiLCBhZGRyIDI+IG9uIHVzYnVzMQp1 aHViMjogMyBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBidXMgcG93ZXJlZAp1Z2VuMC4zOiA8RGVs bD4gYXQgdXNidXMwCnVrYmQwOiA8RGVsbCBVU0IgS2V5Ym9hcmQ+IG9uIHVzYnVzMAprYmQyIGF0 IHVrYmQwCnVodWIzOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGlk MDogPERlbGwgVVNCIEtleWJvYXJkPiBvbiB1c2J1czAKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJv bSB1ZnM6L2Rldi9kYTBzMWEKdWdlbjAuNDogPExvZ2l0ZWNoPiBhdCB1c2J1czAKdW1zMDogPExv Z2l0ZWNoIE9wdGljYWwgVVNCIE1vdXNlLCBjbGFzcyAwLzAsIHJldiAyLjAwLzMuNDAsIGFkZHIg ND4gb24gdXNidXMwCnVtczA6IDMgYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9MApX QVJOSU5HOiByZWR1Y2luZyBzaXplIHRvIG1heGltdW0gb2YgNjcxMDg4NjQgYmxvY2tzIHBlciBz d2FwIHVuaXQKdWdlbjAuNTogPEFtZXJpY2FuIE1lZ2F0cmVuZHMgSW5jLj4gYXQgdXNidXMwCnVr YmQxOiA8S2V5Ym9hcmQgSW50ZXJmYWNlPiBvbiB1c2J1czAKa2JkMyBhdCB1a2JkMQp1bXMxOiA8 TW91c2UgSW50ZXJmYWNlPiBvbiB1c2J1czAKSVAgRmlsdGVyOiB2NC4xLjI4IGluaXRpYWxpemVk LiAgRGVmYXVsdCA9IHBhc3MgYWxsLCBMb2dnaW5nID0gZW5hYmxlZApuZmUwOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gVVAKbXB0NTogbXB0X2NhbV9ldmVudDogMHgxNgptcHQ1OiBtcHRfY2FtX2V2 ZW50OiAweDEyCm1wdDU6IG1wdF9jYW1fZXZlbnQ6IDB4MTYK --001517494564c24ab004a31947d7-- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 20:57:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172C2106564A for ; Thu, 12 May 2011 20:57:35 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id D56D18FC13 for ; Thu, 12 May 2011 20:57:34 +0000 (UTC) Received: from [192.168.0.5] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id 372CC5722D; Thu, 12 May 2011 21:25:02 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Blackman In-Reply-To: Date: Thu, 12 May 2011 21:25:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6FDABC4F-6F50-4AC7-8469-A96D2F8ED301@exonetric.com> References: To: Dillin Smith X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 20:57:35 -0000 On 12 May 2011, at 20:34, Dillin Smith wrote: > Hi all, > > I'm having an issue getting my installation of FreeBSD to detect all > the drives in the system. It has 48 total, 46 2TB, and 2 250GB. The > system consists of six controllers, with eight drives on each. The two > 250GB hard drives are the first drives on controllers 0 and 1. > > There are two of these machines with the exact same configurations, > having the same problem. A very odd thing is that every time the > systems are rebooted, the drives that go undetected vary. Also, when > the systems were full of 250GB drives, all were detected. All drives > are detected in the BIOS of the controllers, just not by FreeBSD. > Any and all help is greatly appreciated. > (output of dmesg attached) Power problems (i.e. under-rated PSU)? Staggered spin-up means they're not all coming up quickly enough? With a rig as complex as that, I'd boot up another OS, like Linux or Windows and see if they can see all the drives. - Mark From owner-freebsd-stable@FreeBSD.ORG Thu May 12 21:03:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63C4E106564A for ; Thu, 12 May 2011 21:03:50 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4118FC0C for ; Thu, 12 May 2011 21:03:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp018.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL300L1OP5Z0780@asmtp018.mac.com> for freebsd-stable@freebsd.org; Thu, 12 May 2011 14:03:36 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-12_08:2011-05-12, 2011-05-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105120159 From: Chuck Swiger In-reply-to: <6FDABC4F-6F50-4AC7-8469-A96D2F8ED301@exonetric.com> Date: Thu, 12 May 2011 14:03:35 -0700 Message-id: <29A273F6-04AA-43CA-AC20-5D9B97B4B05F@mac.com> References: <6FDABC4F-6F50-4AC7-8469-A96D2F8ED301@exonetric.com> To: Mark Blackman X-Mailer: Apple Mail (2.1084) Cc: Dillin Smith , freebsd-stable@freebsd.org Subject: Re: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 21:03:50 -0000 On May 12, 2011, at 1:25 PM, Mark Blackman wrote: > Power problems (i.e. under-rated PSU)? Staggered spin-up means they're not all coming up quickly enough? While your suggestion would generally be a decent guess, the dmesg implies the box is a Sun X4540; it probably has two or three 1500W PSUs: http://www.sun.com/servers/x64/x4540/specs.xml > With a rig as complex as that, I'd boot up another OS, like Linux or Windows and see if they can see all the drives. How about Solaris? :-) Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu May 12 21:23:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC7341065677 for ; Thu, 12 May 2011 21:23:49 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay0.exonetric.net (relay0.exonetric.net [82.138.248.161]) by mx1.freebsd.org (Postfix) with ESMTP id 9FDB38FC0A for ; Thu, 12 May 2011 21:23:49 +0000 (UTC) Received: from [192.168.0.5] (unknown [78.86.207.85]) by relay0.exonetric.net (Postfix) with ESMTP id 92C205722D; Thu, 12 May 2011 22:23:48 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Blackman In-Reply-To: <29A273F6-04AA-43CA-AC20-5D9B97B4B05F@mac.com> Date: Thu, 12 May 2011 22:23:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1843A680-E34B-4C07-A0D4-B4C3D00E9245@exonetric.com> References: <6FDABC4F-6F50-4AC7-8469-A96D2F8ED301@exonetric.com> <29A273F6-04AA-43CA-AC20-5D9B97B4B05F@mac.com> To: Chuck Swiger X-Mailer: Apple Mail (2.1084) Cc: Dillin Smith , freebsd-stable@freebsd.org Subject: Re: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 21:23:49 -0000 On 12 May 2011, at 22:03, Chuck Swiger wrote: > On May 12, 2011, at 1:25 PM, Mark Blackman wrote: >> Power problems (i.e. under-rated PSU)? Staggered spin-up means = they're not all coming up quickly enough? >=20 > While your suggestion would generally be a decent guess, the dmesg = implies the box is a Sun X4540; it probably has two or three 1500W PSUs: >=20 > http://www.sun.com/servers/x64/x4540/specs.xml Ok, good point, missed that. acpi0: on motherboard >=20 >> With a rig as complex as that, I'd boot up another OS, like Linux or = Windows and see if they can see all the drives.=20 >=20 > How about Solaris? :-) Good idea, I've sort of given up on Solaris thanks to Oracle, but that's = a better bet for a test if it's a Sun box. - Mark From owner-freebsd-stable@FreeBSD.ORG Thu May 12 21:56:37 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3E4106564A for ; Thu, 12 May 2011 21:56:37 +0000 (UTC) (envelope-from freebsd-stable@chef-ingenieur.de) Received: from mail.webmatic.de (mail.webmatic.de [212.78.101.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3598FC19 for ; Thu, 12 May 2011 21:56:36 +0000 (UTC) Received: from [127.0.0.1] (p54B7F369.dip.t-dialin.net [84.183.243.105]) by mail.webmatic.de (Postfix) with ESMTPSA id 146366D840 for ; Thu, 12 May 2011 23:38:31 +0200 (CEST) Message-ID: <4DCC5358.4050705@chef-ingenieur.de> Date: Thu, 12 May 2011 23:38:32 +0200 From: Thomas Krause User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: setting usb disc to da1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 21:56:37 -0000 Hello, I've plugged a USB disc to a FreeBSD System and it's dedected as da1: da1: Fixed Direct Access SCSI-2 device But when rebooting the machine, it becomes da0 and I cannot boot the system. What's the trick to set the USB disc to da1 permanent? Thanks, Tom. From owner-freebsd-stable@FreeBSD.ORG Thu May 12 23:14:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 749D4106566C for ; Thu, 12 May 2011 23:14:15 +0000 (UTC) (envelope-from eivinde@terraplane.org) Received: from mail48.e.nsc.no (mail48.e.nsc.no [193.213.115.48]) by mx1.freebsd.org (Postfix) with ESMTP id B33918FC0C for ; Thu, 12 May 2011 23:14:14 +0000 (UTC) Received: from rumrunner.mine.nu (ti0027a380-0970.bb.online.no [80.212.66.204]) by mail48.nsc.no (8.14.4/8.14.4) with ESMTP id p4CMwLds008225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2011 00:58:22 +0200 (MEST) Received: from rumrunner.mine.nu (localhost [127.0.0.1]) by rumrunner.mine.nu (8.14.4/8.14.2) with ESMTP id p4CMwLbD079626; Fri, 13 May 2011 00:58:21 +0200 (CEST) (envelope-from eivinde@terraplane.org) Received: from localhost (rumrunner@localhost) by rumrunner.mine.nu (8.14.4/8.13.8/Submit) with ESMTP id p4CMwLRF079623; Fri, 13 May 2011 00:58:21 +0200 (CEST) (envelope-from eivinde@terraplane.org) X-Authentication-Warning: rumrunner.mine.nu: rumrunner owned process doing -bs Date: Fri, 13 May 2011 00:58:21 +0200 (CEST) From: Eivind E X-X-Sender: rumrunner@rumrunner.mine.nu To: Dillin Smith In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="248852462-514613219-1305241101=:79571" Cc: freebsd-stable@freebsd.org Subject: Re: Fwd: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: eivinde@terraplane.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 23:14:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --248852462-514613219-1305241101=:79571 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 12 May 2011, Dillin Smith wrote: > Hi all, > >   I'm having an issue getting my installation of FreeBSD to detect all > the drives in the system. It has 48 total, 46 2TB, and 2 250GB. The > system consists of six controllers, with eight drives on each. The two > 250GB hard drives are the first drives on controllers 0 and 1. > >   There are two of these machines with the exact same configurations, > having the same problem. A very odd thing is that every time the > systems are rebooted, the drives that go undetected vary. Also, when > the systems were full of 250GB drives, all were detected. All drives > are detected in the BIOS of the controllers, just not by FreeBSD. > Any and all help is greatly appreciated. > (output of dmesg attached) When I had that problem (although on a much simpler machine), the problem turned out to be the piece of junk graphics card I had put in it just for the os install. It had stretched downwards with time until it shorted some pins on the disk controller on side where they were soldered. -- _ _ // \\// Eivind Evensen \/ --248852462-514613219-1305241101=:79571-- From owner-freebsd-stable@FreeBSD.ORG Thu May 12 23:37:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3260F106566B for ; Thu, 12 May 2011 23:37:56 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:266:e1ff:fe0c:8f16]) by mx1.freebsd.org (Postfix) with ESMTP id EA9178FC0A for ; Thu, 12 May 2011 23:37:53 +0000 (UTC) Received: from ur.dons.net.au (ppp203-122-208-198.lns5.adl6.internode.on.net [203.122.208.198]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p4CNbbEl071154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 09:07:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4DCC5358.4050705@chef-ingenieur.de> Date: Fri, 13 May 2011 09:07:37 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <34458417-0D7A-493E-8C52-F3095000D764@gsoft.com.au> References: <4DCC5358.4050705@chef-ingenieur.de> To: Thomas Krause X-Mailer: Apple Mail (2.1084) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: setting usb disc to da1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 May 2011 23:37:56 -0000 On 13/05/2011, at 7:08, Thomas Krause wrote: > I've plugged a USB disc to a FreeBSD System and it's dedected as da1: >=20 > da1: Fixed Direct Access SCSI-2 device >=20 > But when rebooting the machine, it becomes da0 and I cannot boot the > system. What's the trick to set the USB disc to da1 permanent? You can, to some degree, wire the device with.. hint.scbus.0.at=3D"umass-sim0" hint.da0.at=3D"scbus0" However I would recommend using GPT IDs, UFS IDs or GEOM labels in fstab = so the underlying device name is irrelevant. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri May 13 05:04:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 895C41065673 for ; Fri, 13 May 2011 05:04:41 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 106E38FC1B for ; Fri, 13 May 2011 05:04:40 +0000 (UTC) Received: by wyf23 with SMTP id 23so2239167wyf.13 for ; Thu, 12 May 2011 22:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=Fs8vRzv9SrMjp2i+0Su6irKMyJ4zD3XQ1b8xWNLiuq4=; b=fm7Z18wFmeQwdT5n7uM+Ri8x0uKUPXgz17KA+B49wt1CCZohW0d+zRteOveYEouYF8 XZMzQN0tZpKkWLkznXLGZzyupKNnwG4jJ4wrtip+TIrvQb+fnwB43Bp9E9uXVej1s83i nCcwUdbuXIkhJYX5MSwtuWfo4hkwYt5z0hZ1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=Vkyc04q3BNn68k9NNXtKGcFfn4VFC2/CkIDWg4ILZiFI7i7NTagOMgwmVgY8gVuC4b KuxZdqnSu4T6aCpStQqGITjvJiyOSlrC/SQzOHrTPLiOkTMg49kTiybB1Er0FcW/9bPn MrdUmxaUOstyG53PORazcncrKXLTpV+5dFdyQ= Received: by 10.216.50.142 with SMTP id z14mr21791web.37.1305261209975; Thu, 12 May 2011 21:33:29 -0700 (PDT) Received: from [10.0.0.3] (ti0128a380-dhcp0306.bb.online.no [88.88.53.53]) by mx.google.com with ESMTPS id s20sm1124095wbh.57.2011.05.12.21.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 21:33:28 -0700 (PDT) References: <6FDABC4F-6F50-4AC7-8469-A96D2F8ED301@exonetric.com> <29A273F6-04AA-43CA-AC20-5D9B97B4B05F@mac.com> <1843A680-E34B-4C07-A0D4-B4C3D00E9245@exonetric.com> In-Reply-To: <1843A680-E34B-4C07-A0D4-B4C3D00E9245@exonetric.com> Mime-Version: 1.0 (iPhone Mail 8J2) Message-Id: <3A510AD9-EBD4-40BE-9DB0-7805C8808555@gmail.com> X-Mailer: iPhone Mail (8J2) From: Claus Guttesen Date: Fri, 13 May 2011 06:33:21 +0200 To: Mark Blackman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" , Dillin Smith Subject: Re: Hard drive detection X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 05:04:41 -0000 >>=20 >> How about Solaris? :-) >=20 > Good idea, I've sort of given up on Solaris thanks to Oracle, but that's a= better > bet for a test if it's a Sun box. You can try openindiana. Regards Claus >=20 From owner-freebsd-stable@FreeBSD.ORG Fri May 13 10:34:22 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880CC106566B; Fri, 13 May 2011 10:34:22 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03A5B8FC19; Fri, 13 May 2011 10:34:21 +0000 (UTC) Received: by qwc9 with SMTP id 9so1618034qwc.13 for ; Fri, 13 May 2011 03:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4RrG6JR8DyOl1hB5I1Tk17zLteYgUvUDLkmCk1xRRyc=; b=hAEUZcRBicWDn5S+v+RSZQTgkXI4z3i5NCrIyVrqVGuu0PrF5GTDPZ8vohn9BxBRWN qdrBT9eeWZASBnSzq9cg3fIU1VUx2S0rdWzAGY60HxzyUynr/P5sJclvA3mcYkGSFnlX OKk1YdrPE/IJPUKQYkFy2fIXab/ThRqD3dhTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IhE/A+bzy0kCid8+JOmh5i6rXmitNwOZTCBjQrFFYcDAqXDe3GPJ6ICdWrPvpsvEst 0+P1zIoueGFIGH4mrL8/ek2oSigih4xTg1I2eNwfR9Ngfnq92PM6LO4B5e39T2FhqeBD 3DakFBV6wIuXq+OGt6YIp1WKdOLH6ZmtvyPhU= MIME-Version: 1.0 Received: by 10.229.127.81 with SMTP id f17mr1009062qcs.138.1305281525100; Fri, 13 May 2011 03:12:05 -0700 (PDT) Received: by 10.229.217.69 with HTTP; Fri, 13 May 2011 03:12:05 -0700 (PDT) In-Reply-To: <20110508191336.GC3527@DataIX.net> References: <20110508191336.GC3527@DataIX.net> Date: Fri, 13 May 2011 12:12:05 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 10:34:22 -0000 Hi, 2011/5/8 Jason Hellenthal > > List, - Please reply-to freebsd-rc@freebsd.org > > What does it do ?: As stated above, current functionality is undisturbed > while allowing the user to create config's by any name they so desire as > long as it has an extension of ".conf", also introducing the ability to > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > seams not to be included in your patch, unless you change the line (or i'm wrong): if [ -f "$_modular_conf" ]; then by if [ -x "$_modular_conf" ]; then > > > Why ? Simple. How many times have you been bitten by disabling something > in the rc.conf file and left to discover what you just disabled was also > used by another daemon but that daemon is now not starting ? This is a way > to virtualize your configuration allowing you to add multiple _enable= > lines to different configurations for different roles. For instance > rpcbind is used by both samba and nfs*. With this you can add > rpcbind_enable to both a configuration for samba and nfs and when you > disable one service you know that you have not disabled a dependent for > another. > i resolved that by making multiple files source the same conf file. today my biggest problem is bad rc.d script like apache22, postfix, clamd or haproxy who load_rc_config and after overwrite extra_commands variable. this prevent me to add extra commands from a /etc/rc.conf.d/$name file. From owner-freebsd-stable@FreeBSD.ORG Fri May 13 11:27:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E70106566B; Fri, 13 May 2011 11:27:44 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC528FC14; Fri, 13 May 2011 11:27:44 +0000 (UTC) Received: by iyj12 with SMTP id 12so2808957iyj.13 for ; Fri, 13 May 2011 04:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=7/LGFur01hlcyl97RqTGdE4WDo0qRTosBXigD5mkL1w=; b=T+xFJUKvCQxQSdxkmjO/YGgGR+yWgwFI684w2IUj9en3smhSFopHLg+kiOdyxoRYcj PF5V9BlnMp8Dsf4deSrajaGKLtXqqhmV0yco1VA7tP6iNBt3M2KQ97k0lkkG+yawnRRu QT249b/GZ6opZ+kj1WwHjMZf/JIaX2rL4QyJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=R7wlpZByJehQ/de+eZ2PbmUEhslBSldC7keU1QESksIW8leo0zQaoANLGUDoo9OdhJ Yk+nS1OBkYu3pl/IXXiGgmNvlfYz76q6ARpGREU/UIsIwWAi3JGCTef9Z40bGzggedXw EMUxUoYtOhCZdL7QeqT0yNblLwzWl0W+A/NP8= Received: by 10.42.157.67 with SMTP id c3mr1528648icx.95.1305286063703; Fri, 13 May 2011 04:27:43 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-196.dsl.klmzmi.sbcglobal.net [99.190.81.196]) by mx.google.com with ESMTPS id t1sm931523ibm.38.2011.05.13.04.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 04:27:42 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p4DBRd9i004608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 07:27:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p4DBRcPA004607; Fri, 13 May 2011 07:27:38 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 13 May 2011 07:27:38 -0400 From: Jason Hellenthal To: =?iso-8859-1?Q?Micka=EBl?= Maillot Message-ID: <20110513112738.GA2720@DataIX.net> References: <20110508191336.GC3527@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-rc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 11:27:45 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Micka=EBl, On Fri, May 13, 2011 at 12:12:05PM +0200, Micka=EBl Maillot wrote: > Hi, >=20 > 2011/5/8 Jason Hellenthal >=20 > > > > List, - Please reply-to freebsd-rc@freebsd.org > > > > What does it do ?: As stated above, current functionality is undisturbed > > while allowing the user to create config's by any name they so desire as > > long as it has an extension of ".conf", also introducing the ability to > > turn a configuration file off by using chmod(1). You can turn nfsc1.conf > > off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > > >=20 > seams not to be included in your patch, unless you change the line (or i'm > wrong): > if [ -f "$_modular_conf" ]; then > by > if [ -x "$_modular_conf" ]; then >=20 The one you downloaded here used to be this one: http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch?r=3Dbf83c= 231337642f925d6c732ba8c8b070480631e But since alot of slack was coming back on the use of the -x bit it was removed. >=20 > > > > > > Why ? Simple. How many times have you been bitten by disabling something > > in the rc.conf file and left to discover what you just disabled was also > > used by another daemon but that daemon is now not starting ? This is a = way > > to virtualize your configuration allowing you to add multiple _enable=3D > > lines to different configurations for different roles. For instance > > rpcbind is used by both samba and nfs*. With this you can add > > rpcbind_enable to both a configuration for samba and nfs and when you > > disable one service you know that you have not disabled a dependent for > > another. > > >=20 > i resolved that by making multiple files source the same conf file. >=20 > today my biggest problem is bad rc.d script > like apache22, postfix, clamd or haproxy who load_rc_config and after > overwrite extra_commands variable. > this prevent me to add extra commands from a /etc/rc.conf.d/$name file. --=20 Regards, (jhell) Jason Hellenthal --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNzRWpAAoJEJBXh4mJ2FR+dbEH/jCyY0qY5Mh2lke9bxeGrRPy qul0Bjy3RhSuREYNZnW3VgOxpzEatV6S1sz3USYutHIN0V6mOxRHxnBRe9D1Ri2k FCRXh9ZcIlRuAKgQeDit+RscwV9PIH8MFNuox4T1eRunNa/lOKb7jZqJkbe7mK+v J6egWqZL/QwEHt2mC1MrhnGpfWpGZYgRA+xTka5StRVgi16doAg7Bu15ncrBvUI0 UXc4VIuVO3Gl/cO59FRU4DxSp7MQ2wnIA96cRsJmnJC46k4EhyfKQWwBoPqUwUsi 3VKRtobNnrDMPHB1f8Oq/KNKPFokQhkD4qQKbJz56S3X3x9o+mlelOMQQtUQwWA= =Ztl4 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-stable@FreeBSD.ORG Fri May 13 11:31:15 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47DDE106566C for ; Fri, 13 May 2011 11:31:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 78D208FC12 for ; Fri, 13 May 2011 11:31:13 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15957; Fri, 13 May 2011 14:30:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DCD1672.4020405@FreeBSD.org> Date: Fri, 13 May 2011 14:30:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bartosz Stec References: <4DC6A277.4030801@it4pro.pl> <4DC6E23B.2040207@it4pro.pl> <4DC81E22.5030806@it4pro.pl> <4DCC3844.6070008@it4pro.pl> In-Reply-To: <4DCC3844.6070008@it4pro.pl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: Panic during kernel booting on HP Proliant DL180G6 and latest STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 11:31:15 -0000 on 12/05/2011 22:43 Bartosz Stec said the following: > Allright, if anyone want to follow: http://www.freebsd.org/cgi/query-pr.cgi?pr=156974 > I suspect that your best course here is to add some diagnostic printfs in igb_refresh_mbufs and in m_getzone to see what value is actually passed to m_getjcl and why. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri May 13 12:48:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F5A01065675 for ; Fri, 13 May 2011 12:48:03 +0000 (UTC) (envelope-from bartosz.woronicz@korbank.pl) Received: from LISTonosz.Korbank.PL (a.smtp.korbank.com [79.110.199.33]) by mx1.freebsd.org (Postfix) with ESMTP id 39C6B8FC14 for ; Fri, 13 May 2011 12:48:03 +0000 (UTC) Received: from [79.110.194.135] (mech.k.pl [79.110.194.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by LISTonosz.Korbank.PL (Postfix) with ESMTP id A03D91670EB8 for ; Fri, 13 May 2011 14:47:46 +0200 (CEST) Message-ID: <4DCD2881.4020402@korbank.pl> Date: Fri, 13 May 2011 14:48:01 +0200 From: Bartosz Woronicz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Unstable ARP responses times X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 12:48:03 -0000 Since I moved from 7.3-stable to 8.2-stable I go strange long responses of arp, with arping. I.e. root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 79.110.194.140 ARPING 79.110.194.140 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=3 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=4 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=5 time=5.960 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=6 time=7.153 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=7 time=5.960 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=8 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=9 time=280.132 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=10 time=120.429 msec ^C --- 79.110.194.140 statistics --- 18 packets transmitted, 11 packets received, 39% unanswered (0 extra) root@Korbotron82|pts/3|13:36:06|/home/mastier # ping 79.110.194.140 PING 79.110.194.140 (79.110.194.140): 56 data bytes 64 bytes from 79.110.194.140: icmp_seq=0 ttl=64 time=0.348 ms 64 bytes from 79.110.194.140: icmp_seq=1 ttl=64 time=0.204 ms 64 bytes from 79.110.194.140: icmp_seq=2 ttl=64 time=0.171 ms 64 bytes from 79.110.194.140: icmp_seq=3 ttl=64 time=0.223 ms 64 bytes from 79.110.194.140: icmp_seq=4 ttl=64 time=0.283 ms 64 bytes from 79.110.194.140: icmp_seq=5 ttl=64 time=0.322 ms 64 bytes from 79.110.194.140: icmp_seq=6 ttl=64 time=0.250 ms ^C --- 79.110.194.140 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.171/0.257/0.348/0.059 ms Any Idea what does mean ? -- Pozdrawiam, Bartosz Woronicz, System Adminstrator, Korbank S.A. ul. NabyciÅ„ska 19 53-677 WrocÅ‚aw NIP: 894-26-41-602 tel. 071-723-43-23 fax. 071-723-43-29 From owner-freebsd-stable@FreeBSD.ORG Fri May 13 12:53:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B8431065672 for ; Fri, 13 May 2011 12:53:20 +0000 (UTC) (envelope-from bartosz.woronicz@korbank.pl) Received: from LISTonosz.Korbank.PL (a.smtp.korbank.com [79.110.199.33]) by mx1.freebsd.org (Postfix) with ESMTP id CC1778FC08 for ; Fri, 13 May 2011 12:53:19 +0000 (UTC) Received: from [79.110.194.135] (mech.k.pl [79.110.194.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by LISTonosz.Korbank.PL (Postfix) with ESMTP id 549661670573 for ; Fri, 13 May 2011 14:35:28 +0200 (CEST) Message-ID: <4DCD259F.2050708@korbank.pl> Date: Fri, 13 May 2011 14:35:43 +0200 From: Bartosz Woronicz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Unstable ARP responses times X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 12:53:20 -0000 Since I moved from 7.3-stable to 8.2-stable I go strange long responses of arp, with arping. I.e. root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 79.110.194.140 ARPING 79.110.194.140 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=3 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=4 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=5 time=5.960 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=6 time=7.153 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=7 time=5.960 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=8 time=6.199 usec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=9 time=280.132 msec 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=10 time=120.429 msec ^C --- 79.110.194.140 statistics --- 18 packets transmitted, 11 packets received, 39% unanswered (0 extra) root@Korbotron82|pts/3|13:36:06|/home/mastier # ping 79.110.194.140 PING 79.110.194.140 (79.110.194.140): 56 data bytes 64 bytes from 79.110.194.140: icmp_seq=0 ttl=64 time=0.348 ms 64 bytes from 79.110.194.140: icmp_seq=1 ttl=64 time=0.204 ms 64 bytes from 79.110.194.140: icmp_seq=2 ttl=64 time=0.171 ms 64 bytes from 79.110.194.140: icmp_seq=3 ttl=64 time=0.223 ms 64 bytes from 79.110.194.140: icmp_seq=4 ttl=64 time=0.283 ms 64 bytes from 79.110.194.140: icmp_seq=5 ttl=64 time=0.322 ms 64 bytes from 79.110.194.140: icmp_seq=6 ttl=64 time=0.250 ms ^C --- 79.110.194.140 ping statistics --- 7 packets transmitted, 7 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.171/0.257/0.348/0.059 ms Any Idea what does mean ? -- Pozdrawiam, Bartosz Woronicz, System Adminstrator, Korbank S.A. ul. NabyciÅ„ska 19 53-677 WrocÅ‚aw NIP: 894-26-41-602 tel. 071-723-43-23 fax. 071-723-43-29 From owner-freebsd-stable@FreeBSD.ORG Fri May 13 18:10:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C1C106566B for ; Fri, 13 May 2011 18:10:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD008FC0A for ; Fri, 13 May 2011 18:10:11 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta13.emeryville.ca.mail.comcast.net with comcast id j5qn1g0011zF43QAD6ABpi; Fri, 13 May 2011 18:10:11 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id j6A61g00J1t3BNj8k6A7FL; Fri, 13 May 2011 18:10:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D8746102C36; Fri, 13 May 2011 11:10:05 -0700 (PDT) Date: Fri, 13 May 2011 11:10:05 -0700 From: Jeremy Chadwick To: Bartosz Woronicz Message-ID: <20110513181005.GA36587@icarus.home.lan> References: <4DCD2881.4020402@korbank.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCD2881.4020402@korbank.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Unstable ARP responses times X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 18:10:12 -0000 On Fri, May 13, 2011 at 02:48:01PM +0200, Bartosz Woronicz wrote: > Since I moved from 7.3-stable to 8.2-stable I go strange long > responses of arp, with arping. > I.e. > root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 > 79.110.194.140 > ARPING 79.110.194.140 > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=3 time=6.199 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=4 time=6.199 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=5 time=5.960 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=6 time=7.153 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=7 time=5.960 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=8 time=6.199 usec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=9 time=280.132 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=10 > time=120.429 msec > ^C > --- 79.110.194.140 statistics --- > 18 packets transmitted, 11 packets received, 39% unanswered (0 extra) > root@Korbotron82|pts/3|13:36:06|/home/mastier # ping 79.110.194.140 > PING 79.110.194.140 (79.110.194.140): 56 data bytes > 64 bytes from 79.110.194.140: icmp_seq=0 ttl=64 time=0.348 ms > 64 bytes from 79.110.194.140: icmp_seq=1 ttl=64 time=0.204 ms > 64 bytes from 79.110.194.140: icmp_seq=2 ttl=64 time=0.171 ms > 64 bytes from 79.110.194.140: icmp_seq=3 ttl=64 time=0.223 ms > 64 bytes from 79.110.194.140: icmp_seq=4 ttl=64 time=0.283 ms > 64 bytes from 79.110.194.140: icmp_seq=5 ttl=64 time=0.322 ms > 64 bytes from 79.110.194.140: icmp_seq=6 ttl=64 time=0.250 ms > ^C > --- 79.110.194.140 ping statistics --- > 7 packets transmitted, 7 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.171/0.257/0.348/0.059 ms > > Any Idea what does mean ? Can you try turning off flowtable to see if that makes any difference? This is a sysctl and can be adjusted in real-time. net.inet.flowtable.enable=0 Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri May 13 19:55:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F4A7106566B for ; Fri, 13 May 2011 19:55:30 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 484C18FC0C for ; Fri, 13 May 2011 19:55:30 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p4DJtQ79094002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 14:55:26 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id p4DJtQE3048503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 14:55:26 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.4/Submit) id p4DJtPjv048502; Fri, 13 May 2011 14:55:25 -0500 (CDT) (envelope-from dan) Date: Fri, 13 May 2011 14:55:25 -0500 From: Dan Nelson To: Bartosz Woronicz Message-ID: <20110513195524.GC7043@dan.emsphone.com> References: <4DCD2881.4020402@korbank.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCD2881.4020402@korbank.pl> X-OS: FreeBSD 8.2-PRERELEASE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Fri, 13 May 2011 14:55:27 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-stable@freebsd.org Subject: Re: Unstable ARP responses times X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 19:55:30 -0000 In the last episode (May 13), Bartosz Woronicz said: > Since I moved from 7.3-stable to 8.2-stable I go strange long responses > of arp, with arping. > I.e. > root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 > 79.110.194.140 > ARPING 79.110.194.140 > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec arping has a usleep(1) call in its read loop, which can cause delays like this if there are other processes running and the scheduler decides to run another process. Try removing the usleep(1) on line 916 of arping.c and see if that helps. The best solution would be to use the kernel-provided timestamps from the pcap header, rather than calling gettimeofday() in userland. If you run "tcpdump arp", you should be able to see the packet timestamps as the kernel sees them. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Fri May 13 22:32:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14C71065673 for ; Fri, 13 May 2011 22:32:03 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 5DCDA8FC14 for ; Fri, 13 May 2011 22:32:02 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-109-192-071-045.hsi6.kabel-badenwuerttemberg.de [109.192.71.45]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 53C217E882 for ; Sat, 14 May 2011 00:14:14 +0200 (CEST) Message-ID: <4DCDAD36.5080007@bsdforen.de> Date: Sat, 14 May 2011 00:14:14 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.16) Gecko/20101212 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Subject: RELENG_8 does not build with CPUTYPE=core2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 22:32:03 -0000 env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch make-roken.c:1: error: bad value (core2) for -march= switch make-roken.c:1: error: bad value (core2) for -mtune= switch distcc[44991] ERROR: compile make-roken.c on localhost failed *** Error code 1 1 error *** Error code 2 distcc[44988] ERROR: compile /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c on localhost failed *** Error code 1 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 # make -VCPUTYPE nocona # make -VCFLAGS -O2 -pipe -march=nocona CPUTYPE is set with CPUTYPE?=core2. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri May 13 22:35:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E8ED1065680 for ; Fri, 13 May 2011 22:35:06 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E5E718FC18 for ; Fri, 13 May 2011 22:35:05 +0000 (UTC) Received: by vxc34 with SMTP id 34so2965469vxc.13 for ; Fri, 13 May 2011 15:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0YjvZxqcV92dcrJxTZdJnLNG7YI+0B5caKmyGjyGAjU=; b=UC7fNg8bpiT4F6iqt+f5VcYtwi5+9mAa3u2K9ukCcdun+XvJ5eQgtwFo8ceFZB8exO 2WPUi0IBYgkPC7z5O29cMaqSAlh/g1D8mQFsScobQDXAdPjWNuSWRtNilxR0Gdki2O+k eFydUW80Fqh1N8BFYNT16Gdg6imWnuTaXiINs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LjhagR3WfwgeNFnikbP8Z+vytK7KSwniLPVxQsTD1swLf7in+D3sXo8JQq8rBROK+v Yy9ZTYVo3+ft1NY5rnRNX416PYGNXcz85Q9X1mkqYXeeM/cQiessu/95g5IZ60l02dRr t66cie35+Q+OOwKVOCq0w/ukxJtvk5lBEsJ7k= MIME-Version: 1.0 Received: by 10.52.98.231 with SMTP id el7mr305240vdb.229.1305326105091; Fri, 13 May 2011 15:35:05 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.159.6 with HTTP; Fri, 13 May 2011 15:35:05 -0700 (PDT) In-Reply-To: <4DCDAD36.5080007@bsdforen.de> References: <4DCDAD36.5080007@bsdforen.de> Date: Sat, 14 May 2011 00:35:05 +0200 X-Google-Sender-Auth: GEdfAK8CSeX0EZJHoHzsmuLd5L4 Message-ID: From: "K. Macy" To: Dominic Fandrey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 does not build with CPUTYPE=core2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 22:35:06 -0000 The system compiler probably pre-dates cpu specific support. Try installing a newer one from ports. On Sat, May 14, 2011 at 12:14 AM, Dominic Fandrey wr= ote: > env CCACHE_PREFIX=3D/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -p= ipe -march=3Dcore2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/..= /../include -std=3Dgnu99 =A0 -c make-roken.c > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/v= ers/make-print-version.c:1: error: bad value (core2) for -march=3D switch > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/v= ers/make-print-version.c:1: error: bad value (core2) for -mtune=3D switch > make-roken.c:1: error: bad value (core2) for -march=3D switch > make-roken.c:1: error: bad value (core2) for -mtune=3D switch > distcc[44991] ERROR: compile make-roken.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > distcc[44988] ERROR: compile /usr/src/kerberos5/tools/make-print-version/= ../../../crypto/heimdal/lib/vers/make-print-version.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > # make -VCPUTYPE > nocona > # make -VCFLAGS > -O2 -pipe -march=3Dnocona > > CPUTYPE is set with CPUTYPE?=3Dcore2. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > 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 May 13 22:42:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BAB0106566B for ; Fri, 13 May 2011 22:42:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 84D608FC0C for ; Fri, 13 May 2011 22:42:48 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta06.emeryville.ca.mail.comcast.net with comcast id jATu1g0081wfjNsA6AinrS; Fri, 13 May 2011 22:42:47 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta23.emeryville.ca.mail.comcast.net with comcast id jAig1g00p1t3BNj8jAijws; Fri, 13 May 2011 22:42:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1AA1F102C36; Fri, 13 May 2011 15:42:40 -0700 (PDT) Date: Fri, 13 May 2011 15:42:40 -0700 From: Jeremy Chadwick To: Dominic Fandrey Message-ID: <20110513224240.GA40873@icarus.home.lan> References: <4DCDAD36.5080007@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCDAD36.5080007@bsdforen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 does not build with CPUTYPE=core2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 13 May 2011 22:42:48 -0000 On Sat, May 14, 2011 at 12:14:14AM +0200, Dominic Fandrey wrote: > env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch > make-roken.c:1: error: bad value (core2) for -march= switch > make-roken.c:1: error: bad value (core2) for -mtune= switch > distcc[44991] ERROR: compile make-roken.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > distcc[44988] ERROR: compile /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > # make -VCPUTYPE > nocona > # make -VCFLAGS > -O2 -pipe -march=nocona > > CPUTYPE is set with CPUTYPE?=core2. 1) You're using ccache; are you sure this isn't causing some sort of problem? 2) I can't reproduce this on any of our RELENG_8 amd64 systems using CPUTYPE?=core2 with base gcc (4.2.2 date 20070831). However, we use WITHOUT_KERBEROS=true in /etc/src.conf so there may be some "weirdness" with the kerberos stuff; unknown to me. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat May 14 00:09:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE7C71065670 for ; Sat, 14 May 2011 00:09:01 +0000 (UTC) (envelope-from bartosz.woronicz@korbank.pl) Received: from LISTonosz.Korbank.PL (a.smtp.korbank.com [79.110.199.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3154D8FC08 for ; Sat, 14 May 2011 00:09:00 +0000 (UTC) Received: from [192.168.33.244] (unknown [79.110.199.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by LISTonosz.Korbank.PL (Postfix) with ESMTP id 782721670AB7; Sat, 14 May 2011 02:08:43 +0200 (CEST) Message-ID: <4DCDC81A.3020603@korbank.pl> Date: Sat, 14 May 2011 02:08:58 +0200 From: Bartosz Woronicz User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DCD2881.4020402@korbank.pl> <20110513181005.GA36587@icarus.home.lan> In-Reply-To: <20110513181005.GA36587@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Unstable ARP responses times X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 May 2011 00:09:01 -0000 W dniu 13.05.2011 20:10, Jeremy Chadwick pisze: > On Fri, May 13, 2011 at 02:48:01PM +0200, Bartosz Woronicz wrote: >> Since I moved from 7.3-stable to 8.2-stable I go strange long >> responses of arp, with arping. >> I.e. >> root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 >> 79.110.194.140 >> ARPING 79.110.194.140 >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=3 time=6.199 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=4 time=6.199 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=5 time=5.960 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=6 time=7.153 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=7 time=5.960 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=8 time=6.199 usec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=9 time=280.132 msec >> 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=10 >> time=120.429 msec >> ^C >> --- 79.110.194.140 statistics --- >> 18 packets transmitted, 11 packets received, 39% unanswered (0 extra) >> root@Korbotron82|pts/3|13:36:06|/home/mastier # ping 79.110.194.140 >> PING 79.110.194.140 (79.110.194.140): 56 data bytes >> 64 bytes from 79.110.194.140: icmp_seq=0 ttl=64 time=0.348 ms >> 64 bytes from 79.110.194.140: icmp_seq=1 ttl=64 time=0.204 ms >> 64 bytes from 79.110.194.140: icmp_seq=2 ttl=64 time=0.171 ms >> 64 bytes from 79.110.194.140: icmp_seq=3 ttl=64 time=0.223 ms >> 64 bytes from 79.110.194.140: icmp_seq=4 ttl=64 time=0.283 ms >> 64 bytes from 79.110.194.140: icmp_seq=5 ttl=64 time=0.322 ms >> 64 bytes from 79.110.194.140: icmp_seq=6 ttl=64 time=0.250 ms >> ^C >> --- 79.110.194.140 ping statistics --- >> 7 packets transmitted, 7 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.171/0.257/0.348/0.059 ms >> >> Any Idea what does mean ? > Can you try turning off flowtable to see if that makes any difference? > This is a sysctl and can be adjusted in real-time. > > net.inet.flowtable.enable=0 > > Thanks. > It is already turned off # sysctl net.inet.flowtable.enable net.inet.flowtable.enable: 0 Also trurning it on doesn't make much difference # sysctl net.inet.flowtable.enable=1 net.inet.flowtable.enable: 0 -> 1 # arping -i vlan50 10.6.56.160 ARPING 10.6.56.160 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=0 time=2.147 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=1 time=174.050 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=2 time=221.634 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=3 time=283.422 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=4 time=525.137 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=5 time=663.274 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=6 time=213.200 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=7 time=660.249 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=8 time=589.227 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=9 time=378.279 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=10 time=624.204 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=11 time=158.019 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=12 time=6.169 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=13 time=4.587 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=14 time=2.722 msec 60 bytes from 00:08:a1:9b:47:af (10.6.56.160): index=15 time=82.936 msec -- Pozdrawiam, Bartosz Woronicz, System Adminstrator, Korbank S.A. ul. NabyciÅ„ska 19 53-677 WrocÅ‚aw NIP: 894-26-41-602 tel. 071-723-43-23 fax. 071-723-43-29 From owner-freebsd-stable@FreeBSD.ORG Sat May 14 01:00:07 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2745D1065670 for ; Sat, 14 May 2011 01:00:07 +0000 (UTC) (envelope-from scott-allendorf@uiowa.edu) Received: from newton.physics.uiowa.edu (newton.physics.uiowa.edu [128.255.34.132]) by mx1.freebsd.org (Postfix) with ESMTP id E792C8FC13 for ; Sat, 14 May 2011 01:00:06 +0000 (UTC) Received: from [192.168.1.3] (173-21-38-230.client.mchsi.com [173.21.38.230]) (authenticated bits=0) by newton.physics.uiowa.edu (8.14.4/8.14.4) with ESMTP id p4E0cxvC060023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 19:39:02 -0500 (CDT) (envelope-from scott-allendorf@uiowa.edu) Message-ID: <4DCDCF1B.3060300@uiowa.edu> Date: Fri, 13 May 2011 19:38:51 -0500 From: Scott Allendorf Organization: The University of Iowa, Department of Physics and Astronomy User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dominic Fandrey , freebsd-stable@FreeBSD.org References: <4DCDAD36.5080007@bsdforen.de> In-Reply-To: <4DCDAD36.5080007@bsdforen.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070202040800040101020109" Cc: Subject: Re: RELENG_8 does not build with CPUTYPE=core2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 May 2011 01:00:07 -0000 This is a cryptographically signed message in MIME format. --------------ms070202040800040101020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dominic Fandrey wrote: > env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch > /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch > make-roken.c:1: error: bad value (core2) for -march= switch > make-roken.c:1: error: bad value (core2) for -mtune= switch > distcc[44991] ERROR: compile make-roken.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > distcc[44988] ERROR: compile /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c on localhost failed > *** Error code 1 > 1 error > *** Error code 2 > 2 errors > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > > # make -VCPUTYPE > nocona > # make -VCFLAGS > -O2 -pipe -march=nocona > > CPUTYPE is set with CPUTYPE?=core2. > I saw this too when updating systems across the compiler update. As near as I can tell, some part of the build is not using the new "core2"-aware compiler built as part of the toolchain and is using the older, installed version instead. Commenting out the CPUTYPE definition allowed my buildworlds to complete successfully. After the resulting system was installed I was then able to restore CPUTYPE to "core2" and 'make buildworld' would succeed (presumably because the base system compiler now understands "-march=core2"). Hope this help... -Scott -- Scott C. Allendorf Email: scott-allendorf@uiowa.edu Senior Systems Administrator Office: 216A Van Allen Hall Department of Physics and Astronomy Voice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479 ICBM: 41 39 43.6 N 91 31 55.1 W --------------ms070202040800040101020109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPljCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFgDCCBGigAwIBAgIQWVEn8k28fdfi ouWr9SdjyTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTAxMjgwMDAwMDBa Fw0xMjAxMjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXNjb3R0LWFsbGVuZG9yZkB1aW93 YS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDCbu4M9Vj0z4oUqB8MeevP mdMcss5owG0rXYzemd6Nej34P0yMqqD2Y+85OPRYG5tNIwF8JX9GQTUzvprPuKlff3RlYOSM XZi4QvOVOjlSwJWIPXTXC4IJVyAXjrcuKG5OL2w4BaVO4J/UwaLb0Sn0BKDSIX4CJ43deyzn I1mS9MtSa6mZBKzGPPrAZXD4zBiGs4NiZ6oVp3QciMPfAcLjCD60i4nmLnbXbgmpm032Qvx8 pwKO/tGKAZ7SRN965q1ib2HsvuaBe3HrwPajNqfLYNdIARX+l/cqcKldGMo78oGEUZBpW1y/ iy5R6U92YPPcltoceCfsXZRWf/j+uVwJAgMBAAGjggIbMIICFzAfBgNVHSMEGDAWgBSJgmd9 xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUV1JKULZvbQSktuIICFAx1aM1rO4wDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzCBpQYDVR0fBIGdMIGa MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMEqgSKBGhkRodHRwOi8vY3JsLmNvbW9kby5uZXQv VVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBsBggrBgEF BQcBAQRgMF4wNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFBQUNs aWVudENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQGA1Ud EQQdMBuBGXNjb3R0LWFsbGVuZG9yZkB1aW93YS5lZHUwDQYJKoZIhvcNAQEFBQADggEBAJuw cZrFtrsmqM4g5FdW9hhF/wF6iebwX0FIWGDXps10pG0+xiCN7N9gq83K/oDaJ61OsfyaBfU8 vsT/GAQ/v+wHxmKenhe7zidEhDgbccJoYchjXNGLVudUooUgBDNwgaHTjah7zIFcK8ccqIRP eYb3grxkVgU88jYz/dWvQuSSDMVjr21H8zXFBEeamURar4GKhH4Stpcznjl+Y5Uppeq33jpp A9q/UJCHTaPMLmbSOQYlkyV7Kof0YrKhxa2x0CqbuMcI2l1BMqbFDurcqCS0G6Go9EV/oIjW 46igxrOnIbiKynEG4Ch91FWg4lSXPiebL1Eq0fYW6UGH//Ia8xowggWAMIIEaKADAgECAhBZ USfyTbx91+Ki5av1J2PJMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDEy ODAwMDAwMFoXDTEyMDEyODIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZc2NvdHQtYWxsZW5k b3JmQHVpb3dhLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJu7gz1WPTP ihSoHwx568+Z0xyyzmjAbStdjN6Z3o16Pfg/TIyqoPZj7zk49Fgbm00jAXwlf0ZBNTO+ms+4 qV9/dGVg5IxdmLhC85U6OVLAlYg9dNcLgglXIBeOty4obk4vbDgFpU7gn9TBotvRKfQEoNIh fgInjd17LOcjWZL0y1JrqZkErMY8+sBlcPjMGIazg2JnqhWndByIw98BwuMIPrSLieYudtdu CambTfZC/HynAo7+0YoBntJE33rmrWJvYey+5oF7cevA9qM2p8tg10gBFf6X9ypwqV0Yyjvy gYRRkGlbXL+LLlHpT3Zg89yW2hx4J+xdlFZ/+P65XAkCAwEAAaOCAhswggIXMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRXUkpQtm9tBKS24ggIUDHVozWs 7jAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJAYDVR0RBB0wG4EZc2NvdHQtYWxsZW5kb3JmQHVpb3dhLmVkdTANBgkqhkiG9w0BAQUF AAOCAQEAm7BxmsW2uyaoziDkV1b2GEX/AXqJ5vBfQUhYYNemzXSkbT7GII3s32Crzcr+gNon rU6x/JoF9Ty+xP8YBD+/7AfGYp6eF7vOJ0SEOBtxwmhhyGNc0YtW51SihSAEM3CBodONqHvM gVwrxxyohE95hveCvGRWBTzyNjP91a9C5JIMxWOvbUfzNcUER5qZRFqvgYqEfhK2lzOeOX5j lSml6rfeOmkD2r9QkIdNo8wuZtI5BiWTJXsqh/RisqHFrbHQKpu4xwjaXUEypsUO6tyoJLQb oaj0RX+giNbjqKDGs6chuIrKcQbgKH3UVaDiVJc+J5svUSrR9hbpQYf/8hrzGjGCBF0wggRZ AgEBMIHDMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFr ZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6 Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsAhBZUSfyTbx91+Ki5av1J2PJMAkGBSsOAwIaBQCgggJu MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxNDAwMzg1 MVowIwYJKoZIhvcNAQkEMRYEFKH39DqVo34qo9WMdZD4TX/xb8LHMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQsw CQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYD VQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRy dXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24g YW5kIEVtYWlsAhBZUSfyTbx91+Ki5av1J2PJMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwG A1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0 cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBFbWFpbAIQWVEn8k28fdfiouWr9SdjyTANBgkqhkiG9w0BAQEFAASCAQC00EfWuo91 kxa+6XyDBVmWu6bbyj7lp4a5fIN0u0gZlNqXtC+194txmjS2UX6UkalwObVr0Id4k78ImjVb iB5Ubh99Txc/Nkeb+TsKoyEuKB3Fw7jehQB+RS/DEIfo6QKuPyiN/MDktpd577Sm2B7Te3dO BjRa9anmsVXQnQjUDgHwV2ViSS1HA/AnYquYw/LO7G35/PHQMrysOUgfxK4g1NNl+yvgKLso hXD2Jjooxxsg7gp7YBUEQR5POlGRhXbgEWivYra85w4XEL4PKWKvqEaTzFKVZUOKo7koG3w0 rxqHjY5uI793c7MgvOoAn2v3cBQroVmzuzGTZOa6PGO9AAAAAAAA --------------ms070202040800040101020109-- From owner-freebsd-stable@FreeBSD.ORG Sat May 14 11:24:13 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C82D3106566C for ; Sat, 14 May 2011 11:24:13 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 898528FC13 for ; Sat, 14 May 2011 11:24:12 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-161-31.rz.uni-karlsruhe.de [141.3.161.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id E31287E961; Sat, 14 May 2011 13:24:11 +0200 (CEST) Message-ID: <4DCE665A.50907@bsdforen.de> Date: Sat, 14 May 2011 13:24:10 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.16) Gecko/20101212 Thunderbird/3.0.11 MIME-Version: 1.0 To: Scott Allendorf References: <4DCDAD36.5080007@bsdforen.de> <4DCDCF1B.3060300@uiowa.edu> In-Reply-To: <4DCDCF1B.3060300@uiowa.edu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: RELENG_8 does not build with CPUTYPE=core2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 May 2011 11:24:13 -0000 On 14/05/2011 02:38, Scott Allendorf wrote: > Dominic Fandrey wrote: >> env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 >> -pipe -march=core2 -DHAVE_CONFIG_H >> -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c >> make-roken.c >> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >> error: bad value (core2) for -march= switch >> /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: >> error: bad value (core2) for -mtune= switch >> make-roken.c:1: error: bad value (core2) for -march= switch >> make-roken.c:1: error: bad value (core2) for -mtune= switch >> distcc[44991] ERROR: compile make-roken.c on localhost failed >> *** Error code 1 >> ... > > I saw this too when updating systems across the compiler update. As > near as I can tell, some part of the build is not using the new > "core2"-aware compiler built as part of the toolchain and is using the > older, installed version instead. > > Commenting out the CPUTYPE definition allowed my buildworlds to complete > successfully. ... Thanks for the workaround! It still worries me, that there's a bug in the bootstrapping. You never know what kind of trouble comes from that kind of thing. I hope this is going to be fixed. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sat May 14 15:06:48 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9D11065670 for ; Sat, 14 May 2011 15:06:48 +0000 (UTC) (envelope-from freebsd-stable@chef-ingenieur.de) Received: from mail.webmatic.de (mail.webmatic.de [212.78.101.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD008FC12 for ; Sat, 14 May 2011 15:06:48 +0000 (UTC) Received: from [127.0.0.1] (p54B7FAAD.dip.t-dialin.net [84.183.250.173]) by mail.webmatic.de (Postfix) with ESMTPSA id A99A26D4A6; Sat, 14 May 2011 17:06:46 +0200 (CEST) Message-ID: <4DCE9A88.2030500@chef-ingenieur.de> Date: Sat, 14 May 2011 17:06:48 +0200 From: Thomas Krause User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Daniel O'Connor , freebsd-stable References: <4DCC5358.4050705@chef-ingenieur.de> <34458417-0D7A-493E-8C52-F3095000D764@gsoft.com.au> In-Reply-To: <34458417-0D7A-493E-8C52-F3095000D764@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: setting usb disc to da1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 14 May 2011 15:06:48 -0000 I've plugged a USB disc to a FreeBSD System and it's dedected as da1: >> da1: Fixed Direct Access SCSI-2 device >> >> But when rebooting the machine, it becomes da0 and I cannot boot the >> system. What's the trick to set the USB disc to da1 permanent? > You can, to some degree, wire the device with.. > hint.scbus.0.at="umass-sim0" > hint.da0.at="scbus0" > > However I would recommend using GPT IDs, UFS IDs or GEOM labels in fstab so the underlying device name is irrelevant. > > Daniel, I'm not sure with /boot/devices.hint. Could you give me a hint, how to set # camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) at scbus1 target 0 lun 0 (pass1,da1) the Samsung G3 permanently to da1 (the AMCC must be da0). (This is a productive system and I don't want to do tests ...) Thank you! Regards, Thomas.